Operating System Software

CP/M

Read more about CP/M, DR-DOS and how Microsoft became Microsoft here.

CP/M was an operating system originally created for Intel 8080/85 based microcomputers by Gary Kildall of Digital Research, Inc. Initially confined to single tasking on 8-bit processors and no more than 64 kilobytes of memory, later versions of CP/M added multi-user variations, and were migrated to 16-bit processors.

CP/M stood for either Control Program/Monitor or Control Program for Microcomputers (the latter being a backronym). The name shows a prevailing naming scheme of the time, as in Kildall's/Intel's PL/M (Programming Language for Microcomputers) and Prime Computer's PL/P (Programming Language for Prime), both suggesting IBM's PL/I; and IBM's CP/CMS operating system, which Kildall used when working at the Naval Postgraduate School, and which, like TOPS-10, has clear similarities to the CP/M user interface and file system. Gary Kildall himself renamed CP/M in word form as part of the maturation of CP/M from personal project in 1974 to commercial enterprise in 1976.

The combination of CP/M and S-100 bus computers patterned on the MITS Altair was an early "industry standard" for microcomputers, and was widely used through the late 1970s and into the mid-'80s. By greatly reducing the amount of programming required to install an application on a new manufacturer's computer, CP/M increased the market size for both hardware and software.

Hardware model

A minimal 8-bit CP/M system would contain the following components:

• A computer terminal using the ASCII character set
• An Intel 8080 (and later the 8085) microprocessor
• At least 16 kilobytes of RAM
• A minimal bootloader in ROM
• At least one diskette drive.

The only hardware system that CP/M, as sold by Digital Research, would support was the Intel 8080 Development System. Every manufacturer of CP/M compatible systems would customize portions of the operating system for its combination of installed memory, disk drives, and console devices.

CP/M would also run on systems based on the Zilog Z80 processor since the Z80 was able to execute 8080 code. CP/M did not use any of the Z80 specific instructions.

Components of the operating system

In the 8-bit versions, CP/M's software was separated into three components

• console command processor or CCP,
• basic disk operating system or BDOS, and
• basic input/output system or BIOS.

The CCP and BDOS were the same in all installations of a particular revision of CP/M, but the BIOS portion was always adapted to the particular hardware. Adding memory to a computer, for example, meant that the CP/M system had to be reinstalled. Once installed, the operating system was stored in reserved areas at the beginning of each floppy disk. On power-up, the ROM-resident bootloader would look for a floppy disk in drive A: and load from it the operating system.

By modern standards CP/M was primitive owing to the extreme constraints on program size. With version 1.0 there was no provision for detecting a changed disk. If a user changed disks without manually rereading the disk directory the system would write on the new disk using the old disk's data, ruining the data stored on the disk. Starting with 1.1 or 1.2 this danger was reduced: if one changed disks without reading the new disk's directory, and tried to write to it, the operating system would signal a fatal error, avoiding overwriting but requiring a reboot (which took no more than a few seconds).

The majority of the complexity in CP/M was isolated in the BDOS, and to a lesser extent, the CCP. This meant that by porting the limited number of simple commands in the BIOS to a particular hardware platform, the entire OS would work. This significantly reduced the development time needed to support new machines, and was one of the main reasons for CP/M's widespread use. Today this sort of abstraction is common to most OSs, but at the time of CP/M's birth, OSs were typically intended to run on only one machine platform, and multilayer designs were considered unnecessary.

Command processor

The command processor or CCP accepted input from the keyboard. All CP/M commands had to be typed in on the "command line" — the screen would show most often A> and would await input from the user.

CP/M's command line interface was patterned after the operating systems from Digital Equipment, such as RSTS/E for the PDP-11.

Commands generally took the form of a keyword followed by a list of parameters separated by spaces or special characters. If an internal command was recognized, it was carried out by the CCP itself. Otherwise it would attempt to find an executable file on the currently logged disk drive and user area, load it, and pass it any additional parameters from the command line. On completion of a transient program, CP/M would reload the part of the CCP that had been overwritten by application programs — this allowed transient programs a larger memory space.

The commands themselves could sometimes be obscure. For instance, the command to duplicate fileswas named PIP (Peripheral-Interchange-Program), the name of the old DEC utility used for that purpose. The format of parameters given to a program was not yet standardized, so that there was no single "option character" that differentiated options from file names (only the last version of CP/M included options in square brackets fairly consistently).

