Re: gtk function with argv

[Eric Cashon via gtk-app-devel-list]

 
Hi Ruben,

I think what you are looking for is a C variadic function. Something that works 
like g_object_set() with a Null terminated list of arguments.

Using dynamic glib containers might be a better choice. It is simpler to just 
pass a single pointer with your user_data to functions which is how GTK 
callbacks are setup. Also, I have read that variadics have some troubles and 
don't always work well if you call the functions from another language. 

Eric


//gcc -Wall ptr_array1.c -o ptr_array1 `pkg-config --cflags --libs glib-2.0`
 
#include
#include

static void vChart_Init1(gchar *widget, GPtrArray *series)
  {
g_print("Init1\n");
gint i=0;
gint length=series->len;
for(i=0;i

gtk function with argv

[Rúben Rodrigues]

Why guys,

I have a doubt that is more about C language that gtk+ but it's to apply 
to gtk+.

I have this function:

GtkChart vChart_Init(GtkWidget *widget, GtkSeries *series)

My doubt is: How can i use function like this: 
vChart_Init(GTK_WIDGET(widget), "Series A", "Series B", "Series C");

I need that second parameter is dynamic  and is a string (that contains 
the name of serie)

THanks

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[Nicola Fontana]

Il Mon, 9 May 2016 09:35:06 -0500 Edscott Wilson 
 scrisse:

> ...
> Many thanks to all those who have responded. With all the advice I'm now
> going to try cross compiling 64 bit GTK application for windows using all
> the tools available in ArchLinux and the AUR (which is quite a lot). Only
> if that fails I'll go back to Msys-Mingw64.

If you are using Archlinux you can also try my toolchain [1]. I am
maintaining it in sync with the fedora one. I've even been able to
cross compile gobject-introspection so the whole toolchain is
built with introspection enabled, although honestly I did not test
it that much.

[1] https://github.com/ntd/aur-fedora-mingw

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[Edscott Wilson]

2016-05-08 13:41 GMT-05:00 tito-wolit :


> If you don't like the advice being given by the experts on this list
> why you are still hanging around here?
>
>
Because he's a troll who gets a dopamine hit when someone answers. But I
must admit that he is polite and entertaining --although a bit childish---
and brought out good responses from those who have offered help.

Many thanks to all those who have responded. With all the advice I'm now
going to try cross compiling 64 bit GTK application for windows using all
the tools available in ArchLinux and the AUR (which is quite a lot). Only
if that fails I'll go back to Msys-Mingw64.




-- 

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: argv revisited

[Daniel Kasak]

On Mon, May 9, 2016 at 2:24 AM, Andrew Robinson  wrote:

> Because you are entertaining.

Ditto. In fact every single one of your posts has had multiple dummy
spits. Your particular balance of begging for more help vs pouring
scorn on those who try to help is unique. Where else do you post? I
must subscribe there too ...

Dan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[tito-wolit]

On 05/08/2016 05:45 PM, Andrew Robinson wrote:

Like most people in this forum, you don't listen:

 My issue isn't with GTK2, it is with GTK3.
 I know Fedora has precompiled GTK2 binaries but doesn't help me with GTK3.

My original issue is clearly stated as using the following environment:

 32-bit version of GTK+ v3.18 on a 64-bit Windows7 OS

If you don't have at least one of those two things in your environment or
advice, you aren't trying to help, just like the rest of the people in this
forum aren't.

I like reminiscing about the good ol' times, so let's reminisce over the
wonderful advice I received from this group regarding the use of argc and argv
at the beginning of this thread:

 There should be no difference between using 32-bit GTK libs and 64-bit GTK
libs
 You are using 32-bit code, which is buggy/inferior to 64-bit code
 argc and argv are not processed by your app but by your compiler's runtime
 argc and argv are on the stack, unless you program in assembly
 GTK+ doesn't provide argc and argv until you call gtk_init()
 Calling convention is determined by the compiler, not the OS
 argc and argv work for me on Linux with a Linux app using GTK2

All of which is pure, make believe nonsense (expect that last one, but which
is irrelevant to the issue). The people in this forum were offering me links
on the ELF format and on how the Linux loader works -- not a single one of
these links was applicable to the issue, and when they commented on the info
in those links, they made it obvious they didn't read through the entire
articles they linked to, and what little they read, they didn't even
understand. It was so laughable, I kept every single email I sent/received
from this thread so I can document this for others to see: This is the kind of
support/advice you can expect from the "experts" in the gtk-app-devel forum.


If you don't like the advice being given by the experts on this list
why you are still hanging around here?


Meanwhile, in the real world, turns out the issue I was seeing was that
Windows doesn't provide argc and argv, it provides hWnd, uMsg, wParam, and
lParam. There is no argc and argv in Windows (unless you run a MsDOS program)


This is not true on Windows 7 64 bit I have GUI programs with GTK2
where argc and argv are provided as expected. (Yes I have only one of
two things in my environment).


so all the example code they give for using GTK on Windows is flawed.  When I
realized this, I used yet another function in GTK that doesn't work. I was
frustrated but seeing as I could use the laugh, I thought I would post that
issue to this forum and see if anything would change. It didn't.

So my question to this list is: do your mommys and daddys know you are on
their computer, posting to a forum as a make believe expert?


I'm sure insulting the people on the list will give a lot
more technical advice on how to solve your problem.


I spot one difference in that I call g_file_new_for_path to turn the
filename string into a GFile. Maybe this is relevant, maybe not, I can't
tell.


You know what, that might true. If it works, thank you. If it doesn't.



If it doesn't thank you the same for the time and the effort in trying 
to help you?


Ciao,
Tito
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[Chris Moller]

Welcome to my Trash folder; you'll be directed there by the filter I 
just put in place.  Watch out for the falling banana peels.


On 05/08/16 12:24, Andrew Robinson wrote:

Because you are entertaining.

On 5/8/2016 at 9:09 AM, Chris Moller  wrote:

If you don't like the people on this forum, and you don't like the
answers you've gotten, why are you still here?


On 05/08/16 11:45, Andrew Robinson wrote:

Like most people in this forum, you don't listen:

  My issue isn't with GTK2, it is with GTK3.
  I know Fedora has precompiled GTK2 binaries but doesn't help me with

GTK3.



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv revisited

[Andrew Robinson]

Because you are entertaining.

On 5/8/2016 at 9:09 AM, Chris Moller  wrote:
>If you don't like the people on this forum, and you don't like the 
>answers you've gotten, why are you still here?
>
>
>On 05/08/16 11:45, Andrew Robinson wrote:
>> Like most people in this forum, you don't listen:
>>
>>  My issue isn't with GTK2, it is with GTK3.
>>  I know Fedora has precompiled GTK2 binaries but doesn't help me with
GTK3.
>>
>>
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[Chris Moller]

If you don't like the people on this forum, and you don't like the 
answers you've gotten, why are you still here?



On 05/08/16 11:45, Andrew Robinson wrote:

Like most people in this forum, you don't listen:

 My issue isn't with GTK2, it is with GTK3.
 I know Fedora has precompiled GTK2 binaries but doesn't help me with GTK3.




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[6]: argv revisited

[Andrew Robinson]

Like most people in this forum, you don't listen:

My issue isn't with GTK2, it is with GTK3.
I know Fedora has precompiled GTK2 binaries but doesn't help me with GTK3.

My original issue is clearly stated as using the following environment:

32-bit version of GTK+ v3.18 on a 64-bit Windows7 OS

If you don't have at least one of those two things in your environment or
advice, you aren't trying to help, just like the rest of the people in this
forum aren't.

I like reminiscing about the good ol' times, so let's reminisce over the
wonderful advice I received from this group regarding the use of argc and argv
at the beginning of this thread:

There should be no difference between using 32-bit GTK libs and 64-bit GTK
libs
You are using 32-bit code, which is buggy/inferior to 64-bit code
argc and argv are not processed by your app but by your compiler's runtime
argc and argv are on the stack, unless you program in assembly
GTK+ doesn't provide argc and argv until you call gtk_init()
Calling convention is determined by the compiler, not the OS
argc and argv work for me on Linux with a Linux app using GTK2

All of which is pure, make believe nonsense (expect that last one, but which
is irrelevant to the issue). The people in this forum were offering me links
on the ELF format and on how the Linux loader works -- not a single one of
these links was applicable to the issue, and when they commented on the info
in those links, they made it obvious they didn't read through the entire
articles they linked to, and what little they read, they didn't even
understand. It was so laughable, I kept every single email I sent/received
from this thread so I can document this for others to see: This is the kind of
support/advice you can expect from the "experts" in the gtk-app-devel forum.

Meanwhile, in the real world, turns out the issue I was seeing was that
Windows doesn't provide argc and argv, it provides hWnd, uMsg, wParam, and
lParam. There is no argc and argv in Windows (unless you run a MsDOS program)
so all the example code they give for using GTK on Windows is flawed. When I
realized this, I used yet another function in GTK that doesn't work. I was
frustrated but seeing as I could use the laugh, I thought I would post that
issue to this forum and see if anything would change. It didn't.

So my question to this list is: do your mommys and daddys know you are on
their computer, posting to a forum as a make believe expert?

>I spot one difference in that I call g_file_new_for_path to turn the 
>filename string into a GFile. Maybe this is relevant, maybe not, I can't 
>tell.

You know what, that might true. If it works, thank you. If it doesn't.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[5]: argv revisited

[Lucas Levrel]

(Approximate repost of a message I sent with a wrong From address; looks 
like the mods haven't delivered nor rejected it, hence the repost, but I 
don't have the original message so this will break the thread. Sorry for 
that.)


Andrew Robinson:
So is that how to actually get help on the GTK Dev forums? Beg for help? 
I thought posting a problem would be enough, but okay then ...


In my frame, saying please is not begging. I found your "Show me your 
code" a bit too imperative. Also, the etiquette in MLs is different from 
that in StackExchange. But well, I'm not a native English speaker.



Your source code doesn't work, so let's compare environments. I have:

1) Windows7
2) Win32 version of GTK+, version 3.18
3) The pathname that doesn't work contains the UTF-16 character, U+2026
(ellipsis)


Again, I cross-compiled in Linux for Win32, linking the last GTK2 (2.24.X 
I think) statically. Executable tested in Win XP.


NOTE: The UTF-8 version of U+2026 is 0E280A6h, but Windows doesn't 
support UTF-8.


I don't know how the infinity symbol I used is coded in Windows. I 
inserted it with the help of the character map tool. It displays properly 
in the file explorer.



Here is where the problem occurs (simplified):

  oSrcFilename = gtk_file_chooser_get_filename(oBtnSrcFile);
  g_file_get_contents(oSrcFilename,*ptrSrcCode,*lenFile,0);


I looked at your code and could see nothing different about it in this 
regards


I spot one difference in that I call g_file_new_for_path to turn the 
filename string into a GFile. Maybe this is relevant, maybe not, I can't 
tell.


HTH

--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[tito-wolit]

On 05/06/2016 09:27 PM, Andrew Robinson wrote:

I'm sorry for that. One of my biggest flaws in human relations is detecting
when someone is being ironic, sarcastic, or is just joking around, and when
they are being serious.

I would think both list would be interested in knowing what is required of
their projects by the lawyers at GTK. This is an extremely discouraging thing
to consider in whether to use GTK or something else. I think if open source
wanted to be truly open, they would get rid of the lawyers and the lawyer
talk. It is either free to use without fine print, or it is not.


Rights are always coupled with obligations.
You want to take only the sweet without the bitter spots in life?

Ciao,
Tito
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[5]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

I'm sorry for that. One of my biggest flaws in human relations is detecting
when someone is being ironic, sarcastic, or is just joking around, and when
they are being serious.

I would think both list would be interested in knowing what is required of
their projects by the lawyers at GTK. This is an extremely discouraging thing
to consider in whether to use GTK or something else. I think if open source
wanted to be truly open, they would get rid of the lawyers and the lawyer
talk. It is either free to use without fine print, or it is not.

On 5/6/2016 at 10:01 AM, Lucas Levrel  wrote:
>OK. I understand your mileage is very different from mine. Remember, I'm 
>just a GTK user (this is GTK *app devel* list, not GTK devel list).
>
>Just a few remarks before I answer your other mail:
>
>Le 5 mai 2016, Andrew Robinson a écrit :
>> 1) Because there are between 40 to 120Mb worth of libraries or their
>> dependencies I would have to post on my website.
>
>It's not clear to me whether one has to distribute GTK if it's linked 
>statically, because one doesn't distribute the libs themselves. But I'm no 
>lawyer and didn't investigate the question (I don't distribute publicly my 
>small app).
>
>> 3) If I do compile GTK myself, I will have to maintain all that huge amount
of
>> source code on my website, per the licensing agreement.
>
>I use GTK2, it's stable :-)
>
 I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,
>>> (not Msys2, MXE will do all the needed download)
 and provide make their own copy of GTK+ for Win32. Wouldn't that be easy
 and fun?
>>>
>>> All the more as they would have to install Linux beforehand!
>>
>> That attitude is one of the reasons I chose to abandon Windows ...
>
>You didn't understand me: I was continuing on your irony, of course having 
>them install Linux would be even more uneasy and unfun!
>
>-- 
>Lucas Levrel
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/06/2016 07:01 PM, Lucas Levrel wrote:
> Le 5 mai 2016, Andrew Robinson a écrit :
>> 1) Because there are between 40 to 120Mb worth of libraries or their
>> dependencies I would have to post on my website.
> 
> It's not clear to me whether one has to distribute GTK if it's linked
> statically, because one doesn't distribute the libs themselves. But I'm
> no lawyer and didn't investigate the question (I don't distribute
> publicly my small app).
> 

I'm not a lawyer, but:

Part of the idea of the LGPL is, as I understand it, that the user can
relink with a modified version of the library. Imagine party A gives an
LGPL library only to party B who then distributes an app linking with
the library to C. If B refuses C's request for the library's source
code, C has no way to link to a modified version of the library.
Therefore I believe you have to distribute the source code of the
library version you used at least upon request.

In particular, when linking statically, you also have to provide
linkable object files or source code for _your_ application.

I.e. you have to be able to provide source code for all LGPL portions no
matter if you use MSYS2, MXE, Fedora packages or compile the
dependencies yourself. There's no way around it.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[4]: Compiling for Windows [Was: argv revisited]

[Lucas Levrel]

OK. I understand your mileage is very different from mine. Remember, I'm 
just a GTK user (this is GTK *app devel* list, not GTK devel list).


Just a few remarks before I answer your other mail:

Le 5 mai 2016, Andrew Robinson a écrit :

1) Because there are between 40 to 120Mb worth of libraries or their
dependencies I would have to post on my website.


It's not clear to me whether one has to distribute GTK if it's linked 
statically, because one doesn't distribute the libs themselves. But I'm no 
lawyer and didn't investigate the question (I don't distribute publicly my 
small app).



3) If I do compile GTK myself, I will have to maintain all that huge amount of
source code on my website, per the licensing agreement.


I use GTK2, it's stable :-)


I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,

(not Msys2, MXE will do all the needed download)

and provide make their own copy of GTK+ for Win32. Wouldn't that be easy
and fun?


All the more as they would have to install Linux beforehand!


That attitude is one of the reasons I chose to abandon Windows ...


You didn't understand me: I was continuing on your irony, of course having 
them install Linux would be even more uneasy and unfun!


--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[6]: argv revisited

[Andrew Robinson]

Thank you Allin for your wonderful and knowledgeable technical advice,
everything is working now as it should. You are the best. Just ask me anytime
to be a reference for you, and I will do my best, just as you have done for
me.

On 5/5/2016 at 12:58 PM, Allin Cottrell  wrote:
>On Thu, 5 May 2016, Andrew Robinson wrote:
>
>> So is that how to actually get help on the GTK Dev forums? Beg for help?
>
>(This in response to Lucas Levrel's suggesting a "please" following 
>the imperative "show me your source code.")
>
>LL was merely requesting a little civility. In many years of reading 
>this list I don't think I've ever come across such a boorish and 
>pig-headed poster.
>
>-- 
>Allin Cottrell
>Department of Economics
>Wake Forest University

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[4]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

That's weird! I've never heard of a Linux distribution that also has
precompiled packages for Win32. I will check it out at my earliest
convenience. You mentioned GTK2, but I am hoping it also has (or has switched
over to) GTK3.
 I hope this isn't too good to be true. I will be too busy to check for the
next few hours.

Andrew


On 5/5/2016 at 11:42 AM, Dov Grobgeld  wrote: 
Note that if you are using fedora (and possibly other Linux distributions) it
comes with lots of win32 packages precompiled. E.g. all you need to do to get
gtk2 and its dependencies is to do:


   dnf install mingw32-gtk2


You can then compile your gtk programs for windows through cross compilation
and generate a windows install file for your application through nsis. All
your grandma then needs to do on windows is to run the installer.


I have been doing this for several applications for several years, and the
process is so smooth and reliable that I only do the testing on Linux before
compiling and distributing for Windows.


Regards,

Dov



On Thu, May 5, 2016 at 8:30 PM, Andrew Robinson  wrote:

