The Old New Thing

.net is an os component.

It's should not be the app developer's duty to parse the command line.

> .net is an os component.

Well no, actually, it isn't.  It's an optional addon, see where Windows Update / Microsoft Update put it.

See also this blog's tagline:

> not actually a .NET blog

Now:

> It's should not be the app developer's duty to parse the command line.

There I agree; that's why I think the way that Unix-like OSes do it is better.  Your main() function gets handed an array of strings, rather than one long string; the shell has already done the parsing, and the kernel has kept the array-of-strings setup all the way through until it starts your program.  (Or in the case of Windows, either cmd.exe or explorer.exe has done the parsing.)

Now I realize the reason this doesn't happen is because cmd.exe used to be command.com, and it used to be that DOS only had 640K of RAM available, and command.com had to use as little of that as possible.  But that argument just means that each program had to include the same parsing code over and over again (and get it wrong in many cases!  apparently including .net for some odd command lines); it didn't mean the parsing code could go away.  Well, unless the program didn't care about its arguments; then it could go away.

For some reason, it just seems like a bad tradeoff...

Tuesday, October 03, 2006 9:09 AM by BryanK

>> .net is an os component.

>

> Well no, actually, it isn't.  It's an

> optional addon

Prior to Vista that's true, it's not a critical integrated component like IE.  However, the quoted poster was correct for Vista.

> See also this blog's tagline:

>> not actually a .NET blog

Of course that's true.  Now I'm wondering how some .NET stuff sneaked into this blog a few months ago.

> Prior to Vista that's true

And since there is no such thing as Vista yet, only betas (and RCs?), it is still true.  And depending on how many times Vista gets pushed back again before it finally gets released, it may be true for quite some time yet.

(OK, yes, I'm being pedantic now.  You're right, I wasn't paying any attention to Vista when I made that comment.)

Regarding the "not actually a .NET blog" comment, my point was that since the issue is with .Net's command line parsing code, and Raymond is on the shell team, he (1) probably has no way of even looking into the problem, and (2) very likely can't do anything about it.

Carlos commented on my blog post and set me straight. It turns out that it's not just a .NET thing, it's a CommandLineToArgvW thing.

"Most apps (including .Net apps) use CommandLineToArgvW to decode their command lines.  It uses crazy escaping rules which explain the behaviour you're seeing."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/commandlinetoargv.asp

CommandLineToArgvW has a special interpretation of backslash characters when they are followed by a quotation mark character ("), as follows:

   * 2n backslashes followed by a quotation mark produce n backslashes followed by a quotation mark.

   * (2n) + 1 backslashes followed by a quotation mark again produce n backslashes followed by a quotation mark.

   * n backslashes not followed by a quotation mark simply produce n backslashes.

A quick note about CommandLineToArgvW -- these easiest way to get the command-line back in properly parsed form is----to use the __argc and __argv global variables that *all* C (and C++) program are allowed to access.

They aren't documented very much, but they work like a charm.  And yes, I already reported to Microsoft that they should be mentioned more in the documentation :-)

I recently posted on my confusion when I tried to use commandline arguments ending in \" and got unpredictable

> And since there is no such thing as Vista yet, only betas (and RCs?), it is still true.

windows.net (server2k3) has .net framework installed, correct? At least it is bundled with windows ce .net, including windows mobile.

When .net framework is installed, it's an os component, much like directx (wasn't bundled with win95a/b - but could be installed).

> Those internal variables are specific to the Microsoft Visual C runtime.

Because argc & argv are broken, you are thus suggesting it would be better to use unportable OS specific functions (CommandLineToArgvW/GetCommandLineW)?

If you use some other company's OS you may not have those functions. But you knew that, right? I mean, you wouldn't recommend people do stuff that might break in the future, would you?

> Now your code is portable to all compilers

No, now your code is portable to all *Windows* compilers.  Unless Unix (i.e. "some other company's OS") has a CommandLineToArgvW call that acts the way Windows' does, that I've missed?  ;-P

Using the values that the C library startup routine passes to your main() function is *supposed* to work on any OS that has a C compiler.

(Now, if the program's C library uses CommandLineToArgvW to get these values, it still won't be portable as far as the user is concerned.  They'll pass "\\" on the command line, and expect one backslash and no quotes.  "\\\" will be expected to give one backslash and one quote (and not terminate the command line).  Or at least, this is what happens under any Bourne shell, and it seems a *heck* of a lot more logical to me.  But, the code will at least *compile* on other OSes.)

(To clarify: I suspect that "use the standard please" meant that you should use the arguments to main(), not the undocumented __argc and __argv variables provided by only the Microsoft C library.  But I don't know what he meant for sure, so maybe I shouldn't assume it.  And since you were talking about the undocumented variables, it seems that his argument doesn't make much sense in the context it was presented.)

int program_argc;
int program_argv;
int main(int argc, char **argv)
{
 program_argc = argc;
 program_argv = argv;
 ...
}

PingBack from http://blogs.msdn.com/michkap/archive/2006/12/13/1275292.aspx