Basic disk operating system

The basic disk operating system (BDOS) provided access to such operations as opening a file, output to the console, or printing. Application programs would load processor registers with a function code for the operation, and addresses for parameters or memory buffers, and call a fixed address in memory. Since the address was the same independent of the amount of memory in the system, application programs would run the same way for any type or configuration of hardware.

Basic input output system

The basic input output system or BIOS provided the lowest level functions required by the operating system. These included reading or writing single characters to the system consoles and reading or writing a sector of data from the disk. The BDOS handled some of the buffering of data from the diskette, but before CP/M 3.0 it assumed a fixed disk sector size of 128 Bytes, as used on single-density 8-inch floppy disks. Since most 5.25-inch disk formats used larger sectors, the blocking and deblocking and the management of a disk buffer area was handled by model-specific code in the BIOS.

File system

File names consisted of up to 8 characters, a period, then up to three characters as a file name extension. The extension usually identified the type of the file. For example, .COM indicated a binary executable program file, and .TXT indicated a file containing ASCII text.

File size was specified as the number of 128-byte records (directly corresponding to disk sectors on 8-inch drives) occupied by a file on the disk.There was no generally supported way of specifying byte-exact file sizes. The current size of a file was maintained in the file's file control block (FCB) by the operating system. Since many application programs (such as text editors) prefer to deal with files as sequences of characters rather than as sequences of records, by convention text files were terminated with a control-Z character (ASCII SUB, hexadecimal 1A). Determining the end of a text file therefore involved examing the last record of the file to locate the terminating control-Z. This also meant that inserting a control-Z character into the middle of a file usually had the effect of truncating the text contents of the file.

File modification times (timestamps) were not supported, although some later variants of CP/M added this feature as an extension.

CP/M 2.2 had no sub-directories in the file structure but provided 16 "user areas" to organize files on a disk. The user area concept was to make the single-user version of CP/M somewhat compatible with multi-user MP/M systems. A common patch for the CP/M and derivative operating systems was to make one user area accessible to the user independent of the currently set user area. A supported command was "USER x" where x is a value from 0 to 15. User 0 was the default. If one changed to another user, such as USER 1, the material saved on the disk for this user would only be available to USER 1; USER 2 would not be able to see it or access it. Since CP/M was a single-user operating system, no security was provided for the user command; nothing would prevent any user from logging in successively as any of the 16 users. The user area feature arguably had little utility on small floppy disks, though it was more useful for organizing files on machines equipped with large hard drives.

History

The beginning and CP/M's heyday

In 1974 CP/M was a private project of Gary Kildall, under the name "Control Program/Monitor". During the conversion of CP/M to a commercial product, trademark registration documents filed in November 1977 gave the product's name as "Control Program for Microcomputers".

This renaming of CP/M was part of a larger effort by Kildall and his business-partner wife to convert Kildall's personal project of CP/M and the Intel-contracted PL/M compiler into a commercial enterprise. The Kildalls astutely intended to establish the Digital Research brand and its product lines as synonymous with "microcomputer" in the consumer's mind, similar to what IBM and Microsoft together later successfully accomplished in making "personal computer" synonymous with IBM and Microsoft product offerings. Intergalactic Digital Research, Inc. was later renamed via a corporation change-of-name filing to Digital Research, Inc..

CP/M used the 7-bit ASCII set. The other 128 characters made possible by the 8-bit byte were not standardized. For example, one Kaypro used them for Greek characters, and Osborne machines used the 8th bit set to indicate an underlined character. International CP/M systems most commonly used the ISO 646 norm for localized character sets, replacing certain ASCII characters with localized characters rather than adding them beyond the 7-bit boundary.

While graphics-capable S100 systems existed from the commercialization of the S100 bus, CP/M did not provide any standardized graphics support until the release of CP/M 3.0 with GSX (Graphic System eXtension). Owing to the small memory available, graphics was never a common feature associated with 8-bit CP/M operating systems.