On 5/5/2016 at 10:23 AM, Lucas Levrel  wrote:
>Le 5 mai 2016, Andrew Robinson a écrit :
>
>> So if I don't want to make my on copy of the GTK+ libraries,
>
>Why wouldn't you want to build your static libs for future inclusion in
>your software? Where "build" is for "let the Makefile of MXE do all the
>work needed to build".

1) Because there are between 40 to 120Mb worth of libraries or their
dependencies I would have to post on my website.

2) You could get under 40Mb, if you are only going to use one function from
one or two libraries, and you don't want the user to have any features like
skinning.

(I am going to reference Allegro here, only just for comparison sake)

3) If I do compile GTK myself, I will have to maintain all that huge amount of
source code on my website, per the licensing agreement. If I use Allegro, I do
nothing else unless I customize the source code, only then will I have to post
source code.

4) Furthermore, I would have to answer questions on why users couldn't compile
the source code for making GTK+ for Win32 on Windows7 (or 8 or 10 or XP),
something the GTK community has been unwilling to do itself. With Allegro, I
literally simply download DevC++ for Windows7, select DevPak to download
Allegro, compile, and you are done! Compare that to GTK: Downgrade your Visual
Studio to version 2013, install GIT if you don't already have it, clone the
GTK repository, install a minimalistic Linux environment like MSYS2, install
MinGW, spend a few days trying to get to know these things, try compiling a
Win32 version of GTK+ using half-arse written instructions, if that doesn't
work try installing and using MXE, if that doesn't work follow the terse
instructions posted on an almost hidden website at Nachos blog, if you are
still having problems, go to the GTK developer forum where they won't give you
any help, ... etc

The setting up the development environment for GTK relies on lots and lots of
esoteric command line parameters, and it seems like no two computers use the
same exact parameters. Developing on Windows for Windows is super easy and
user friendly, whereas developing on Windows for GTK is not. Windows forums
are not really friendly either, but they are much more friendly than the Linux
forums are, and anyways I can avoid the forums because there is so much code
and advice posted on the Internet for Windows, that it is hard not to find
what you are looking for, no matter how esoteric your needs are.

>> I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,
>(not Msys2, MXE will do all the needed download)
>> and provide make their own copy of GTK+ for Win32. Wouldn't that be easy
>> and fun?
>
>All the more as they would have to install Linux beforehand!

That attitude is one of the reasons I chose to abandon Windows ... you sound
just like Satya Nadella trying to pawn Windows 10 off to the world. If Linux
was so great, people would already be using it in droves, instead of barely
mustering 3% of the entire market.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[5]: argv revisited

[Allin Cottrell]

On Thu, 5 May 2016, Andrew Robinson wrote:


So is that how to actually get help on the GTK Dev forums? Beg for help?


(This in response to Lucas Levrel's suggesting a "please" following 
the imperative "show me your source code.")


LL was merely requesting a little civility. In many years of reading 
this list I don't think I've ever come across such a boorish and 
pig-headed poster.


--
Allin Cottrell
Department of Economics
Wake Forest University
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[5]: argv revisited

[Andrew Robinson]

So is that how to actually get help on the GTK Dev forums? Beg for help? I
thought posting a problem would be enough, but okay then ... pretty please
help me ...

Your source code doesn't work, so let's compare environments. I have:

1) Windows7
2) Win32 version of GTK+, version 3.18
3) The pathname that doesn't work contains the UTF-16 character, U+2026
(ellipsis)

NOTE: The UTF-8 version of U+2026 is 0E280A6h, but Windows doesn't support
UTF-8.

Here is where the problem occurs (simplified):

  oSrcFilename = gtk_file_chooser_get_filename(oBtnSrcFile);
  g_file_get_contents(oSrcFilename,*ptrSrcCode,*lenFile,0);
 
gtk_message_dialog_format_secondary_markup(oMsgSuccess,*szPrintfLong,lenFile);
  gtk_dialog_run(oMsgSuccess);
  gtk_widget_hide(oMsgSuccess)
  g_free(ptrSrcCode)

What I am doing is just printing out the size of any file I choose from the
file chooser of the application. It works perfectly for any file in any
directory other than the one containing the ellipsis. I looked at your code
and could see nothing different about it in this regards, so I question
whether you are actually trying this in the same or similar environment I am.

On 5/5/2016 at 10:16 AM, Lucas Levrel  wrote:
>Le 5 mai 2016, Andrew Robinson a écrit :
>>> I've just tested a filename containing spaces and U+221E (infinity
>>> symbol), writing and reading both work.
>> So you verified that in Windows using the Win32 version of GTK+? Show me
your
>> source code.
>
>"Please."
>
>Cross-compiled on Linux with i686-pc-mingw32-gcc from mingw-cross-env-2.21 
>(previous name of MXE), GTK2 statically linked. I think I already posted 
>the code snippet for reading. Here for writing:
>-:-:-:-
>   GtkWidget *dialog;
>   dialog = gtk_file_chooser_dialog_new
> ("Title", GTK_WINDOW(gtkwin),
>  GTK_FILE_CHOOSER_ACTION_SAVE, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
>  GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, NULL);
>   gtk_file_chooser_set_do_overwrite_confirmation
> (GTK_FILE_CHOOSER (dialog), TRUE);
>   /* gtk_file_chooser_set_current_folder
>  (GTK_FILE_CHOOSER (dialog), default_folder_for_saving); */
>   gtk_file_chooser_set_current_name
> (GTK_FILE_CHOOSER (dialog), "foo.bar");
>   if(gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT){
> char *filename;
> filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
> GFile *outfile=g_file_new_for_path(filename);
> GFileOutputStream *FOstream=
>   g_file_replace(outfile, NULL, FALSE, G_FILE_CREATE_NONE, NULL,NULL);
> assert(FOstream);
> GDataOutputStream *DOstream=
>   g_data_output_stream_new(G_OUTPUT_STREAM(FOstream));
> assert(DOstream);
> gboolean res=
>   g_data_output_stream_put_string(DOstream,some_string,NULL,NULL);
> assert(res);
> g_object_unref(DOstream);
> g_object_unref(FOstream);
> g_object_unref(outfile);
> g_free(filename);
>   }
>   gtk_widget_destroy(dialog);
>-:-:-:-
>
>
>
>-- 
>Lucas Levrel
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[4]: Compiling for Windows [Was: argv revisited]

[Dov Grobgeld]

Note that if you are using fedora (and possibly other Linux distributions)
it comes with lots of win32 packages precompiled. E.g. all you need to do
to get gtk2 and its dependencies is to do:

   dnf install mingw32-gtk2

You can then compile your gtk programs for windows through cross
compilation and generate a windows install file for your application
through nsis. All your grandma then needs to do on windows is to run the
installer.

I have been doing this for several applications for several years, and the
process is so smooth and reliable that I only do the testing on Linux
before compiling and distributing for Windows.

Regards,
Dov

On Thu, May 5, 2016 at 8:30 PM, Andrew Robinson  wrote:

> On 5/5/2016 at 10:23 AM, Lucas Levrel  wrote:
> >Le 5 mai 2016, Andrew Robinson a écrit :
> >
> >> So if I don't want to make my on copy of the GTK+ libraries,
> >
> >Why wouldn't you want to build your static libs for future inclusion in
> >your software? Where "build" is for "let the Makefile of MXE do all the
> >work needed to build".
>
> 1) Because there are between 40 to 120Mb worth of libraries or their
> dependencies I would have to post on my website.
>
> 2) You could get under 40Mb, if you are only going to use one function from
> one or two libraries, and you don't want the user to have any features like
> skinning.
>
> (I am going to reference Allegro here, only just for comparison sake)
>
> 3) If I do compile GTK myself, I will have to maintain all that huge
> amount of
> source code on my website, per the licensing agreement. If I use Allegro,
> I do
> nothing else unless I customize the source code, only then will I have to
> post
> source code.
>
> 4) Furthermore, I would have to answer questions on why users couldn't
> compile
> the source code for making GTK+ for Win32 on Windows7 (or 8 or 10 or XP),
> something the GTK community has been unwilling to do itself. With Allegro,
> I
> literally simply download DevC++ for Windows7, select DevPak to download
> Allegro, compile, and you are done! Compare that to GTK: Downgrade your
> Visual
> Studio to version 2013, install GIT if you don't already have it, clone the
> GTK repository, install a minimalistic Linux environment like MSYS2,
> install
> MinGW, spend a few days trying to get to know these things, try compiling a
> Win32 version of GTK+ using half-arse written instructions, if that doesn't
> work try installing and using MXE, if that doesn't work follow the terse
> instructions posted on an almost hidden website at Nachos blog, if you are
> still having problems, go to the GTK developer forum where they won't give
> you
> any help, ... etc
>
> The setting up the development environment for GTK relies on lots and lots
> of
> esoteric command line parameters, and it seems like no two computers use
> the
> same exact parameters. Developing on Windows for Windows is super easy and
> user friendly, whereas developing on Windows for GTK is not. Windows forums
> are not really friendly either, but they are much more friendly than the
> Linux
> forums are, and anyways I can avoid the forums because there is so much
> code
> and advice posted on the Internet for Windows, that it is hard not to find
> what you are looking for, no matter how esoteric your needs are.
>
> >> I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,
> >(not Msys2, MXE will do all the needed download)
> >> and provide make their own copy of GTK+ for Win32. Wouldn't that be easy
> >> and fun?
> >
> >All the more as they would have to install Linux beforehand!
>
> That attitude is one of the reasons I chose to abandon Windows ... you
> sound
> just like Satya Nadella trying to pawn Windows 10 off to the world. If
> Linux
> was so great, people would already be using it in droves, instead of barely
> mustering 3% of the entire market.
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[4]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

On 5/5/2016 at 10:23 AM, Lucas Levrel  wrote:
>Le 5 mai 2016, Andrew Robinson a écrit :
>
>> So if I don't want to make my on copy of the GTK+ libraries,
>
>Why wouldn't you want to build your static libs for future inclusion in 
>your software? Where "build" is for "let the Makefile of MXE do all the 
>work needed to build".

1) Because there are between 40 to 120Mb worth of libraries or their
dependencies I would have to post on my website.

2) You could get under 40Mb, if you are only going to use one function from
one or two libraries, and you don't want the user to have any features like
skinning.

(I am going to reference Allegro here, only just for comparison sake)

3) If I do compile GTK myself, I will have to maintain all that huge amount of
source code on my website, per the licensing agreement. If I use Allegro, I do
nothing else unless I customize the source code, only then will I have to post
source code.

4) Furthermore, I would have to answer questions on why users couldn't compile
the source code for making GTK+ for Win32 on Windows7 (or 8 or 10 or XP),
something the GTK community has been unwilling to do itself. With Allegro, I
literally simply download DevC++ for Windows7, select DevPak to download
Allegro, compile, and you are done! Compare that to GTK: Downgrade your Visual
Studio to version 2013, install GIT if you don't already have it, clone the
GTK repository, install a minimalistic Linux environment like MSYS2, install
MinGW, spend a few days trying to get to know these things, try compiling a
Win32 version of GTK+ using half-arse written instructions, if that doesn't
work try installing and using MXE, if that doesn't work follow the terse
instructions posted on an almost hidden website at Nachos blog, if you are
still having problems, go to the GTK developer forum where they won't give you
any help, ... etc

The setting up the development environment for GTK relies on lots and lots of
esoteric command line parameters, and it seems like no two computers use the
same exact parameters. Developing on Windows for Windows is super easy and
user friendly, whereas developing on Windows for GTK is not. Windows forums
are not really friendly either, but they are much more friendly than the Linux
forums are, and anyways I can avoid the forums because there is so much code
and advice posted on the Internet for Windows, that it is hard not to find
what you are looking for, no matter how esoteric your needs are.

>> I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,
>(not Msys2, MXE will do all the needed download)
>> and provide make their own copy of GTK+ for Win32. Wouldn't that be easy 
>> and fun?
>
>All the more as they would have to install Linux beforehand!

That attitude is one of the reasons I chose to abandon Windows ... you sound
just like Satya Nadella trying to pawn Windows 10 off to the world. If Linux
was so great, people would already be using it in droves, instead of barely
mustering 3% of the entire market.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[3]: Compiling for Windows [Was: argv revisited]

[Lucas Levrel]

Le 5 mai 2016, Andrew Robinson a écrit :


Actually, MXE isn't a compiler, but a Makefile that compiles a cross compiler.


OK.


So if I don't want to make my on copy of the GTK+ libraries,


Why wouldn't you want to build your static libs for future inclusion in 
your software? Where "build" is for "let the Makefile of MXE do all the 
work needed to build".



I must tell grandma and grandpa to get their own copy of MSYS2 and MXE,

(not Msys2, MXE will do all the needed download)
and provide make their own copy of GTK+ for Win32. Wouldn't that be easy 
and fun?


All the more as they would have to install Linux beforehand!

--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[4]: argv revisited

[Lucas Levrel]

Le 5 mai 2016, Andrew Robinson a écrit :

I've just tested a filename containing spaces and U+221E (infinity
symbol), writing and reading both work.

So you verified that in Windows using the Win32 version of GTK+? Show me your
source code.


"Please."

Cross-compiled on Linux with i686-pc-mingw32-gcc from mingw-cross-env-2.21 
(previous name of MXE), GTK2 statically linked. I think I already posted 
the code snippet for reading. Here for writing:

-:-:-:-
  GtkWidget *dialog;
  dialog = gtk_file_chooser_dialog_new
("Title", GTK_WINDOW(gtkwin),
 GTK_FILE_CHOOSER_ACTION_SAVE, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
 GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, NULL);
  gtk_file_chooser_set_do_overwrite_confirmation
(GTK_FILE_CHOOSER (dialog), TRUE);
  /* gtk_file_chooser_set_current_folder
 (GTK_FILE_CHOOSER (dialog), default_folder_for_saving); */
  gtk_file_chooser_set_current_name
(GTK_FILE_CHOOSER (dialog), "foo.bar");
  if(gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT){
char *filename;
filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
GFile *outfile=g_file_new_for_path(filename);
GFileOutputStream *FOstream=
  g_file_replace(outfile, NULL, FALSE, G_FILE_CREATE_NONE, NULL,NULL);
assert(FOstream);
GDataOutputStream *DOstream=
  g_data_output_stream_new(G_OUTPUT_STREAM(FOstream));
assert(DOstream);
gboolean res=
  g_data_output_stream_put_string(DOstream,some_string,NULL,NULL);
assert(res);
g_object_unref(DOstream);
g_object_unref(FOstream);
g_object_unref(outfile);
g_free(filename);
  }
  gtk_widget_destroy(dialog);
-:-:-:-



--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[4]: argv revisited

[Andrew Robinson]

So you verified that in Windows using the Win32 version of GTK+? Show me your
source code.

On 5/5/2016 at 3:57 AM, Lucas Levrel  wrote:
>Le 3 mai 2016, Andrew Robinson a écrit :
>
>>> I don't think I tried filenames with spaces, but I did test filenames with
>>> accented letters in both Linux and Windows, and it worked (using GTK2).
>>> E.g. for reading a file contents into one big string I have this:
>>
>> I don't know about accented letters, since they are a part of the Windows
>> version of ASCII. Try a real life UNICODE character, such as the one I have
in
>> my path, C:\My.\Images.
>
>Hi,
>
>I've just tested a filename containing spaces and U+221E (infinity 
>symbol), writing and reading both work.
>
>-- 
>Lucas Levrel
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[3]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

Actually, MXE isn't a compiler, but a Makefile that compiles a cross compiler.

So if I don't want to make my on copy of the GTK+ libraries, I must tell
grandma and grandpa to get their own copy of MSYS2 and MXE, and provide make
their own copy of GTK+ for Win32. Wouldn't that be easy and fun?

On 5/5/2016 at 1:04 AM, Lucas Levrel  wrote:
>Le 3 mai 2016, Andrew Robinson a écrit :
>
 Is it really necessary for every Windows application bundle to ship its
 own copy of GTK+?
>>
>>> By default MXE links statically. So you don't have any dll to bundle with
>>> your app. In such circumstances, what does LGPL say? Do you still have to
>>> provide the GTK source code (given that you don't distribute GTK libs)?
>>
>> Well I can't ship MSYS2 and MXE with my application, and I most certainly
>> can't sell any application to grandma and grandpa, if it requires
instructions
>> on how to install MSYS2 and MXE just so you can run my application.
>
>I really don't understand why you say this. As its name says, MXE is a 
>compiling environment. Would you ship your assembler with your executable?
>
>
>-- 
>Lucas Levrel
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[3]: argv revisited

[Lucas Levrel]

Le 3 mai 2016, Andrew Robinson a écrit :


I don't think I tried filenames with spaces, but I did test filenames with
accented letters in both Linux and Windows, and it worked (using GTK2).
E.g. for reading a file contents into one big string I have this:


I don't know about accented letters, since they are a part of the Windows
version of ASCII. Try a real life UNICODE character, such as the one I have in
my path, C:\My.\Images.


Hi,

I've just tested a filename containing spaces and U+221E (infinity 
symbol), writing and reading both work.


--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Compiling for Windows [Was: argv revisited]

[Lucas Levrel]

Le 3 mai 2016, Andrew Robinson a écrit :


Is it really necessary for every Windows application bundle to ship its
own copy of GTK+?



