Hm. I'm not entirely sure if you guys reading this thread have a real perception
about the professional or commercial use of a multi-tasking OS in the 1980s.
So please let me explain. I hope you don't mind. It's nothing personal.
- I don't claim to be a true professional, either. But I knew people who were.
Hence, I do at least know that I know nothing. The story of computing has much more depth than it seems.
The world of the end user is very different to that of the developers/professionals etc.
If they were here and if they'd speak about their business past and the hardware they worked with,
most Vogons users would perhaps cry out "history revisionists!", "liars!" etc. 🙄
Okay, let's got back on topic.
Let's take PC-MOS/386 again for example, that "DOS multi-tasker".
Do you guys realize how much it relates to another classic OS ? 😀
PC-MOS/386 was essentially to DOS, what MP/M was to the CP/M era.
MP/M was a power-user version of CP/M: A multi-user, multi-tasking OS.
The real deal, so to say. There also was CP/Net, also fascinating.
MP/M could run ordinary CP/M applications on up to 25 terminals.
Simultanously. If it had enough memory.
To give an idea:
https://hackaday.io/project/163683-the-thing- … -mpm-experiment
https://en.wikipedia.org/wiki/MP/M
8-Bit MP/M also supported at least a few hundred KBs of memory via bank-switching (in 1979);
not much unlike LIM EMS cards for PCs did provide half a decade later on.
Anyway, most end users likely never had heard of MP/M before.
Because they were busy playing Winter Games on their C64 or something.
So it didn't exist, right ?
The few who had to work with CP/M privately likely never used MP/M, either, it seems.
Left alone because it was out of their reach financially and/or because CP/M 2.2 (=DOS) was good enough for them.
Or maybe, because in the later years, a CP/M emulator like NICE22 on PC was all they ever knew about the platform.
When I mentioned MP/M or CP/M v3 a while ago on vcfed, no one was amazed of its potential, either.
That kind of made me sad. I ran it in Zemu and was blown away by MP/M. But that's another story.
--
Okay, maybe that's all still a bit to theoretical.
Let's take a more practical example, a real-world example.
What was very popular in the 1980s?
Garfield ? Leisure Suit Larry ? Stirrup Pants ? Shoulder Pads ? Boxy cars ? Mullets ? VHS ?
Okay, let's take Mullets! Err, no, rather VHS. 😅
VHS. Video tapes.
Back in the day, video rental stores were a big thing. I hope we can agree so far.
People borrowed VHS, brought them back, asked for films of a specific genre..
If you had a video rental store in the 1980s, how did you manage all the data ?
Which film was out, which was coming back, when the <foo> film would come out.. ?
How did you do this ? By hand, using notes ?
10.000 cassettes and a few hundred customers ? (a wild guess, not my field, pardon)
With a database application.
And a huge database.
If you planned to use a C64 and an 1541 drive for that purpose, then good luck.
This is an application calling for a real computer, with a hard disk drive,
with lots of QIC streamer cassettes in storage for making backups from time to time.
If the database was read-only or if some sort of SHARE.EXE was running,
you could even run the whole VHS database on a cheap serial terminal in your entrance
and simulatously have the 80386 host PC in the back room doing a backup of it while it runs.
In fact, you could run the database program in several rooms, simultanously.
Or in one room, for the two or three employees of yours who service the customers simultanously.
That's why the virtual sessions of MP/M and PC-MOS/386 were so fascinating, by the way! 😁
Back in the day, a single powerful PC could replace a hand full of individual PCs.
You could even use a DOS application with a single-PC license on multiple terminals, without breaking the EULA.
Because, it was, in fact, running on a single PC. Just multiple times. 😉
Moral of the story: One proper 80386 system with enough RAM was worth more than a couple of PCs,
while simulanously being cheaper (in price) than a couple of PCs (say, XTs).
In the example of our VHS rental store, this could have even gone so far that
your secondary outlets merely had a terminal installed.
An acoustic coupler or modem was all it needed to call your PC in the main store.
The employee in the small outlet could see the DOS application on his cheap terminal,
as if it was running on a PC locally.
If the small outlet wasn't far away, a null-modem cable could be used, even.
RS-232 can do about 25m without help. That's enough for a cheap wiring in a large building, at least.
With some amplifiers or converters (RS-422, RS485, etc) it would go even further.
Systems like MP/M or MOS/386 weren't being used in mega corporations, big enterprises (not only).
They were being used down the alley, in your favorite store. You may only have never noticed.
--
RAM.
1MB, I think, really wasn't much memory in retro spect. Maybe for home use, yes.
Even if a 32-Bit OS was around, the need for memory would't have had become any lesser.
Rather the contray, as 16-Bit Windows executables teached us in the past.
Ideally, applications don't use much bits - that's what the OS is supposed to use.
16-Bit applications, run on a 32-Bit host provide best performance/memory usage, perhaps.
- Things like the device drivers, the filesystem driver, the scheduler etc: They all do benefit from 32-Bit, and/or the 80386 instructions.
The application, unless it is doing much math on its own, merely calls functions of the OS.
- The low-level part is then done by the OS.
But even if you're doing much number crunching, it's a task for the FPU, anyway.
Commercial software like AutoCAD and PCB programs supported it for a reason.
(If you can't afford it -that old horse again-, run it on an x87 emulator on your 386 - some of them use 32-Bit code.)
So if we're trying to make best use of a 32-Bits processor,
then we would need to truncate/limit the number of bits in the applications code.
Always using 32-Bit values for each little thing isn't very efficent.
Otherwise, the CPU's external cache must cache unneccesary and large 32-Bit code.
This would make an "all-32-Bit OS" running slower than a plain 16-Bit or a 16-Bit/32-Bit hybrid OS on a 386.
That's why an OS like PC-MOS/386 was written the way it was.
There were a lot of commercial succesful applications for DOS around.
Some of them, like Turbo Pascal, were creating efficient code, even!
But applications grew and grew, more and more data had to be processed.
Even with a 32-Bit software, this trend wasn't stoppable.
Programs needed 500KB each, at the time. With the tendency to grow.
Even with a highly efficient OS, - like PC-MOS/386 kind of was - , the need for RAM was still persisted.
So even if they had been re-compiled freshly for OS/2 or Minix or something,
they would still have been a few hundred KBs in size, maybe even bigger due to 32-Bits.
The need for multitasking those quickly broke the 1MB barrier, no matter what.
Virtual memory at least borrowed some time.
--
80286 vs 80386
That's also why IBM wasn't completely wrong by choosing the 80286.
The 80286 processor was the most advanced 16-Bit processor at the time.
In other words, the "top of the line" x86 processor.
It also was the last one to use the same 16-Bit instruction set of the 8086 used in the IBM PC 5150.
Porting source code from Real-Mode DOS to 16-Bit Protected-Mode was feasible, both were using segmentation.
16-Bit OS/2 was like a "Super DOS", API and ABI wise. The next logical step of an evolution.
Not unlike the IBM AT, which replaced the XT.
So existing products on the market could be adapted without a complete re-write.
Maybe even half-automatically, by using a converter tool.
Turbo Pascal, dBase, Clipper, Lotus 1-2-3, WordStar, AutoCad, P-Cad, etc.
The 80386 surely was remarkable, but it wasn't part of the 16-Bit family.
It was another category. It was x86, surely, but part of another market segment.
Once you start to think in categories like Personal Computing, micro computers, 16-Bit etc.
Then the decisions of IBM do make sense, in a weird kind of way.
The relationship of IBM vs end users was like a relationship between a king and its citizens, maybe.
Once you're in a high position, like a politician, you can hardly relate to the people "down there" anymore.
And that's the big difference to Microsoft I think. They worked with the OEM market, which served end-users.
Like masterminds who worked together with their dealers to serve their.. "customers". IMHO. 😉
The 80386 was highly needed by Microsoft, unlike IBM.
Merely the 80386 could emulate multiple 8086 CPUs simultanously;
to run badly written/crashy DOS and Windows applications side-by-side. 😉
(If they were clean, Concurrent-DOS 286 and the 286 would have had sufficed.)
With 16-Bit OS/2, that never would have been necessary to begin with. No need for V86.
Windows 3.0 application running via WLO DLLs were already natively running on a 286 (or 386).
They could multi-task without any need for V86. Microsoft made a first step here, also, by requiring Windows 3.0 applications to be "clean" (MARK utility).
Same goes for Family API programs (OS/2 programs with a built-in OS/2 runtime; for use on DOS).
They could multi-task, if being run on OS/2.
If all existing native-DOS programs had been replaced by Family API programs,
they could still run on outdated hardware of its time: The OS/2 runtime would make them run on old DOS PCs.
Same goes for 16-Bit Windows applications with that WLO header.
With a bit of exchanging "backup copies", the whole IT world-wide could have had updated ("migrated") over night.
Similarily to how PC-/MS-DOS 3.x made it around the globe. It almost replaced DOS 2.x over night.
The whole concept of Windows NT's NTVDM/WoW and 32-Bit OS/2's VDM/Win-OS/2 wasn't needed at the time.
If everything had continued as planned, both 16-Bit Windows and DOS were going to unify with OS/2 (WLO, Family API) by the end of the 80s.
Late 1980s programs like PDS 7.1 already supported compiling such hybrid EXEs out-of-box.
If 16-Bit OS/2 had succeded as expected, as planned (hoped), the resulting programs could still run fine on an 80386.
- In fact, some Microsoft releases of 16-Bit OS/2 had a 32-Bit HPFS driver to take advantage of the 80386.
The support for the 80386 never was in danger. Later releases of OS/2 could run on both CPUs, maybe.
Windows 2.x also was available for PC/XT, AT and AT 386, after all.
Really, no one was de-valuing the 80386. Rather the contrary, OS/2 as an 80286 OS saw it as a high-end CPU.
That's akin to how Windows 2.x thought highly of the 256 colour modes of VGA, I think.
256c was hi-def to it. It used it to dither in tru-colour, as best at it could.
If history had been slightly different, all current 32-Bit or 64-Bit releases of OS/2
could still run those weird "Microsoft Windows" applications from the distant past just fine.
We would look back at them, maybe, while scratching our heads in wonderment.
That's why I started this thread originally, I guess.
Willow/WLO was an interesting fusion of both 16-Bit worlds.
PS: Attached are pictures of a demo copy of PC-MOS/386 from 1987.
Unfortunately, I can't link here to the download of the "PC-MOS 386 demo".
The Wyse terminal is the kind of serial hardware that was used back then.
Also worth testing isthis solid-state database.
Please run in on an XT class PC first, and then on an AT. 😀
It will give you an idea how demanding a DOS database application can be.
Depending on the XT's specs, it may need minutes to fish out a single entry (BC548, 8086 etc).
If you can't run it, please watch a video of it, at least:
https://www.youtube.com/watch?v=cMZK64LaUn0