"Ben Hutchings" <ben.hutchings@businesswebsoftware.com> wrote in message news:A7F746377BDB7D4EA8E6623AF92F43C80C7C5C@copper.bwsint.com...
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