Multiuser DOS

Concurrent CP/M-86

The initial version of CP/M-86 1.0 (with BDOS 2.x) was adapted and became available to the IBM PC in 1982. It was commercially unsuccessful as IBM's PC DOS 1.0 offered much the same facilities for a considerably lower price. Like PC DOS, CP/M-86 did not fully exploit the power and capabilities of the new 16-bit machine.

It was soon supplemented by an implementation of CP/M's multitasking 'big brother', MP/M-86 2.0 since September 1981. 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 1.1 (with BDOS 2.2) and MP/M-86 2.x were merged to create Concurrent CP/M-86 3.0 (also known as CCP/M-86) with BDOS 3.0 in 1982/1983. Initially, this was a single-user operating system supporting true multi-tasking of up to four (in its default configuration) CP/M-86 compatible programs. Later versions supported dumb terminals and so could be deployed as multiuser systems. Concurrent CP/M-86 3.1 (BDOS 3.1) shipped on 21 February 1984.

Concurrent CP/M-86 with Windows

In February 1984 Digital Research also offered a version of Concurrent CP/M-86 with windowing capabilities named Concurrent CP/M with Windows for the IBM Personal Computer and Personal Computer XT.

Concurrent CP/M-86/80

This was an adaptation of Concurrent CP/M-86 for the LSI-M4, LSI Octopus and CAL PC computers. These machines had both 16-bit and 8-bit processors, because in the early days of 16-bit personal computing, 8-bit software was more available and often ran faster than the corresponding 16-bit software. Concurrent CP/M-86/80 allowed users to run both CP/M (8-bit) and CP/M-86 (16-bit) applications. When a command was entered, the operating system ran the corresponding application on either the 8-bit or the 16-bit processor, depending on whether the executable file had a .com or .cmd extension. It emulated a CP/M environment for 8-bit programs by translating CP/M system calls into CP/M-86 system calls, which were then executed by the 16-bit processor.

Concurrent DOS

In August 1983, Bruce Skidmore, Ray Pedrizetti, Dave Brown and Gordon Edmonds teamed up to create PC-MODE, an optional module for Concurrent CP/M-86 3.1 (with BDOS 3.1) to provide basic compatibility with PC DOS (and MS-DOS). This was shown publicly at COMDEX in December 1983 and shipped in March 1984 as Concurrent DOS 3.1 (a.k.a. CDOS with BDOS 3.1) to hardware vendors. 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, applications which performed screen manipulations, such as the WordStar word processor for DOS, would not, and native Concurrent CP/M (or CP/M-86) versions were required.

While Concurrent DOS 3.1 up to 4.1 had been developed in the US, OEM adaptations and localizations were carried out by DR Europe's OEM Support Group in Newbury, UK, since 1983.

Digital Research positioned Concurrent DOS 4.1 with GEM as alternative for IBM's TopView in 1985.

Concurrent PC DOS

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 1986 the OEM Support Group was relocated into Digital Research's newly created European Development Centre (EDC) in Hungerford, UK in 1986, which started to take over further development of the Concurrent DOS family since Concurrent DOS 4.11, including siblings like DOS Plus and successors.

Concurrent DOS 286 and FlexOS

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. 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. 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 incorporated into the E-2 step minor changes in the microcode that allowed Digital Research to run emulation mode much faster (see LOADALL). These same limitations affected FlexOS 286 version 1.0, a reengineered derivation of Concurrent DOS 286, which was developed by Digital Research's new Flexible Automation Business Unit in Monterey, CA, since 1986.

Later versions added compatibility with PC DOS 2.x and 3.x.

Concurrent DOS 386 and Concurrent DOS XM

Developed in Digital Research's European Development Centre in Hungerford, UK, versions 5 and 6 (Concurrent DOS XM) could bank switch up to 8 MB of EEMS to provide a real-mode environment to run multiple CP/M-86 and DOS programs concurrently and support up to three users (one local and up to two hooked up via serial terminals).

In 1987, Concurrent DOS was rewritten to become Concurrent DOS 386. This ran on machines equipped with the Intel 80386 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.

Known versions include:

Adaptations

Known CCI Concurrent DOS adaptations by Concurrent Controls, Inc. include:

Multiuser DOS

Later versions of Concurrent DOS 386 incorporated some of the enhanced functionality of DR's later single-user PC DOS clone DR DOS 5.0, after which the product was renamed to the more explanatory Multiuser DOS (a.k.a. MDOS), starting with version 5.0 (with BDOS 6.5) in 1991.

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.

Known versions include:

All versions of Digital Research and Novell DR Multiuser DOS reported themselves as "IBM PC DOS" version 3.31.

DataPac Australasia

Known versions by DataPac Australasia Pty Limited include:

In 1997, Datapac was bought by Citrix Systems, Inc. and System Manager was abandoned soon later. In 2002, the Sydney-based unit was spun out into Citrix' Advanced Products Group.

Concurrent Controls

Known CCI Multiuser DOS versions by Concurrent Controls, Inc. (CCI) include:

All versions of CCI Multiuser DOS report themselves as "IBM PC DOS" version 3.31.

In 1999, CCI changed its name to Applica, Inc. In 2002, Applica Technology became Aplycon Technologies, Inc.

Intelligent Micro Software, Itera and Integrated Solutions

DOS 386 Professional

IMS Multiuser DOS

Known adaptations of IMS Multiuser DOS include:

All versions of IMS Multiuser DOS report themselves as "IBM PC DOS" version 3.31.

REAL/32

Intelligent Micro Software Ltd. (IMS) of Thatcham, UK, acquired a license to further develop Multiuser DOS from Novell in 1994 and renamed their product REAL/32 in 1995.

IMS REAL/32 versions:

REAL/32 7.50 to 7.74 report themselves as "IBM PC DOS" version 3.31, whereas 7.80 and higher report a version of 6.20. LBA and FAT32 support was added with REAL/32 7.90 in 1999. On 2002-04-19, Intelligent Micro Software Ltd. filed for insolvency and was taken over by one of its major customers, Barry Quittenton's Itera Ltd. This company was dissolved on 2006-03-28. Since then REAL/32 is maintained by Integrated Solutions Ltd. of Thatcham, UK.

REAL/NG

REAL/NG was IMS' attempt to create the "Next Generation" of REAL/32, also named "REAL/32 for the internet age". REAL/NG promised "increased range of hardware from PCs to x86 multi-processor server systems".

Advertised feature list, as of 2003:

By 10 December 2003, IMS made "REALNG V1.60-V1.19-V1.12" available, which, based on the Internet Archive, seems to be the latest release.

By 2005, the realng.com website was mirroring the IMS main website, and had no mention of REAL/NG, only REAL/32.

Application software

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 badly-written applications 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 did not 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, 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)