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[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[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[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[2]: argv

[Andrew Robinson]

On 4/16/2016 at 1:47 PM, Enno Borgsteede  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[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[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  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[2]: argv

[Andrew Robinson]

On 4/16/2016 at 6:47 AM, David Marceau  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  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[2]: argv

[Andrew Robinson]

On 4/15/2016 at 11:53 PM, Florian Pelz  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[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[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[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[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: 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  wrote:
>On Sat, 9 Apr 2016 18:39:49 -0700
>"Andrew Robinson"  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  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
>-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