The Life of MS-DOS
b13rg.github.io
b13rg.github.io
https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...
(Arguably DOS was barely in the picture already by the time Windows 3.x's 386 Enhanced Mode came around. It is a hypervisor where DOS and Windows live in virtual machines!)
"The Win32 API is implemented by three modules, each consisting of a 16-bit and a 32-bit component:"
Fully?
Windows/386 was the first version to do that, I believe. It's worth noting that it and its descendants were based around this hypervisor architecture but the fact seems to be little-known, perhaps because the virtualisation was so "transparent" (and allowing pass-through hardware access by default). Only later did things like Xen, KVM, QubesOS, etc. "rediscover" this architecture --- but with a "deny by default" model for security instead.
IBM invented hypervisors in the 1960s, and IBM mainframes have seen continual production use of hypervisors ever since then. IBM's mainframe hypervisors had a massive impact on the computer science research community – basically all academic hypervisor research can be historically traced to that initial work inside IBM – and it was that research which the initial developers of systems such as Xen and KVM drew upon.
By contrast, Windows/386 and its successors (Win3.x 386 Enhanced Mode, and Win95/98/Me's VMM kernel) were essentially a historical dead-end. They weren't doing anything which hadn't already been done on other platforms a decade or more earlier. Systems on other platforms were doing far more advanced virtualisation at the same time. They didn't really contribute any significant ideas to future systems, or to academic research into hypervisor technology.
If Xen/KVM/QubesOS/etc started by "rediscovering" anything, it was by "rediscovering" IBM VM, not by "rediscovering" Windows/386.
Similarly, one of the cofounders of VMware, Mendel Rosenblum, is a CS professor at Stanford, and VMware’s first products were built on his academic research into hypervisors.
Academic research has had far more practical significance in this space than you give it credit for. Meanwhile, Virtual 8086 mode’s limitations meant it had limited value except as a backward compatibility environment for running legacy DOS software on newer operating systems (Windows, OS/2, Linux, etc), and as the years passed that use case became less and less relevant-V86 mode is essentially a technological dead-end. The academic research which went into VMware and Xen left a major mark on the whole industry.
And if you read academic papers on hypervisors, you’ll see IBM’s mainframe virtualisation technology cited as prior work, again and again and again.
https://en.wikipedia.org/wiki/CEMM was earlier
I had a 486 with 8Mb of RAM and a 40Mb disk, DBLSPACEd. It usually didn't had enough low memory (because DBLSPACE was a hog) for some games, so... I started Windows and played these DOS games from there.
I don't remember which one game occasionally would drop out with OOM in the DOS (it had 8Mb in the minimal requirements) but run just fine when started from Windows. Virtual memory with swap for the rescue!
I even used Calendar (if my memory serves me well) as an alarm clock to remind myself about the time.
PC-DOS had a 6.3, but as far as I know, MS-DOS only went to 6.22 before going to 7 (which was not shipped standalone).
Probably typo mistake from author?
MS-DOS ended at 6.22.
PC DOS started to significantly _diverge_ from MS-DOS thereafter, with PC DOS 6.3, then 7, then 7.01, then 7.1.
And TBH, in the early days of DOS – let's say up to MS-DOS 3.3 – it wasn't a lot better than CP/M. No command-line editing, no file manager, disk partitions of max 32MB, no built-in disk cache. This was the version that was a big hit and it was kinda basic.
IBM built PC DOS 4.00 and MS licensed it from them. It was bigger, slower, & a bit more complicated – but it started offering improvements.
It provided part of the impetus for DR to offer DR-DOS 3.41, the first widely-distributed version. It had the key improvements of PC/MS-DOS 4.00 (disk partitions >32MB being principal) but it was as small as MS-DOS 3.3 and as compatible.
The DOS market only became competitive when DR introduced DR DOS 5, which integrated all the most important 3rd-party enhancements: 386 memory management, a disk cache, a full-screen text editor, and a graphical file manager... and it was sold at retail for the first time, as an upgrade to (and improvement over) MS-DOS 3.3, PC/MS-DOS 4.00 and vendor-proprietary tweaks like Compaq DOS 3.31 (which was the first DOS with >32MB partition support in the way that became standard.)
MS was more or less forced to respond, which it did with MS-DOS 5 which pretty much matched DR DOS 5 feature-for-feature, including being sold at retail.
The next few years they competed hard, each trumping the other on features in each release.
But, people came to expect a lot more from DOS than that, and DOS' architecture had never been designed with those greater expectations in mind, so the end result was a complicated and difficult to manage mess. CP/M's architecture was fundamentally no better (indeed, DOS 1.0's architecture was just a slightly evolved copy of CP/M's): if people had tried to make CP/M do the things which late 1980s / early 1990s DOS systems were expected to do, CP/M would have turned into just as big a mess as DOS did.
Unix and Linux, what a world.
The DOSBox development team really likes to take their time, and often rejects outside contributions. They are only interested in running games, so will even reject bug fixes, unless you can show the bug harms some game. They are still on SourceForge and Subversion, which also acts to discourage outside contributors. Overall a rather conservative and risk-averse approach.
The forks are at GitHub, and have GitHub Actions for CI, and more modern build processes/etc. DOSBox-X wants to support running all applications, including non-games; DOSBox Staging has more of a games-centric focus, but still is much more open to new and improved features than the original DOSBox is. Both have a much faster development and release cycle, and are much more welcoming to new contributors.
DOS itself may not be a moving target, but there is still a long way to go in supporting corner cases, features of the platform which applications rarely use, etc.
[0] https://dosbox-x.com/ https://github.com/joncampbell123/dosbox-x
[1] https://dosbox-staging.github.io/ https://github.com/dosbox-staging/dosbox-staging
I read somewhere[0] that a major reason for DOS's success was that it had thousands of programs "already written" for it on launch day due to backwards compatibility with CP/M software. Iirc the same article argued that backwards compatibility is Microsoft's (and Intel's) greatest strength. I can run programs compiled on Windows 95 on Windows 10 today. They go really far with this -- one version of Windows had a hack built into the kernel to work around a bug in SimCity![1]
[0] Placeholder for source, if someone finds it!
[1] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
Probably not the article you want, but has a little tidbits:
Sure some new games are cross-platform and work in Linux and Mac, but for anyone who's been gaming for awhile, most of your favorites are PC, and a lot of 'em will still work. A few of the ones that used oddball custom memory management near the end of the DOS era won't work on a modern system. And some that used custom VB controls in the Win-95 era. But a surprising number overall still do.
One that amuses me is SST.[1] Written in the late-60s to early 70s on a mainframe, then ported to PC in the early 90s, still works just fine in Windows 10 (last updated in 2019). Still has a teletype terminal style interface, but also it still just works. And sure, a lot of that was due to the porting done in the 90s, but a lot is also just due to the basic stability of the platform.
That's a game my dad might've played in school, and my grandson could play now.
I wonder how much software written today will still 'just work' in 30+ years? Sure, we can use virtual machines and emulators and such, but without that, will anything written today still 'just work' the way old software does? So much now is constant churn with monthly/weekly/daily updates and dependencies and everything - constant maintenance to keep it running. So many network dependencies even for things that don't need them. I'd say most of us aren't really building software to last.
And if nothing is built to last, that great value of backward compatibility and longevity is lost. Which is kinda sad.
Yeah, that’s not what a hybrid kernel entails, and that is certainly not the primary difference between DOS and NT. I had to stop reading.
To me, it would be far more interesting to see what modern compilers and development tooling could do towards producing DOS programs and operating system extensions. The tooling from back in the day was very baroque. You had to rely on different mutually incomparable dos extenders to get around all the limitations. (Just try to find the documentation to Phar Lap 386 in 2022.)
The STL didn't exist until the late 90s, and before C++98 it was a wild-west.
The OS is still ancient and lacks most every possible security measure.
Every program can r/w any memory and so on…
The netsec industrial complex has really set back computing.
These memory managers could also turn the extended memory (above 1024kB) into managed XMS or EMS memory. LIM EMS was accessible to DOS apps and XMS to DOS-extender apps.
These were killer features in 1990 or so, and I made good money from optimising DOS memory for clients around that time.
Indeed, it would be awesome to see how much a machine can do without all the layers. Even the Intel CPU security fixes could be bypassed and gain some extra speed.
Regardless of the qualities of DOS, the user interfaces of the graphical programs was in many cases superior compared to today, everything keyboard controlled, clearly labeled shortcut keys, views that usually only did one thing, distinctive coloring.
I have not made any claims about security features on a network computer.
I had coax network on MS-DOS even back then.
MS DOS did not, because that was the main selling point of Windows for Workgroups.
We used 3rd party TSR drivers for it.
Examples:
- MOUSE.COM driver https://www.vogons.org/viewtopic.php?t=58777
- CDROM driver http://manmrk.net/tutorials/DOS/cdrom.htm
- Network stack https://en.wikipedia.org/wiki/IPX/SPX
- Graphics driver https://dosdriver.de/graph.php
- Sound card drivers https://dosdriver.de/sound.php
For instance:
DR DOS 6 had Netware Lite; DR DOS 7 had Personal Netware.
https://en.wikipedia.org/wiki/Personal_NetWare
I think several versions of DOS included MSCDEX.EXE (or DR's equivalent), but not the device driver, because back then there were lots of different CD interfaces: Mitusmi, Panasonic and Sony on sound cards, some early EIDE ones, and SCSI on higher-end kit.
Mouse drivers came with your mouse. ;-)
MS did have a network stack bundled for free on the NT Server installation CD, and some versions of it support server mode for peer-to-peer operation.
DOS could do all this stuff, but you had to assemble the bits from different sources, and this was sometimes for good reasons, sometimes technical (a profusion of incompatible CD-ROM interfaces) and sometimes commercial (P2P LAN support).
So do calculators and typewriters. (Some people use computers to, gasp, perform computations, and low or no overhead is nice.)
we're still talking about real-mode DOS here. Most of those optimizations aren't going to work.
Regardless, you can target DOS just fine today. You'll need some code to bootstrap your program into protected/long mode and then your app has full freedom. You'll need to figure out the correct switches to pass to gcc to get it output a freestanding binary, and possibly a special linker script, etc.
Freedom but, let's be honest, no real utility today. You can't access the network because you'll need to write the entire network stack from scratch. You'll need to write a driver for your network hardware. Can't touch video without writing a driver for your Nvidia hardware. Or sound card.
I suspect what most people want from a "modern" DOS would be something like this: a very thin API layer that contains OpenGL (or Vulkan), audio, and networking capability. As well as drivers for common USB devices and something that can read/write FAT/exFAT. But once you add all of that you realize it's nowhere near as lightweight as old DOS was and your app now has a thousand more responsibilities that something like the Linux kernel is currently handling for you.
I think people may be looking for something like a unikernel framework. Something like Linux is a lot of overhead if all you want to do is run a single program on a machine (virtual or physical).
There are a lot of these little optimizations that are found in modern compilers that you could only dream about in 1991.
This is a very old version, but I've seen bits and pieces of the last one they shipped and things like command.com and the "kernel" were nearly the same as this, except for maybe some memory management changes. What part did you want to reimplement?
https://forums.overclockers.com.au/threads/retro-faq-dos-199...
He said if I could pass his end-of-year test he would give me the permission to start coding in C++ (I already had Borland C++ at home and was WAY past all this). He was a complete dick about it. Mr. Crow. He can eat it now.
I threw the test and intended to get a perfect 0%. One question that came up is what was the first operating system for the IBM computer system. It was PC-DOS because that's the contracted name. MS-DOS was the name for the generic Intel based system. I knew the answer.
His answer sheet was WRONG. So I got 1 out of 40 questions right. I could have scored a 100% but I hated him as a teacher so much.
His words were "You will never be anything in computers unless you can pass my class". Three letters to prove him wrong: CTO.