While the 8-inch single density format (so-called "distribution format") was standardized, various 5¼ inch formats were used depending on the characteristics of particular systems and to some degree the choices of the designers. No single manufacturer prevailed in the 5¼ inch era of CP/M use. A software manufacturer had to prepare a separate version of the program for each brand of hardware on which it was to run. With some manufacturers (Kaypro is an example), there was not even standardization across the company's different models. Because of this situation, disk format translation programs, which allowed a machine to read many different formats, became popular and reduced the confusion, as did programs like kermit which allowed transfer of data and programs from one machine to another using the serial ports that most CP/M machines had. The fragmented CP/M market, requiring distributors either to stock multiple formats of disks or to invest in multiformat duplication equipment, compared with the more standardized IBM PC disk formats, was a contributing factor to the rapid obsolescence of CP/M after 1981.

CP/M was described as a "software bus", allowing multiple programs to interact with different hardware in a standardized way. Programs written for CP/M were typically portable between different machines, usually only requiring specification of theescape sequence for control of the screen and printer. This portability made CP/M popular, and much more software was written for CP/M than for operating systems that only ran on one brand of hardware. One restriction on portability was that certain programs used the extended instruction set of the Z80 processor and would not operate on an 8080 or 8085 processor.

Hundreds of different brands of machines ran CP/M, some notable examples being the Altair, the IMSAI 8080, the Osborne 1 and Kaypro portables, MSX, and even the Apple II when an extra Z80-card was installed. The best selling CP/M capable system of all time was probably the Commodore 128, although few people actually used its CP/M abilities. In the UK, CP/M was also available for the BBC Micro when equipped with a Z80 co-processor. Furthermore, it powered the popular Amstrad PCW word-processing system and was available for the Amstrad CPC series.

WordStar, one of the first widely used word processors, and dBASE, an early and popular database program for small computers, were originally written for CP/M. An early outliner, KAMAS (Knowledge and Mind Amplification System) was also written for CP/M, though later rewritten for MS-DOS. Turbo Pascal, the ancestor of Borland Delphi, and Multiplan, the ancestor of Microsoft Excel, also debuted on CP/M before MS-DOS versions became available. Various character or text-based games were written. Lifeboat Associates started collecting and distributing user-written "free" software. One of the first was XMODEM, which allowed communication via modem and phone line.

The 16-bit world

Versions of CP/M were later completed for some 16-bit CPUs as well, although they required the application programs to be re-compiled for the new CPUs -- or, if they were written in assembly language, to be largely rewritten from scratch.

One of the first was CP/M-86 for the Intel 8086, which was soon followed by CP/M-68k for the Motorola 68000. At this point the original 8-bit CP/M became known as CP/M-80 to avoid confusion. There was also a port to the Zilog Z8000, named CP/M-8000.

CP/M-68k was initially used in the Atari ST computer, but Atari decided to go with a newer DOS called GEMDOS. It also was used on the SORD M68 and M68MX computers. CP/M-86 was expected to be the standard operating system of the new IBM PCs, but DRI and IBM were unable to negotiate development and licensing terms. IBM turned to Microsoft instead, and Microsoft delivered PC-DOS based on a CP/M "clone," 86-DOS. Although CP/M-86 became an option for the IBM PC after DRI threatened legal action, it never overtook Microsoft's system.

WhenDigital Equipment Corporation put out the Rainbow 100 to compete with IBM, it came with CP/M-80 using a Z80 chip, and CP/M-86 or MS-DOS using an 8088 microprocessor. The Z80 and 8088 CPUs ran concurrently. A benefit of the Rainbow was that it could continue to run 8-bit CP/M software as users moved into the 16-bit world of MS-DOS.

MS-DOS takes over

Many of the basic concepts and internal mechanisms of early versions of MS-DOS were patterned after those of CP/M. Internals like file-handling data structures were identical, and both referred to disk drives with a letter (A:, B:, etc.). The main innovation was MS-DOS's FAT file system. This intentional similarity made it easier to port popular CP/M software like WordStar and dBase. However, CP/M's concept of separate user areas for files on the same disk was never ported to MS-DOS. Since MS-DOS had access to more memory (as few IBM PCs were sold with less than 64 KiB of memory, while CP/M had to run in 16 KiB if necessary), more commands were built in to the command-line user interface logic, making MS-DOS somewhat faster and easier to use on floppy-based computers.