By default MXE links statically. So you don't have any dll to bundle with
your app. In such circumstances, what does LGPL say? Do you still have to
provide the GTK source code (given that you don't distribute GTK libs)?


Well I can't ship MSYS2 and MXE with my application, and I most certainly
can't sell any application to grandma and grandpa, if it requires instructions
on how to install MSYS2 and MXE just so you can run my application.


I really don't understand why you say this. As its name says, MXE is a 
compiling environment. Would you ship your assembler with your executable?



--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Matthew A. Postiff]

Try this package:

$ pacman -Ss mingw-w64-i686-gtk3
mingw32/mingw-w64-i686-gtk3 3.18.6-1 [installed]
GObject-based multi-platform GUI toolkit (v3) (mingw-w64)


On 5/4/2016 3:51 PM, Andrew Robinson wrote:
> Yeah, I see that, but that only downloads 64-bit binaries. I need the Win-32
> binaries. 
>
> On 5/4/2016 at 12:20 PM, Florian Pelz  wrote:
>> On 05/04/2016 03:59 PM, Andrew Robinson wrote:
>>> No, there are no Win32 binaries in MSYS2. Where are you getting your
>>> information?
>>>
>> MSYS2 contains pacman. `pacman -Syu mingw-w64-x86_64-gtk3` downloads
>> GTK+ binaries for x86_64 and puts them in the C:\msys64\mingw64
>> directory (by default). This directory is what you want to ship with
>> your application later on. Try it.
>>
>>
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

Yeah, I see that, but that only downloads 64-bit binaries. I need the Win-32
binaries. 

On 5/4/2016 at 12:20 PM, Florian Pelz  wrote:
>On 05/04/2016 03:59 PM, Andrew Robinson wrote:
>> No, there are no Win32 binaries in MSYS2. Where are you getting your
>> information?
>> 
>
>MSYS2 contains pacman. `pacman -Syu mingw-w64-x86_64-gtk3` downloads
>GTK+ binaries for x86_64 and puts them in the C:\msys64\mingw64
>directory (by default). This directory is what you want to ship with
>your application later on. Try it.
>
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/04/2016 03:59 PM, Andrew Robinson wrote:
> No, there are no Win32 binaries in MSYS2. Where are you getting your
> information?
> 

MSYS2 contains pacman. `pacman -Syu mingw-w64-x86_64-gtk3` downloads
GTK+ binaries for x86_64 and puts them in the C:\msys64\mingw64
directory (by default). This directory is what you want to ship with
your application later on. Try it.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

No, there are no Win32 binaries in MSYS2. Where are you getting your
information?

