通过

more fun with GetCommandLine()

  • 项目

Raymond mentioned this particular API once.  I mention it, because I had to call it today.  A certain third party app has existed for many years, happily calling CreateProcess() and not putting a space in the lpCommandLine string between the executable name and the first argument.  (I assume this was a bug, not intentional.) This worked for them because the program files directory has a space in it; thus the full path to the executable has quotes around it. 

Example malformed command line:
lpCommandLine = ""c:\program files\application\app.exe"param1 param2 ..."

CreateProcess(), aparently, matches the quotes and ignores everything else past the closing quote--at least in as much as it needs to figure out what executable to run.  This actually worked just fine for previous versions of IE, because IE parsed the command line in a similar way, just looking for the close quote and assuming everything after it was an argument, even if there was no whitespace.  However, for IE7 we changed it to not call GetCommandLine() for the arguments, but just to use the parameters passed to WinMain(), which--surprise, surprise--meant we did not get param1.  (This was done for various reasons that are not relevant to this discussion.)  This, of course, means apps that used to work no longer work, and we need to fix that.

So I am looking at changing IE's argument parsing back to the old code.  What is my point?  I have two reasons for bringing it up.  First, I just like to tell app-compat stories.  Here is more fuel for the "break them or accomodate them" debate.  (What would you do?) Second, GetCommandLine() returns a non-const string, which I found odd.  What happens if I change it?  What if someone calls GetCommandLine() after I change it?  (Note to self: sometime, when it is not so late, try it and see what happens.)

Comments