CP/M rapidly lost market share as the microcomputing market moved to the PC platform, and it never regained its former popularity. Byte Magazine, at the time one of the leading industry magazines for microcomputers, essentially ceased covering CP/M products within a few years of the introduction of the IBM PC. For example, in 1983 there were still a few advertisements for S100 boards and articles on CP/M software, but by 1987 these were no longer found in the magazine.

Later versions of CP/M-86 made significant strides in performance and usability however and were made compatible with MS-DOS. For some time in the 1980s, the resulting system was considered to be a better x86 OS than MS-DOS. To reflect this compatibility the name was changed, and CP/M-86 became DOS Plus, which in turn became DR-DOS.

ZCPR

ZCPR (the Z80 Command Processor Replacement) was introduced on February 2, 1982 as a drop-in replacement for the standard Digital Research command processor (CCP) and was initially written by a group of computer hobbyists who called themselves "The CCP Group". They were Frank Wancho, Keith Petersen (the archivist behind Simtel at the time), Ron Fowler, Charlie Strom, Bob Mathias, and Richard Conn. Richard was, in fact, the driving force in this group (all of whom maintained contact through email).

ZCPR1 was released on a disk put out by SIG/M (Special Interest Group/Microcomputers), a part of the Amateur Computer Club of New Jersey.

ZCPR2 was released on February 14, 1983. It was released as a set of ten disks from SIG/M. ZCPR2 was upgraded to 2.3, and also was released in 8080 code, permitting the use of ZCPR2 on 8080 and 8085 systems.

ZCPR3 was released on Bastille Day, July 14, 1984, as a set of nine disks from SIG/M. The code for ZCPR3 could also be compiled (with reduced features) for the 8080 and would run on systems that did not have the requisite Z80 microprocessor.

In January of 1987, Richard Conn decided to stop developing ZCPR, and Echelon asked Jay Sage (who already had a privately enhanced ZCPR 3.1) to continue work on ZCPR. Thus, ZCPR 3.3 was developed and released. ZCPR33 no longer supported the 8080 series of microprocessors, and added the most features of any upgrade in the ZCPR line.

Features of ZCPR as of version 3 included:

• shells
• aliases
• I/O redirection
• flow control
• named directories
• search paths
• custom menus
• passwords
• on line help

ZCPR3.3 also included a full complement of utilities with considerably extended capabilities. While enthusiastically supported by the CP/M user base of the time, ZCPR alone was insufficient to slow the demise of CP/M.

• ZCPR3, The Manual by Richard Conn: ISBN 0918432596
• comp.os.cpm FAQ (also present at this Digital Research related site)
• Z-System Corner: Tenth Anniversary of ZCPR - part of The Computer Journal, issue 54

DOS [MS-DOS, DRDOS, PCDOS, IBM-DOS]

• Single Tasking. DOS could load only one program at a time.
• 640 KB memory barrier. Dos was not design to handle the large amounts of RAM which PCs began to have.
• 16 bit architecture. DOS was design for 16-bit CPUs and could not take advantage of the 32-bit processors which were introduced in 1985. [The 80386]
• Command Line Interface. DOS used a Command Line Interface, (sometimes called a Character Cell Interface).

MS Windows 3.x - an operating environment

Graphical Environment Manager

GEM (Graphical Environment Manager) was a windowing system created by Digital Research, Inc. (DRI) for use with the CP/M operating system on the Intel 8088 and Motorola 68000 microprocessors. Later versions ran over DOS as well.

GEM is known primarily as the graphical user interface (GUI) for the Atari ST series of computers, and was also supplied with a series of IBM PC-compatible computers from Amstrad. It was the core for a small number of DOS programs, the most notable being Ventura Publisher. It was ported to a number of other computers that previously lacked graphical interfaces, but never gained popularity on those platforms. DRI also produced FlexGem for their FlexOS realtime operating system.

History

GSX

GEM started life at DRI as a more general purpose graphics library known as GSX (Graphics System eXtension), written by a team led by Lee Jay Lorenzen who had recently left Xerox PARC (birthplace of the GUI). GSX was essentially a DRI-specific implementation of the GKS graphics standard proposed in the late 1970s. GSX was intended to allow DRI to write graphics programs (charting, etc.) for any of the platforms CP/M would run on, a task that would otherwise require considerable effort to port due to the large differences in graphics hardware (and concepts) between the various systems of that era.

