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
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 fr
Mr. Robinson,
My original email was verbose so it never made it to the mailing list so
I decided to send it directly to you. I didn't realize you're were
going to be upset with the entire community because of my answer.
There was no condescending or tone of superiority ever conveyed in that
email
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&T syntax, which is basically
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
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 shoul
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 k
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 Pel
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
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 call
> 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
argu
To all my fellow developers,
I can see that I am not going to get anywhere with anyone in this group
regarding my GTK issue, so I am abandoning my GTK+ project and moving on
because it was a critical problem. But before I move on, I think other
programmers like myself should know why I choose GTK+
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 dow
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 descri
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 thi
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
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 pop
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 a
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
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 ar
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 pro
> 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 sta
> _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.
“I
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 arg
Hi,
I collected all the necessary packages[*] to build the latest
gtk+-2.24.30. As I would like to create my own gtk+-2.0
runtime environment, I configured all these packages with
--prefix=/tmp/g2 before I ran "make" on them. Next, without
deleting a single bit in /tmp/g2, I compiled my prog
You are correct. I haven't used it in a long time. I'm glad you noticed. Did
you find anything else incorrect with what I said?
On 4/16/2016 at 2:55 PM, Errol van de l'Isle wrote:
>> _pascal was used for older 16-bit Windows programs.
>> _stdcall is used for newer 32-bit Windows programs.
>> _cde
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,
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
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.dl
29 matches
Mail list logo
