I think I did have some time early -90's someone did alternative C0.lib which actually when you linked it with your programs it made much easier porting some *nix software to MS-DOS. No need to make modifications command line handler, as that modified startup-library as I think it's or was called, did what was needed.
It was then COMMAND.COM ie. Dos command line did not do that. And there were alternatives like something called 4DOS which I did never use, but those could have done it. Or did they?
I have't used Windows for quite long time. And I do not know if CMD.EXE or PowerShell whatever its name are any better. Maybe someone knowing would like to comment this.
This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
Powershell is a completely different model where native commands run in-process, you can import commands and invoke APIs from arbitrary .NET assemblies, and then the PS runtime handles all argument parsing (and many other things). But it also lets you invoke and interop with arbitrary command-line executables and then those do their own parsing like they always have.
This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
So is that CreateProcess much different from nix execve() which passes just a pointer to string of executable first followed by pointers to arguments *argv[], and process environment same way *envp[]?
Thus it is the shell which responsibility is to expand all wildcards before passing to that executable arguments nix systems, which do not expand any wildcards itself before passing to executed program.
I'm no Windows programmer so, genuinely what's the difference from point of executed program and just that Windows any shells do not expand wildcards etc. ?
My previous post when I did mention that alternative c0.obj (not lib, sorry) that I for example had about 36 years ago from somewhere was a nifty modified trick which took that plain dumb MS-DOS COMMAND.COM passed string and instead just making it a char *argv[] array first expanded wildcards before your main() got control. It did work very well and saved quite bit of effort when I ported some tools to MS-DOS and I think there was another version of it for OS/2 (1.something) that I used also.
I did not have to add ported software from unix any command line expanding code myself because that alternative startup c0.obj did it for me. Shame I do not remember where I got it and who did it, but it was really good. Now thinking of it perhaps it was from Compu$erve some forum or WSMR-SIMTEL20 archive.
I remember that also Fabrice Bellards lzexe and something spawnsq() (not sure about exact name any more) library also was in use. The latter swapped (saved out file) out running most of MS-DOS program before executing like execve() and freed a lot more memory to run that other program then loading it back when called program was done. I think it used something like 8k memory while resident when other called was running. Which was often enough and no need do any horrible .BAT rewrite tricks to able to accomplish same functionality.
PowerShell has a built-in command parser that all cmdlets share (provided commands; `function` based command scripts; so forth) and it's in a C# library that other .NET-based CLIs can import if they like (though today it's still not that common in writing .NET CLIs to use PowerShell's command parser and not a simpler one or the new-ish System.CommandLine which also doesn't quite resemble PowerShell's built-in one).
no, Windows still leaves that to the program. Usually handled by the msvc runtime for argv/argc, but the base windows API is GetCommandLine, giving you a single string.
Comments
And in the many decades and OS rewrites since, they have long since corrected this mistake... right?
I think I did have some time early -90's someone did alternative C0.lib which actually when you linked it with your programs it made much easier porting some *nix software to MS-DOS. No need to make modifications command line handler, as that modified startup-library as I think it's or was called, did what was needed.
It was then COMMAND.COM ie. Dos command line did not do that. And there were alternatives like something called 4DOS which I did never use, but those could have done it. Or did they?
I have't used Windows for quite long time. And I do not know if CMD.EXE or PowerShell whatever its name are any better. Maybe someone knowing would like to comment this.
This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
Powershell is a completely different model where native commands run in-process, you can import commands and invoke APIs from arbitrary .NET assemblies, and then the PS runtime handles all argument parsing (and many other things). But it also lets you invoke and interop with arbitrary command-line executables and then those do their own parsing like they always have.
So is that CreateProcess much different from nix execve() which passes just a pointer to string of executable first followed by pointers to arguments *argv[], and process environment same way *envp[]?
Thus it is the shell which responsibility is to expand all wildcards before passing to that executable arguments nix systems, which do not expand any wildcards itself before passing to executed program.
I'm no Windows programmer so, genuinely what's the difference from point of executed program and just that Windows any shells do not expand wildcards etc. ?
My previous post when I did mention that alternative c0.obj (not lib, sorry) that I for example had about 36 years ago from somewhere was a nifty modified trick which took that plain dumb MS-DOS COMMAND.COM passed string and instead just making it a char *argv[] array first expanded wildcards before your main() got control. It did work very well and saved quite bit of effort when I ported some tools to MS-DOS and I think there was another version of it for OS/2 (1.something) that I used also.
I did not have to add ported software from unix any command line expanding code myself because that alternative startup c0.obj did it for me. Shame I do not remember where I got it and who did it, but it was really good. Now thinking of it perhaps it was from Compu$erve some forum or WSMR-SIMTEL20 archive.
I remember that also Fabrice Bellards lzexe and something spawnsq() (not sure about exact name any more) library also was in use. The latter swapped (saved out file) out running most of MS-DOS program before executing like execve() and freed a lot more memory to run that other program then loading it back when called program was done. I think it used something like 8k memory while resident when other called was running. Which was often enough and no need do any horrible .BAT rewrite tricks to able to accomplish same functionality.
PowerShell has a built-in command parser that all cmdlets share (provided commands; `function` based command scripts; so forth) and it's in a C# library that other .NET-based CLIs can import if they like (though today it's still not that common in writing .NET CLIs to use PowerShell's command parser and not a simpler one or the new-ish System.CommandLine which also doesn't quite resemble PowerShell's built-in one).
no, Windows still leaves that to the program. Usually handled by the msvc runtime for argv/argc, but the base windows API is GetCommandLine, giving you a single string.
EDIT: https://nullprogram.com/blog/2022/02/18/