Hacker News Reader

Comment by ChrisSD | Hacker News Reader

In the Windows world there is no argc/argv. There is only the commandline string. The C runtime will parse this to emulate the required arguments.

The commandline is stored in the process environment block and can be set to anything when the process is created.

View on HN

https://docs.microsoft.com/en-us/windows/win32/learnwin32/wi...

You then pass it into https://docs.microsoft.com/en-us/windows/win32/api/shellapi/... to get it split out if you need it.

I can see why they did it that way. No reason to waste cycles on something if you do not need it. Though most frameworks go and call it for you anyway these days.

It's a carryover from the MS-DOS days. One unfortunate part is that each program has to implement globs and any similar feature itself.

Even in a modern Unix, globs are expanded by the shell before invoking exec(3) with the individual arguments split out. They are not split/expanded by the C runtime.

...and I'm pretty sure DOS inherited it from CP/M.

‘Implement’ isn’t necessary. That code could be provided by a shared library.

That could be the superior option. Moving command line expansion into a shared library gets rid of the problem where the command line with globs expanded is too long, could have standardized option handling earlier (that system-provided library for globbing could easily grow to handle option flags), could better handle file names containing spaces, etc.

Note that WinMain isn't the "real" entry point either. The C runtime calls WinMain after doing its startup. By convention the entry point is one of:

* mainCRTStartup

* wmainCRTStartup

* WinMainCRTStartup

* wWinMainCRTStartup

Conveniently these all have the exact same function signature (i.e. the real entry point signature). For example:

    extern "C" int WinMainCRTStartup()

Although obviously the C runtime implementations differ for each of the listed entry points.

https://docs.microsoft.com/en-us/cpp/build/reference/entry-e...

You can also set what it is using that compiler option if you want. You usually do not want to as the default versions do quite a bit of stuff. I think the winmain one was the 3.x default. But changed when they added in other bits (I want to say threading, and console setup but I could be wrong).

Windows is a weird one as it has this odd DOS/VMS/OS2/Win16/32 heritage so entry into the program is one that has some bagage. Winmain is one of those leftovers. The params passed in need to use the functions associated to them.

My advice is always with this stuff. read the docs. There is a ton of info in there. It is kind of picky to get just right.

I'd also add that CommandLineToArgvW doesn't do exactly the same thing that the C runtime does to parse arguments. They used to be the same but the C runtime was tweaked in 2008 whereas CommandLineToArgvW was kept the same for backwards compatibility. See http://daviddeley.com/autohotkey/parameters/parameters.htm#W...

Huh. Wouldn't this have caused inter-operability problems for programs that spawn other processes?

Presumably they would have tested extensively for regressions. But I'm not sure what would break that wasn't already broken. It was an obscure undocumented case that was not intuitive.

Other links with code to parse/construct command lines:

- https://web.archive.org/web/20200128073602/http://www.window...

- https://web.archive.org/web/20191119112915/https://blogs.msd...

The Windows applications can still access this information using the __argc and __argv global variables:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/argc-...

These also come from the C runtime, not from Windows itself.

And if you are building the app with the C runtime, you may as well just use regular main().

You can make Windows pre-process the command line args and expand globs so that main() works like normal on Unix. It just isn't the default.

The shell can do whatever processing it likes but at the end of the day all that's passed to the application is a string. The string may or may not be what a user typed but the application has no knowledge of that.

It isn't done by the shell on Windows.

The shell is whatever you use as a shell. Be that cmd, powershell or your own invention. My point is that it doesn't matter. The shell can process the command line however it likes but all the application receives is a single string.

The application can then do whatever it likes with the string. Sure you can use an entry point that parses the arguments in different ways but that's still the application parsing the string. You're just using a library function to do the parsing instead of doing it manually.

At no point does "Windows" do anything. As far as its concerned it's just a string being passed in at process creation.

If it's not the shell and not the application, are you saying there's a kernel setting that enables glob expansion?

I suspect you're really talking about linking to setargv.obj?

You link an alternate library into the application and it will expand args for you.

Reply on news.ycombinator.com