GSX consisted of two parts: a selection of routines for common drawing operations, and the device drivers that are responsible for handling the actual output. The former was known as GDOS and the latter as GIOS, a play on the division of CP/M into machine-independent BDOS and machine-specific BIOS. GDOS was a selection of routines that handled the GKS drawing, while GIOS actually used the underlying hardware to produce the output.

GEM

GSX evolved into one part of what would later be known as GEM, which was an effort to build a fully GUI system using the earlier GSX work as its basis. Originally known as Crystal as a play on an IBM project called Glass, the name was later changed to Gem, the use of the acronym evolved later (see backronym).

Under GEM, GSX became the GEM VDI, responsible for basic graphics and drawing. VDI also added the ability to work with multiple fonts and added a selection of raster drawing commands to the formerly vector-only GKS-based drawing commands. VDI also added multiple viewports, a key addition for use with windows.

A new module, GEM AES (Application Environment Services), provided the window management and UI elements, and GEM Desktop used both libraries in combination to provide a Mac-like GUI. The 8086 version of the entire system was first demoed at the 1984 COMDEX, and shipped as GEM/1 on 28 February 1985.

Later versions

At this point Apple Computer sued DRI in what would turn into a long dispute over the "look and feel" of the GEM/1 system, which was an almost direct copy of the Macintosh (with some elements bearing a closer resemblance to those in the earlier Lisa). This eventually led to DRI being forced to change several basic features of the system. Apple would later go on to sue other companies for similar issues.

DRI responded with the "lawsuit friendly" GEM/2, which allowed the display of only two fixed windows on the "desktop" (other programs could do what they wished however), changed the trash can icon, and removed the animations for things like opening and closing windows. It was otherwise similar to GEM/1, but also included a number of bug fixes and cosmetic improvements.

The last commercial release was GEM/3 which had speed improvements and shipped with a number of basic applications. Commercial sales of GEM ended with GEM/3; the source code was subsequently made available to a number of DRI's leading customers.

One-off versions

GEM/4 included the ability to work with Bézier curves, a feature still not common outside the PostScript world. This version was produced specifically for Artline a drawing program from CCP. The system also included changes to the font management system, which made it incompatible with the likes of Timeworks Publisher.

Another version of GEM called GEM/5 was produced by GST for Timeworks Publisher 2.1. It contained an updated look with 3D buttons, font scaling on the fly was included. It came complete with all the standard 3.1 tools. This version was produced from GEM 3.13 with only the Bézier handling taken from GEM 4.

ViewMax

GEM Desktop itself was spun off as a product known as ViewMAX which was used solely as a file management shell under DR-DOS. In this form the system could not run other GEM programs. This led to the odd situation where you could have a number of applications (including ViewMAX) all with their own copy of the GEM system "inside" of them. This scenario was actually rare, as there were not that many GEM programs.

In these forms GEM survived until DRI was purchased by Novell and all GEM development was cancelled.

Throughout this time DRI had also been working on making the GEM system capable of multitasking. This started with X/GEM based on GEM/1, but this required use of one of the multitasking CP/M based operating systems. GEM/XM was an updated version of GEM/2 which allowed multitasking and the ability to run DOS programs in shell windows (as Windows does today). None of these saw the light of day, but the GEM/XM source code is now freely available under the GNU General Public License.

Lee Lorenzen had left soon after the release of GEM/1, when it became clear that DRI had no strong interest in applications development. He then formed his own company with another of the GEM developers, Dan Meyer, and started Ventura Software. They developed Ventura Publisher, which was later marketed by Xerox (and eventually to Corel), which would go on to be a very popular desktop publishing program for some time.

Atari versions

Development of the production 68000 version of GEM began in September of 1984, when Atari sent a team called "The Monterey Group" toDigital Research to begin work on porting GEM. Originally the plan was to run GEM on top of CP/M-86k, both ostensibly ported to the Motorola 68000 by DRI prior to the ST design being created. In fact, these ports were unusable and would require considerable development. Atari eventually decided to give up on the existing code and port a DOS-like operating system that DRI had experimented with instead, GEMDOS. Development began in September of 1984 when Atari sent a team called "The Monterey Group" to DRI to begin work on porting GEM and GEMDOS, producing a system they referred to as TOS.

