On the Vogon forums, user MarkDastedt posted an interesting bit of source code he discovered on an old company DVD: a very basic, very rudimentary implementation of multicore support for DOS. Another user, dartfrog, took a closer look and had this to say:
Interesting stuff nonetheless. A worker core is running with no interrupt handlers, no page tables, no memory protection, and no OS. That’s about as close to bare metal as you can get, meanwhile the other core is still running DOS. Fascinating.
↫ MarkDastedt at the Vogon forums
It’s effectively a simple demo, but according to other users in the thread, it fits in neatly with sporadic other attempts to bring some form of SMP or multicore-awareness to DOS. For instance, Michael Chourdakis worked on something similar to this demo for a series of articles now only available on the Wayback Machine. It makes for a cool demo, but moving from this to something robust and usable in DOS is not an easy task.
Still, the possibilities are definitely there, even if you don’t implement full, modern SMP or multicore support. You could have specific DOS applications offloading dedicated tasks to different cores, but as others in the same thread note, individual cores are already stupidly powerful for anything DOS can do, making the use case for additional cores rather moot.
SMP DOS seems like an interesting idea, but pretty useless without first having a multitasking DOS.
Multitasking DOS. was real though. I think DR DOS had this, though I’ve never used it. And there were several more:
https://en.wikipedia.org/wiki/Multiuser_DOS
In the very late 90s I ever so vaguely remember trying out “Concurrent DOS 386”. or was it “VM/386”, meh I don’t recall. You could run different applications at the same time, displayed on screen side by side. The DOS programs were running concurrently. IIRC it wasn’t running SMP, just single core. It even worked with games. These were more of a curiosity than anything because windows could also run DOS tasks concurrently and it was generally a better environment for multitasking.
You can still take advantage of multicore CPUs in MS-DOS by using a threaded executable (that could theoretically exist). MS-DOS is a passive OS that stays out of the way once an app has launched (unless explicitly invoked by the app or a hardware interrupt), so a DOS extender can give a DOS executable multi-threaded functionality.
Personally, I never understood the point of Concurrent DOS. The whole point of DOS (as we came to know it in the IBM PC) was to be a set of fairly simple services that can be invoked on demand, it wasn’t meant to have a multitasking kernel messing with extenders like DOS4 GW or with apps running in big real mode. Digital Research chasing the idea of making DOS multitasking and multiuser, when DOS (and more importantly, the apps that run on it) weren’t meant to be such, was Digital Research’s big mistake.
kurkosdr,
DOS worked, because it just “got out of the way”. It is practically a “proper BIOS” where you have a rudimentary filesystem, a way to load and execute programs, but does not give you any headaches along the way.
Or maybe a “better boot loader”
Yes, it standardized some services, like EMS, HIMEM, XMS, DPMI. But otherwise it ran what are essentially “mini operating systems”
Every complex DOS application or game came with their own implementation for memory management, multi-threading, and in. many cases hardware drivers (everything from sound cards to basic keyboard and mouse)
I’m not sure a “multitasking” DOS would fit in there without breaking existing programs.
FYI, DOS is unaware of the existence of DPMI (and hence can’t possibly have had a role in standardizing DPMI), DPMI is implemented by DOS extenders such as DOS 4G(W), and part of it is implemented by operating systems that offer a Virtual DOS machine.
Raymond Chen has a good overview about what problem DPMI solves and how it solves it (here’s a teaser: a Virtual DOS machine offers a virtual 16-bit 8086 CPU, but it can 32-bit DOS programs utilizing protected mode DOS extenders, isn’t that weird?)
https://devblogs.microsoft.com/oldnewthing/20230829-00/?p=108661
https://devblogs.microsoft.com/oldnewthing/20160328-00/?p=93204
kurkosdr,
I know DPMI is not technically part of proper DOS itself. But it has been intertwined enough, that almost all “modern” DOS games and large productivity applications were aware of it.
And since it was initiated by Microsoft, it is not too foreign.
Thinking back, it is probably closest to a true “multitasking” DOS implementation ever. It would not be “too hard” to write a kernel that supported multiple DPMI applications at the same time… and that is more or less exactly what Windows was.
(“too hard” meaning not impossible, but it was a large task anyway)
sukru,
I’m not sure why you are saying this when we actually had multiple multitasking DOS implementations and I even linked to a list earlier. Are you only counting technology made by Microsoft?
If we must limit the scope to microsoft, then I would say the closest thing they had to “multitasking” (other than windows of course) was probably dosshell, which could actually launch and switch between between multiple DOS programs….albeit very limited by conventional memory.
https://archive.org/details/msdos_dosshell
sukru,
Oh, I have heard about about a multitasking version of DOS called “MS DOS 4”, not to be confused with “MS DOS 4″…
https://en.wikipedia.org/wiki/MS-DOS_4.0_(multitasking)
I’ve always been curious about how it worked and what it actually did, but I haven’t come across much information about it. Apparently it was overlooked by IBM in favor of OS/2.
https://web.archive.org/web/20200218140536/https://sites.google.com/site/pcdosretro/multitaskingdos4
Alfman,
I might have missed something? I was trying to talk in general, and posted my experience with Windows and OS/2. Those were the ones that “could run DOOM” (as a stress test)
Today, I would also include DOSEMU (early linux), dosbox, 86box and similar there.
I heard good things about QEMM, but never actually had the chance to try.
sukru,
I find that to be rather arbitrary, but I did test some games and they did work, I really don’t remember if doom was among them. I’m just saying it’s odd to hear you speak hypothetically of something that actually existed.
I’ve used it extensively. Don’t expect it to perform miracles though. All of those memory managers are fighting the same conventional memory limitations. The only way to really overcome that is to load DOS programs into dedicated memory not shared with anything else. QEMM didn’t do this, but concurrent DOS implementations did.
Alfman,
Sorry we might have lost track somewhere
1 – It started with why multi-tasking in DOS is hard, since every non-trivial DOS program is essentially a mini operating system
2 – Someone mentioned DPMI, which was a “aha” moment. Since most DPMI programs miraculously behaved better.
They still came with drivers for everything, keyboard, mouse, vga, sound blaster, gus, adlib, timer
But at least adhered to some rules
3 – And then I realized Windows was the best multi-tasking DOS
4 – You reminded there were others
Is this a good summary?
sukru,
Sure, I was just perplexed about “the closest thing we had…”.
Anyway all good.
sukru,
I guess you can debate what constitutes a “proper DOS”, but just for the record multitasking DOS was a real thing. Obviously solving the technical problems requires some degree of hardware virtualization. The prime example of this that everyone is familiar with was windows, which managed to run DOS environments concurrently despite the fact they were designed to program the hardware directly. Although the most prominent, windows wasn’t the only game in town that could do that.
Alfman,
That is true. But by Windows 95, they were more or less the best deal in town. They were able to run DOOM and other games entirely windowed in a desktop environment.
There was also OS/2 of course, with their “better than Windows and DOS” emulation. Unfortunately they were not long lived.
kurkosdr,
I suppose. If the goal is concurrency within an application rather than outside of it, then that whittles down the use cases. But a game or CAD program could make use of SMP even without multitasking at the OS level. However if you wanted to play music or run a background process in one application and while going about other normal tasks in another, you’d benefit from having OS level multitasking.
> Personally, I never understood the point of Concurrent DOS.
I supported it in production in the late 1980s and in its time it was an excellent and highly competitive offering in the small-systems space.
> Digital Research chasing the idea of making DOS multitasking and multiuser, when DOS (and more importantly, the apps that run on it) weren’t meant to be such, was Digital Research’s big mistake.
Then you do not understand the history.
In the late 1970s and very early 1980s, DR owned the business microcomputer industry. It wrote and sold CP/M, the industry-standard business micro OS, and because CP/M was the industry standard, business micros mostly used the Intel 8080 or Zilog Z80 CPUs, and used the S100 expansion bus from the MITS Altair.
Then IBM came up with a (for IBM) inexpensive _16-bit_ business micro, with the relatively new Intel 8086. DR did not offer CP/M for the 8086 and it was not binary compatible with Intel’s earlier 8080 line. The 8086 launched in 1979 and IBM already used it in its DisplayWriter dedicated word-processor. DR promised a 16-bit CP/M for over 3 years but didn’t deliver.
https://nemanjatrifunovic.substack.com/p/the-late-arrival-of-16-bit-cpm
MS made a deal to provide the ROM BASIC for IBM’s new machine. With no DR OS available, it also made a deal to provide an OS as well. It licensed SCP’s 86-DOS, Tim Paterson’s homegrown CP/M-a-like OS for the 8086.
86-DOS is not a CP/M clone: in place of CP/M’s filesystem, it uses the disk filesystem from MS Disk BASIC, and 86-DOS was hand-written in assembler while CP/M was written in PL/M and compiled — but 86-DOS was API compatible with CP/M.
The PC was a huge hit and that meant DOS was too.
DR tried to strike back. It already sold MP/M, a multiuser multitasking networked version of CP/M. It also finally launched CP/M-86. It was an official OS from IBM for the PC, but 5x the price of MS-DOS.
CP/M-86 was too little too late. DOS had the lead. DR recognised this and responded by bringing MP/M to the 8086 and merged it with CP/M-86 to create Concurrent CP/M: a multitasking multiuser CP/M for the PC.
It then added DOS application support to Concurrent CP/M to create Concurrent DOS.
So you are missing the critical points here:
1. DR was already the dominant OS vendor when DOS launched, with a design very like DR’s OS.
2. It didn’t develop a multitasking DOS: it developed its own multitasking OS first, _then_ added DOS binary support to it.
3. DR was trying to compete with DOS by offering a better OS that could do things DOS couldn’t, which makes perfect sense.
The niche for Concurrent DOS was simple and obvious: if you wanted a multiuser business computer, for instance several point of sale machines all synched to a single stock database, then UNIX was very expensive and back then mostly needed proprietary hardware. PC networking was in its infancy, and PCs were very expensive so you’d need a $2000+ PC for each employee.
But with CDOS you had 1 powerful PC and a bunch of $500 dumb terminals and cheap serial cables.
If you consider the historical and commercial context it makes perfect sense.
Finally, all those laptops that ship with FreeDOS can take advantage of their multi-core CPUs.
I’ll show myself out…
Back in the 80’s/90’s there was a DOS alternative called Throughbred. It was multiuser/multitasking. I believe that company is still in business although they do business data these days.