E. Scott Larsen wrote:
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
I find this hard to believe, as WinMain is just given a pointer into the command line returned by GetCommandLine(), incremented past the program name and any following space.
don't remember which is which, but one gives just the executable name,
one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all.
I can imagine there's some variation in program name; it's normal for programs to be started with short names rather than their full filenames. The quoting is weird though; that should be removed before you see it.
Also, I _distinctly_ remember something very whacky when I used unicode, I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth.
According to the docs, this ought to work: wchar_t ** argv; int argc; argv = CommandLineToArgvW(GetCommandLineW(), &argc); but I've never tried it; maybe it doesn't. If you were using WinCE then I feel your pain and hope you've recovered.
hmmm, I wonder why we were having so much trouble with it then? Maybe we were using __argv or something like that because we needed the executable and GetCommandLine() stripped it? I honestly don't remember. I _do_ remember significant problems with it though. Everything you say below looks familiar. Hmmm.... Ben Hutchings wrote:
E. Scott Larsen wrote:
Just FYI to this thread in general. It's been a while since I've
messed
with WinMain and command lines, but if my memory serves me right (it
was
at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
I find this hard to believe, as WinMain is just given a pointer into the command line returned by GetCommandLine(), incremented past the program name and any following space.
don't remember which is which, but one gives just the executable name,
one gives the full path to the executable (seems like there's two variations on this, like one is quoted and one is not, don't remember the details), and it seems like there's one that doesn't give the executable at all.
I can imagine there's some variation in program name; it's normal for programs to be started with short names rather than their full filenames. The quoting is weird though; that should be removed before you see it.
Also, I _distinctly_ remember something very whacky when I used
unicode,
I don't remember the details, but the commandline arguments were a significant pain for a program built with unicode support using the unicode windows entry function. That still tastes bad in my mouth.
According to the docs, this ought to work:
wchar_t ** argv; int argc; argv = CommandLineToArgvW(GetCommandLineW(), &argc);
but I've never tried it; maybe it doesn't.
If you were using WinCE then I feel your pain and hope you've recovered.
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"Ben Hutchings"
E. Scott Larsen wrote:
Just FYI to this thread in general. It's been a while since I've messed with WinMain and command lines, but if my memory serves me right (it was at a different place, so I don't have the code here), there's some additional whacky issues here. WinMain recieves the first arguments differently depending on how it is run: *) from MSVC debugger *) from a commandline *) by clicking on an shortcut icon *) by clicking in an explorer window
I find this hard to believe, as WinMain is just given a pointer into the command line returned by GetCommandLine(), incremented past the program name and any following space.
I don't understand this either. Looking at the MFC code for CWinApp::ParseCommandLine() in appcore.cpp, line 433, this uses __argc and __targv and works in all the situations above. I'd conclude from that that the command lines are consistent, wrt parameter placement, on a single platform, and across Win32 platforms supported by the library (All desktop Win32 OSs). I have seen differences, however, with the formation of the module name - include/excluding the full path in short/long format. If long format is used, then it can be/is enclosed in double quotes to cope with spaces in paths, eg "Program Files".
According to the docs, this ought to work:
wchar_t ** argv; int argc; argv = CommandLineToArgvW(GetCommandLineW(), &argc);
but I've never tried it; maybe it doesn't.
According to my MSDN (MSVC 7.0), CommandLineToArgvW support varies between platforms: Windows NT/2000/XP: Included in Windows NT 3.5 and later. Windows 95/98/Me: Unsupported. I'd assume this is because it's unicode which is unsupported directly on 9x platforms, but there is no ANSI version - CommandLineToArgvA(). -- Craig
participants (3)
-
Ben Hutchings -
Craig Henderson -
E. Scott Larsen