As Atari had provided most of the development of the 68k version, they were given full rights to continued developments without needing to reverse-license it back to DRI, who had apparently lost interest in the 68000 platform. As a result, the Apple-DRI lawsuit did not apply to the Atari versions of GEM, and they were allowed to keep a more Mac-like UI.

Over the next seven years, from 1985 to 1992, new versions of TOS would be released with each new generation of the ST line. Updates included support for more colors and higher resolutions in the raster-side of the system, but remained generally similar to the original in terms of GKS support. In 1992 Atari released TOS 4, or MultiTOS, along with their final computer system, the Falcon030. In combination with MiNT, TOS 4 allowed full multitasking support in GEM.

Continued development

Caldera Thin Clients (later known as Lineo, a division of the company now known as the SCO Group), released the source to GEM under the General Public Licence (GPL) in April 1999. The development of GEM for PC is continued as OpenGEM and FreeGEM. It also has been ported to the Atari ST again to be used in the free TOS clone EmuTOS.

Description

The "full" GEM system consisted of three main parts:

1. GEM VDI (Virtual Device Interface)
2. GEM AES (Application Environment Services)
3. GEM Desktop (an application providing drag-and-drop based file management)

The GEM VDI was the core graphics system of the overall GEM engine. It was responsible for "low level" drawing in the form of "draw line from here to here". VDI included a resolution and coordinate independent set of vector drawing instructions which were called from applications through a fairly simple interface. TVDI also included environment information (state, or context), current color, line thickness, output device, etc.

These commands were then examined by GDOS, whose task it was to send the commands to the proper driver for actual rendering. For instance, if a particular GEM VDI environment was connected to the screen, the VDI instructions were then routed to the screen driver for drawing. Simply changing the environment to point to the printer was all that was needed (in theory) to print, dramatically reducing the developer workload (they formerly had to do printing "by hand" in all applications). GDOS was also responsible for loading up the drivers and any requested fonts when GEM was first loaded.

One major advantage the VDI provided over the Macintosh was the way multiple devices and contexts were handled. In the Mac such information was stored in memory inside the application. This resulted in serious problems when attempting to make the Mac handle pre-emptive multitasking, as the drawing layer (QuickDraw) needed to have direct memory access into all programs. In GEM VDI however, such information was stored in the device itself, with GDOS creating "virtual devices" for every context – each window for instance. This advantage remained largely theoretical however, as the multitasking versions of GEM were never officially released.

The GEM AES provided the window system, window manager, UI style and other GUI elements (widgets). For performance reasons, many of the GUI widgets were actually drawn using character graphics. Compared to the Macintosh, AES provided a rather spartan look and the system shipped with a single monospaced font.

The AES performs its operations by calling the VDI, but in a more general sense the two parts of GEM were often completely separated in applications. Applications typically called AES commands to set up a new window, with the rest of the application using VDI calls to actually draw into that window.

The GEM Desktop was an application program that used AES to provide a file manager and launcher, the traditional "desktop" environment that users had come to expect from the Macintosh. Unlike the Macintosh, the GEM Desktop was based on top of DOS (MS-DOS or DR DOS+ on the PC, TOS on the Atari), and as a result the actual display was cluttered with computer-like items including path names and wildcards. In general GEM was much more "geeky" than the Mac, but simply running a usable shell on DOS was a huge achievement on its own.

MS Windows NT - the intended successor to DOS and Windows 3.x

• Pre-emptive multi-tasking. Preemptive multi-tasking is much better than co-operative. In pre-emptive multi-tasking the OS can "preempt" and application which is not using its time slice and give it to another application which needs it. Because of this the system is much more efficient and stable. An application crashing will not crash the entire system.
• No Memory Barrier. NT can access all RAM without the need of special drivers or programs.
• 32-bit architecture. NT can take full advantage of the 32-bit CPUs
• GUI. NT has a GUI

OS/2 Warp- IBM beats Microsoft

MS Windows 95/98 - the first commercially successfully market to the private user

Ms Windows XP is actually an upgrade to MS Windows NT.
Back to the top ^

Functions of an Operating System

• Managing the hardware resources of the computer
• Acting as an interpreter between the computer and the application software
• Providing a user interface

Other Operating Systems

Macintosh

UNIX

Linux - a free UNIX