Re: Re[2]: argv revisited

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

Re[2]: argv revisited

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,

Re[2]: argv revisited

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

Re[2]: argv revisited

>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

Re[2]: argv

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

Re[2]: argv

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

Re: Re[2]: argv

> _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.

Re: Re[2]: argv

> 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

Re[2]: argv

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

Re[2]: argv

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

Re[2]: argv

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

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

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

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

> 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

Re[2]: argv

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

Re[2]: argv

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

Re[2]: argv

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

Re[2]: argv

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

Re[2]: Re[2]: argv

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

Re[2]: argv

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

Re: Re[2]: argv

> 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

Re[2]: argv

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+

Re[2]: argv

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,

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

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

Re[2]: argv

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

Re[2]: argv

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

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

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

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

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

Re[2]: argv

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

Re[2]: argv

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