It did, and also up till 3.0 (thus 2.10 and 2.11) had also SWITCHAR which you could change command options character / to - like in it was in UNIX convention, from CONFIG.SYS definition.
The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards.
I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular.
e: Now did it change also path separator from \ to / ?
It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.
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.
And file handles stdin, stdout, stderr same file numbers also. There was and still is overlapping features with Microsoft later and current operating systems.
Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.
Thankfully they ditched it. One of the best things about DOS was that it gave users control over the directory structure. While other OS's just barfed a billions directories all over your disk on install and spewed system files wherever they felt like it, DOS let you decide where you wanted things with the exception of a couple of files in the root directory. This did mean that some people just dumped everything into the root of their system drive, but everyone else could organize things however they wanted. You could learn a lot about someone, and their system, with a single dir command.
True, it wasn't without it's limits, you could also get some potentially undesirable results if you got overly creative with directory/file names, but it was still the best in terms of giving you freedom to organize
Comments
Unexpectedly, MS-DOS 2.0 included a /dev directory.
https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...
It did, and also up till 3.0 (thus 2.10 and 2.11) had also SWITCHAR which you could change command options character / to - like in it was in UNIX convention, from CONFIG.SYS definition.
The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards.
I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular.
https://www.homecomputermuseum.nl/en/collectie/act-computers...
e: Now did it change also path separator from \ to / ? It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.
Oh my, I'm sorry how many typos I made and forgot to fix.
s/ARAIC/AFAIC/g s/70kb/720kB/g
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/
A lot of early dos development was trying to see how many unix concepts they could fit, directories, pipes, environment, devices.
And file handles stdin, stdout, stderr same file numbers also. There was and still is overlapping features with Microsoft later and current operating systems.
Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.
Thankfully they ditched it. One of the best things about DOS was that it gave users control over the directory structure. While other OS's just barfed a billions directories all over your disk on install and spewed system files wherever they felt like it, DOS let you decide where you wanted things with the exception of a couple of files in the root directory. This did mean that some people just dumped everything into the root of their system drive, but everyone else could organize things however they wanted. You could learn a lot about someone, and their system, with a single dir command.
try making an AUX directory, or CON file, or PRN
True, it wasn't without it's limits, you could also get some potentially undesirable results if you got overly creative with directory/file names, but it was still the best in terms of giving you freedom to organize