The splash image is a throwback to the early IBM PC DOS manuals which are freely available on pcjs [1]. Very entertaining to read these high quality manuals, especially the ones for 1.0 and 2.0. You can tell a lot of work went into refining those documents for an audience who barely had any idea what a computer was. They even have a bit of internal details (e.g. about FAT) and such at the end.
I love this kind of 'alternate history' computing - OS concepts that could have been, should have been.
It makes me wonder about what aspects of modern systems we take for granted. And also what kinds of OS research are going on today, the kinds of systems we might see in the future. Does anyone have any resources to help stay abreast of that?
If we're talking alternate history, DOS 2.0 is a completely different beast than the CP/M-based DOS 1.0. It added things like directories, pipes, device files, and hard disk support. If you look at the PC-DOS 2 manual, they broke compatibility with the existing API in a few places to make that happen. They even promised more, such as that it'd eventually have support for multi-tasking.
Digital Research was in fact able to deliver on the idea of a multi-tasking DOS.
https://en.wikipedia.org/wiki/Multiuser_DOS Compatibility suffered in some places, as the idea of having to share a system wasn't present in most DOS drivers. It filled its niche, but never broke out of it.
I feel if MS-DOS did establish a stronger multi-tasking foundation in those early years, there may have been less of a need of NT for home users. Who knows how many more years the average person would have been using DOS?
Microsoft already had a multiuser, multitasking platform -- Xenix. They had an internal initiative called XenDOS that was intended to make Xenix and DOS more compatible with one another, allowing for development of programs source-compatible with both. That's where all the Unixisms in DOS 2.0 and later came from. DOS 2.0 had a few that later versions didn't -- like a configuration option to select / or - as the switch flag character and full compatibility with use of / as a path separator.
XenDOS was likely abandoned when it was found that third-party programs had started assuming direct hardware access in the DOS 1.x days, making transition to a new DOS framework difficult.
Windows 9x had full PMT and decent memory protection. It was a separate kernel that ran alongside DOS and populated DOS memory data structures to keep the two systems in sync. It could have been a "home user" successor kernel, but the writing was definitely on the wall at Microsoft that NT with its more robust architecture was the future, as far back as the mid-90s, with 9x acting as a transitional phase.
You know, CP/M and DOS computers were kind of the exception among their contemporaries: most 8bit (and some 16 bit) microcomputers of the era booted to a BASIC prompt, and would either user special BASIC commands or POKE calls to load stuff. Looking forward to seeing what comes out of this re-imagining.
True IBM PCs (up until the PC-AT, I believe) would also boot into BASIC if the floppy drive was empty and there was no fixed disk. In fact, in early versions of PC-DOS, all the basic command did was bootstrap the ROM BASIC, so it didn’t work on later clones.
The early PS/2 line, at least, would still boot into BASIC, if I remember correctly. I'm fairly certain my Model 70 386 would do so, but I can't remember if I had to disconnect the hard disk or what. Anyway, I definitely remember the Model 25s doing so, but of course they were closer to XTs than they were to "real" PS/2s.
The ThinkPad 701 with the butterfly keyboard would bring up BASIC if you removed the hard drive. That was a 486, none of the later machines seemed to do so.
Agreed. Having commands for "the DOS" (in the generic sense of a disk operating system) commingled with BASIC was the norm for the Apple II, Commodore 64, and Atari 8-bit machines. The PC was definitely the oddball when it came to having a separate DOS command line and BASIC interpreter.
ROM BASIC was available on IBM PCs but clones typically didn't have it.
The Tandy TRS-80 line of computers which were the bestselling 8-bit computers until 1982 also didn't have commands for "the DOS" commingled with BASIC. The various DOS's available for the platform booted directly from disk.
The basic in ROM on IBM PCs was cassette basic and only supported loading and saving from cassette tapes. Although there might have been an obscure clone manufacturer or two which supported a cassette tape interface, in general clone makers didn't so there was no needed for an embedded cassette basic. Even IBM didn't support a cassette tape interface after the original IBM PC (5150). This meant that for years you could boot an IBM computer to cassette basic but not actually load or save any BASIC programs once you had done so.
Probably because it was aimed at business and IBM knew many of their customers would like to use something besides BASIC. So a separate minimal OS and development environments made more sense.
IBM didn't know what to do (no one really did), so you could boot to DOS or you could boot to PC-BASIC. The PC even supported boot to BASIC and load from cassette like a $300 home computer. Crazy times.
IBM had been established for decades before the PC, also the PC in general was established for years before their entry.
I think they knew what to do. It was a bit of a gamble, sure. And you can make the argument they guessed wrong. But the success of the PC and subsequent crushing of the rest of the industry was incredibly successful.
The flexible design did catch on, simultaneously a blessing and a curse to IBM.
You get a powerful, structured, and easy to learn language that is also pretty trivial to implement while also being capable of low-level assembly access if really needed and to even compile native binaries for much better performance than most BASIC ever dreamed of.
Some oddness to be found: run MSBASIC.EXE, then enter the command "FILES" (which is the BASIC command to get a listing of the files in the current directory), essentially a DIR command. That gets stuck in an endless loop, showing ". .*"
It's quite neat, but I think that a major downside with this approach would be the extra memory consumption from including BASIC in the DOS. The demo uses 34kB (out of e.g. 64kB) for the OS.
Not sure how that compares with PC-DOS 1.0, but it seems high.
> All preview binaries shown here are DEBUG versions, which means that all run-time assertions are enabled, so file sizes and memory usage are larger than normal, and overall performance is slightly lower.
there's something extremely zen of programming fundamental abstractions (say linear recurrence ala fib) on very limited bare systems.. it connects the theory and optimization to the physical manifestation and is very zen inducing
Yes, I went to that link immediately on landing on the page hoping to find what I was looking for. Didn't realize the titles were actually additional links that I needed to click through.
1. https://www.pcjs.org/documents/manuals/ibm/