Operating Systems and Software Standards
For the first fifteen years of electronic computing, system software was a property of a particular machine, in the way a chassis or a power supply is. A program written for one computer did not run on another, not because the second was less capable but because nothing about the two was the same: the character code, the number format, the instruction set, the way a job was submitted, the way a file was named, the way a disk sector was addressed. Each was a local decision, made once by a manufacturer and binding on everyone who bought the product. Software was therefore a cost of owning a computer rather than an asset independent of it, and replacing the computer meant rewriting everything that ran on it.
Between roughly 1956 and 1990, that condition was dismantled piece by piece, not by a single invention but by an accumulation of interface specifications: an agreed character code, an agreed floating-point format, standardized programming languages, a portable operating system written in a portable language, a hardware abstraction layer that let one operating system serve machines from vendors who had never spoken to one another, and finally a written specification of the operating system interface itself that no implementation owned. Together they turned system software into a standard, and in doing so changed the economics of building electronics more thoroughly than any single processor or memory technology.
This article is about that separation, and deliberately not about the machines. The hardware story of the microcomputer decade, including the Altair, the Apple II, the IBM Personal Computer, and the Macintosh, belongs to Personal Computer Revolution, which treats CP/M, MS-DOS, and the graphical interface as episodes within the story of those products. The minicomputer hardware on which time-sharing and Unix were built belongs to Minicomputer Era, which mentions Unix in passing as something the PDP-11 made possible. Here the machines are background and the interfaces are the subject: how system software stopped being an artifact of a specific box, and why that mattered more to the electronics industry than the fate of any box ever did.
The Resident Monitor and the Economics That Produced It
The first operating systems were written to solve an accounting problem. A large computer of the mid-1950s rented for figures that made every idle minute expensive, and the machine spent most of its time idle: an operator loaded a card deck, the program ran, the operator unloaded the results, mounted a different tape, loaded the next deck. The processor waited through all of it. The remedy was to leave a small program permanently in memory whose only job was to run the next job, reading the control cards, loading the compiler and the program, catching failures, and moving on without human intervention.
That resident program is the ancestor of every operating system since. The one usually credited as the first, GM-NAA I/O, was built for the IBM 704 in 1956 by Robert Patrick of General Motors Research and Owen Mock of North American Aviation: it batched jobs, provided a common set of input and output routines, and stayed in memory between them. The SHARE user group generalized it into the SHARE Operating System in 1959, and IBM's FORTRAN Monitor System and later IBSYS carried the idea onto the 709 and 7090 series. The Atlas Supervisor at the University of Manchester went further in 1962, scheduling several programs at once and managing a paged store automatically, which is where the word supervisor and the practice of demand paging enter the vocabulary.
Job Control and the First Portable Habit
Batch monitors introduced something more durable than batching: a written language for describing work to a machine. Control cards told the monitor which compiler to run, which tapes to mount, and what to do on an error. The languages were terse and system-specific, but separating the description of a computation from the computation itself proved to be one of the most portable habits in computing. Shell scripts, makefiles, and container manifests all descend from the control card.
The monitor also established the first practical boundary between application and system. A program that read a card by calling the monitor rather than by driving the card reader directly was insulated, for the first time, from a piece of hardware. The insulation was thin, and programmers routinely defeated it for speed, but the principle was in place: some code belongs to the machine, some belongs to the problem, and the two should meet at a documented interface.
System/360 and the Architecture as Specification
The decisive precedent for everything that follows came from IBM on April 7, 1964, and it was a hardware announcement with a software argument at its center. System/360 was not one computer but a family of six models spanning a wide range of price and performance, all sharing one instruction set, one character code, one set of input and output conventions, and one operating system family. A program written for the smallest model would run on the largest. IBM had committed to an architecture, in the sense that Gene Amdahl, Gerrit Blaauw, and Fred Brooks gave the word: a specification of the machine as seen by a program, deliberately separated from the engineering that realized it.
That separation is the central idea of this article, arriving fully formed a decade before the microprocessor. The System/360 instruction set outlived the transistor logic of the first models, the integrated-circuit implementations that followed, and every packaging, cooling, and process technology IBM has used since; its descendants still run today. The implementations were replaced repeatedly. The specification was not. For the electronics industry, the lesson was that a documented interface is a longer-lived asset than any circuit that satisfies it, and the rest of this history is a series of rediscoveries of that lesson at different levels of the stack.
The accompanying software effort taught the opposite lesson at the same time. OS/360 was late, enormous, and famously difficult; Brooks wrote The Mythical Man-Month in 1975 largely to explain why adding programmers to a late software project makes it later. The mismatch was instructive: the hardware architecture succeeded because it was a small, precise, written specification, and the operating system struggled because it was a large, evolving, unwritten one. Every later success in this story came from making the software interface small enough to write down.
Time-Sharing and the Computing Utility
Batch processing optimized the machine at the expense of the person. A programmer submitted a deck and waited hours to learn that a comma was missing. Time-sharing inverted the priority: give many people simultaneous interactive access by switching the processor among them fast enough that each believes the machine is his own. The technique was cheap in principle and demanding in practice, requiring memory protection so that one user could not corrupt another, a scheduler that switched contexts in milliseconds, and a file system holding many users' work with some notion of who could read what.
CTSS at MIT
The Compatible Time-Sharing System, demonstrated at the Massachusetts Institute of Technology in November 1961 and developed on IBM 709 and later 7090 and 7094 hardware, was the first system to show that this worked with real users doing real work. Fernando Corbató and his colleagues described it at the Spring Joint Computer Conference in 1962. The compatible in its name is a reminder of the transitional politics of the moment: CTSS ran the existing batch monitor as one of its jobs, so the institution did not have to abandon its investment in order to experiment.
CTSS produced a great deal of what is now taken for granted: an on-line file system with per-user directories, interactive text editors, electronic mail among users of the same machine, and the practice of typing a password the system did not print back. It also produced the first generation of people who expected a computer to answer immediately, and that expectation drove the next twenty years of system design. The Dartmouth Time-Sharing System, built by John Kemeny and Thomas Kurtz in 1964 around the BASIC language they designed for it, showed that the approach could serve undergraduates rather than researchers.
Multics and What It Attempted
Multics, begun in 1964 as a joint project of MIT's Project MAC, Bell Telephone Laboratories, and General Electric, and described in a series of papers at the 1965 Fall Joint Computer Conference, set out to be a computing utility: a machine that a community could plug into the way it plugged into the electricity supply, running continuously, serving hundreds of users, and never being shut down. Meeting that goal required inventing most of what a modern operating system contains. Multics on the GE 645 provided segmented virtual memory in which a file and a region of memory were the same object, dynamic linking so that a program loaded a routine only when it first called it, a hierarchical directory tree with access control lists, rings of protection rather than a single supervisor-user boundary, and a command interpreter that was an ordinary program rather than part of the kernel.
Multics was also written almost entirely in a high-level language, a dialect of PL/I, when this was considered reckless for a system whose performance mattered. It was not the first to try; the Burroughs Master Control Program of 1961 was written in a high-level language of its own, ESPOL. But Multics made the argument in the most visible possible setting and lost on the immediate merits: the system was late, the hardware expensive, and the performance disappointing enough that Bell Labs withdrew in 1969. Honeywell, which bought General Electric's computer business in 1970, sold Multics to a modest number of customers for two more decades. The last installation shut down in 2000.
Judged as a product, Multics was a limited success. Judged as a specification of what an operating system should provide, it was among the most influential systems ever built. Its hierarchical file system, its protection model, and its insistence that the system be written in a language a person could read all passed into the systems that displaced it, in some cases carried by the same people.
Unix at Bell Labs
Ken Thompson had worked on Multics and did not want to lose the interactive environment when Bell Labs withdrew. In 1969 he found an underused PDP-7 in an acoustics research department and, with Dennis Ritchie and Rudd Canaday, built a small time-sharing system for it: a hierarchical file system, a handful of utilities, a command interpreter that was an ordinary program, and a set of system calls small enough to memorize. The name Unix, suggested by Brian Kernighan, was a joke at Multics' expense, the system being a stripped-down and single-user thing by comparison.
The work moved to a PDP-11/20 in 1970, and the first edition of the UNIX Programmer's Manual was dated November 3, 1971. The system was still written in assembly language. What it already had was a design attitude more important than any of its mechanisms: make each program do one thing, make text the universal interchange format, and represent devices as files so that a program need not know whether it writes to a disk, a terminal, or another program. The pipe, added in 1973, made composition of small tools routine, and the shell that provided it was replaceable because it was not part of the kernel.
The economic significance of that design is easier to state now than it was then. A system built from small, composable, text-mediated programs can be extended by its users without modifying the system itself. Bell Labs had built, without especially intending to, a platform on which its recipients would do a great deal of unpaid development, and that property is what made the distribution to universities so consequential.
The 1973 Rewrite in C and Why Portability Was Decisive
Ritchie had been developing a systems programming language, C, derived from Thompson's B and ultimately from BCPL, and by 1973 it was capable enough to write a kernel in. The fourth edition of Unix, that year, was rewritten largely in C. Contemporary opinion held that an operating system needed assembly language for speed and for access to machine facilities a high-level language would hide. Ritchie and Thompson accepted a measurable penalty in size and speed for a property not then valued: the system could be read, modified, and above all moved.
The proof came in 1977. Bell Labs deliberately acquired an Interdata 8/32, chosen because its architecture differed from the PDP-11 in almost every respect that mattered, and Steve Johnson and Dennis Ritchie moved Unix onto it; the University of Wollongong in Australia had independently carried out a similar port to an Interdata 7/32 at about the same time. The exercise forced the machine-dependent parts of the kernel apart from the rest and produced a portable C compiler along the way. The published accounts argued the case explicitly: moving a large program to a new machine could cost a small fraction of writing it again.
This is the pivot of the entire history, and its importance is easiest to see from the hardware side. Before portable system software, a company that designed a new processor also had to fund an operating system, a compiler, a linker, a debugger, a file system, and a set of utilities before its instruction set was worth anything to a customer. That software burden was a barrier to entry far more forbidding than the cost of the silicon, and it protected incumbents who had already paid it. After portable system software, a new processor needed a C compiler back end and a machine-dependent kernel layer, and the accumulated software of the world became available to it. The workstation and server industry of the 1980s, the RISC processors of the same period, and the embedded processor market that followed all depended on this. A new instruction set could be evaluated on its engineering merits rather than on how much software its sponsor could afford to write.
The seventh edition of 1979 is generally taken as the last research system in the direct line. It carried the portable C compiler, the Bourne shell, and roughly fifty system calls, and most commercial Unix derivatives descend from it. Its interface was small enough that a competent programmer could hold the whole of it in mind, which is precisely why it could later be written down as a standard.
The Consent Decree, the Universities, and Berkeley
A Product That Could Not Be Sold
Unix spread through universities because of an antitrust settlement. Under the consent decree that AT&T entered with the United States Department of Justice in 1956, the Bell System was confined to common carrier communications and was required to license its patents on request. AT&T was therefore barred from selling computer products. Unix could not be turned into a business, so Bell Labs distributed it on terms that amounted to the cost of the tape and the shipping, with the source code included because there was no support organization to hide it behind.
The consequences were out of all proportion to the intent. The fifth edition of 1973 went to educational institutions on those terms, and the sixth edition of 1975 was the first licensed to companies, at a commercial fee of twenty thousand dollars, while academic recipients continued to pay a nominal charge. Because the source came with it, Unix became the system computer science was taught on. John Lions at the University of New South Wales produced a line-by-line commentary on the sixth edition kernel in 1976 and 1977 that circulated for years, and the seventh edition license restricted classroom use of the source in a way that only increased the commentary's circulation. A generation of systems programmers learned the trade by reading one specific operating system, and carried its interface into every company they later joined.
It is worth stating plainly what a regulatory settlement accomplished. A rule meant to keep a telephone monopoly out of the computer business produced, as a side effect, the widest distribution of production-quality system software that had ever occurred, and with it the interface the industry eventually standardized on. No one planned this.
The Berkeley Line
The University of California, Berkeley, received Unix in 1974 and began improving it. Bill Joy assembled the first Berkeley Software Distribution in March 1978, essentially a set of additions to the sixth edition; 2BSD followed in May 1979 with the vi editor and the C shell. The turn came at the end of 1979 with 3BSD, the first version to support the VAX with virtual memory, which made Unix viable on the machines universities were then buying.
The Defense Advanced Research Projects Agency funded the work from about 1980, and the result was 4.2BSD in 1983, which folded a complete TCP/IP implementation and the socket interface into the Unix kernel. That decision did more to establish the Internet protocols than any standards document, because every institution running Berkeley Unix on a VAX then had a working, source-available protocol stack. 4.3BSD followed in June 1986 and 4.3BSD-Tahoe in June 1988, the latter separating machine-dependent code more cleanly to ease porting.
Berkeley then confronted the licensing problem directly. Because the networking code had been written at Berkeley rather than at Bell Labs, it could be released without an AT&T license, and Networking Release 1 appeared in June 1989 as the first freely redistributable piece of the system. Networking Release 2, in June 1991, was very nearly a complete operating system on the same terms. Unix System Laboratories sued Berkeley Software Design in 1992 over the result, the University of California countersued, and the matter settled in January 1994 substantially in Berkeley's favor, with only three files of some eighteen thousand requiring removal. The Computer Systems Research Group issued 4.4BSD-Lite and closed in 1995. FreeBSD, NetBSD, and OpenBSD descend from this line, and its networking interfaces remain embedded in a great deal of commercial equipment.
Fragmentation and the Standardization Answer
The Unix Wars
The 1982 antitrust settlement that led to the breakup of the Bell System on January 1, 1984, removed the restriction that had kept Unix free. AT&T could now sell it, and did: System III in 1981, System V in 1983, and a succession of releases thereafter. At the same time every workstation and minicomputer vendor was shipping its own derivative. SunOS came from the Berkeley line, HP-UX and AIX and Ultrix and Irix and Xenix from various mixtures of Berkeley and System V, each with its own additions, its own device model, and its own incompatibilities.
The portability that C and Unix had bought was being spent. Software written for one vendor's Unix required work to move to another's, and the differences were exactly the sort that are cheap for a vendor to create and expensive for a customer to bridge. AT&T and Sun Microsystems began work in 1987 on a unification, releasing System V Release 4 in 1988 as a merger of System V, the Berkeley line by way of SunOS, and Xenix. Competitors read the alliance as an attempt to make Sun the industry's reference implementation, and in 1988 they founded the Open Software Foundation to build an alternative, OSF/1; AT&T and its allies answered with Unix International. Two consortia and several years of expensive maneuvering followed, at exactly the moment when the personal computer platform was gaining the volume to compete against.
POSIX and the Single UNIX Specification
The resolution did not come from either camp winning. It came from writing the interface down in a document that no vendor owned. The IEEE began work on a portable operating system interface in the early 1980s and published IEEE Std 1003.1 in 1988, a specification of system calls and the C library that could be implemented on both System V and Berkeley lineages. Richard Stallman is generally credited with suggesting the name POSIX. The standard was adopted internationally as ISO/IEC 9945-1:1990, and it acquired commercial force when the United States government made conformance a procurement requirement through Federal Information Processing Standard 151. Vendors who wanted to sell to federal agencies implemented POSIX whether or not they liked it, and Microsoft added a POSIX.1 subsystem to Windows NT for precisely this reason, supporting the kernel and library interfaces without providing a shell or the usual utilities.
The trademark took a parallel route. The participants in both consortia formed the Common Open Software Environment alliance in March 1993, ending the most damaging phase of the conflict. AT&T sold its Unix assets to Novell in June 1993, and Novell transferred the UNIX trademark to X/Open that October. X/Open turned the industry's consolidated wish list, known as Spec 1170 for the number of interfaces it enumerated, into the first Single UNIX Specification in 1994, marketed as UNIX 95. X/Open and the Open Software Foundation merged in 1996 to form The Open Group, which published the second version in 1997 with 1,434 interfaces. From 1998 the Austin Group, a joint working group of the IEEE, ISO/IEC JTC 1, and The Open Group, produced a single document serving as both the POSIX standard and the Single UNIX Specification. Version 3 appeared in 2002 with 1,742 interfaces, technically identical to IEEE Std 1003.1-2001, and Version 4 followed in December 2008 alongside POSIX.1-2008 with 1,833 interfaces. The current revision, IEEE Std 1003.1-2024, was published on June 14, 2024, as The Open Group Base Specifications Issue 8, with the international standard ISO/IEC/IEEE 9945 following in 2026.
The outcome is worth stating carefully, because it is the model for a great deal of later standards practice in electronics. The commercial Unix vendors that fought the Unix wars have almost all disappeared or retreated to niches. The interface they were fighting over survived them all, and is now implemented most widely by systems that none of those companies produced, including Linux, the BSD descendants, macOS, and the POSIX interfaces offered by embedded real-time kernels. The specification outlived every implementation that motivated it. That sentence describes the whole subject of this article.
CP/M and the Hardware Abstraction Layer
The microcomputer faced the same problem in miniature and solved it in a way that became the direct ancestor of modern embedded software structure. In 1974 Gary Kildall wrote a control program for Intel 8080 development systems and founded Digital Research to sell it. CP/M, which began as Control Program/Monitor and was later marketed as Control Program for Microcomputers, became the operating system of the eight-bit business machine, and its requirements were modest by design: about sixteen kilobytes of memory, one floppy disk drive, and an ASCII terminal.
The Three-Layer Design
CP/M was divided into three parts, and the division is the whole point. The Console Command Processor read commands and loaded programs. The Basic Disk Operating System provided the file system and the system call interface that application programs used. The Basic Input/Output System, the BIOS, contained every routine that touched actual hardware: reading and writing a disk sector, sending and receiving a character, testing whether a key had been pressed. Only the BIOS knew what disk controller was fitted, how many tracks the drive had, or which port the serial interface occupied.
A manufacturer building a new 8080 or Z80 machine therefore wrote a BIOS, typically a few kilobytes of assembly language, and inherited an operating system and a software library. Everything above the BIOS stayed byte-identical, so an application that called the BDOS ran on machines from companies that had never coordinated with each other or tested against each other's boards. By September 1981 Digital Research had sold more than 250,000 licenses, and by 1982 CP/M had been adapted to more than 450 distinct computer systems.
The gap the abstraction failed to close is instructive. CP/M standardized the software interface but not the recording format of the floppy disk, and manufacturers chose different track counts, sector sizes, and densities. Software houses consequently shipped the same program on dozens of physically incompatible diskettes, and a small business existed in converting between them. Standardizing the programming interface without standardizing the medium left the user with half a solution, a lesson repeated by later standards that specified protocol but left connectors or timing to the implementer.
What the Abstraction Bought the Industry
Before CP/M, a software company chose a machine and addressed the people who owned it. After CP/M, it addressed a market defined by an interface. WordStar, dBASE II, SuperCalc, and Microsoft's language products all reached customers this way, and they in turn made the machines worth buying. That reciprocal relationship between applications and installed base decided nearly every subsequent platform contest in electronics.
The structural idea outlived CP/M by a wide margin. A board support package for an embedded operating system, a hardware abstraction layer in a microcontroller vendor's software development kit, and a device driver model in any modern kernel are the same construction: a thin, replaceable, vendor-written layer presenting fixed semantics upward and touching registers downward. So are the economics. The layer is a fixed cost the silicon vendor pays once to make a large body of existing software run on new hardware, and it often decides whether a technically sound processor finds customers. Digital Research demonstrated that such a layer could be small enough to be worth writing and stable enough to be worth relying on.
The IBM Personal Computer and the Platform That Was Not the Hardware
The Choice and the License
When IBM assembled its personal computer in 1980 and 1981, it needed an operating system quickly and did not intend to write one. Negotiations with Digital Research over CP/M-86 did not produce an agreement; accounts of why differ and remain disputed. IBM turned to Microsoft, which did not have an operating system either but knew where to find one. Tim Paterson at Seattle Computer Products had written 86-DOS in 1980 for that company's 8086 board, modeling its programming interface on CP/M so that eight-bit software could be translated mechanically. Microsoft licensed it, hired Paterson in May 1981, bought it outright that July for twenty-five thousand dollars, and IBM shipped it in August as PC DOS 1.0.
IBM offered three operating systems for the 5150: PC DOS, CP/M-86, and the UCSD p-System. The prices differed sharply, PC DOS being much the cheapest, and the market decided almost immediately. The far more consequential detail was contractual rather than technical. Microsoft's license to IBM was nonexclusive, and Microsoft retained the right to sell the same product to anyone else as MS-DOS. Within about a year it had licensed the system to more than seventy other companies.
This is the arrangement that made the operating system rather than the hardware into the platform. IBM's machine was assembled from parts anyone could buy, and its one proprietary element, the ROM BIOS, was reimplemented by Compaq and then by Phoenix Technologies using clean-room methods. Once a compatible BIOS could be purchased by anyone, the hardware was a commodity; what remained scarce was the operating system, and Microsoft owned it. Value moved from the company that made the box to the company that defined the interface, and stayed there for two decades. The structural outcome followed from the license.
DOS as an Interface Specification
MS-DOS was technically unambitious and became a standard anyway, which is part of the lesson. Version 1.0 offered a flat directory and the FAT12 file system. Version 2.0, released in 1983 for the IBM PC XT and its hard disk, added a hierarchical directory tree, user-installable device drivers, environment variables, and inheritable redirectable file handles, all borrowed visibly from Unix. Version 3.0 in April 1985 introduced FAT16 for larger partitions, and dozens of manufacturers shipped adapted OEM versions.
Three interface layers were now stacked on the same hardware, and applications used all three inconsistently. The ROM BIOS presented a device-level interface in firmware. DOS presented a file-and-process interface above it. Some programs bypassed both and wrote directly to video memory and hardware registers for speed. That last practice is what actually defined PC compatibility: a clone was compatible if it ran the software that cheated, which meant it had to reproduce the hardware, not merely the documented interface. The industry spent the following fifteen years slowly re-establishing the discipline that the abstraction layers had been created to enforce, through protected mode, device driver models, and eventually the hardware abstraction layer of Windows NT. The episode is a useful caution: an interface specification only delivers its benefits if implementers are actually prevented from going around it.
The Graphical Succession
From Research to Product
The graphical interface followed the same path from laboratory to specification, more slowly because it demanded memory and bandwidth that stayed expensive until the mid-1980s. Xerox's Palo Alto Research Center built the Alto in 1973, a single-user machine with a bitmapped display, a mouse, and an Ethernet connection, and developed Smalltalk on it, in which the interface and the programming environment were the same thing. Xerox commercialized the research in 1981 as the 8010 Star, which introduced the desktop metaphor in nearly its final form and demonstrated at the same time that it could not be sold at workstation prices.
Apple's Lisa of 1983 and Macintosh of 1984 brought the interface within reach of a business buyer, and the software architecture mattered as much as the price. Apple placed the user interface routines, the Toolbox, in read-only memory and required applications to call them, which is why Macintosh programs looked and behaved alike from the beginning. The company published Inside Macintosh as a specification of how an application was expected to behave, not merely of what functions existed. Consistency of interface became a documented contract between platform and developer, and that is what lets a person who has learned one program use another.
The Windows Line and the Subsystem Idea
Microsoft's answer took a decade to become convincing. Windows 1.0 shipped in November 1985 as a graphical layer over DOS, Windows 2.0 followed in 1987, and Windows 3.0 in May 1990 was the first version to succeed commercially, largely because the 80386 finally provided the memory management it needed. Microsoft and IBM had meanwhile developed OS/2 jointly from 1985, shipping it in 1987 as the intended successor to DOS; the partnership dissolved around 1990 and 1991, with IBM continuing OS/2 alone.
Windows NT, first released as version 3.1 in July 1993 under David Cutler, who had led VMS development at Digital Equipment Corporation, is the interesting case for this article because it treated the operating system interface explicitly as a specification to be implemented rather than as a thing the kernel simply was. NT had a small privileged executive and a hardware abstraction layer beneath it, and above it ran environment subsystems: a Win32 subsystem, an OS/2 subsystem, and a POSIX.1 subsystem included to satisfy the federal procurement requirement described earlier. The application programming interface had been separated from the kernel that served it. The POSIX subsystem was never a serious environment and was retired in the early 2000s in favor of Windows Services for UNIX and, much later, the Windows Subsystem for Linux, but the architectural point stands: by 1993 the interface was understood to be a specification, and the kernel merely one thing that could satisfy it.
X11 and the Networked Display
A parallel and more explicitly standardized effort ran through the Unix world. The X Window System began at MIT's Project Athena in 1984, and version 11 in 1987 fixed a protocol rather than an implementation: a display server and a client program communicate over a byte stream, so the program need not run on the machine driving the screen. Because X11 specified the wire protocol, hardware vendors wrote their own servers, optimized for their own graphics hardware, while running everyone's applications. The workstation companies that shipped those servers are mostly gone; the protocol outlasted them by decades and is only now being displaced.
The Standards Beneath the Standards
Portable operating systems were possible only because lower-level agreements had already been reached. Software cannot move between machines that disagree about what a character is, what a number is, or what a program text means. Three families of standards settled those questions, and each shapes how electronic hardware is designed.
Character Codes
Work on a standard character code began in May 1961, when the IBM engineer Bob Bemer submitted a proposal to subcommittee X3.2 of the American Standards Association. The first edition, ASA X3.4-1963, was revised substantially in 1967 and again as USAS X3.4-1968, later maintained as ANSI X3.4 through the 1986 edition. ASCII is a seven-bit code with 128 positions: ninety-five printable characters and thirty-three control codes, several of which, including carriage return, line feed, and the escape sequences Bemer introduced, still govern the behavior of terminals and printers.
Adoption was neither immediate nor universal. IBM introduced its own Extended Binary Coded Decimal Interchange Code in 1963 for the System/360 line and used it for decades, so the two largest bodies of computing data in the world were mutually unreadable without translation. The international standard ISO/IEC 646 of 1967 matched ASCII closely but reserved certain positions for national use, so the same byte printed as a different character in different countries, a long-running nuisance for anyone exchanging text or writing C, whose braces and brackets occupied several of the contested positions. Eight-bit extensions such as ISO/IEC 8859-1 relieved the pressure for Western European languages without solving the general problem. Unicode 1.0, published in 1991 and aligned with ISO/IEC 10646, finally did, keeping the first 128 code points identical to ASCII so that existing seven-bit data remained valid.
For electronics, the consequence is that serial interfaces, terminals, printers, instrument command languages, and communication protocols could be specified against an agreed alphabet. The SCPI command language used by test instruments, the Hayes AT modem command set, and most text-based Internet protocols all assume ASCII.
Floating-Point Arithmetic
Before 1985, every manufacturer defined its own floating-point format. IBM's System/360 used a hexadecimal exponent, Digital Equipment Corporation used several different binary formats across its product lines, and smaller machines used whatever their designers found convenient. The formats differed in word layout, in exponent and significand widths, in rounding, in whether underflow was gradual or abrupt, and in what happened on division by zero. A numerical program that produced a correct answer on one machine could produce a subtly wrong one on another.
The standardization came from an unusual direction: a microprocessor company needed a specification. Intel's project manager John Palmer approached William Kahan of the University of California, Berkeley, for the arithmetic of a floating-point coprocessor. Kahan, with Jerome Coonen and Harold Stone, produced the draft known as the K-C-S proposal, and the Intel 8087, announced in 1980, was the first device to implement it. The IEEE working group adopted a refined version as IEEE Std 754-1985, specifying formats, four rounding modes, gradual underflow through denormal numbers, signed infinities, quiet and signaling values for results that are not numbers, and the exceptions arithmetic must raise. IEEE 854-1987 generalized the model to other radices, and the standard was revised in 2008 and 2019.
The effect on hardware design was permanent. A floating-point unit became a component with a written acceptance specification rather than a matter of designer preference, which made it possible to verify one, compare two, and buy one from a third party. It made numerical libraries portable and results reproducible across machines, which matters enormously in any field that certifies software. Every general-purpose processor, digital signal processor, and graphics processor with binary floating-point hardware today is measured against this specification, four decades after the coprocessor that motivated it was discontinued.
Standardized Programming Languages
The third leg is the languages themselves, and the sequence shows how long standardization takes. FORTRAN was standardized as ASA X3.9-1966 and revised as ANSI X3.9-1978, generally called FORTRAN 77. COBOL, defined by the CODASYL committee in 1959 and 1960, became an American national standard in 1968 and was revised in 1974 and 1985. Pascal was standardized internationally as ISO 7185:1983. Ada was defined for the United States Department of Defense as MIL-STD-1815 in 1980, revised as ANSI/MIL-STD-1815A in 1983, and adopted as ISO 8652:1987. C, despite being the language the portable operating system was written in, waited until ANSI X3.159-1989, adopted internationally as ISO/IEC 9899:1990.
What made these standards effective was not the documents alone but the conformance testing that accompanied several of them. The National Bureau of Standards, later the National Institute of Standards and Technology, maintained validation suites for FORTRAN and COBOL compilers, and the Ada Compiler Validation Capability was a condition of selling an Ada compiler to the Department of Defense. A compiler either passed or it did not, and the result was published. The same instrument later governed the Single UNIX Specification, where the right to use the UNIX trademark depends on passing a defined test suite. A specification without a test is an aspiration; a specification with a test is a contract. That is why interoperability plugfests and certification programs now accompany essentially every successful hardware interface standard.
What the Electronics Industry Took From It
The history above was written by computer scientists and consumed by hardware engineers, and the practices it left behind are now so ordinary their origin is invisible.
The first is that an instruction set is a product in its own right. System/360 established the point and the microprocessor industry adopted it wholesale. The x86 instruction set has been implemented in NMOS and in CMOS at dozens of process nodes, by Intel, AMD, Cyrix, VIA, and others, in designs sharing no circuitry whatever, and software written in 1985 still runs. The ARM architecture makes the separation a business model: the company writes the architecture and licenses it, and hundreds of different silicon products satisfy it. RISC-V removes the license as well. In each case the durable asset is the document.
The second is the deliberate hardware abstraction layer, which is CP/M's BIOS grown up. Every embedded processor vendor now ships one with board support packages, because a processor without them cannot inherit the existing software base, and the quality of that layer routinely decides design wins between parts of comparable capability. Operating system interfaces migrated downward with it: real-time kernels for industrial and automotive equipment commonly offer POSIX interfaces, and network equipment, test instruments, and industrial controllers run Linux or a BSD derivative because that supplies a protocol stack, a file system, a toolchain, and a hiring pool at once. Even personal computer firmware was rewritten, UEFI replacing the sixteen-bit ROM BIOS in the 2000s while keeping the idea that firmware presents a documented interface rather than a specific machine.
The third is that platform control follows the interface rather than the manufacturing. The nonexclusive MS-DOS license is the canonical illustration, but the pattern recurs constantly: in the videocassette format contest, where licensing breadth beat technical parity; in the compact disc, where the Red Book specification became the asset; in mobile telephony, where the air interface, not the base station, is what companies fight over. Firms that own only the manufacturing discover that their product has become a commodity.
The fourth and most general is the habit of writing an interface down separately from anything that implements it, and then testing implementations against the document. That is what the Austin Group does for POSIX, what JEDEC does for memory interfaces, what the USB Implementers Forum and the PCI Special Interest Group do for buses, and what IEEE 802 committees do for networks. It is a procedural invention as much as a technical one, and this history is where the industry learned to trust it.
Conclusion
Over roughly thirty-five years, system software changed category. In 1955 it was part of a machine, written for that machine, obsolete when the machine was retired. By 1990 it was a specification: a document describing an interface, implemented by many parties, tested against a published suite, and independent of any particular silicon. The route ran through the resident monitor and through System/360, which proved that an architecture could outlive its implementations; through time-sharing and Multics, which established what an operating system should provide; through Unix and its rewrite in C, which proved the system itself could be moved; through the consent decree that put the source into universities; through CP/M's BIOS and the MS-DOS license, which showed how a small abstraction and a contract could turn many incompatible machines into one market; and through POSIX, the Single UNIX Specification, ASCII, IEEE 754, and the standardized languages, which wrote the agreements down where no vendor could revoke them.
The lesson the electronics industry drew is compact and is worth stating as the industry practices it. Hardware is temporary. Every processor in this history has been discontinued, every one of the operating systems has been rewritten or abandoned, and most of the companies that fought over them no longer exist. What survived was the written interface: the instruction set, the character code, the number format, the system call list, the wire protocol. An interface specification can outlive every implementation behind it, and the engineering decision that most reliably compounds in value is the decision to define one carefully and then refuse to break it.