On 5/4/2016 at 12:29 AM, Florian Pelz  wrote:
>On 05/04/2016 02:22 AM, Andrew Robinson wrote:
>> I have an idea! Why doesn't someone just compile all the binaries for Win32
>> and Win64 and make them available on the Internet, that way none of us will
>> have to go through all this stupid BS just to get some binaries? Just two
>> packages, one for Win32 and one for Win64, using only just the command line
>> options that
>>
https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
>> tell us to use.
>
>All the binaries are available and maintained in MSYS2. No need to
>duplicate work.
>
>If you want a newer Glib, you can try modifying the PKGBUILD and see if
>it still works [1]. The version already seems right though.
>
>You can also just download gedit for Windows, remove gedit.exe and put
>in your .exe. You won't need some of the libraries and it's not very
>clean and maintainable, but it's a quick hack to get a working GTK+.
>
>And yes, Windows support could be a little cleaner and better
>documented. It's not that bad though, people are working on it, and I'm
>sure they'd appreciate help.
>
>However, it seems many just ignore the LGPL when it comes to source code
>distribution? Of course when using an unmodified version of glibc/GTK+/…
>you can just find the library version you used and fetch the source code
>from the upstream website when needed, but that may mean more work in
>the future.
>
>[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-glib2
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[3]: Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

On 5/3/2016 at 5:42 PM, Allin Cottrell  wrote:
>On Tue, 3 May 2016, Andrew Robinson wrote:
>
>> I have never seen a cross-compiled version of Fedora. Is it related to the
>> mythical Chimera?
>
>Read for comprehension. Fedora is strictly Linux (of course), but 
>offers a set of packages that enable you to cross-compile with ease 
>for MS Windows.

That isn't what he said but I get it now.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/04/2016 02:22 AM, Andrew Robinson wrote:
> I have an idea! Why doesn't someone just compile all the binaries for Win32
> and Win64 and make them available on the Internet, that way none of us will
> have to go through all this stupid BS just to get some binaries? Just two
> packages, one for Win32 and one for Win64, using only just the command line
> options that
> https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
> tell us to use.

All the binaries are available and maintained in MSYS2. No need to
duplicate work.

If you want a newer Glib, you can try modifying the PKGBUILD and see if
it still works [1]. The version already seems right though.

You can also just download gedit for Windows, remove gedit.exe and put
in your .exe. You won't need some of the libraries and it's not very
clean and maintainable, but it's a quick hack to get a working GTK+.

And yes, Windows support could be a little cleaner and better
documented. It's not that bad though, people are working on it, and I'm
sure they'd appreciate help.

However, it seems many just ignore the LGPL when it comes to source code
distribution? Of course when using an unmodified version of glibc/GTK+/…
you can just find the library version you used and fetch the source code
from the upstream website when needed, but that may mean more work in
the future.

[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-glib2

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[2]: Compiling for Windows [Was: argv revisited]

[Allin Cottrell]

On Tue, 3 May 2016, Andrew Robinson wrote:


I have never seen a cross-compiled version of Fedora. Is it related to the
mythical Chimera?


Read for comprehension. Fedora is strictly Linux (of course), but 
offers a set of packages that enable you to cross-compile with ease 
for MS Windows.


Allin Cottrell
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[2]: Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

I just found the link to MSVC 2013 on Microsoft's site. Visual Studio is not
free, Visual Studio Express or Community is free. It will still require me to
uninstall my current version of MSVC in order to run this older version,
because different versions of MSVC on the same computer do not play well
togther, and this is not a trivial thing to do but it is doable. Sure would be
nice though, if GTK supported the Windows community by having a MSVC 2015/2016
or Code::Blocks or GCC version of this.

So all I had to do to find the instructions to fetch the compiled Win32
binaries for GTK+, is go to Google and do a search for "Nachos blog" -- why
didn't I think of that from the very beginning? Are there any other off the
beaten path blogs that say the same thing, or is this the only one? And the
instructions aren't really complete. It isn't as simple as "go to the MSYS2
site, download, and run it". Some of the packages that you need to download to
MSYS2, will either not install or will not work properly if your path contains
spaces or UNICODE (it's that ugly Windows UTF-16 thing again). And the GTK
dlls it creates are outdated, notably the libglib.dll. And by the way, don't
worry about all that extra junk that pacman puts on your computer, it's there
for a reason. I also really enjoy all that talk about forking the compiler
source code, you know, in case the main branch doesn't work. That will
certainly make the project all the more maintainable (not). I would have to
research each and every line of those instructions from
https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
to make sure I knew how to do it, and what each command line option means, if
the instructions still work, so if I ran into problems (like the UTF-16
thing), I would know what went wrong and how to fix it, otherwise it most
definitely is not complete because of all the "gotchas".

I have an idea! Why doesn't someone just compile all the binaries for Win32
and Win64 and make them available on the Internet, that way none of us will
have to go through all this stupid BS just to get some binaries? Just two
packages, one for Win32 and one for Win64, using only just the command line
options that
https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
tell us to use.

On 5/3/2016 at 3:29 PM, Paolo Borelli  wrote: 


On Tue, May 3, 2016 at 11:52 PM, Andrew Robinson  wrote:

The website, https://github.com/wingtk/gtk-win32, looks really good at first
glance, until you read the fine print where it says, "Any version of VS apart
from 2013 is not supported". What if I don't have VS 2013, what then? You
can't download it from Microsoft's website although you can buy it for $400+
from Amazon.


MSVC Community Edition if free (free as in beer, not free software) and works
just fine.



Mingw doesn't have any binaries for GTK+, it is a compiler and you have to
download 27 sub-projects that the GTK+ toolkit is comprised of, then compile
them all with the (hopefully) proper command line switches to get binaries. It
is a laborious and a very, very poorly documented process. Again, no thank
you.




Not really. It is a matter of running a couple of commands and you fetch the
compiled binaries for gtk.
This old blog post is still valid
https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/



I have never seen a cross-compiled version of Fedora. Is it related to the
mythical Chimera?




Not sure because I do not do cross compiling (we use both the above methods in
production to distribute windows applications). As far as I know it is just a
matter of "dnf installl gtk3-mingw64" or something similar.




Paolo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: Re[2]: Compiling for Windows [Was: argv revisited]

[Paolo Borelli]

On Tue, May 3, 2016 at 11:52 PM, Andrew Robinson 
wrote:

> The website, https://github.com/wingtk/gtk-win32, looks really good at
> first
> glance, until you read the fine print where it says, "Any version of VS
> apart
> from 2013 is not supported". What if I don't have VS 2013, what then? You
> can't download it from Microsoft's website although you can buy it for
> $400+
> from Amazon.


MSVC Community Edition if free (free as in beer, not free software) and
works just fine.

Mingw doesn't have any binaries for GTK+, it is a compiler and you have to
> download 27 sub-projects that the GTK+ toolkit is comprised of, then
> compile
> them all with the (hopefully) proper command line switches to get
> binaries. It
> is a laborious and a very, very poorly documented process. Again, no thank
> you.
>
>
Not really. It is a matter of running a couple of commands and you fetch
the compiled binaries for gtk.
This old blog post is still valid
https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/


I have never seen a cross-compiled version of Fedora. Is it related to the
> mythical Chimera?
>
>
Not sure because I do not do cross compiling (we use both the above methods
in production to distribute windows applications). As far as I know it is
just a matter of "dnf installl gtk3-mingw64" or something similar.


Paolo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

There are many ways to have good gtk3 binaries for Windows:


- if you are using mingw you can fetch updated gtk3 binaries from msys2
(https://github.com/Alexpux/MSYS2-packages)

- if you are cross compling Fedora and other distros provide mingw binaries

- if you are using MSVC, there are no pre-built binaries, but
https://github.com/wingtk/gtk-win32 provides a script to build them easily

We decided to not distribute binaries from gtk.org/gnome.org anymore since we
do not have the resources to do that for all the possible platforms and
toolchain combinations. Other projects like msys2 are much better equipped to
provide binaries (and this is the same on linux where binaries are provided by
distros).

The website, https://github.com/wingtk/gtk-win32, looks really good at first
glance, until you read the fine print where it says, "Any version of VS apart
from 2013 is not supported". What if I don't have VS 2013, what then? You
can't download it from Microsoft's website although you can buy it for $400+
from Amazon. If I bought it, I would either have to have another computer to
install it on, or uninstall the current version I have so I could install the
2013 version and be sure it was "bug free". No thank you.

Mingw doesn't have any binaries for GTK+, it is a compiler and you have to
download 27 sub-projects that the GTK+ toolkit is comprised of, then compile
them all with the (hopefully) proper command line switches to get binaries. It
is a laborious and a very, very poorly documented process. Again, no thank
you.

I have never seen a cross-compiled version of Fedora. Is it related to the
mythical Chimera?

PS -- The only help the GTK+ Project has ever offered the Windows community
for obtaining GTK+ for Windows is their weblink instructing you to download
MSYS2 ... the end! No mention of which of the 27+ sub-projects are required to
compile the entire GTK+ toolkit suite, or what developer tools are required,
or how to do any of it. So if something were to go wrong during the compile, I
would not expect the GTK+ Project to be there to offer any help. Even if GTK+
had listed https://github.com/wingtk/gtk-win32 for instructions, I would have
been impressed -- disappointed -- but still impressed.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: Compiling for Windows [Was: argv revisited]

[Paolo Borelli]

On Tue, May 3, 2016 at 9:32 PM, Andrew Robinson  wrote:

> Been there, done that. The latest version of GTK+ that GNOME has is 2.24,
> i.e.
> -- there are no 3.x binaries.
>
>
There are many ways to have good gtk3 binaries for Windows:

- if you are using mingw you can fetch updated gtk3 binaries from msys2 (
https://github.com/Alexpux/MSYS2-packages)
- if you are cross compling Fedora and other distros provide mingw binaries
- if you are using MSVC, there are no pre-built binaries, but
https://github.com/wingtk/gtk-win32 provides a script to build them easily


We decided to not distribute binaries from gtk.org/gnome.org anymore since
we do not have the resources to do that for all the possible platforms and
toolchain combinations. Other projects like msys2 are much better equipped
to provide binaries (and this is the same on linux where binaries are
provided by distros).

Paolo


___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

On 5/3/2016 at 11:34 AM, Dov Grobgeld  wrote:
>Another equivalent scons-based way of compiling for windows with gcc is
>shown in my program giv.
>
>See: https://github.com/dov/giv/blob/master/SConstruct
>
>SCons uses the Sconstruct files to do the cross-compilation and also calls
>out to nsis to create a windows installer.
>
>The complete gtk run time is only about 20MB in size (at least for gtk2)
>which with todays hard disk sizes really is negligable, so I agree that
>there is no reason to try to create a common gtk runtime.
>
>I still remember the frustration back in the days when there was a common
>run environment and installing glade would make inkscape or gimp fail, or
>vice verse. Individual run time environments is really the way to go!
>
>For a peak into the bad old days, see e.g. the following thread:
>http://comments.gmane.org/gmane.comp.gnome.gtk%2B.general/16828

Been there, done that. The latest version of GTK+ that GNOME has is 2.24, i.e.
-- there are no 3.x binaries.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/03/2016 08:34 PM, Dov Grobgeld wrote:
> The complete gtk run time is only about 20MB in size (at least for gtk2)
> which with todays hard disk sizes really is negligable, so I agree that
> there is no reason to try to create a common gtk runtime.
> 
> I still remember the frustration back in the days when there was a common
> run environment and installing glade would make inkscape or gimp fail, or
> vice verse. Individual run time environments is really the way to go!
> 
> For a peak into the bad old days, see e.g. the following thread:
> http://comments.gmane.org/gmane.comp.gnome.gtk%2B.general/16828
> 
> 
> Regards,
> Dov
> 

This is convincing. Thank you.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Dov Grobgeld]

Another equivalent scons-based way of compiling for windows with gcc is
shown in my program giv.

See: https://github.com/dov/giv/blob/master/SConstruct

SCons uses the Sconstruct files to do the cross-compilation and also calls
out to nsis to create a windows installer.

The complete gtk run time is only about 20MB in size (at least for gtk2)
which with todays hard disk sizes really is negligable, so I agree that
there is no reason to try to create a common gtk runtime.

I still remember the frustration back in the days when there was a common
run environment and installing glade would make inkscape or gimp fail, or
vice verse. Individual run time environments is really the way to go!

For a peak into the bad old days, see e.g. the following thread:
http://comments.gmane.org/gmane.comp.gnome.gtk%2B.general/16828


Regards,
Dov

On Tue, May 3, 2016 at 7:44 PM, Allin Cottrell  wrote:

> On Tue, 3 May 2016, Dave Howorth wrote:
>
> On 2016-05-03 16:57, Florian Pelz wrote:
>>
>>> I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
>>> can be downloaded and installed from other installers, so there is just
>>> one GTK+ installed on Windows instead of one copy of perhaps different
>>> versions of GTK+ for each application.
>>>
>>
>> That's been a longstanding desire of many people. The other side of the
>> argument of course is that all the applications have to be compatible with
>> that particular version of the libraries, which has sometimes proven to be
>> problematic even when the libraries ship with Windows. Expecting every
>> application to be updated every time there is a library update is not
>> realistic. It's not like a linux distro where the distro can update and
>> recompile all the dependencies itself.
>>
>
> Yep, Florian's desire is a "natural" one from the point of view of anyone
> used to Linux but unfortunately it's totally impractical on MS Windows.
> It's a real No-No for any third-party package to install DLLs into system
> directories on Windows; this would likely break all sorts of things.
>
> It may seem like a terrible waste of disk space to install multiple
> per-application copies of GTK, but you just have to get over it. Basically
> the same on Mac OS X.
>
> (I might note: even on Linux, GTK updates are not necessarily harmless.
> For example, updating from GTK 3.18 to 3.20 breaks emacs and gnumeric; they
> still run, but they're damaged.)
>
> Allin Cottrell
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Allin Cottrell]

On Tue, 3 May 2016, Dave Howorth wrote:


On 2016-05-03 16:57, Florian Pelz wrote:

I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
can be downloaded and installed from other installers, so there is just
one GTK+ installed on Windows instead of one copy of perhaps different
versions of GTK+ for each application.


That's been a longstanding desire of many people. The other side of the 
argument of course is that all the applications have to be compatible with 
that particular version of the libraries, which has sometimes proven to be 
problematic even when the libraries ship with Windows. Expecting every 
application to be updated every time there is a library update is not 
realistic. It's not like a linux distro where the distro can update and 
recompile all the dependencies itself.


Yep, Florian's desire is a "natural" one from the point of view of 
anyone used to Linux but unfortunately it's totally impractical on 
MS Windows. It's a real No-No for any third-party package to install 
DLLs into system directories on Windows; this would likely break all 
sorts of things.


It may seem like a terrible waste of disk space to install multiple 
per-application copies of GTK, but you just have to get over it. 
Basically the same on Mac OS X.


(I might note: even on Linux, GTK updates are not necessarily 
harmless. For example, updating from GTK 3.18 to 3.20 breaks emacs 
and gnumeric; they still run, but they're damaged.)


Allin Cottrell
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/03/2016 06:12 PM, Dave Howorth wrote:
> On 2016-05-03 16:57, Florian Pelz wrote:
>> I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
>> can be downloaded and installed from other installers, so there is just
>> one GTK+ installed on Windows instead of one copy of perhaps different
>> versions of GTK+ for each application.
> 
> That's been a longstanding desire of many people. The other side of the
> argument of course is that all the applications have to be compatible
> with that particular version of the libraries, which has sometimes
> proven to be problematic even when the libraries ship with Windows.
> Expecting every application to be updated every time there is a library
> update is not realistic. It's not like a linux distro where the distro
> can update and recompile all the dependencies itself.
>

That's a good argument, but those who don't want to risk breakage due to
incompatibilities could still bundle it the old-fashioned way. Of
course, maybe it's too much effort and most people prefer stability on
Windows. I'm not going to take the time, so thank you for explaining the
reasons.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Dave Howorth]

On 2016-05-03 16:57, Florian Pelz wrote:

I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
can be downloaded and installed from other installers, so there is just
one GTK+ installed on Windows instead of one copy of perhaps different
versions of GTK+ for each application.


That's been a longstanding desire of many people. The other side of the 
argument of course is that all the applications have to be compatible 
with that particular version of the libraries, which has sometimes 
proven to be problematic even when the libraries ship with Windows. 
Expecting every application to be updated every time there is a library 
update is not realistic. It's not like a linux distro where the distro 
can update and recompile all the dependencies itself.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/03/2016 04:57 PM, Andrew Robinson wrote:
> Well I can't ship MSYS2 and MXE with my application, and I most certainly
> can't sell any application to grandma and grandpa, if it requires instructions
> on how to install MSYS2 and MXE just so you can run my application.
> 

For MSYS2, you create a package for installing your application in
MSYS2. Then you use a clean MSYS2 installation with which you install
your application package and all dependencies. You can then copy the
installed directories and contents and use them as a bundle. You still
have to ship the GTK+ source code you used though.

Look at gedit for an example:

https://git.gnome.org/browse/gedit/tree/win32/make-gedit-installer

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Lucas Levrel]

Le 2 mai 2016, Florian Pelz a écrit :


On 05/02/2016 12:36 PM, Lucas Levrel wrote:

Then I found MinGW Cross Env, now called MXE (http://mxe.cc/). It
compiled my project with no effort at all.


This is interesting. May I hijack this thread?

I did not know about MXE. What is their relationship with MSYS2?


I don't know. I'm a mere user and haven't even subscribed to their ML.


Distributing the GTK+ source code with bundles for LGPL compliance seems
easier with MXE. How do others handle source code distribution? This is
not an issue for GNOME projects and I can't find examples.

Is it really necessary for every Windows application bundle to ship its
own copy of GTK+?


By default MXE links statically. So you don't have any dll to bundle with 
your app. In such circumstances, what does LGPL say? Do you still have to 
provide the GTK source code (given that you don't distribute GTK libs)?


--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv revisited

[Lucas Levrel]

Le 2 mai 2016, Andrew Robinson a écrit :


I could find functions that worked for the command line, but I couldn't find
any that worked for the filechooser, and when I go online and do a search,
there are no examples for what I want to do. The GNOME forum answered my
UNICODE question for the command line issue, but didn't answer the part about
filechooser, and then they had the nerve to close out my bug report, which I
thought was very rude.

Also, I am kind of leery about having long filenames in Windows, and although
I didn't see a problem with it, I have seen lots of Linux programs that would
not work if certain file name paths contained any spaces. I am just not
getting any good feelings with GTK, which is sad, because it is the only
toolkit I know of that has a working add_from_file function.


I don't think I tried filenames with spaces, but I did test filenames with 
accented letters in both Linux and Windows, and it worked (using GTK2). 
E.g. for reading a file contents into one big string I have this:

-:-:-:-
  GtkWidget *dialog;
  dialog = gtk_file_chooser_dialog_new
("Title", GTK_WINDOW(gtkwin),
 GTK_FILE_CHOOSER_ACTION_OPEN, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
 GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT, NULL);
  /* gtk_file_chooser_set_current_name
 (GTK_FILE_CHOOSER (dialog), "foo.bar"); */
  if(gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT){
char *filename;
filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
GFile *infile=g_file_new_for_path(filename);
GFileInputStream *FIstream=g_file_read(infile, NULL, NULL);
assert(FIstream);
GDataInputStream *DIstream=
  g_data_input_stream_new(G_INPUT_STREAM(FIstream));
assert(DIstream);
char *string=
  g_data_input_stream_read_until(DIstream,"",NULL,NULL,NULL);
assert(string);
/* ... */
g_free(string);
g_object_unref(DIstream);
g_object_unref(FIstream);
g_object_unref(infile);
g_free(filename);
  }
  gtk_widget_destroy(dialog);
-:-:-:-

(Not sure I understand your need, though.)

--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv revisited

[Andrew Robinson]

>Your problem about using UTF16 is related to the fact you are using
>windows os and not linux or unix or macos x.  All the others use utf-8
>EXCEPT WINDOWS.

Isn't that what I was saying? It is horrid that Microsoft uses UTF-16 because,
just like their software, it bloats everything to twice the size it would be
otherwise, and it isn't backwards compatible with ASCII. UTF-8 is the future,
I just hope someone makes it the standard before Microsoft tries to monopolize
the UNICODE world with the insanely stupid UTF-16 standard. It is one of the
reasons I choose to use GoAsm because GoAsm is truly UTF-8 compliant, meaning
even if my code is written in UTF-8, it will still compile with no problem.

>There are functions to convert to and from whatever
>strings you need.  Look up internationalization stuff, texttools. UTF16
>is akin to what windows calls wchar(wide char) by the way.  That should
>nudge you in the right direction for that.

I could find functions that worked for the command line, but I couldn't find
any that worked for the filechooser, and when I go online and do a search,
there are no examples for what I want to do. The GNOME forum answered my
UNICODE question for the command line issue, but didn't answer the part about
filechooser, and then they had the nerve to close out my bug report, which I
thought was very rude.

Also, I am kind of leery about having long filenames in Windows, and although
I didn't see a problem with it, I have seen lots of Linux programs that would
not work if certain file name paths contained any spaces. I am just not
getting any good feelings with GTK, which is sad, because it is the only
toolkit I know of that has a working add_from_file function.

There are other GUI toolkits that claim to work with Windows and Linux UNICODE
file names, and they are very well documented. Nano-X, AntTweakBar, Allegro,
CEGUI, and Qt all seem to be okay in this regards, although I still haven't
tested them thoroughly yet to make sure they really do what they say they can
do. I am about to find out.

>Also be careful what functions you use in window to debug print your
>strings.
>i.e. wprintf != printf.
>use wprintf with wchar string
>use printf with ascii strings
>etc...

Thanks for the tip. I'm trying to avoid any Windows functions, even debug ones
but if I have no choice, I will keep that in mind.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[David Marceau]

On 04/30/2016 11:25 PM, Andrew Robinson wrote:
> My initial request for help in this forum was that main(argc,argv) only
> returned garbage instead of the command line when using the 32-bit version of
> GTK+ v3.18 on a 64-bit Windows7 OS. This forum was unable to offer any expert
> help or advice on this matter so I put it aside. A few days later I thought
> about it and realized that main(argc,argv) implies that the args for the
> command line are on the stack, but that is only true for Linux or Windows
> command line apps. The correct interface for Windows is
> main(hWnd,uMsg,wParam,lParam), hence the reason I couldn't get the command
> line args with GTK+ in Windows. I was following GTKs code examples without
> realizing that they were inapplicable.
> 
> Since this forum was no help in addressing my original problem, I then
> submitted a similar issue to the Gnome forum. I told them I was attempting
> cross-OS programming for Windows and Linux, so while I could use GetCommandA()
> or GetCommandW() to get the command line, there were still issues since
> GetCommandW() was based on Windows being UTF16 and GTK+/Linux were UTF8. Gnome
> said that they had a cross-OS function for that: g_win32_get_command_line().
> 
> Now my new problem I had was either locating a Win32 version of GTK+ greater
> than v3.18 or locating a version of libglib.dll greater than v2.40. It isn't
> going to happen. The GTK+ project itself does not support Win32 or Win64,
> expecting the developer to install MSYS2 and then ... nothing. The GTK+
> project gives no further instructions on what to do next. Getting the Linux
> binaries for GTK+ in MSYS2 seems easy, but I don't want the Linux binaries, I
> want the Windows binaries. I would compile my own binaries for Windows but
> there is little reliable and complete information out there on how to do it
> and what is there isn't credible. From what I understand, compiling binaries
> for Win32 is a very time consuming and tedious project, so I knew if I had any
> problems compiling it, I would not receive any help from the GTK+ (or probably
> even the GNOME) community in resolving them.
> 
> While GNOME was more knowledgeable than the GTK+ Dev forum, they still did not
> address the rest of the issues I discussed. For one thing, the GTK+
> documentation should state it that all their code examples are only applicable
> to Linux or the console version Windows apps, since main(argc,argv) does not
> apply to non-console version of Windows apps. Second, GNOME did not mention
> the corresponding function for the file chooser, when a file name has UTF16
> characters in it. Gnome closed out my bug report before I had a chance to
> confirm it, so that was rude of them.
Mr. Robinson,

Your problem about using UTF16 is related to the fact you are using
windows os and not linux or unix or macos x.  All the others use utf-8
EXCEPT WINDOWS.  There are functions to convert to and from whatever
strings you need.  Look up internationalization stuff, texttools. UTF16
is akin to what windows calls wchar(wide char) by the way.  That should
nudge you in the right direction for that.

Also be careful what functions you use in window to debug print your
strings.
i.e. wprintf != printf.
use wprintf with wchar string
use printf with ascii strings
etc...


> 
> I am still not going to pursue using GTK+ in this project of mine, having
> moved on to a better supported and more mature GUI toolkit, but I thought that
> any feedback, even negative feedback, would be a good thing, since there might
> be other people out there like me that aren't getting answers to simple
> problems like this one.
> 
> Now they know.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Andrew Robinson]

Thank you Lucas, for submitting this post. MXE seems very interesting and I
feel compelled to do some more research into it.

On 5/2/2016 at 3:36 AM, Lucas Levrel  wrote:
>(copy to OP in case he's already unsubscribed, apologies for duplication 
>if he's not)
>
>Le 30 avril 2016, Andrew Robinson a écrit :
>> Now my new problem I had was either locating a Win32 version of GTK+
greater
>> than v3.18 or locating a version of libglib.dll greater than v2.40. It
isn't
>> going to happen. The GTK+ project itself does not support Win32 or Win64,
>> expecting the developer to install MSYS2 and then ... nothing. The GTK+
>> project gives no further instructions on what to do next. Getting the Linux
>> binaries for GTK+ in MSYS2 seems easy, but I don't want the Linux binaries,
I
>> want the Windows binaries. I would compile my own binaries for Windows but
>> there is little reliable and complete information out there on how to do it
>> and what is there isn't credible. From what I understand, compiling
binaries
>> for Win32 is a very time consuming and tedious project, so I knew if I had
any
>> problems compiling it, I would not receive any help from the GTK+ (or
probably
>> even the GNOME) community in resolving them.
>
>I'm not an expert programmer and when I wanted to compile for Windows the 
>software I developped in Linux, I couldn't achieve a satisfactory result 
>(using the -mwin32 or -mwindows flag gave either a clumsy additional 
>command window, or yielded an antivirus alert!).
>
>Then I found MinGW Cross Env, now called MXE (http://mxe.cc/). It compiled 
>my project with no effort at all. When you install it, it compiles the 
>cross-compiler and the libs you want, so this takes quite long, but with 
>no user intervention. Then all you have to do is add such lines in your 
>Linux-ready Makefile:
>
># prepend all binaries with a later-defined prefix
>PKG_CONFIG=$(CROSS)pkg-config
>CXX=$(CROSS)g++
>LD=$(CROSS)ld
>AR=$(CROSS)ar
>STRIP=$(CROSS)strip
>..
># define the prefix in the rules targeting Windows
>myrule : CROSS=/path/to/bin/i686-pc-mingw32-
>myrule : ...
>
>HTH
>
>-- 
>Lucas Levrel

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

[Florian Pelz]

On 05/02/2016 12:36 PM, Lucas Levrel wrote:
> […]
> 
> I'm not an expert programmer and when I wanted to compile for Windows
> the software I developped in Linux, I couldn't achieve a satisfactory
> result (using the -mwin32 or -mwindows flag gave either a clumsy
> additional command window, or yielded an antivirus alert!).
> 
> Then I found MinGW Cross Env, now called MXE (http://mxe.cc/). It
> compiled my project with no effort at all. When you install it, it
> compiles the cross-compiler and the libs you want, so this takes quite
> long, but with no user intervention. Then all you have to do is add such
> lines in your Linux-ready Makefile:
> 
> # prepend all binaries with a later-defined prefix
> PKG_CONFIG=$(CROSS)pkg-config
> CXX=$(CROSS)g++
> LD=$(CROSS)ld
> AR=$(CROSS)ar
> STRIP=$(CROSS)strip
> ...
> # define the prefix in the rules targeting Windows
> myrule : CROSS=/path/to/bin/i686-pc-mingw32-
> myrule : ...
> 
> HTH
> 

This is interesting. May I hijack this thread?

I did not know about MXE. What is their relationship with MSYS2?

Distributing the GTK+ source code with bundles for LGPL compliance seems
easier with MXE. How do others handle source code distribution? This is
not an issue for GNOME projects and I can't find examples.

Is it really necessary for every Windows application bundle to ship its
own copy of GTK+?

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Compiling for Windows [Was: argv revisited]

[Lucas Levrel]

(copy to OP in case he's already unsubscribed, apologies for duplication 
if he's not)


Le 30 avril 2016, Andrew Robinson a écrit :

Now my new problem I had was either locating a Win32 version of GTK+ greater
than v3.18 or locating a version of libglib.dll greater than v2.40. It isn't
going to happen. The GTK+ project itself does not support Win32 or Win64,
expecting the developer to install MSYS2 and then ... nothing. The GTK+
project gives no further instructions on what to do next. Getting the Linux
binaries for GTK+ in MSYS2 seems easy, but I don't want the Linux binaries, I
want the Windows binaries. I would compile my own binaries for Windows but
there is little reliable and complete information out there on how to do it
and what is there isn't credible. From what I understand, compiling binaries
for Win32 is a very time consuming and tedious project, so I knew if I had any
problems compiling it, I would not receive any help from the GTK+ (or probably
even the GNOME) community in resolving them.


I'm not an expert programmer and when I wanted to compile for Windows the 
software I developped in Linux, I couldn't achieve a satisfactory result 
(using the -mwin32 or -mwindows flag gave either a clumsy additional 
command window, or yielded an antivirus alert!).


Then I found MinGW Cross Env, now called MXE (http://mxe.cc/). It compiled 
my project with no effort at all. When you install it, it compiles the 
cross-compiler and the libs you want, so this takes quite long, but with 
no user intervention. Then all you have to do is add such lines in your 
Linux-ready Makefile:


# prepend all binaries with a later-defined prefix
PKG_CONFIG=$(CROSS)pkg-config
CXX=$(CROSS)g++
LD=$(CROSS)ld
AR=$(CROSS)ar
STRIP=$(CROSS)strip
...
# define the prefix in the rules targeting Windows
myrule : CROSS=/path/to/bin/i686-pc-mingw32-
myrule : ...

HTH

--
Lucas Levrel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

argv revisited

[Andrew Robinson]

My initial request for help in this forum was that main(argc,argv) only
returned garbage instead of the command line when using the 32-bit version of
GTK+ v3.18 on a 64-bit Windows7 OS. This forum was unable to offer any expert
help or advice on this matter so I put it aside. A few days later I thought
about it and realized that main(argc,argv) implies that the args for the
command line are on the stack, but that is only true for Linux or Windows
command line apps. The correct interface for Windows is
main(hWnd,uMsg,wParam,lParam), hence the reason I couldn't get the command
line args with GTK+ in Windows. I was following GTKs code examples without
realizing that they were inapplicable.

Since this forum was no help in addressing my original problem, I then
submitted a similar issue to the Gnome forum. I told them I was attempting
cross-OS programming for Windows and Linux, so while I could use GetCommandA()
or GetCommandW() to get the command line, there were still issues since
GetCommandW() was based on Windows being UTF16 and GTK+/Linux were UTF8. Gnome
said that they had a cross-OS function for that: g_win32_get_command_line().

Now my new problem I had was either locating a Win32 version of GTK+ greater
than v3.18 or locating a version of libglib.dll greater than v2.40. It isn't
going to happen. The GTK+ project itself does not support Win32 or Win64,
expecting the developer to install MSYS2 and then ... nothing. The GTK+
project gives no further instructions on what to do next. Getting the Linux
binaries for GTK+ in MSYS2 seems easy, but I don't want the Linux binaries, I
want the Windows binaries. I would compile my own binaries for Windows but
there is little reliable and complete information out there on how to do it
and what is there isn't credible. From what I understand, compiling binaries
for Win32 is a very time consuming and tedious project, so I knew if I had any
problems compiling it, I would not receive any help from the GTK+ (or probably
even the GNOME) community in resolving them.

While GNOME was more knowledgeable than the GTK+ Dev forum, they still did not
address the rest of the issues I discussed. For one thing, the GTK+
documentation should state it that all their code examples are only applicable
to Linux or the console version Windows apps, since main(argc,argv) does not
apply to non-console version of Windows apps. Second, GNOME did not mention
the corresponding function for the file chooser, when a file name has UTF16
characters in it. Gnome closed out my bug report before I had a chance to
confirm it, so that was rude of them.

I am still not going to pursue using GTK+ in this project of mine, having
moved on to a better supported and more mature GUI toolkit, but I thought that
any feedback, even negative feedback, would be a good thing, since there might
be other people out there like me that aren't getting answers to simple
problems like this one.

Now they know.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Enno Borgsteede]

Andrew,

On 4/16/2016 at 1:47 PM, Enno Borgsteede <ennob...@gmail.com> wrote:


1) Argc and argv are initially processed only by the OS, and never by the
linker or GTK or any compiler until after main() is called. Nothing you can

do

with the linker, GTK, or the compiler can change that fact.

Not true. The program arguments are supplied by the OS, but not
necessarily as argc and argv.

That's funny! What are they supplied as? argz and argf?
I have no idea. It's up to the OS, and reading your initial message, and 
the latest by Bill Kelly, I think it's safe to assume that Windows 
doesn't supply anything arg like when it starts an EXE.



In a C program, they are prepared by the
init part of the run time library, which is linked against the main
program. That init part makes sure that argc and argv etc. are passed in
a format that main understands. Check
http://stackoverflow.com/questions/3469955/in-c-how-is-the-main-method-initially-called

Notice how there is no accepted answer to that question? There is no such
thing as a "C program". There are programs that are written in C but there are
no C programs.
I know what I read, and I have debugged loads of C programs at times 
when source level debuggers were too memory hungry to run on the 
available hardware. The experience that I gained then tells me that the 
answers on stackoverflow are close enough to illustrate that argc and 
argv are prepared by some OS dependent startup code. And if you don't 
have that code in your program, there is no argc and argv in registers, 
on the stack, or anywhere else where you think it is.


And in my language a C program is short for a program written in C.

In reality, the operating system is what parses the command line only for the
number of arguments and the command line itself ... nothing more and nothing
less.
I think it's safer not to assume anything about the OS. It's obvious 
that in needs to parse a command line in such a way that it knows what 
built in command or executable program needs to be started, but any 
assumption going further than that is at your own risk.



and http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html

That's interesting but I'm not using Linux, I'm using GTK on a Win32 system.
And if you had actually read that article, you would know the only thing it
says about argc and argv is that it pushes them onto the stack ... nothing
more and nothing less.
I read that, and I know that it's about Linux, and you're building a 
Win32 program. But the overall scheme is the same on Windows, meaning 
that the code called on entry, i.e. not main, processes whatever 
available in the process context to create argc and argv values to be 
used by main.


And if you don't have that code, which in this context can be linked 
from the C runtime library, you can not count on argc and argv being 
available. They happen to be there in Linux, because the Linux exec 
variants put them there, but as far as I know, that is not the case for 
Windows (see Bill Kelly's reply).


A calling convention is a specification of how a callee passes 
parameters to a caller, and whether the callee or caller clean up the 
stack afterwards. It is not a property of the compiler or language, it 
is only a property of an API or a DLL. 
Rubbish. I've debugged enough code to know that there are differences in 
conventions between compilers and languages. For instance in C, strings 
are much different from strings in Pascal, so the way you retrieve them 
in a procedure or function written in assembler is highly different.


This is true for compilers and CPU architectures too, meaning that one C 
compiler may push everything on the stack, where another uses CPU 
registers until they run out, and available registers depend on CPU 
architecture. Moreover, with proper optimization, a call to a C function 
may not be compiled into a real call at all, but to some extra assembly 
inserted in the caller function. I've seen that multiple times.



When you write in assembler, and don't use the C startup libraries, you
will get the program arguments and environment in the format supplied by
the OS, or more exact the OS's program loader.

Exactly, and that format in the case of GTK is _cdecl, which means parameters
as specified in code are pushed on the stack in a right-to-left order and the
caller cleans up the stack when done. In ASM, this means you don't declare a
function as _cdecl, you simply push the expected parameters in the right order
and clean up the stack when the function returns.
True. But that doesn't change what Bill Kelly wrote, being that you need 
to retrieve the program arguments yourself, because Windows does not 
supply them in argc argv format.


regards,

Enno

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Bill Kelly]

Andrew Robinson wrote:
> 
> The AddressOfEntryPoint is 0088 and is determined by me. The entry point
> is therefore always the same.

I may be misunderstanding the problem; but if you're implementing the startup
code yourself, don't you need to call GetCommandLine() in 
Kernel32.lib/Kernel32.dll?
Or obtain the command line from the NT Process Environment Block structure 
directly?

As I understand it, nothing is passed on the stack to the entry point of an EXE.
The fs segment register is initialized, however, and your Process' PEB structure
can be obtained via fetching from segment fs, offset 0x30.  (Or gs:0x60 for 
x64.)

This would allow direct access to the ProcessParameters structure, as it is a
field in the (semi-documented) PEB.

References:

http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FProcess%2FPEB.html

http://tech.reboot.pro/printthread.php?tid=4417


Regards,

Bill


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Howdy to you too Bill,

The AddressOfEntryPoint is 0088 and is determined by me. The entry point
is therefore always the same.

>Does the entry point change depending on whether you do or don't link with
>GTK ?

>Had you considered instructing the linker to use your own custom entry
>point, so that you have full control over the startup?

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Bill Kelly]

Howdy,

Andrew Robinson wrote:
> This should be easy, but it is not. I am writing an assembly language program
> involving GTK+. I want to parse the command line for options but am unable to
> do so. The code to find argv and argc is simple:
> 
> main:
>push ebp
>mov ebp, esp
>lea eax, [ebp + 12]
>lea ecx, [ebp + 8]


Assuming your linker is producing a .exe file, what's the entry point
in the PE32 header?

Example:

$ dumpbin /headers stdcall_dll_user.exe
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file stdcall_dll_user.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
 14C machine (x86)
   4 number of sections
55CC0078 time date stamp Wed Aug 12 19:27:04 2015
   0 file pointer to symbol table
   0 number of symbols
  E0 size of optional header
 102 characteristics
   Executable
   32 bit word machine

OPTIONAL HEADER VALUES
 10B magic # (PE32)
   10.00 linker version
 A00 size of code
 E00 size of initialized data
   0 size of uninitialized data
12F6 entry point (004012F6) _mainCRTStartup
[...]


$ dumpbin /disasm stdcall_dll_user.exe | grep -A 2 -E "_main|004010B3"
_main:
  00401000: 56 pushesi
  00401001: 8B 35 9C 20 40 00  mov esi,dword ptr [__impiob_func]
--
  004010B3: 6A 10  push10h
  004010B5: 68 08 22 40 00 push402208h
  004010BA: E8 01 05 00 00 call__SEH_prolog4
--
  004011D0: E8 2B FE FF FF call_main
  004011D5: 83 C4 0C   add esp,0Ch
  004011D8: A3 38 30 40 00 mov dword ptr ds:[00403038h],eax
--
_mainCRTStartup:
  004012F6: E8 6E 03 00 00 call___security_init_cookie
  004012FB: E9 B3 FD FF FF jmp 004010B3


Does the entry point change depending on whether you do or don't link with
GTK ?

Had you considered instructing the linker to use your own custom entry
point, so that you have full control over the startup?


Regards,

Bill

(yes, plenty of assembly in the 80's and 90's as a matter of necessity)


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

On 4/16/2016 at 1:47 PM, Enno Borgsteede <ennob...@gmail.com> wrote:

>> 1) Argc and argv are initially processed only by the OS, and never by the
>> linker or GTK or any compiler until after main() is called. Nothing you can
do
>> with the linker, GTK, or the compiler can change that fact.

>Not true. The program arguments are supplied by the OS, but not 
>necessarily as argc and argv.

That's funny! What are they supplied as? argz and argf?

>In a C program, they are prepared by the 
>init part of the run time library, which is linked against the main 
>program. That init part makes sure that argc and argv etc. are passed in 
>a format that main understands. Check

>http://stackoverflow.com/questions/3469955/in-c-how-is-the-main-method-initially-called

Notice how there is no accepted answer to that question? There is no such
thing as a "C program". There are programs that are written in C but there are
no C programs.

In reality, the operating system is what parses the command line only for the
number of arguments and the command line itself ... nothing more and nothing
less.

>and http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html

That's interesting but I'm not using Linux, I'm using GTK on a Win32 system.
And if you had actually read that article, you would know the only thing it
says about argc and argv is that it pushes them onto the stack ... nothing
more and nothing less.

>which is the URL shown in the best answer.

>> 2) Assemblers don't have their own calling conventions. OSes have their own
>> calling conventions and you pick a compiler with the same calling
convention,
>> or you hand program yourself, or your program will never work.

>OSes have calling conventions of their own, but compilers and languages 
>have them too. A Pascal compiler passes strings in another way than a C 
>compiler does.

A calling convention is a specification of how a callee passes parameters to a
caller, and whether the callee or caller clean up the stack afterwards. It is
not a property of the compiler or language, it is only a property of an API or
a DLL.

>When you write in assembler, and don't use the C startup libraries, you 
>will get the program arguments and environment in the format supplied by 
>the OS, or more exact the OS's program loader.

Exactly, and that format in the case of GTK is _cdecl, which means parameters
as specified in code are pushed on the stack in a right-to-left order and the
caller cleans up the stack when done. In ASM, this means you don't declare a
function as _cdecl, you simply push the expected parameters in the right order
and clean up the stack when the function returns.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: argv

[Errol van de l'Isle]

> _pascal was used for older 16-bit Windows programs.
> _stdcall is used for newer 32-bit Windows programs.
> _cdecl is the defacto standard for all main() functions *declared* in
> C.
> 
> All three conventions use the same stack parameter order of right-to-
> left.

Pascal uses left to right.

“It’s wingardium leviOsa, not leviosAH.”
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: argv

[Errol van de l'Isle]

> 1) The initial handling of argc and argv are not done by your
> application but
> by the linker.
Incorrect. The linker has nothing to do with argc and argv.

> 2) In C, argc and argv are on the stack, ready to be used, but not
> necessarily
> in assemblers
Yes and no :) It depends on what the start-up routine if any does
before calling main.

Are you linking in the C run-time start up. Under gcc this is crt0.o
and it is this which sets up the arguments for main() and other book
keeping before calling it.

In fact main() is not the starting point for any application and that
includes C.

There is no need for argc and argv to use gtk_init(). You can just pass
null pointers.

> You obviously know absolutely nothing about system assembly language
> programming, yet you are offering advice to people about it as if you
> were an
> expert? You shouldn't even be in this forum offering advice on things
> you know
> nothing about, so I am not responding to you anymore. You can BS some
> of the
> people some of the time, but you can't BS all the people all the
> time.
Now that is not nice. :( Yes I do know assembly language (several of
them) but it is not my first choice of language for doing any
programming unless it is very low level which the high level language
can not do such as switching privileges or very tight loops that need
to be very fast but even that may have minimal to zero gain over a high
level language. Those parts will only be a tiny part of an application.

Your problem has nothing to do with GTK or any other graphical tool
kit. It is all about how the application is started. Without knowing
how you are linking your application and with what, all we can do is
guess (or try to mind read) what you are doing.

If you can provide information on how you are linking your objects and
in what order then I may be able to spot where the error is. The best
would be the full linker command.

Got grade F in mind reading skills at Hogwarts.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Hi David,

I don't have any templates because templates are not a part of any machine
code language specification, nor are they necessary when programming in
assembly, since everything is hand-coded to whatever specification you feel
like coding it to.

_pascal was used for older 16-bit Windows programs.
_stdcall is used for newer 32-bit Windows programs.
_cdecl is the defacto standard for all main() functions *declared* in C.

All three conventions use the same stack parameter order of right-to-left.
That means the stack will look the same for _stdcall and _cdecl upon entry to
main() on a 32-bit system:

   esp-0 = rtn addr
   esp-4 = *argc
   esp-8 = ***argv

The fact that GCC is based on all three C standards, which means that
main(*argc,***argv) in GTK must be _cdecl, but even if it weren't, the only
difference that could matter here, is that the stack would look like this upon
entry to main() on a 32-bit system:

   esp-0 = rtn addr
   esp-4 = ***argv
   esp-8 = *argc

_fastcall is not applicable here, but in the case of GCC/GTK, it would mean
ecx and edx would contain the first two command line parameters, which they
most definitely do not in this instance.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Enno Borgsteede]

Andrew,

In reality, this is what it actually is:

1) Argc and argv are initially processed only by the OS, and never by the
linker or GTK or any compiler until after main() is called. Nothing you can do
with the linker, GTK, or the compiler can change that fact.
Not true. The program arguments are supplied by the OS, but not 
necessarily as argc and argv. In a C program, they are prepared by the 
init part of the run time library, which is linked against the main 
program. That init part makes sure that argc and argv etc. are passed in 
a format that main understands. Check


http://stackoverflow.com/questions/3469955/in-c-how-is-the-main-method-initially-called

and

http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html

which is the URL shown in the best answer.


2) Assemblers don't have their own calling conventions. OSes have their own
calling conventions and you pick a compiler with the same calling convention,
or you hand program yourself, or your program will never work.
OSes have calling conventions of their own, but compilers and languages 
have them too. A Pascal compiler passes strings in another way than a C 
compiler does.


When you write in assembler, and don't use the C startup libraries, you 
will get the program arguments and environment in the format supplied by 
the OS, or more exact the OS's program loader.


regards,

Enno

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[3]: argv

[Andrew Robinson]

You aren't listening. I know *EXACTLY* where it should be. The only problem,
it isn't there. Why not?

On 4/16/2016 at 1:35 PM, Allin Cottrell  wrote:
>You should be aware of how unimpressive a performance you're putting 
>on. By your own account you have a mistaken notion of where in 
>memory your program's argument array is to be found. But apparently 
>you are lacking one or more of the curiosity, the initiative or the 
>intellectual firepower to actually investigate and solve this 
>problem. Instead you embark on endless rounds of self-justification 
>and slagging-off of those who are trying to help you.
>
>Into the bargain, you tell us "Farewell" half-a-dozen postings ago 
>then continue right on with more of the same. One of those people 
>for whom "farewell" is really just a bid for yet more attention.
>
>Allin Cottrell
>
>
>On Sat, 16 Apr 2016, Andrew Robinson wrote:
>
>> Your replies are an example of exactly what I am talking about here
regarding
>> support from the Linux community. Look at the huge number of things you got
>> blatantly wrong so far [etc.]

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[David Marceau]

YES there are two different calling conventions used in older win32
applications they push/pop the args in different orders in the assembler
part essentially.

http://unixwiz.net/techtips/win32-callconv.html
1)PASCAL calling convention(preferred legacy WINAPI calling convention)
"The other most popular convention is __stdcall. In it the parameters
are again pushed by the caller, but the stack is cleaned up by the
callee. It is the standard convention for Win32 API functions (as
defined by the WINAPI macro in ), and it's also sometimes
called the "Pascal" calling convention."

