| Company / developer | Digital Research, Inc. |
|---|---|
| OS family | CP/M |
| Working state | Current |
| Source model | Closed source |
| Latest stable release | V7.22 R18 / 2004 |
| Kernel type | Monolithic kernel |
| Default user interface | Command line interface |
| License | Proprietary |
| Official website | Various (see notes) |
Multiuser DOS is a soft real-time multi-user multi-tasking operating system for IBM PC-compatible microcomputers.
An evolution of the older Concurrent CP/M-86 and Concurrent DOS operating systems, it was originally developed by Digital Research and later further developed by Novell. Its ancestry lies in the earlier Digital Research 8-bit operating systems CP/M and MP/M and the 16-bit single-tasking CP/M-86 which evolved from CP/M.
Contents |
The initial version of CP/M for the IBM PC, CP/M-86, was commercially unsuccessful, as Microsoft's MS-DOS offered much the same facilities for a considerably lower price. Like MS-DOS 1.0, CP/M-86 did not fully exploit the power and capabilities of the new 16-bit machine.
It was soon superseded by an implementation of CP/M's multitasking 'big brother', MP/M-86. This turned a PC into a multiuser machine capable of supporting multiple concurrent users using dumb terminals attached by serial ports. The environment presented to each user made it seem as if they had the entire computer to themselves. Since terminals cost a fraction of the then-substantial price of a complete PC, this offered considerable cost savings, as well as facilitating multi-user applications such as accounts or stock control in a time when PC networks were rare, very expensive and difficult to implement.
CP/M-86 and MP/M-86 were later merged to create Concurrent CP/M-86 (also known as CCP/M-86 with BDOS 3.0), which offered CP/M-86 compatibility in conjunction with MP/M-86's multiuser capabilities. Concurrent CP/M-86 3.1 (BDOS 3.1) shipped on 21 February 1984.[1]
In August 1983, Bruce Skidmore, Ray Pedrizetti, Dave Brown and Gordon Edmonds teamed up to create PC-MODE,[2] an optional module for Concurrent CP/M-86 3.1[1] (with BDOS 3.1) to provide basic compatibility with PC DOS (and MS-DOS). This was shown publicly in December 1983[2] and shipped in March 1984 as Concurrent DOS 3.1 (aka CDOS with BDOS 3.1) to hardware vendors.[3] Simple DOS applications, which did not directly access the screen or other hardware, could be run. For example, although a console program such as PKZIP worked perfectly and offered more facilities than the CP/M-native ARC archiver, more complex applications which performed screen manipulations, such as WordStar for DOS, would not, and thus native Concurrent CP/M versions were required.
Concurrent DOS 3.2 (with BDOS 3.2) in 1984 was compatible with PC DOS 1.x and was available for many different hardware platforms, the version with an IBM PC compatible BIOS/XIOS was named Concurrent PC DOS 3.2.
In January 1985, Digital Research previewed Concurrent DOS 286 in cooperation with Intel. The operating system would function strictly in 80286 native mode, allowing protected mode multi-user, multitasking operation while running 8086 emulation.[4] While this worked on the B-1 step of prototype chip samples, Digital Research, with evaluation copies of their operating system already shipping in April, discovered problems with the emulation on the production level C-1 step of the processor in May, which would not allow Concurrent DOS 286 to run 8086 software in protected mode. The release of Concurrent DOS 286 had been scheduled for late May, but was delayed until Intel could develop a new version of the chip.[4] In August, after extensive testing E-1 step samples of the 80286, Digital Research said that Intel had corrected all documented 286 errata, but that there were still undocumented chip performance problems with the prerelease version of Concurrent DOS 286 running on the E-1 step. Intel said that the approach, Digital Research wished to take in emulating 8086 software in protected mode differed from the original specifications; nevertheless they implemented minor changes in the microcode that allowed Digital Research to run emulation mode much faster, incorporated into the E-2 step.[5] These same limitations affected FlexOS 286 version 1.0, a derivation of Concurrent DOS 286.
Later versions added compatibility with PC DOS 2.x and 3.x.
Versions 5 and 6 (Concurrent DOS XM) could bank switch multiple programs using EMS.
In 1987 Concurrent DOS was rewritten and renamed Concurrent DOS 386. This ran on machines equipped with the Intel 80386 processor (and later processors), using the 386's hardware facilities for virtualizing the hardware, allowing most DOS applications to run unmodified under Concurrent DOS 386, even on terminals. The OS supported concurrent multiuser file access, allowing multiuser applications to run as if they were on individual PCs attached to a network server. Concurrent DOS 386 allowed a single server to support a number of users on dumb terminals or inexpensive low-specification PCs running terminal emulation software, without the need for expensive workstations and then-expensive network cards. It was a true multiuser system; several users could use a single database with record locking to prevent mutual interference.
Later versions of Concurrent DOS incorporated some of the enhanced functionality of DR's later single-user PC DOS clone DR-DOS, after which the product was renamed to the more explanatory Multiuser DOS (aka MDOS).
Multiuser DOS suffered from several technical limitations that restricted its ability to compete with LANs based on PC DOS. It required its own special device drivers for much common hardware, as PC DOS drivers were not multiuser or multi-tasking aware. Driver installation was more complex than the simple PC DOS method of copying the files onto the boot disk and modifying CONFIG.SYS appropriately - it was necessary to relink the Multiuser DOS kernel (known as a nucleus) using the SYSGEN command.
Multiuser DOS was also unable to use many common PC DOS additions such as network stacks, and it was limited in its ability to support later developments in the PC-compatible world, such as graphics adaptors, sound cards, CD-ROM drives and mice. Although many of these were soon rectified—for example, graphical terminals were developed, allowing users to use CGA, EGA and VGA software—it was less flexible in this regard than a network of individual PCs, and as the prices of these fell, it became less and less competitive, although it still offered benefits in terms of management and lower total cost of ownership. Unlike MP/M, it never became popular for single-user but multitasking use. It was priced as a multi-user operating system, of course, and required special device drivers, unlike single-user multitasking DOS additions such as Quarterdeck's DESQview.
While the various releases of this operating system had increasing ability to run MS-DOS programs, software written for the platform could take advantage of its features by using function calls specifically suitable for multiuser operation. It used pre-emptive multitasking, preventing any one badly-written application from delaying other processes by retaining control of the processor.
The API provided support for blocking and non-blocking message queues, mutual-exclusion queues, the ability to create sub-process threads which executed independently from the parent, and a method of pausing execution which did not waste processor cycles, unlike idle loops used by single-user operating systems. Applications were started as "attached" to a console. However, if an application didn't need user interaction it could "detach" from the console and run as a background process, later reattaching to a console if needed.
Another key feature was that the memory management supported a "shared" memory model for processes (in addition to the usual models available to normal DOS programs). In the shared memory model the "code" and "data" sections of a program were isolated from each other. Because the "code" contained no modifiable data, code sections in memory could be shared by several processes running the same program.
Programs written, or adapted, for any multitasking platform need to avoid the technique used by single-tasking systems of going into endless loops until interrupted when, for example, waiting for a user to press a key; this wasted processor time that could be used by other processes. Instead, Concurrent DOS provided an API call which a process could call to "sleep" for a period of time. Later versions of the Concurrent DOS kernel included Idle Detection, an innovative feature which monitored MS-DOS API calls to determine whether the application was doing useful work or in fact idle, in which case the process was suspended allowing other processes to run. Idle Detection was the catalyst for the patented DR-DOS Dynamic Idle Detection power management feature invented in 1989 by Roger Gross and John Constant and marketed as BatteryMax (US Patent 5,355501)