7 ms·

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 commandl

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.

kevin_thibedeau 6y ago
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.
- ChrisSD 6y ago
  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.
  - kevin_thibedeau 6y ago
    It isn't done by the shell on Windows.
    - ChrisSD 6y ago
      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.
    - mortehu 6y ago
      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?
      - kevin_thibedeau 6y ago
        You link an alternate library into the application and it will expand args for you.
sumtechguy 6y ago
https://docs.microsoft.com/en-us/windows/win32/learnwin32/winmain--the-application-entry-point 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/nf-shellapi-commandlinetoargvw 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.
- FreeFull 6y ago
  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.
  - frutiger 6y ago
    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.
  - userbinator 6y ago
    ...and I'm pretty sure DOS inherited it from CP/M.
  - Someone 6y ago
    ‘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.
- ChrisSD 6y ago
  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.
jussij 6y ago
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-argv-wargv?view=vs-2019 https://docs.microsoft.com/en-us/cpp/c-runtime-library/argc-...
- int_19h 6y ago
  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().

kevin_thibedeau 6y ago

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.

ChrisSD 6y ago
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.
- kevin_thibedeau 6y ago
  It isn't done by the shell on Windows.
  - ChrisSD 6y ago
    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.
  - mortehu 6y ago
    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?
    - kevin_thibedeau 6y ago
      You link an alternate library into the application and it will expand args for you.

sumtechguy 6y ago

https://docs.microsoft.com/en-us/windows/win32/learnwin32/winmain--the-application-entry-point 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/nf-shellapi-commandlinetoargvw 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.

FreeFull 6y ago
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.
- frutiger 6y ago
  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.
- userbinator 6y ago
  ...and I'm pretty sure DOS inherited it from CP/M.
- Someone 6y ago
  ‘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.
ChrisSD 6y ago
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.

jussij 6y ago

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-argv-wargv?view=vs-2019 https://docs.microsoft.com/en-us/cpp/c-runtime-library/argc-...

int_19h 6y ago
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().