2)C calling convention
"The default convention — shown above — is known as __cdecl."


The template win32 windows application uses the pascal calling convention:
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
return 0;
}


The template win32 console application uses the cdecl calling convention
for its main entry point unless told otherwise:
int main(int argc, char* argv[]) {
return 0;
}

So for your application code, does your main have:

int __cdecl main(int argc, char **argv)
{
 return 0;
}

or
int __stdcall main(int argc, char **argv)
{
 return 0;
}

gtk_init's calling convention doesn't specify either cdecl or stdcall.
The default gcc/g++ compiler uses is cdecl unless otherwise specified
elsewhere:
void gtk_init (int *argc, char ***argv);

I do hope this helps.

Cheers.


On 04/16/2016 02:03 PM, Andrew Robinson wrote:
> Actually, I know exactly where argc and argv *SHOULD* be, just like they are
> for every other C-based program that uses main(), but they either are not
> really there, or they have been "corrupted". I know the way I have described
> it sounds confusing, but I was just going overboard in trying to describe what
> I was thinking the problem could be. It is confusing me why such a simple
> thing won't work, when everything else does work.
> 
> On 4/16/2016 at 10:05 AM, Florian Pelz <pelzflor...@pelzflorian.de> wrote:
>> On 04/16/2016 06:50 PM, Andrew Robinson wrote:
>>> Assembly language has no calling convention whatsoever until you hand code
> it
>>> to have whatever calling convention you want it to have, preferably
> matching
>>> the calling convention of whatever you are interfacing to.
>>>
>>
>> This is not a matter of calling convention.
>>
>> If I understand you correctly, your problem is that argc and argv are
>> not stored where you expect them to be. My (and your?) theory is that
>> argc and argv are not being set up the way you expect them to be.
>>
>> However, it is *not* GTK+ that sets up argc and argv before your entry
>> point gets called. It is either the operating system or some
>> linker-generated machine code you don't normally get to see. That is,
>> not everything in your .exe file is part of your assembly code. This is
>> why I suggested you check GoLink documentation, GoDev forums and the
>> answers on Stack Overflow about GoLink instead of GTK+.
>>
>>> Have you actually ever programmed in assembly?
>>>
>>
>> Yes.
>>
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Your replies are an example of exactly what I am talking about here regarding
support from the Linux community. Look at the huge number of things you got
blatantly wrong so far:

