Re[2]: argv revisited

Because you are entertaining. On 5/8/2016 at 9:09 AM, Chris Moller <mol...@mollerware.com> 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: >> Lik

Re[6]: argv revisited

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

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

lev...@yahoo.fr> 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

Re[6]: argv revisited

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 w

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

ations 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 <arobinso...@cox.net> wrote: On 5/5/2016 at 10:23 AM, Lucas Levrel <llev...@

Re[5]: argv revisited

<llev...@yahoo.fr> 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 m

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

On 5/5/2016 at 10:23 AM, Lucas Levrel <llev...@yahoo.fr> 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

Re[4]: argv revisited

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 <llev...@yahoo.fr> wrote: >Le 3 mai 2016, Andrew Robinson a écrit : > >>> I don't think I tried filenames with spaces, but I did test filenames with

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

? On 5/5/2016 at 1:04 AM, Lucas Levrel <llev...@yahoo.fr> 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

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

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 <pelzflor...@pelzflorian.de> wrote: >On 05/04/2016 03:59 PM, Andrew Robinson wrote: >> No, there are no Win32 binaries in MSYS2. Where are you getting your

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

No, there are no Win32 binaries in MSYS2. Where are you getting your information? On 5/4/2016 at 12:29 AM, Florian Pelz <pelzflor...@pelzflorian.de> 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 Win

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

On 5/3/2016 at 5:42 PM, Allin Cottrell <cottr...@wfu.edu> 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 (

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

relli <paolo.bore...@gmail.com> wrote: On Tue, May 3, 2016 at 11:52 PM, Andrew Robinson <arobinso...@cox.net> 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

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

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

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

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

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: Compiling for Windows [Was: argv revisited]

t;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

argv revisited

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

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

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

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

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: >> Assembl

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

Farewell

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

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

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

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

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

2016 at 12:30 PM, Mark Cianfaglione <m.cianfagli...@valydate.com> 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 m

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

ng 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

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

sted 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 nonsen

Re[2]: argv

gt; 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

argv

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