Note that 2 of the features added: a) support for subdirectories, and b) replacing File Control Blocks (FCB) with file handles, are the same as for MSX-DOS:
MSX-DOS (1) uses FCBs and a single root directory
MSX-DOS (2) also uses file handles and supports subdirectories
MSX-DOS (both versions) build on a low-level driver which controls the floppy/hard drive. This came in ROM and included higher-level disk handling (file operations, Disk-BASIC etc). The "DOS" part came on a floppy (MSX-DOS.SYS/COMMAND.COM or MSX-DOS2.SYS/COMMAND2.COM).
Yes Microsoft was involved here too. Note that MSX-DOS offered some CP/M compatibility: some programs pulled straight from CP/M (Z80 flavour) could run under it. Some functions deal with CP/M-derived 128-byte "records" (from CP/M floppy formats' sector sizes) rather than byte sizes. But no CP/M disk formats were supported afaik.
Other than that, MSX-DOS2 offered some memory management functions for MSX2's memory mapper. Not sure if equivalent functionality was included in MS-DOS 2?
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.
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 </i>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.
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.
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).
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
Xenix was targeted at a hardware spec that was well out of reach for the ordinary home PC consumer. The amount of ram and HDD needed to install and run it would make a computer in 1985/1986 money equivalent to a $12,000 desktop today. They always knew they needed to keep developing DOS for the low end.
Sure, but as the article points out, had it not been for the change of heart, Xenix light could have been something like Coherent.
Having learnt UNIX on Xenix, I know how expensive it was, we had a single tower that the teacher carried on into class, while we in groups of 2 students had about 15 minutes time slots to try out our applications that we prepared on MS-DOS ahead of time with Turbo C 2.0.
I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA.
Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.
It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
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.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
>...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
> 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.
It's easier to directly generate binary object code than assembly. It also makes for a way, way faster compiler. Also, one of the first programs I wrote when developing my compiler was an object file disassembler.
That was one example among many others that I could have chosen from compiled languages, I just happened to chose the very first successful one.
I might also add that I was surprised that you lost an opportunity to advocate for D, which what I was actually hitting for with that remark alongside a smiley.
Some people forget not only is Fortran one of the few languages with first class support for GPU programming, and one of the reasons OpenCL lost, it has all the goodies of modern languages.
I used it as example, as I could have used any other compiled language, including D.
I know this is software focused, but as much of the work done in DOS 2.0 was to support the introduction of hard disks, it would be worth mentioning what the hardware was in the PC/XT:
As I recall 8 inch class HDD (5, 10, 20MB?) were called Winchester in the pre-PC/XT era, named for the earlier IBM product, and then the terminology carried on into the microcomputer/desktop world when the 5.25" full height HDD was introduced for the XT.
This is enlightening. Growing up playing with Unix boxes (and XENIX, specifically, mostly writing shell scripts and playing in the filesystem) and programming MS-DOS in assembly I could often see strange parallels between how stuff worked in MS-DOS and his stuff was in Unix. I just assumed MSFT programmers had used Unix at some point and wanted to lift features and idioms from it to use in DOS. It never occurred to me, knowing XENIX was a MSFT-licensed Unic derivative, that there might be more direct inspiration in that vague Unix "flavor" in DOS.
I never did any CP/M programming, so the whole FCB-based file manipulation API in MS-dos just seemed like strange old cruft to me. Had I been exposed to CP/M the Unix inspiration behind the handle-based API would have been a lot more apparent. (I got in about the MS-DOS 3.3 timeframe...)
What a strange world it would have been in MSFT got IBM to buy into the Unix path separator.
Using the backslash: one of those incredibly idiotic things that caused untold misery and time waste further down the road. Future generations cursed the day.
2BSD is still hanging on getting updates and forked projects to this day. My understanding is that it's longevity in the face of the existence of 4bsd is because it is 16-bit clean, These days it is mainly for people who want a unix for their microcontroller.
Yes, memory was the main issue. The PC launched with 64KB of RAM. Technically there was a model with 16KB of RAM and no disk drive but I don't think they produced or sold many of those.
Technically it could be expanded all the way to 640KB
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)
Right, that ROM BASIC was such a waste for them for years.
Some clone makers quickly found out ways take advantage of that space adding more RAM there. Then bit later it came area where you could even map over 1MB placed memory blocks there with a config.sys loaded driver.
I could get the extra 48KB memory for less than IBM charged. More importantly, double sided floppy drives were already on the market but you couldn't get them from IBM at any price.
So I went to a local component supplier and got a pair of double sided drives. They worked "out of the box" in DOS, but unsurprisingly, only side 1 of each drive showed up as A: and B: drives.
So I wrote a TSR to add C: and D: drive letterss which were side 2 of each drive.
It was super easy.
Later I heard about a fancier TSR that combined side 1 and 2 of each drive into a single drive letter with twice the capacity.
But that was a much more complicated task, and I was happy enough with my four-drive-letter solution.
>"But it soon became clear that IBM was committed to keeping DOS 2.0 as close as possible to the eight thousand bytes [8K] used by DOS 1.1, so as not to disrupt their existing user base. [...] The first version of MS-DOS 2.0 shipped with IBM PC XT as PC-DOS 2.0 on March 8, 1983. It required about 20 KB of RAM, far more than MS DOS 1.0, so both versions continued to be sold simultaneously for a while."
And that approximate doubling, in RAM requirements, year by year (compare to Moore's Law for hardware!) for Microsoft's OS'es, has got us, fellow students of computer history, to where we are today -- with Microsoft OS'es being the size that they are and requiring the RAM that they do!
And it all started with upgrading (or "upgrading", take your pick of term!) an 8KB OS to a 20KB OS! :-)
"The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness."
Note that 2 of the features added: a) support for subdirectories, and b) replacing File Control Blocks (FCB) with file handles, are the same as for MSX-DOS:
MSX-DOS (both versions) build on a low-level driver which controls the floppy/hard drive. This came in ROM and included higher-level disk handling (file operations, Disk-BASIC etc). The "DOS" part came on a floppy (MSX-DOS.SYS/COMMAND.COM or MSX-DOS2.SYS/COMMAND2.COM).
Yes Microsoft was involved here too. Note that MSX-DOS offered some CP/M compatibility: some programs pulled straight from CP/M (Z80 flavour) could run under it. Some functions deal with CP/M-derived 128-byte "records" (from CP/M floppy formats' sector sizes) rather than byte sizes. But no CP/M disk formats were supported afaik.
Other than that, MSX-DOS2 offered some memory management functions for MSX2's memory mapper. Not sure if equivalent functionality was included in MS-DOS 2?
Unexpectedly, MS-DOS 2.0 included a /dev directory.
https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...
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.
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
> under MS-DOS command line parsing was left completely to a a loaded program
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.
>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 </i>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.
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/
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).
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.
>gave users control over the directory structure
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
Traditional reference how Microsoft was doubling down on UNIX with Xenix, before having a change of heart.
The Future of Xenix, Bill Gates Interview on Unix World, back in 1985
https://archive.org/details/Unix_World_Vol02_10.pdf
Xenix was targeted at a hardware spec that was well out of reach for the ordinary home PC consumer. The amount of ram and HDD needed to install and run it would make a computer in 1985/1986 money equivalent to a $12,000 desktop today. They always knew they needed to keep developing DOS for the low end.
Sure, but as the article points out, had it not been for the change of heart, Xenix light could have been something like Coherent.
Having learnt UNIX on Xenix, I know how expensive it was, we had a single tower that the teacher carried on into class, while we in groups of 2 students had about 15 minutes time slots to try out our applications that we prepared on MS-DOS ahead of time with Turbo C 2.0.
I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA.
Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.
The easy way to write assembler for a machine with no compilers is to write the code in C, get the algorithm right, then translate it to asm.
Or any other compiled language for that matter. :)
It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
As did many other compiled languages including those predating C, people should stop putting it on pedestal.
Fortran 77 manual for UNIX, https://www.unix.com/man_page/v7/1/f77
You can find plenty of other examples, when doing digital archaeology.
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
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.
Yes there were alternatives.
What irks me is this mystical selling point, have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
As you point out, people are not curious enough for what is outside of their bubble and take the marketing message as is.
Even more so, when knowledge was spread via the local library and what magazines one could get their hands on.
>Yes there were alternatives.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
>...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
So by that I'm wishing you a nice day, cheers.
> 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.
It's easier to directly generate binary object code than assembly. It also makes for a way, way faster compiler. Also, one of the first programs I wrote when developing my compiler was an object file disassembler.
Fortran is a terrible language for developing an OS. It doesn't even have pointers.
That was one example among many others that I could have chosen from compiled languages, I just happened to chose the very first successful one.
I might also add that I was surprised that you lost an opportunity to advocate for D, which what I was actually hitting for with that remark alongside a smiley.
The standard language has had both dumb and smart pointers for 36 years. Based storage has been available as a common extension for over forty.
Some people forget not only is Fortran one of the few languages with first class support for GPU programming, and one of the reasons OpenCL lost, it has all the goodies of modern languages.
I used it as example, as I could have used any other compiled language, including D.
Turbo C didn't exist when MSDOS was written. Or any compiler for the x86.
I agree. Not sure whether that was the case for MS-DOS but I’m sure it was useful.
Gotta find some time to read some of the code to chill.
I know this is software focused, but as much of the work done in DOS 2.0 was to support the introduction of hard disks, it would be worth mentioning what the hardware was in the PC/XT:
https://en.wikipedia.org/wiki/ST-506/ST-412
https://www.google.com/search?client=firefox-b-d&q=ST-212+ha...
I love that for the next few years they were commonly called Winchester drives due to IBM's original naming in the early 70's.
My dad still called it "Winchester" well into the 80s. I remember when we got our first "Winchester", a 20MB hard drive.
My first hard drive was 6Mb. I had to design/build my own interface board for it, and write the driver for RT-11.
As I recall 8 inch class HDD (5, 10, 20MB?) were called Winchester in the pre-PC/XT era, named for the earlier IBM product, and then the terminology carried on into the microcomputer/desktop world when the 5.25" full height HDD was introduced for the XT.
This is enlightening. Growing up playing with Unix boxes (and XENIX, specifically, mostly writing shell scripts and playing in the filesystem) and programming MS-DOS in assembly I could often see strange parallels between how stuff worked in MS-DOS and his stuff was in Unix. I just assumed MSFT programmers had used Unix at some point and wanted to lift features and idioms from it to use in DOS. It never occurred to me, knowing XENIX was a MSFT-licensed Unic derivative, that there might be more direct inspiration in that vague Unix "flavor" in DOS.
I never did any CP/M programming, so the whole FCB-based file manipulation API in MS-dos just seemed like strange old cruft to me. Had I been exposed to CP/M the Unix inspiration behind the handle-based API would have been a lot more apparent. (I got in about the MS-DOS 3.3 timeframe...)
What a strange world it would have been in MSFT got IBM to buy into the Unix path separator.
CP/M showed a lot of similarities to DEC's RT-11.
> the Unix path separator.
Using the backslash: one of those incredibly idiotic things that caused untold misery and time waste further down the road. Future generations cursed the day.
decades later there are fuzix and elks running on 8085 or 8086 respectively:
https://www.fuzix.org/downloads/0.4/
https://github.com/ghaerr/elks
>Even a scaled-down version of Unix was too demanding for the 8086 chip”.
Interesting. At my old job I got my hands on Wang IN/ix around 1985, a 16 bit UNIX.
It ran on an 8086 but needed 512k memory. It ran fine. I wonder if memory was the main issue ? But seems the issue was probably memory for IBM and MS
2BSD is still hanging on getting updates and forked projects to this day. My understanding is that it's longevity in the face of the existence of 4bsd is because it is 16-bit clean, These days it is mainly for people who want a unix for their microcontroller.
Here is one, https://github.com/RetroBSD/retrobsd. This is for the pic32, so I may be wrong about the 16-bit thing.
I don't know if anyone has done it but it looks like it could fit, perhaps not on a original 8086 PC, but perhaps a 286 with 640K.
Yes, memory was the main issue. The PC launched with 64KB of RAM. Technically there was a model with 16KB of RAM and no disk drive but I don't think they produced or sold many of those.
640
64, not 640.
Well, 16 KB - 256 KB, with a directly addressable 64 KB and a segmented architecture to reach further.
I had one of these in mid 1982 to late https://en.wikipedia.org/wiki/IBM_Personal_Computer
Technically it could be expanded all the way to 640KB
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)
And it included a cassette interface.
And BASIC in ROM.
Right, that ROM BASIC was such a waste for them for years.
Some clone makers quickly found out ways take advantage of that space adding more RAM there. Then bit later it came area where you could even map over 1MB placed memory blocks there with a config.sys loaded driver.
16KB and no floppy drive. That was my first PC!
I could get the extra 48KB memory for less than IBM charged. More importantly, double sided floppy drives were already on the market but you couldn't get them from IBM at any price.
So I went to a local component supplier and got a pair of double sided drives. They worked "out of the box" in DOS, but unsurprisingly, only side 1 of each drive showed up as A: and B: drives.
So I wrote a TSR to add C: and D: drive letterss which were side 2 of each drive.
It was super easy.
Later I heard about a fancier TSR that combined side 1 and 2 of each drive into a single drive letter with twice the capacity.
But that was a much more complicated task, and I was happy enough with my four-drive-letter solution.
>"But it soon became clear that IBM was committed to keeping DOS 2.0 as close as possible to the eight thousand bytes [8K] used by DOS 1.1, so as not to disrupt their existing user base. [...] The first version of MS-DOS 2.0 shipped with IBM PC XT as PC-DOS 2.0 on March 8, 1983. It required about 20 KB of RAM, far more than MS DOS 1.0, so both versions continued to be sold simultaneously for a while."
And that approximate doubling, in RAM requirements, year by year (compare to Moore's Law for hardware!) for Microsoft's OS'es, has got us, fellow students of computer history, to where we are today -- with Microsoft OS'es being the size that they are and requiring the RAM that they do!
And it all started with upgrading (or "upgrading", take your pick of term!) an 8KB OS to a 20KB OS! :-)
"The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness."
-- Martin Reiser, quoted by Niklaus Wirth
Well said, Liam Proven, well said!