1) The initial handling of argc and argv are not done by your application but
by the linker.

2) In C, argc and argv are on the stack, ready to be used, but not necessarily
in assemblers

3) GTK+ has no influence on the command line until you call gtk_init on it

In reality, this is what it actually is:

1) Argc and argv are initially processed only by the OS, and never by the
linker or GTK or any compiler until after main() is called. Nothing you can do
with the linker, GTK, or the compiler can change that fact.

2) Assemblers don't have their own calling conventions. OSes have their own
calling conventions and you pick a compiler with the same calling convention,
or you hand program yourself, or your program will never work.

3) In C code, main(*argc,***argv) means the starting point for your program
has been called and you can access the command line via argc and argv. In
fact, gtk_init(*argc,***argv) will not work if you do not pass it the command
line arguments, argc and argv, which you get from main().

You obviously know absolutely nothing about system assembly language
programming, yet you are offering advice to people about it as if you were an
expert? You shouldn't even be in this forum offering advice on things you know
nothing about, so I am not responding to you anymore. You can BS some of the
people some of the time, but you can't BS all the people all the time.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/16/2016 07:59 PM, Andrew Robinson wrote:
> Don't forget that GTK is already running on top of the Windows command line
> and therefore I have no direct access to it. Everything is processed by GTK
> before I can ever get to it for myself.
> 
> I do suspect that Windows may be the cause of this issue, but I have no proof
> of it. One way to narrow down this issue was to see if anybody could reproduce
> this issue, but that isn't going to happen.
> 
> Don't worry about it though, I am abandoning this project as of today.
> 

I'm not sure if you are still on the list, so I'm cc'ing you.

I hope you reconsider what you think about our community. We are trying
to help.

While GTK+ could alter your command-line when the GTK+ DLL loads (like
this for example [1]) if it wanted to, it does not do so. That neither
Windows nor GoLink place argc and argv on the stack as you expect is a
far more likely explanation than an error in GTK+. Also, [2] makes it
sound likely. The workaround they describe is calling the Windows API
function GetCommandLine() to retrieve argc and argv. Doing so would
probably solve your problem and save your project.

By the way, you can bundle GTK+ programs like the Windows version of
gedit does [3]. It is plug and play and the bundle isn't that large.
However, it is not easy to create such a bundle.

[1] https://git.gnome.org/browse/glib/tree/glib/gconstructor.h
[2]
https://stackoverflow.com/questions/21946783/accessing-command-line-arguments-in-asm-win-7
[3] https://wiki.gnome.org/Apps/Gedit
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Actually, I know exactly where argc and argv *SHOULD* be, just like they are
for every other C-based program that uses main(), but they either are not
really there, or they have been "corrupted". I know the way I have described
it sounds confusing, but I was just going overboard in trying to describe what
I was thinking the problem could be. It is confusing me why such a simple
thing won't work, when everything else does work.

On 4/16/2016 at 10:05 AM, Florian Pelz <pelzflor...@pelzflorian.de> wrote:
>On 04/16/2016 06:50 PM, Andrew Robinson wrote:
>> Assembly language has no calling convention whatsoever until you hand code
it
>> to have whatever calling convention you want it to have, preferably
matching
>> the calling convention of whatever you are interfacing to.
>> 
>
>This is not a matter of calling convention.
>
>If I understand you correctly, your problem is that argc and argv are
>not stored where you expect them to be. My (and your?) theory is that
>argc and argv are not being set up the way you expect them to be.
>
>However, it is *not* GTK+ that sets up argc and argv before your entry
>point gets called. It is either the operating system or some
>linker-generated machine code you don't normally get to see. That is,
>not everything in your .exe file is part of your assembly code. This is
>why I suggested you check GoLink documentation, GoDev forums and the
>answers on Stack Overflow about GoLink instead of GTK+.
>
>> Have you actually ever programmed in assembly?
>> 
>
>Yes.
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[2]: Re[2]: argv

[Andrew Robinson]

Don't forget that GTK is already running on top of the Windows command line
and therefore I have no direct access to it. Everything is processed by GTK
before I can ever get to it for myself.

I do suspect that Windows may be the cause of this issue, but I have no proof
of it. One way to narrow down this issue was to see if anybody could reproduce
this issue, but that isn't going to happen.

Don't worry about it though, I am abandoning this project as of today.

On 4/16/2016 at 10:29 AM, Errol van de l'Isle  wrote:
>
>> Yes, I have a test program and it is the one I am debugging, and no,
>> it won't
>Is this test program in C and uses GTK so that you can confirm that you
>are not getting any command line sent to the application. This way you
>could narrow down where the error is. If the C test program gets the
>arguments then it is your code. If it does not then you need to look
>else where.
>
>There are other possibilities to look for which are Microsoft specific.
>Which can prevent arguments being passed. https://msdn.microsoft.com/en
>-us/library/zay8tzh6.aspx could be an issue. There can be different C
>run time start up code so make sure that you have one and the right
>one.
>
>You can get the command line using the Microsoft API https://msdn.micro
>soft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx and h
>ttps://msdn.microsoft.com/en-
>us/library/windows/desktop/bb776391%28v=vs.85%29.aspx which is what the
>C runtime will call anyway.
>
>> one of the (hidden) reasons I came here. Is this just a problem with
> Don't hide information
>
>I'm a lumberjack, and I'm okay,
>I sleep all night and I work all day.
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: Re[2]: argv

[Errol van de l'Isle]

> Yes, I have a test program and it is the one I am debugging, and no,
> it won't
Is this test program in C and uses GTK so that you can confirm that you
are not getting any command line sent to the application. This way you
could narrow down where the error is. If the C test program gets the
arguments then it is your code. If it does not then you need to look
else where.

There are other possibilities to look for which are Microsoft specific.
Which can prevent arguments being passed. https://msdn.microsoft.com/en
-us/library/zay8tzh6.aspx could be an issue. There can be different C
run time start up code so make sure that you have one and the right
one.

You can get the command line using the Microsoft API https://msdn.micro
soft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx and h
ttps://msdn.microsoft.com/en-
us/library/windows/desktop/bb776391%28v=vs.85%29.aspx which is what the
C runtime will call anyway.

> one of the (hidden) reasons I came here. Is this just a problem with
 Don't hide information

I'm a lumberjack, and I'm okay,
I sleep all night and I work all day.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/16/2016 06:50 PM, Andrew Robinson wrote:
> Assembly language has no calling convention whatsoever until you hand code it
> to have whatever calling convention you want it to have, preferably matching
> the calling convention of whatever you are interfacing to.
> 

This is not a matter of calling convention.

If I understand you correctly, your problem is that argc and argv are
not stored where you expect them to be. My (and your?) theory is that
argc and argv are not being set up the way you expect them to be.

However, it is *not* GTK+ that sets up argc and argv before your entry
point gets called. It is either the operating system or some
linker-generated machine code you don't normally get to see. That is,
not everything in your .exe file is part of your assembly code. This is
why I suggested you check GoLink documentation, GoDev forums and the
answers on Stack Overflow about GoLink instead of GTK+.

> Have you actually ever programmed in assembly?
> 

Yes.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

On 4/16/2016 at 6:47 AM, David Marceau <uticdmarceau2...@yahoo.ca> wrote:

I understand what you are saying David, but I know you most certainly do not
understand what I am saying.

Can you explain *BEFOREHAND*, how one compiler/linker could do everything
required to make a working program, except it would cause GTK only to make
argc and argv invalid, and all *BEFORE* my code was actually called, i.e. --
at the entry point of main()? Suggesting not to use GoAsm and GoLink suggests
GoAsm and GoLink are involved in a conspiracy to make the Win32 GTK+ version
3.18 runtimes fail to pass a valid argc and argv to the program. I'm not
buying into that.

All my buttons and file choosers and dialogs work perfectly, but argc and argv
are unusable. Could it be due to a bug? You advice would avoid determining if
that were the case. I have novel idea: instead of asking me to go off on a
wild goose chase, why don't you go off on a wild goose chase and try to
reproduce my problem? But I know you won't. I know nobody will. So nobody will
ever know if this is a bug or GtkD has bad runtimes or ... ? I know you would
like to see me to go on some far off tangent, and disappear for awhile when
trying all these many different things to see if it makes any difference. What
if it did make a difference? Could you explain why? No, otherwise you would
say way before I tried. So the end result of all of this would be that it
wouldn't be helpful to me with my original problem, which is the Win32 GTK+
v3.18 runtimes pass invalid argc and argv parameters to main().

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Assembly language has no calling convention whatsoever until you hand code it
to have whatever calling convention you want it to have, preferably matching
the calling convention of whatever you are interfacing to.

Have you actually ever programmed in assembly?

On 4/16/2016 at 9:31 AM, Florian Pelz <pelzflor...@pelzflorian.de> wrote:
>On 04/16/2016 06:23 PM, Andrew Robinson wrote:
>> That is completely incorrect. By definition, main(argc,argv) means that
before
>> you add even one line of code, argc and argv are on the stack, ready to be
>> used. 
>
>That's how it should be in C, but not necessarily in assemblers. Since
>you seem to know assembly programming fairly well otherwise, I assume
>the "bug" is that this is not the case here.
>
>Maybe this helps you:
>https://stackoverflow.com/questions/21946783/accessing-command-line-arguments-in-asm-win-7
>
>Or maybe I still misunderstand you.
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/16/2016 06:23 PM, Andrew Robinson wrote:
> That is completely incorrect. By definition, main(argc,argv) means that before
> you add even one line of code, argc and argv are on the stack, ready to be
> used. 

That's how it should be in C, but not necessarily in assemblers. Since
you seem to know assembly programming fairly well otherwise, I assume
the "bug" is that this is not the case here.

Maybe this helps you:
https://stackoverflow.com/questions/21946783/accessing-command-line-arguments-in-asm-win-7

Or maybe I still misunderstand you.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

On 4/15/2016 at 11:53 PM, Florian Pelz <pelzflor...@pelzflorian.de> wrote:
>GTK+ has no influence on the command line until you call gtk_init on it,
>after which a valid command line remains a valid command line. Your
>problem is not related to GTK+. What influences the command line is the
>way GoLink calls main, so you should be asking your question on the
>GoDev forum. Alternatively, you can use GCC instead of GoDev and follow
>the advice given to you.

That is completely incorrect. By definition, main(argc,argv) means that before
you add even one line of code, argc and argv are on the stack, ready to be
used. All gtk_init() does it take argc and argv, parse it for GTK+ command
line parameters only, remove only the GTK+ command line parameters, then pass
argc and argv back to the program.

What that means is, I can parse the command line before and after gtk_init(),
but the GTK group probably intended users to let gtk_init() parse the command
line first.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Why can't anybody understand that GCC outputs the same exact machine code
language that an assembler outputs? Anything *any* compiler in the world
outputs, an assembly language can output, but not vice versa. The only
prerequisite required is that you must understand how the compiler and the
target OS works at the assembly level.

I am an assembly language programmer so I don't need any assembly language
GTK+ examples. Like I said, I have an assembly language program for the Win32
GTK+ v3.18 package that has buttons and file choosers and dialogs ... all
working as expected. I only have a problem with the command line arguments not
being passed to my program.

On 4/16/2016 at 3:44 AM, Florian Pelz  wrote:
>On 04/16/2016 10:53 AM, Lucas Levrel wrote:
>> Gtk2 came with "gtk-demo". Doesn't Gtk3 have a similar app? However, I
>> don't know if it parses command-line args, if that's what you're looking
>> for.
>
>It is called gtk3-demo and it doesn't parse command-line args because
>its examples are not run from the command-line. AFAIK gtk_init will
>probably lose it's command-line parsing ability anyway and use only
>environment variables instead. I'm not sure though. Of course
>command-line parsing can still be useful for the application itself.
>
>Probably it wouldn't help Andrew anyway because gtk3-demo is written in
>C and the GoDev tools don't include a C compiler. What Andrew is asking
>for is a GoAsm assembly language GTK+ example program if I'm not mistaken.
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Re[2]: argv

[Andrew Robinson]

Hi Errol,

Yes, theoretically it should not matter if I use 32-bit or 64-bit libraries,
but maybe, just maybe, the 32-bit version does have a bug the 64-bit version
doesn't -- or is that physically impossible to ever happen?

Yes, GNU ASM (or GAS or GNU AS) uses the AT syntax, which is basically
designed to be unreadable because GAS was made to be parsable by a C compiler
and not made to be readable by assembly language programmers or engineers
familiar with desktop microprocessor manuals.

Yes, since GCC conforms to the _cdecl calling convention, that is why I knew
exactly where to look for argc and argv on the stack, and that is why there
can never be a "problem of calling convention" with GCC since there is only
one calling convention -- well actually, the programmer can also use _fastcall
or _thiscall elsewhere in the program, except with main().

Yes, pretty much everyone will not be familiar with GTK from an assembly
language point of view, so why is everyone giving advice on something they
know nothing about? They cannot truly understand calling conventions unless
they know assembly, because that is what calling convention are defined with.
They cannot understand why ***argv is the same as *argv[], yet they want to
tell me how this works and where I can get an education on something they know
nothing about?

>do not include the personal e-mail address of others in the mailing list

Noted. I apologize for that.

>Your original posting was fairly terse which lead to others assuming
>that you did not know much on the subject. To many it looks like you
>had only got to the parsing the augments stage and no further :-/ .

All they had to do was ask. Communication is thee number one problem of all
corporations and other businesses, so maybe everyone should make it a policy
to repeat back what you think something said, rather than assume you
understood what they heard?

>Back to your original problem :-) You may have done this already. Have
>you tried making a test application using the libraries you are using
>in C, C++ or D. You will need to make sure that you are using the same
>memory model etc. as your assembly. All this needs to do is get the
>command line arguments, print them to the terminal (or where ever you
>want) and then display a dialog window where you click on a button to
>exit. This would make sure that you have GTK compiled in, test that you
>can get the arguments and see what code is actually generated for the
>GUI application.

Yes, I have a test program and it is the one I am debugging, and no, it won't
work. What I was hoping for was outside verification of this issue, and was
one of the (hidden) reasons I came here. Is this just a problem with my
environment or have a found a bug? Who knows?

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[David Marceau]

 it in order to gain the royalties from that
entirely.  It is much harder from them when Google's Android/Linux is
provided as open-source placing all the manufacturers at a level-playing
field without falling under the iron-grip of secret OEM agreements with
Microsoft.  Recently it has been discussed that is still the case with
certain companies attempting to evade lawsuits with Microsoft when using
Android they still need to pay Microsoft for some licensing fees for
parts of Android.

These are but a few examples of the so-called "Microsoft community" that
crush anyone outside of it.  The idea of learning stuff under-the-hood
and "do-it-yourself" with Microsoft product is an illusion.  What
technology Microsoft deems core, you will never have the privilege to
have your eyes on that. I won't recommend you to change, but I needed to
answer to your perception that the Microsoft community is supportive
when in fact it is subtly only looking to preserve its piece of the
larger profit pies.  It has slowly expanded from operating systems(dos
to windows) to office productivity(office, office365), gaming
consoles(xbox), mobile devices(surface),  desktop accessories(mice and
keyboards) and now 3D stuff.  When it does expand, it leaves no room for
competitors; it crushes them.  The only opponent it has never succeeded
in crushing is GNU/Linux because as others on this mailing list have
pointed out this is a community of volunteers, conscientious volunteers,
trying to help others, without any regard for $$$profit.  When you leave
government and companies make decisions solely on profit, they end up in
crisis management situations rather than being in mature preventive
environments.  Decisions made in free and open-source communities are
based on the right thing to do and not based on profit.  They're not
perfect code-bases, but since they are open, they can be improved by
those who can when they are ready when they reach that phase in their
lives where it becomes a priority for them to contribute to open-source
in whatever way they can.  The stuff out in GNU/Linux now for doing
daily stuff is good enough your grandma can use it.  That means we don't
need Microsoft anymore for anything which means no more profit for
Microsoft.  Microsoft will eventually cease to exist because their
purpose is not to contribute to society but to make profit.  These two
values are ultimately in conflict with each other.  You choose which
value is most important for you.  You may choose to become a purist
profiteer or not or a compromise somewhere in the middle.  Life is
complicated so at times we are purist and at times we are not.

Don't see this as condescending.  See this as clarifying of my
perspective that I believe GNU/Linux better reflects the global
consciousness and the direction we want the world to go towards.  I make
these suggestions towards more GNU/Linux and less Microsoft, but in no
way did I ever impose anything.  Just keep these things in mind when you
reflect and make your decisions along the way.

