MS-DOS did not run things behind the scenes in Windows 95, 98 or ME, no matter how convincing an appearance of this Windows gave. They are fully 32-bit operating systems that preferably use DOS only while booting, though they will fall back to DOS device drivers as a last resort when Windows drivers are missing.
(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!)
386 Enhanced Mode actually is a hypervisor that runs DOS inside a virtual machine
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.
> Only later did things like Xen, KVM, QubesOS, etc. "rediscover" this architecture
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.
VMs in mainframes and academic research are too detached from personal computing to be of much practical significance; it was really the 386 and its VM86 mode that brought virtualisation to the masses.
Xen started out as a research project at the University of Cambridge.
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.
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.
Note that this was a big deal not because 45K was a lot of memory in general by that point, but because the first 640K ("conventional" memory) is special in DOS. If you didn't have enough of it free, many programs simply couldn't run, so having DOS itself take up significantly less of this memory was a big win.
Again, I was there. No. Microsoft stopped updating MS-DOS 6.0 at 6.2.2.
I never saw DOS 6.3 ( There was a PC-DOS 6.3, which I think was unchanged except for "Disk Compression" . Next thing was the DOS 7.0 used to boot Windows 95 FE.
I was a kid with not much else to do. We had a home PC and no internet connectivity. I spent so much time going through the MS-DOS manual and trying out all the commands. If only I had spent that time learning Linux commands...
Luckily, my older brother had brought home a "Learning UNIX" book when I was a kid, which helped me learn about UNIX fundamentals years before getting my hands on a machine with it. I was fascinated with the book because UNIX sounded too advanced compared to what I was using back then (an 8-bit Amstrad CPC464). I still use the same knowledge such as managing shell background jobs, exiting vi, using tar, permissions, and so forth 30 years later. UNIX is quite magical in its consistency.
I rarely bring in anecdotes from my mum, but she said it seemed like I was learning something so arcane, as if I was learning how to run nuclear powerplants when I studied Unix at the age of 16. I still use the knowledge I learned from those books, thanks IDC and O'Reilly. I still think Sendmail and bind DNS is a bitch. I still also ridicule Microsoft, although on various points I know I am at least partially wrong.
My brother did the same. Unfortunately the letter F came early and with it "format.exe" unfortunately the explanation in his book wasn't clear ... and there was no backup of many things.
Same. MS-DOS was such a turd of an operating system. So much time fiddling with IRQ settings and disabling stuff to squeeze out just a little more conventional memory so I could play Warcraft II
Fiddling with IRQ settings was because the IBM PC design didn't allow sharing of interrupts (I think because they didn't expect it to be as popular as it was). Squeezing out memory was due to two design flaws---one being IBM assigning the address space above 640K for peripherals and ROMS (MS-DOS never had a 640K limit) and two being MS-DOS required memory to be contiguous.
I was at a conference or something one time and saw a talk by Bill Gates, where he said that they'd tried to convince IBM to use a 68000 CPU in the original PC. Imagine what DOS could have been with a 32-bit instruction set and 16MB address space from day one. A lot of the eccentricities of DOS at the API level stem from the limitations of the hardware.
Have you seen the Sharp X68000? Its operating system, Human68k, is pretty much as close as one can get to a beat-for-beat MS-DOS clone on such radically different hardware.
Most CP/M software tried to do a lot less than MS-DOS/PC-DOS software did, which made CP/M a lot simpler and easier to manage in practice than DOS was. The vast majority of CP/M applications were purely text mode, no graphics (especially not on the screen, printer/plotter graphics was somewhat more common), no sound (except the terminal bell), only supported IO devices were floppy/hard disks, and serial IO to talk to printers/plotters/modems; they managed to get by with very limited memory (many CP/M systems only had 64KB of memory, with some of that reserved for the OS or hardware; higher-end systems with bank switching could have 128KB, occasionally even up to 512KB). If your DOS applications stuck to the same limited feature set, DOS could be about as simple.
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.
I've had pretty limited experience using CP/M - I think the last time I actually played with it was in the early 90s when some old guy I knew was still using it to run a BBS. As far as I recall it was just as atrocious as DOS and other things of that era, at least from a UX point of view. DOS's int 21h API is a close cousin of the system library in CP/M, so I'd expect the developer experience to be kind of similar. Is there something specific you think CP/M was doing better?
It most definitely wasn't that "CP/M was an atrocious clone of DOS"! It's the other way round: DOS is a much-enhanced clone of CP/M.
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.
I can relate to this because it's one of the reasons I originally downloaded all 14 floppy disk images required to install Slackware. I've always been a big 'just read the god damn manual' type of guy and I immediately realized there would be an endless opportunity to read a lot of manuals.
In many cases better served by a fork of DOSBox, such as DOSBox-X [0] or DOSBox Staging [1].
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.
Since its 'compatible' it would sit alone, just like every other from scratch, compatible tree would. Perhaps with a notion that the source is available, FOSS licensed.
>Because of its similarity to CP/M, it was easy to port programs originally designed for CP/M on 8080 and Z80 processors to QDOS, which targeted 8086 processors.
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]
A lot of that CP/M compatibility comes from the fact that the 8086 had a high degree of backwards compatibility with the 8080/8085 (and thus also the 8008). It wasn't actual binary compatibility, but the instruction set was either a strict superset or close enough (albeit with different encoding) that you could take an 8080 program written in assembly language and run it through an appropriate 8086 assembler to produce a valid 8086 binary. Since the processor made it possible to port software that seamlessly, it made sense for operating systems to also provide a compatible ABI.
Not only this, but MS-DOS supported the CP/M style "Call 5" system call interface as well as the "modern" MS-DOS "int 21" system call interface, which is why to this day there is a jmp instruction at 0005h of the .com file format.
The backwards compatibility remains a huge feature of DOS and Windows.
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.
It is strange though I suppose it could be considered an independent reimplementation since there is no shared source. There's also DOSEmu and DOSBox, which while not directly bootable, are DOS environments.
“ Windows XP moved to the NT kernel, whose primary difference was moving away from a monolithic kernel to a hybrid kernel. With MS-DOS, the kernel and operating system exists completely within the kernel space. Windows NT uses a safer structure, where the kernel is split between the kernel space and the user space.”
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.
When I discovered ProDos for Apple ][/e (Actually what I had the was the bulgarian clone called Pravetz 8C) I was so overjoyed (because at school MS-DOS is what we used on PC/AT/XT machines) and it was closer. Then I learned that there were even more options!
The sources for MS-DOS have been floating around the net basically forever. The original first few releases are even on Microsoft's github. It largely is already in ASM. Some of the user programs are written in C.
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.)
Personally for me it would be an interesting experience to see what and why they chose to do things they did with MS-DOS. One thing to try is to see if it's possible to write a 64 bit DOS extender.
There’s a couple attempts at running 64-bit in DOS. It usually has no benefits for old code and very little new 64-bit is being written and there are no libraries for common compilers.
Making easy to understand and maintain programs in C++, with compilers that can that can do aggressive optimizations and inlining that compilers of the day could not do.
The STL didn't exist until the late 90s, and before C++98 it was a wild-west.
> with compilers that can that can do aggressive optimizations
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 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).
MSDOS did have MMU support since 80386, IIRC. So I think GPs claim might be inaccurate. But it wasn't a security feature, it was a productivity feature. It protected your programs from defects in other programs and vice versa. This helps programmers find defects during design and helps users for defects that escape testing.
DR and MS DOS 5 and later have a 386 memory manager which can put an x86-32 CPU into Virtual 86 mode, remap RAM over any unused blocks in the I/O and ROM area (between 641kB-1024kB) to make Upper Memory Blocks, and load small resident parts of the OS into those blocks in order to keep as much base memory (0kb-640kB) free.
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.
The MMU is inside the processor. Any operating system running on an 80386 or higher has set registers/tables and gets hardware provided memory management.
I agree with the sentiment but note there were still viruses being circulated through floppy disks. So, 3rd party code may still be executed on a non-networked machine.
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 took the time a few years ago to learn a bit about how to use Autodesk Animator (it was released with a BSD license some ~10 years ago and can be downloaded legally for free these days). Was really impressed with the GUI. Just press a single key to open the menu that begins with that letter, then the first letter of the menu-item you want to use. They managed to use only words that begin with unique letters while still making a lot of sense. Plus some other single-key shortcuts. And many, to me, unusual design choices everywhere, but it all makes sense and is consistent in a way that after a few hours I was not bothered at all by the fact that nothing was like a modern GUI, and there was definitely nothing about using more modern GUI conventions I can think of that would make it more pleasant to work with.
It spread first as windows worm that exploited several 0-days. If the host didn't have the Siemens PLC device drivers with a configuration that matched the exact configuration of what they were expecting for the centrifuges, they payload was dormant and it just replicated. Only if it matched would it patch the PLC's programming upon re-connection to fake reporting that the speed was normal while it was actually spinning out of control.
Yea, there was alot of features that one is used to in modern OS that was missing in MS-DOS.
It does not mean those features didnt exist or wasnt being used.
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).
I think the parent may be thinking more of "demoscening" the DOS kernel and basically optimising it to its limits. Yes, the original was written in Asm, but it's definitely not that highly optimised.
gcc-ia16 and OpenWatcom are both modern compilers that generate as good a set of code as any compiler ever did for Pentium and older processors. But using a higher level language like C means there’s more than one compiler that can compile your DOS. That’s a reason to be hopeful if you’re a DOS developer.
constexpr code and move semantics didn't exist until relatively recently. These are steps towards less bloat and more aggressive optimization. They also can elide gratuitous copy construction.
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?
This finally helps prove that I was right. I threw a test in high school when the computer teacher decided that his mainframe and cobol approach was the best.
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.
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!)