I was introduced to Multi-user software in the mid 1980's by an OEM who was implementing MP/M II to run on a TRS 80 Model II. I was the primary beta site for the project. Old timers will remember that there were quite a few upscale S-100 computers that supported a multi-user configuration. MP/M II was the multi-tasking version of CP/M.
A rarely lamented truth is the fact that DOS as we know it, has proved far more difficult to implement in a multi-tasking mode than CP/M. The MP/M II multi-tasking concept was quite straight forward and within its limitations worked quite well. I added a special card into the TRS 80 Model II that contained 384k RAM and 4 serial ports. The fact that CP/M and been designed in the beginning to run on a paper terminal (A Teletype with a keyboard) actually made it easier to get multi-tasking to work. In as much as the Teletype was the classic serial device, the usage of terminals and modems was inherent in the CP/M design. Multi-tasking in the CP/M world was likewise fairly easily implemented. The multi-tasking kernel was loaded in the upper 16k of the available 64k RAM which represented the maximum address space supported by the 8080/Z80 family of processors, and the 'lower 48' was available for bank switching. The latter was accomplished via hardware calls.
In order to switch tasks, the multi-tasking kernel merely had to save all the register contents from the CPU which it did by pushing them on a stack, make a hardware call to switch into position the RAM bank associated with the next process to be run, Pop the stacks associated with that task, and let it run.
Intelligence was added to the task switching fairly easily. Since all I/O came in via CPU ports, the multi-tasking kernel could monitor the the port status of the appropriate ports and adjust the time slices to favor the tasks that were active. Even a 4 megahertz Z80 didn't have trouble getting around to receive the input from quite a number of keyboards. The over all result was reminiscent of surfing the WEB with a modem connection. Sometimes you wait, and sometimes performance is better than other times!
Though the concept was a success, and though for a year or so I ran as many as 4 users on a TRS 80 with 4 of the 8 inch floppy drives, the marketing was not so successful. The decade of Dos had arrived. In a tragic setback for multi-tasking, MicroSoft Dos (MSDOS) won out over CP/M 86 in the market place during the transition to the 8088 processor. There are a lot of stories about how or why IBM tilted to MSDOS over CP/M 86, but the consequences to the multi-tasking community were profound.
MSDOS and CP/M 86 were very similar in many respects, but MSDOS had some missing parts. Their API's were different, but the real problem was that MSDOS left out the serial port and terminal support. MSDOS also assumed there would be a video card of some type memory mapped into the address area somewhere above A000h. You could load ANSI.SYS and get MSDOS to recognize an ESCAPE Code, but software writers quickly worked around the 'non support' of serial ports under MSDOS by writing numerous applications that went straight to the hardware when using the serial port. This glaring defect in MSDOS is still with us today and explains when in every application that uses a serial port you must define within the application which serial port your are using (COM1, COM2, etc.). In fairness to MSDOS however, I should note that CP/M (all versions) contained numerous invitations for direct hardware calls as well, so don't assume from my comments here that if CP/M 86 had taken over the world, that today there would be no problems with the heritage of undocumented hardware calls.
If the MSDOS API had been sufficiently robust so as to properly support serial communications, the "Which COM port is my modem on?" question would never need to be answered but once. The applications would interact with the virtual port which could be known as simple the "modem port" and the operating system could handle the mundane task of routing the communications to the physical port of your choice. In this vision, when you installed a modem, you would declare its characteristics to the 'operating system' and the applications would be immediately functional. We had this in 1976 in CP/M, but on the road to DOS land we lost it, and multi-tasking with it. To this day, if on your DOS computer if you reach around behind it and yank the modem cable out of COM1 and stick it into COM2, you will have to redefine and reconfigure every modem program that you have to inform it of the change instead of simply selecting a DOS configuration option to "route modem output to COM 2".
The 8086-8088 CPU (characteristic of the classic PC) presented an inherent opportunity for multi-tasking by virtue of its very design. It achieved its increased address space (up to 1 megabyte) be adding a segment register. Thus the 8086-8088 was in one sense, simply the 8080 memory model with integrated bank switching. This should have been a dream for a multi-tasking operating system, because the various 64k segments could be easily accessed very quickly within the CPU address set and without going outside for 'buss calls' to switch memory banks.
It was not to be, however. Digital Research (creator's of CP/M) produced 'Concurrent CP/M' which never threatened to dominate the market. Early on Digital Research attempted to market their CP/M 86 API (which was more conducive to multi tasking that the MSDOS API), but it was a market failure. After all, technically superior software does not always win out over alternatives.
The demise of the ESCAPE code video controls and the rise of the memory mapped video presented a formidable obstacle to multi-tasking. The ESCAPE Codes were designed to be embedded in the flow of data and were thus easy to send 'down the hose' to a terminal. Stated simply, in the classic multi-user configuration with multiple terminals as used in MP/M II there is no place for multiple memory mapped video cards yet, the dos software which quickly became popular assumed that it would have exclusive use of a video card. That was a problem
Before these problems were answered, the large memory model dos program came to be. This large model application assumed that multiple 64k segments would be available and indeed today DOS tasks which will load and run in less than 512k of RAM are rare. Although there is conceptual utility in running a multitude of 64k programs, the practical use is certainly non-existent in the mass market where small model programs are not to be found. It's not that a multitude of small model programs linked or piped together might not have served as well as better than a large memory model development just didn't go in that direction. Additionally TSRs were invented of which Sidekick was the classic. This added an element of multi-tasking to the large memory model while at the same time complicating the virtualization of the DOS model because every TSR of necessity relied on undocumented system calls in order to function.
In an orderly world, one would design the operating system and then write the applications to fit within the operating system, but as the Dos market exploded the applications drove the market. People bought and used TSR's because they filled a need, and screamed at the operating system's folks if they didn't run. Never mind that every TSR ever written is by definition a maverick program which does not conform to the standards expected of programs functioning within the DOS API. It is small wonder that whenever anyone has a DOS computer that misbehaves the first advice give is to "unload all TSR programs!"