Sincerely,
David Marceau
http://adequatech.ca


On 04/12/2016 07:58 AM, David Marceau wrote:
> Taken from an older gtk tutorial, but nevertheless should apply to your
> situation:
> http://www.gtk.org/tutorial1.2/gtk_tut-2.html
> 
> #include 
> 
> int main( int   argc,
>   char *argv[] )
> {
> GtkWidget *window;
> 
> //<<<<<<<<<<<<<<<<<<<<<<<<<<<
> //DID YOU INTRODUCE THIS LINE IN YOUR CODE?
> gtk_init (, );
> //>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_widget_show  (window);
> 
> gtk_main ();
> 
> return(0);
> }
> 
> 
> "Here is our gtk_init again. As before, this initializes the toolkit,
> and parses the arguments found on the command line. Any argument it
> recognizes from the command line, it removes from the list, and modifies
> argc and argv to make it look like they never existed, allowing your
> application to parse the remaining arguments.
> 
>gtk_init (, );
> "
> 
> DID YOU CATCH THAT LAST PART?  It grabs any arguments that are gtk
> specific and removes them.  The leftover arguments are left within the
> argv array.  Did you call gtk_init?  Did you pass any non-GTK-switch
> arguments to your app?  If not, it would explain why your argsv holds
> empty/uninitialized values.
> 
> If you really need to resort to assembler, just run the gcc/g++ compiler
> with the "-c -S" to generate the assembler to see how they gcc compiler
> does it with the above gtkhello.c
> 
> THIS IS THE ENVIRONMENT SETUP ON DEBIAN LINUX:
> pkg-config --cflags --libs gtk+-2.0
> 
> -pthread -I/usr/include/gtk-2.0
> -I/usr

Re: argv

[Florian Pelz]

On 04/16/2016 10:53 AM, Lucas Levrel wrote:
> Gtk2 came with "gtk-demo". Doesn't Gtk3 have a similar app? However, I
> don't know if it parses command-line args, if that's what you're looking
> for.
>

It is called gtk3-demo and it doesn't parse command-line args because
its examples are not run from the command-line. AFAIK gtk_init will
probably lose it's command-line parsing ability anyway and use only
environment variables instead. I'm not sure though. Of course
command-line parsing can still be useful for the application itself.

Probably it wouldn't help Andrew anyway because gtk3-demo is written in
C and the GoDev tools don't include a C compiler. What Andrew is asking
for is a GoAsm assembly language GTK+ example program if I'm not mistaken.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Lucas Levrel]

Le 15 avril 2016, Andrew Robinson a écrit :


Let me rephrase this whole entire issue: Does anyone here have a working,
tested, and simple program (not a command line only program) that runs in
Windows with the GTK+ Win32 libraries, version 3.0 or above? If so, please
give me a link of it so I can test it on my system. It could help tremendously
in troubleshooting a problem am I seeing in an otherwise working program I
have.


Gtk2 came with "gtk-demo". Doesn't Gtk3 have a similar app? However, I 
don't know if it parses command-line args, if that's what you're looking 
for.


Also, I've got limited knowledge in the compiling-assembly-linking 
process, but (just as Florian Pelz says) I don't see how, if your program 
tries to parse CL args before calling gtk_init, linking to Gtk could alter 
them. Maybe you could link to a dummy lib where gtk_init is a no-op, to 
see if that makes any difference?


Good luck.
--
LL
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re[2]: argv

[Errol van de l'Isle]

> 1) It uses the 64-bit Linux libraries whereas I am using the 32-bit
> Win
Should not really matter

> 2) GCC assembly language sucks :^)
It uses AT syntax which many think is not nice to read.

> 3) Despite #2 above, I noticed something very peculiar about the
> disassembly
> code. For argv, GCC uses a 32-bit register, whereas for the argc, GCC
> uses a
> 64-bit register. This isn't documented anywhere. Does this apply to
> 32-bit Win
> code as well, i.e. -- argv would use a 32-bit register and argc would
> use a
> 16-bit register? This disassembly example violates the 64-bit code
> convention
> used by the C standard and by the Win and Linux OSes as well.
You might have come across the nightmare of which calling convention to
use. Things vary between OS and compiler! This document might be of
interest http://agner.org/optimize/calling_conventions.pdf  .

> 4) The documentation implies argc and argv are consecutive
This is the C convention.

> 5) It uses the Gtk+2 libraries whereas I am using Gtk+3. It appears
> that the
> Gtk+2 libraries pass parameters in the registers and there is no
> stack
> cleanup, whereas the Gtk+3 libraries pass parameters on the stack and
> stack
> cleanup is required. Again, not documented. This may not matter
> unless I
> wanted to convert my application later on to 64-bit, so this is good
> to know
> beforehand.
See 3. This is again the problem of calling convention.

The majority of people will use GTK from a high level language so
questions on assembly would not be second nature.

When replying to the mailing list only reply to the list and do not
include the personal e-mail address of others in the mailing list. They
will get two copies of your message and will probably (and possible
have) get a little bit fed up to put it nicely.

Your original posting was fairly terse which lead to others assuming
that you did not know much on the subject. To many it looks like you
had only got to the parsing the augments stage and no further :-/ . If
the others on the list are still reading, play nicely now there is no
need to start a flame war. :o)

Back to your original problem :-) You may have done this already. Have
you tried making a test application using the libraries you are using
in C, C++ or D. You will need to make sure that you are using the same
memory model etc. as your assembly. All this needs to do is get the
command line arguments, print them to the terminal (or where ever you
want) and then display a dialog window where you click on a button to
exit. This would make sure that you have GTK compiled in, test that you
can get the arguments and see what code is actually generated for the
GUI application.

Always look on the bright side of life
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

GTK+ has no influence on the command line until you call gtk_init on it,
after which a valid command line remains a valid command line. Your
problem is not related to GTK+. What influences the command line is the
way GoLink calls main, so you should be asking your question on the
GoDev forum. Alternatively, you can use GCC instead of GoDev and follow
the advice given to you.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

I already know how to program. That isn't my problem.

On 4/15/2016 at 3:46 PM, Florian Pelz  wrote:
>On 04/15/2016 09:30 PM, Mark Cianfaglione wrote:
>> […]
>> To the community's defense I have to say that I've never seen anyone use
>> ANY Gtk from assembler in the 7+ years that I've been using it. (Other
>> than what is compiled from GCC.)
>> 
>> Sounds like you are breaking new ground. Do keep the list posted if you
>> do manage to get it to work to add to the community based knowledge.
>> 
>> Mark
>>
>
>There is "Programming From the Ground Up" [1], an excellent but old book
>on x86 (i.e. 32-bit) assembler programming on GNU/Linux which has a
>section on using libgnomeui from the assembler. It uses the GNU
>assembler's AT syntax by the way, not Intel syntax.
>
>[1] https://savannah.nongnu.org/projects/pgubook/
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/15/2016 09:59 PM, Andrew Robinson wrote:
> I may be the only person writing a
> program in GoAsm for for GTK+3 and cross-OS, but that has nothing to do with
> my problem.

That you use GoAsm and GoLink instead of GCC can make a difference.
Different build toolchains may not be compatible. Where did you get your
GTK+ packages from? Does calling GTK+ functions even work?

Either way, the stack usage is probably the same for all 32-bit Windows
programs. In the MSYS2 GCC, argc is at ebp+8, argv is at ebp+12, so
argv[1] is retrieved like this:

moveax, DWORD PTR [ebp+12]
moveax, DWORD PTR [eax+4]

Maybe you accessed the argv array pointer instead of the array elements?

You can try it yourself on MSYS2 and compiling to assembler code like this

gcc `pkg-config --cflags gtk+-3.0` -S test.c -masm=intel

and linking like this:

gcc -o test test.s `pkg-config --libs gtk+-3.0`

I have no idea how to do this in GoAsm and I'm not going to try.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/15/2016 09:30 PM, Mark Cianfaglione wrote:
> […]
> To the community's defense I have to say that I've never seen anyone use
> ANY Gtk from assembler in the 7+ years that I've been using it. (Other
> than what is compiled from GCC.)
> 
> Sounds like you are breaking new ground. Do keep the list posted if you
> do manage to get it to work to add to the community based knowledge.
> 
> Mark
>

There is "Programming From the Ground Up" [1], an excellent but old book
on x86 (i.e. 32-bit) assembler programming on GNU/Linux which has a
section on using libgnomeui from the assembler. It uses the GNU
assembler's AT syntax by the way, not Intel syntax.

[1] https://savannah.nongnu.org/projects/pgubook/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

I have a working program written in GoAsm for Win32 GTK+. It is a very easy
thing to do, much easier than you could imagine. I could post code, if you
wanted to see it, since it is such a simple program. I found two other people
on the Internet who have built and run GTK+ programs in assembly, both written
in NASM, both for GTK+2, and both cross-OS. I may be the only person writing a
program in GoAsm for for GTK+3 and cross-OS, but that has nothing to do with
my problem. I would be willing to discuss all of this and more with anyone who
would care to listen, but not until I get my problem resolved. That's because
if the community won't support me, why would I support the community? As you
probably already know, getting my "trivial" problem resolved is leading to
something else entirely. This is something I have repeatedly come across in
the Linux community:

1) You have a problem! I don't have that problem, you must be stupid! -- but
said in more subtle way, obviously
2) You have a problem? You have come to the right place because I know
everything, blah, blah, blah, ... sorry I couldn't help you with your problem
3) You have a problem? Your problem is something unrelated to Linux/GTK+/etc
-- is Windows anywhere on your system? Is it an obsolete 32-bit instance
instead of the vastly superior 64-bit instance? Are you using the right
compiler?

Two people in this forum have done exactly what I have listed above, so this
is no exaggeration.

Thanks,

Andrew

On 4/15/2016 at 12:30 PM, Mark Cianfaglione 
wrote:
>
>On 15/04/16 03:17 PM, Andrew Robinson wrote:
>> It is good advice but do you have a *working* or *tested* example that I
can
>> do this with using the GTK+ Win32 libraries? I don't and that is my problem
>> and it is one hundred percent a GTK+ problem because I am only using GTK+
for
>> my program.
>>
>To the community's defense I have to say that I've never seen anyone use 
>ANY Gtk from assembler in the 7+ years that I've been using it. (Other 
>than what is compiled from GCC.)
>
>Sounds like you are breaking new ground. Do keep the list posted if you 
>do manage to get it to work to add to the community based knowledge.
>
>Mark
>
>___
>gtk-app-devel-list mailing list
>gtk-app-devel-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: Fwd: Fw: Re[2]: argv

[Andrew Robinson]

My problem is not an assembly language issue, it is a command line issue.

Anything outside of that is not an issue for me, ever.

On 4/15/2016 at 11:56 AM, Emmanuele Bassi  wrote:
>Hi;
>
>I hope you realize you're asking on the GTK+ app development list
>about a problem you have when writing Assembly. To say that you're
>asking on the wrong list is probably an understatement.
>
>GTK+ only provides a C API, which is usually consumed via C; if you're
>trying to use it via platform-specific Assembly then you're completely
>on your own. My strong suggestion is to write a small C test case, and
>look at a disassembly of a small C program looks like, if you still
>want to continue trying to use the GTK+ API in Assembly.
>
>There's another misconception you have, though, that I think explains
>why you're getting answers you don't like:
>
>On 15 April 2016 at 18:59, Andrew Robinson  wrote:
>
>> I hope this thread makes the news. I want people to see how horrible the
Linux
>> community is at supporting or encouraging it's customers.
>
>"Customer" is a person who pays somebody else for services rendered.
>You are not paying anybody, here. This is a community mailing list,
>and we're all volunteers, here.
>
>Finally, I hope you considered that if nobody here has answered how to
>solve your Assembly issue by now it's probably because nobody here has
>tried to use GTK+ API from Assembly.
>
>Ciao,
> Emmanuele.
>
>-- 
>https://www.bassi.io
>[@] ebassi [@gmail.com]

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Just so there is no misunderstandings here, I want everyone to realize that
when a typical GTK+ program is selected from Windows Explorer:

1) A DOS CLI window appears
2) After a short delay, the GTK+ program appears

If you leave off the "/console" option on compilation, the DOS CLI does not
appear, but when you exit your GTK+ program, it will still be running in the
background. The only way to close it then, is to open Windows Task Manager and
kill the thread for your GTK+ application. With the "/console" option, closing
the GTK+ program still leaves the DOS CLI open and the Task Manager still
shows your program running, but when you close the DOS CLI, the program
completely exits.

This sequence of operations is why I believe Windows is "stealing" my command
line args and passing on something else that is nonsense, or that the only
real way to get the command line args with Win32 GTK+ programs is to not use
the args, but to use g_application_new(G_APPLICATION_HANDLES_COMMAND_LINE).

Thanks,

Andrew 

On 4/15/2016 at 11:35 AM, Florian Pelz  wrote:
>On 04/12/2016 01:58 PM, David Marceau wrote:
>> If you really need to resort to assembler, just run the gcc/g++ compiler
>> with the "-c -S" to generate the assembler to see how they gcc compiler
>> does it with the above gtkhello.c
>
>This here really is good advice. If you don't want to read GNU assembler
>language, then make gcc output Intel assembler syntax (see [1]).
>
>That said, you are asking for advice on a GTK+ list when your problems
>apparently have nothing to do with GTK+.
>
>[1]
>https://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax
>

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Mark Cianfaglione]

On 15/04/16 03:17 PM, Andrew Robinson wrote:

It is good advice but do you have a *working* or *tested* example that I can
do this with using the GTK+ Win32 libraries? I don't and that is my problem
and it is one hundred percent a GTK+ problem because I am only using GTK+ for
my program.

To the community's defense I have to say that I've never seen anyone use 
ANY Gtk from assembler in the 7+ years that I've been using it. (Other 
than what is compiled from GCC.)


Sounds like you are breaking new ground. Do keep the list posted if you 
do manage to get it to work to add to the community based knowledge.


Mark

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

It is good advice but do you have a *working* or *tested* example that I can
do this with using the GTK+ Win32 libraries? I don't and that is my problem
and it is one hundred percent a GTK+ problem because I am only using GTK+ for
my program.

On 4/15/2016 at 11:35 AM, Florian Pelz  wrote:
>On 04/12/2016 01:58 PM, David Marceau wrote:
>> If you really need to resort to assembler, just run the gcc/g++ compiler
>> with the "-c -S" to generate the assembler to see how they gcc compiler
>> does it with the above gtkhello.c
>
>This here really is good advice. If you don't want to read GNU assembler
>language, then make gcc output Intel assembler syntax (see [1]).
>
>That said, you are asking for advice on a GTK+ list when your problems
>apparently have nothing to do with GTK+.
>
>[1]
>https://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax
>

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Fwd: Fw: Re[2]: argv

[Emmanuele Bassi]

Hi;

I hope you realize you're asking on the GTK+ app development list
about a problem you have when writing Assembly. To say that you're
asking on the wrong list is probably an understatement.

GTK+ only provides a C API, which is usually consumed via C; if you're
trying to use it via platform-specific Assembly then you're completely
on your own. My strong suggestion is to write a small C test case, and
look at a disassembly of a small C program looks like, if you still
want to continue trying to use the GTK+ API in Assembly.

There's another misconception you have, though, that I think explains
why you're getting answers you don't like:

On 15 April 2016 at 18:59, Andrew Robinson  wrote:

> I hope this thread makes the news. I want people to see how horrible the Linux
> community is at supporting or encouraging it's customers.

"Customer" is a person who pays somebody else for services rendered.
You are not paying anybody, here. This is a community mailing list,
and we're all volunteers, here.

Finally, I hope you considered that if nobody here has answered how to
solve your Assembly issue by now it's probably because nobody here has
tried to use GTK+ API from Assembly.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[Florian Pelz]

On 04/12/2016 01:58 PM, David Marceau wrote:
> If you really need to resort to assembler, just run the gcc/g++ compiler
> with the "-c -S" to generate the assembler to see how they gcc compiler
> does it with the above gtkhello.c

This here really is good advice. If you don't want to read GNU assembler
language, then make gcc output Intel assembler syntax (see [1]).

That said, you are asking for advice on a GTK+ list when your problems
apparently have nothing to do with GTK+.

[1]
https://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Fwd: Fw: Re[2]: argv

[Andrew Robinson]

Hi David,

I am here because I have a problem getting GTK+ to work and am seeking
community support. So I was surprised to see this off-the-record email
response from David ...



>On 4/15/2016 at 5:03 AM, David Marceau  wrote:

>You should be using 64-bit hardware by now and I encourage you to get some.
>Then try straight GNU/Linux rather than windows.  ArchLinux and Debian
>are the go-to choices in respective order of my preference.
>If all hell breaks loose and I need to use Windows, then MSYS2 is where
>I decide to land and so should you.

>If you learn about assembler,then you'll need to expose yourself to gnu
>assembler because you are eventually going to care about portability.
>Otherwise stick to c++ or golang and forget about assembler and focus
>your efforts on your problems at hand rather than smaller assembler
>instructions.  You're tripping up on very trivial stuff.  arguments.
>You would have overcome this problem in seconds if you had been using
>golang rather than assembler or gcc/g++.  The gtk stuff is doable and
>portable from golang also with gotk3 and go-gtk.

