The Road to MS-DOS 2.0

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.

But only the first 256 KB was on the motherboard, you needed a memory expansion card for the extra 384 KB, and I don't think they really existed in 1982.

Actually, you could somewhat break the 640KB limit in the early days (not that most people could afford that much RAM) days. Until EGA came along in 1984, there was free address space upto 704KB that you could use as conventional memory without much issue (or 736KB if you limited yourself to CGA).

And later we had the mess of EMS, which would work on the original 5150 with the right expansion card (and the right software to take advantage of it, like Lotus 123)

It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.

Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.

Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.

ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.

But when Turbo C with assembler (TASM) came out those were just great. And by that asm output generating feature it was often way faster way to write something first in C, translate to asm and go from there do what you wanted with that asm directly. I'm not sure which higher level compilers came with that feature, but once available it was many times just great thing to have for sure.