1) All my hardware is 64-bit ... that has nothing to do with my problem.

2) Are you trying to say that GTK+ doesn't work very well in Windows or that
no one in the Linux world wants to support any Windows related issues, and
that is why I should get rid of anything Windows related and move over to
Linux?

3) I do not need to know GNU assembly to understand the workings GTK+ or to
program my app. GNU is cryptic because it deviates from the machine code
language used to document microprocessor operation by ALL microprocessor
manufacturers, so it is very reasonable to not want to learn it or use it.

4) My program is portable, not because it is written in ASM but because it is
a GTK+ program. Since my program is not open source, nobody has to know.

5) A great number of DLLs and apps are 32-bit code and probably will always be
32-bit because  32-bit has some advantages that 64-bit does not. I
need some of those 32-bit DLLs as helper functions for my program. 32-bit and
64-bit DLLs cannot be mixed, I don't want to resort to COM objects or some
other such nonsense, so I settled for a 32-bit only solution for my app.

I know you have a problem with what I am doing and why I am doing it, but I am
here to solve my problems, not yours.

The bottom line is, none of your "advice" helps me to fix my "trivial"
problem, it is a dodge and evade of my problem. It still won't work and am I
basically being told to not expect any help because no one will attempt to
reproduce the issue, that no one will actually look into the issue, that I am
using the wrong programming language, that I am using the apparently inferior
Win32 GTK+ libraries, that I should be using a different OS, and then all my
problems would go away. All that advice has done is give me a very good reason
to never want to switch to Linux or any of it's derivatives.

I hope this thread makes the news. I want people to see how horrible the Linux
community is at supporting or encouraging it's customers. Thanks for turning
me off to Linux forever and I hope this thread turns many other people off to
Linux forever too. At least the community "support" I have received here
explains why, even with the extra horrible Win8 and Win10 releases, Linux
STILL cannot make a dent in the desktop OS world -- and never will.

Have a nice day,

Andrew

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Hi John,

The C code for main(int argc, char *argv[]) is standardized and can only mean
one thing on a 32-bit version of any program: argc is an immediate value of 4
bytes length and argv is a 4-byte pointer to an array of 32-pointers to
zero-terminated strings. Then when main is called, it will first push the
32-bit argv integer value, then push a 32-bit argc pointer, then push the
32-bit return address. So the offsets are correct, i.e. -- [ebp-0] = return
address of callee, [ebp-4] = int argc, and [ebp-8] = *argv.

So debugging this is easy: look at the first three 32-bit items on the stack
at the entry point of main(), and look for an integer value of 4 (because I
have three test parameters on the command line that I am passing) on the
stack. But it does not exist *anywhere* on the stack, even 20 or 30 items
down. But then the API documentation for GTK+ says that argc is not an int,
but a pointer to an int (int *argc and char ***argv). So if I presume
everything on the stack is a pointer, I still cannot find the integer value of
4. The closest I have come is a value of 2, which is still wrong. I don't know
if I mentioned this, but *every* value on the stack points to nonsense
(meaning "not the command line or it's address"), no matter how far you
recurse into it. The address where the command line string is contained is not
even close to being referenced by anything on the stack. It's interesting that
my debugger can automatically find the command line but GTK+ cannot.

Therefore it would make sense that the code you have posted below does not
work due to the above mentioned observations, although according to the
documentation it seems as though it should ... unless the API documentation is
wrong or my 32-bit GTK+ runtimes I got from the GtkD project are corrupted
with bad source code or that GtkD used a compiler parameter that restricts the
runtimes to processing of the GUI only. So I did a little research and
discovered that there is a function for getting the command line in GTK+:

g_application_new(G_APPLICATION_HANDLES_COMMAND_LINE)

which used in conjunction with g_signal_connect() and G_CALLBACK, passes it
off to a function where you can use the code like you posted below, with the
usual expected results. Why have this function though, if a simple direct
routine like you posted below would work? It would be overkill, but I am going
to try using this method and if it works, it would prove that the GTK+ API
documentation is incorrect, that argc and argv are not pointers or values, but
handles -- at least in the 32-bit version of GTK+ for Windows. This would
explain why I can't make it work in GTK+ v3.18 or why the code posted below
doesn't work.

Andrew

On 4/14/2016 at 8:03 AM, John Coppens <j...@jcoppens.com> wrote:
>On Sat, 9 Apr 2016 18:39:49 -0700
>"Andrew Robinson" <arobinso...@cox.net> wrote:
>
>> The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
>> debugger and looked at the stack, and there is nothing else on the stack
>> except for ebp, rtn addr, and these two parameters. I even tried
>> daisy-chaining the addresses to see where they would lead, and they are not
>> even close to pointing to the actual command line. I can easily find the
>> command line using a memory search, so I know what address it should be.
What
>> am I doing wrong here? I have:
>
>Never done this, and I don't have Windows, so I don't know if this is useful.
>
>- The command line you found may not be the same as is passed to main().
>Recall that that argv is an array of strings, not pointers to the actual
>command line.
>
>- This program shows the addresses of the individual args:
>
>#include
  
>   
>int
>main(int argc, char *argv[]) {
>  int i;
>
>  for (i = 0; i < argc; i++) {
>printf("%p: %s\n", [i], argv[i]);
>  }
>
>  return 0;
>}
>
>~$ ./args a b c d
>0x7ffd48ffc538: ./args
>0x7ffd48ffc540: a
>0x7ffd48ffc548: b
>0x7ffd48ffc550: c
>0x7ffd48ffc558: d
>
>As you can see, the addresses are aligned to 8 byte levels, as this is a
>64-bit computer. Your offsets could be wrong, as they depend on the
>word length of the computer.
>
>John

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

[John Coppens]

On Sat, 9 Apr 2016 18:39:49 -0700
"Andrew Robinson" <arobinso...@cox.net> wrote:

> The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
> debugger and looked at the stack, and there is nothing else on the stack
> except for ebp, rtn addr, and these two parameters. I even tried
> daisy-chaining the addresses to see where they would lead, and they are not
> even close to pointing to the actual command line. I can easily find the
> command line using a memory search, so I know what address it should be. What
> am I doing wrong here? I have:

Never done this, and I don't have Windows, so I don't know if this is useful.

- The command line you found may not be the same as is passed to main().
Recall that that argv is an array of strings, not pointers to the actual
command line.

- This program shows the addresses of the individual args:

#include   
    
   
int
main(int argc, char *argv[]) {
  int i;

  for (i = 0; i < argc; i++) {
printf("%p: %s\n", [i], argv[i]);
  }

  return 0;
}

~$ ./args a b c d
0x7ffd48ffc538: ./args
0x7ffd48ffc540: a
0x7ffd48ffc548: b
0x7ffd48ffc550: c
0x7ffd48ffc558: d

As you can see, the addresses are aligned to 8 byte levels, as this is a
64-bit computer. Your offsets could be wrong, as they depend on the
word length of the computer.

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re[2]: argv

[Andrew Robinson]

Hi David,

Yes I use gtk_init(), since it is impossible to run any GTK application
without it (or at least one of it's alternatives). I have a complete working
application but when I tried making a simple modification to the source to
read the command line, it won't work and I can't figure out why.

We both interpret the documentation for gtk_init() the same way, namely that
argc and argv exist before and after gtk_init(), the only difference being
that gtk_init() strips out only the GTK command arguments from the command
line, leaving the rest of the arguments alone. In my case, since I am not
passing any GTK specific commands, argc and argv should remain untouched by
gtk_init(). In both cases, argc and argv do not contain any data that makes
sense.

I didn't compile my own version of the GTK runtime libraries, since the GTK
project doesn't support providing precompiled runtime binaries for Gtk+3 Win32
or Win64. I am looking for a simple plug-and-play solution to my current
project therefore I didn't want to start yet another project in order to
create my own GTK runtime binaries, so I "borrowed" the only ones I could find
from the GtkD project. There is nothing wrong with doing that, is there?

I looked at your example below and I notice many peculiar things about it:

1) It uses the 64-bit Linux libraries whereas I am using the 32-bit Win
libraries
2) GCC assembly language sucks :^)
3) Despite #2 above, I noticed something very peculiar about the disassembly
code. For argv, GCC uses a 32-bit register, whereas for the argc, GCC uses a
64-bit register. This isn't documented anywhere. Does this apply to 32-bit Win
code as well, i.e. -- argv would use a 32-bit register and argc would use a
16-bit register? This disassembly example violates the 64-bit code convention
used by the C standard and by the Win and Linux OSes as well.
4) The documentation implies argc and argv are consecutive parameters, yet
they are not consecutive in the disassembly. One has an offset of 32 and the
other of 20, when they should be 24 and 32. This too isn't documented anywhere
but apparently has something to do with #3 above. This could be my problem so
I will try different offsets to the stack to see what it returns.
5) It uses the Gtk+2 libraries whereas I am using Gtk+3. It appears that the
Gtk+2 libraries pass parameters in the registers and there is no stack
cleanup, whereas the Gtk+3 libraries pass parameters on the stack and stack
cleanup is required. Again, not documented. This may not matter unless I
wanted to convert my application later on to 64-bit, so this is good to know
beforehand.

Live long and prosper,
Andrew

On 4/12/2016 at 4:58 AM, David Marceau <uticdmarceau2...@yahoo.ca> wrote:
>Taken from an older gtk tutorial, but nevertheless should apply to your
>situation:
>http://www.gtk.org/tutorial1.2/gtk_tut-2.html
>
>#include 
>
>int main( int   argc,
>  char *argv[] )
>{
>GtkWidget *window;
>
>//<<<<<<<<<<<<<<<<<<<<<<<<<<<
>//DID YOU INTRODUCE THIS LINE IN YOUR CODE?
>gtk_init (, );
>//>>>>>>>>>>>>>>>>>>>>>>>>>
>
>window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
>gtk_widget_show  (window);
>
>gtk_main ();
>
>return(0);
>}
>
>
>"Here is our gtk_init again. As before, this initializes the toolkit,
>and parses the arguments found on the command line. Any argument it
>recognizes from the command line, it removes from the list, and modifies
>argc and argv to make it look like they never existed, allowing your
>application to parse the remaining arguments.
>
>   gtk_init (, );
>"
>
>DID YOU CATCH THAT LAST PART?  It grabs any arguments that are gtk
>specific and removes them.  The leftover arguments are left within the
>argv array.  Did you call gtk_init?  Did you pass any non-GTK-switch
>arguments to your app?  If not, it would explain why your argsv holds
>empty/uninitialized values.
>
>If you really need to resort to assembler, just run the gcc/g++ compiler
>with the "-c -S" to generate the assembler to see how they gcc compiler
>does it with the above gtkhello.c
>
>THIS IS THE ENVIRONMENT SETUP ON DEBIAN LINUX:
>pkg-config --cflags --libs gtk+-2.0
>
>-pthread -I/usr/include/gtk-2.0
>-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/
>-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0
>-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12
>-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
>-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
>-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2
>

Re: argv

[David Marceau]

Taken from an older gtk tutorial, but nevertheless should apply to your
situation:
http://www.gtk.org/tutorial1.2/gtk_tut-2.html

#include 

int main( int   argc,
  char *argv[] )
{
GtkWidget *window;

//<<<<<<<<<<<<<<<<<<<<<<<<<<<
//DID YOU INTRODUCE THIS LINE IN YOUR CODE?
gtk_init (, );
//>>>>>>>>>>>>>>>>>>>>>>>>>

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show  (window);

gtk_main ();

return(0);
}


"Here is our gtk_init again. As before, this initializes the toolkit,
and parses the arguments found on the command line. Any argument it
recognizes from the command line, it removes from the list, and modifies
argc and argv to make it look like they never existed, allowing your
application to parse the remaining arguments.

   gtk_init (, );
"

DID YOU CATCH THAT LAST PART?  It grabs any arguments that are gtk
specific and removes them.  The leftover arguments are left within the
argv array.  Did you call gtk_init?  Did you pass any non-GTK-switch
arguments to your app?  If not, it would explain why your argsv holds
empty/uninitialized values.

If you really need to resort to assembler, just run the gcc/g++ compiler
with the "-c -S" to generate the assembler to see how they gcc compiler
does it with the above gtkhello.c

THIS IS THE ENVIRONMENT SETUP ON DEBIAN LINUX:
pkg-config --cflags --libs gtk+-2.0

-pthread -I/usr/include/gtk-2.0
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2
-lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo
-lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
-lglib-2.0 -lfontconfig -lfreetype

THIS IS TO COMPILE THE ABOVE GTKHELLO
gcc gtkhello.c `pkg-config --cflags --libs gtk+-2.0`

THIS IS TO GENERATE THE ASSEMBLER FOR GTKHELLO
gcc -S gtkhello.c `pkg-config --cflags --libs gtk+-2.0`

cat gtkhello.s
.file   "gtkhello.c"
.text
.globl  main
.type   main, @function
main:
.LFB206:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movl%edi, -20(%rbp)
movq%rsi, -32(%rbp)
leaq-32(%rbp), %rdx
leaq-20(%rbp), %rax
movq%rdx, %rsi
movq%rax, %rdi
callgtk_init
movl$0, %edi
callgtk_window_new
movq%rax, -8(%rbp)
movq-8(%rbp), %rax
movq%rax, %rdi
callgtk_widget_show
callgtk_main
movl$0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE206:
.size   main, .-main
.ident  "GCC: (Debian 5.3.1-14) 5.3.1 20160409"
.section.note.GNU-stack,"",@progbits



Cheers,
David Marceau



On 04/09/2016 09:39 PM, Andrew Robinson wrote:
> This should be easy, but it is not. I am writing an assembly language program
> involving GTK+. I want to parse the command line for options but am unable to
> do so. The code to find argv and argc is simple:
> 
> main:
>push ebp
>mov ebp, esp
>lea eax, [ebp + 12]
>lea ecx, [ebp + 8]
> 
> The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
> debugger and looked at the stack, and there is nothing else on the stack
> except for ebp, rtn addr, and these two parameters. I even tried
> daisy-chaining the addresses to see where they would lead, and they are not
> even close to pointing to the actual command line. I can easily find the
> command line using a memory search, so I know what address it should be. What
> am I doing wrong here? I have:
> 
> Gtk3+
> Win32
> v3.18.3.0
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

argv

[Andrew Robinson]

This should be easy, but it is not. I am writing an assembly language program
involving GTK+. I want to parse the command line for options but am unable to
do so. The code to find argv and argc is simple:

main:
   push ebp
   mov ebp, esp
   lea eax, [ebp + 12]
   lea ecx, [ebp + 8]

The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
debugger and looked at the stack, and there is nothing else on the stack
except for ebp, rtn addr, and these two parameters. I even tried
daisy-chaining the addresses to see where they would lead, and they are not
even close to pointing to the actual command line. I can easily find the
command line using a memory search, so I know what address it should be. What
am I doing wrong here? I have:

Gtk3+
Win32
v3.18.3.0
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

How can I get argc and argv from Gtk+ API?

[zxx zxx]

Hi all:

I have some experience in Qt but not Gtk+. I can get argc and argv from
Qt API when I develop application with Qt4:
QCoreApplication::argc();
QCoreApplication::argv();

But I don't know how to get argc and argv from Gtk+ API when I develop
application with Gtk+.
Does anyone know how to get argc and argv from Gtk+ API? please tell
me.

Thanks :)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How can I get argc and argv from Gtk+ API?

[David Nečas]

On Tue, Aug 09, 2011 at 03:19:16PM +0800, zxx zxx wrote:
 I have some experience in Qt but not Gtk+. I can get argc and argv from
 Qt API when I develop application with Qt4:
 QCoreApplication::argc();
 QCoreApplication::argv();
 
 But I don't know how to get argc and argv from Gtk+ API when I develop
 application with Gtk+.
 Does anyone know how to get argc and argv from Gtk+ API? please tell
 me.

You get argc and argv as arguments to your main() function as usual.

Or from the GApplicationCommandLine argment passed to your
command-line handler of GtkApplication/GApplication if you use the
GApplication framework.

Yeti

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

argv at gtk_init (argc, argv)

[Xu, Ming (NIH/NLM/NCBI) [F]]

Hello.

wxWidget wraps gtk on linux/unix port. I used its wxMemoryDC to draw
bitmaps onto memory buffer on a c++ cgi application, where wxFont, wxPen,
wxBrush, etc, all need underneath gtk libs to be initialized. I just started 
with gtk_init (NULL, NULL) but I would like to utilize argv
like --gtk-module, --display, etc to specifying display deivce. 

===
gtk_init (argc, argv) looks for the following argv options:

--gtk-module
--g-fatal-warnings
--gtk-debug
--gtk-no-debug
--gdk-debug
--gdk-no-debug
--display
--sync
--name
--class
=

could you give me the references/samples on how to use argv features.

after one instance of the cgi application run and called gtk_init (argc, 
argv), what happends when the second instance of the cgi application start to 
run and call it  again ?
do the two cgi instances have separate gtk libs workspace or they share gtk 
libs workspace ?

after calling gtk_init (argc, argv), do I need to do something on gtk before 
application exits ?

thanks in advances

ming
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list