That fragmentation also complicated what it meant for an operating system to be UNIX. Some systems could trace their development directly back to Bell Labs UNIX. Others could implement interfaces defined by standards such as POSIX without sharing that ancestry. UNIX would also become a certification and trademark applied to systems meeting a defined specification. Source lineage, compatibility, and the UNIX name were becoming separate questions.
There was another possibility. If the important interfaces and behavior of UNIX could be described, developers could reproduce them without using UNIX source code at all. Such systems could be Unix-like: built around many of the same concepts and interfaces without becoming another branch of the original UNIX source tree. That distinction became increasingly important as UNIX ideas spread beyond systems descended directly from Bell Labs.
Commercial UNIX systems continued the original source lineage. Standards increasingly defined what software could expect from a Unix environment, and independent projects could pursue Unix compatibility without UNIX ancestry at all. Following these paths separately helps explain how UNIX became both a family of operating systems and a model that extended far beyond its original source code.
The oldest meaning of UNIX is also the most straightforward: an operating system belongs to the UNIX family because its development can be traced back to the operating system created at Bell Labs. This is UNIX as a source-code lineage. Later systems may differ substantially from early UNIX, but there is still a historical path connecting their development.
That lineage began branching early. UNIX source moved to universities, computer manufacturers, and other organizations, where it was adapted to different hardware and different needs. Changes accumulated, features moved between branches, and vendors eventually developed distinct commercial products. UNIX became less like a single operating system with successive versions and more like a family whose members shared an ancestor.
Source ancestry does not mean that a later system must still contain some particular percentage of the original Bell Labs code. Operating systems are continually maintained and rewritten. Drivers disappear with obsolete hardware, subsystems are replaced, interfaces are redesigned, and old implementations give way to new ones. After decades of development, asking how much original code remains can tell us less about the relationship than asking how the system developed.
A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.
The branches did not remain isolated either. Commercial UNIX systems could incorporate ideas and technology associated with both AT&T UNIX and BSD. Later standards encouraged common interfaces across systems with increasingly different internals. A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.
One of the most important lines ran through AT&T’s System V. As AT&T moved UNIX further into the commercial market, System V became a major branch of UNIX development and an important foundation for commercial UNIX systems during the 1980s and 1990s.
Computer manufacturers of this period commonly developed operating systems around their own hardware. UNIX gave vendors an established operating model and software environment while leaving room to optimize the system for particular machines and customers. The result was not one commercial UNIX, but an ecosystem of related products.
Some of the most important commercial UNIX systems included:
These systems shared UNIX ancestry, but they were not interchangeable releases of the same operating system. Vendors differentiated them through administration tools, filesystems, networking, graphical environments, hardware support, and features aimed at their particular markets. UNIX on a graphics workstation could look quite different from UNIX running business applications on a large enterprise server.
The commercial UNIX market eventually contracted, but its branches did not all meet the same fate. Some continued as specialized enterprise systems. Others passed through acquisitions into new companies or disappeared along with the hardware platforms and companies that had supported them.
IBM’s AIX became closely associated with IBM’s workstation and enterprise hardware. Rather than disappearing as UNIX declined on general-purpose computers, AIX remained in the enterprise market and eventually became centered on IBM’s POWER systems.
UNIX did not need to dominate the broader operating-system market for AIX to remain useful. Customers with established systems could value stability, compatibility, vendor support, and the ability to continue running existing workloads already built around the platform.
Sun Microsystems followed a different path. Its early SunOS releases were strongly connected to BSD. Solaris represented Sun’s move toward System V and eventually combined technology and ideas from both sides of the UNIX family.
Solaris became one of the most visible commercial UNIX systems of the workstation and server era. Sun paired the operating system closely with its SPARC hardware while also supporting other architectures, including x86.
Sun was eventually acquired by Oracle, bringing Solaris with it. The Solaris story also continued outside its commercial owner. Open-source work surrounding OpenSolaris contributed to illumos, from which several operating systems continue the Solaris-derived tradition.
Not every important commercial UNIX needs its own complete history here. HP-UX, IRIX, and Tru64 UNIX show how closely commercial UNIX could become tied to a manufacturer’s hardware and business.
These included:
Their histories differ, but they shared a problem as the market changed. Proprietary workstation architectures declined and the computer industry consolidated, making separate UNIX implementations harder to justify. Some systems retained specialized customers for years. Others eventually reached the end of active development.
The Santa Cruz Operation occupied another interesting part of the commercial UNIX market. SCO concentrated heavily on bringing UNIX to comparatively inexpensive Intel-based systems. Businesses could run multiuser UNIX applications without purchasing one of the proprietary workstation or server platforms associated with many other UNIX vendors.
SCO’s UNIX business eventually passed to Caldera, a company already known for selling Linux. Caldera had also experimented with making Linux installation friendlier: one of its graphical installers let you play Tetris while waiting for the installation to finish.
Sometimes computing history includes waiting for Linux to install while playing Tetris.
Caldera later renamed itself The SCO Group. For the UNIX lineage we are following here, that is where we can leave the branch.
Source lineage tells us where an operating system came from. It does not necessarily tell us how software written for that system will behave. As UNIX divided into competing implementations, differences between those systems created a practical problem. Software developers needed a common set of interfaces they could rely upon even when the underlying operating systems came from different branches.
Standards addressed that problem without requiring common source code. They could define the interfaces and behavior an operating system was expected to provide. Different operating systems could then implement those interfaces in their own ways.
UNIX ancestry and UNIX compatibility are not the same thing.
UNIX ancestry and UNIX compatibility are not the same thing. A system descended from Bell Labs UNIX could have genuine UNIX ancestry while differing from later standards. Another system could implement standardized Unix interfaces without containing UNIX source code at all.
POSIX, the Portable Operating System Interface, developed as an effort to define a common interface that software could expect across operating systems. Rather than defining how an operating system had to work internally, POSIX concentrated on interfaces visible to programs and users. Software could rely upon defined behavior instead of the peculiarities of a particular vendor’s UNIX.
Among the areas standardized by POSIX are:
Two operating systems can implement the same POSIX interfaces while using very different code internally. POSIX could therefore improve portability across an increasingly diverse UNIX family without requiring every implementation to descend from UNIX source.
Windows NT provides an interesting example. I remember wondering why Microsoft cared about including POSIX support in Windows NT. I also remember people describing Windows NT as a UNIX because it supported POSIX. That never seemed quite right. The difference between lineage and standards explains why.
Microsoft could implement a POSIX environment without turning Windows NT into a descendant of UNIX. POSIX described interfaces an operating system could provide; it did not prescribe where the operating system’s source code had to come from. Windows NT shows just how far the Unix interface had traveled beyond the UNIX family itself.
Microsoft continued experimenting with ways to support Unix and, later, Linux software on Windows. We will return to that history when we follow the Windows branch. For now, POSIX shows how Unix compatibility could extend beyond the UNIX family.
POSIX was part of a broader effort to bring consistency to an increasingly fragmented Unix world. Other standards efforts were also trying to define a common operating environment, and over time those efforts converged.
POSIX and the Single UNIX Specification should not be treated as competing definitions of Unix. Today, the core volumes of the Single UNIX Specification are simultaneously the IEEE POSIX standard and the ISO/IEC 9945 standard. Much of the standardized Unix programming environment is shared between them.
The Single UNIX Specification extends that foundation into the standard used to measure conformance for UNIX systems. It encompasses the base operating-system environment along with the additional requirements needed to provide a consistent UNIX environment.
Source ancestry tells us how an operating system developed. Standards tell us whether the environment it provides meets an established specification.
Source ancestry and standards can now answer different questions. One tells us how an operating system developed. The other tells us whether the environment it provides meets an established specification.
UNIX is also a trademark. The Open Group administers the UNIX trademark and operates the certification program associated with the Single UNIX Specification.
Certification is based upon conformance rather than genealogy. A product must demonstrate that it passes the applicable certification tests, and its supplier must agree to the requirements of the certification program. The Open Group can then grant the supplier a license to use the UNIX trademark with that product.
A system can have historical UNIX ancestry without currently being a certified UNIX product. Tracing source code back to Bell Labs is not what certification establishes. Certification tells us that a particular product conforms to a defined UNIX specification.
The word UNIX can describe several related but distinct relationships:
| Term | Meaning |
|---|---|
| UNIX-derived | Historical or source ancestry |
| POSIX conforming | Implements the applicable POSIX interfaces |
| UNIX certified | Certified to the applicable UNIX specification and licensed to use the UNIX trademark |
| Unix-like | Resembles or implements the broader Unix operating model |
Keeping these meanings separate clears up otherwise confusing descriptions of operating systems. Standards allowed Unix compatibility to extend beyond the original source tree. Certification gave the UNIX name a definition that did not depend solely upon tracing code back to Bell Labs.
Unix interfaces could be described independently of the source code that originally implemented them. An operating system therefore did not have to descend from Bell Labs UNIX to provide a familiar Unix environment. Developers could create their own implementations of the same ideas and interfaces.
The term Unix-like is useful for this broader family. It can describe systems that follow Unix conventions, provide similar tools and interfaces, or deliberately seek compatibility without claiming UNIX source ancestry or certification. The boundary is less precise than either a source lineage or a formal standard, but the term helps separate the influence of Unix from the narrower history of UNIX itself.
Independent implementation also mattered because UNIX source was proprietary. Reproducing Unix behavior without copying that source made it possible to pursue goals that commercial UNIX vendors were not necessarily trying to achieve. One of the most consequential attempts began with the GNU Project.
Richard Stallman announced the GNU Project in 1983 with the goal of developing a complete free Unix-compatible operating system. Its name, GNU’s Not Unix, deliberately captured the distinction. GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.
Unix compatibility gave the project an existing model to work from. Developers did not need to invent an entirely new operating environment simply because they were writing new code. Programs, commands, programming interfaces, and established Unix practices provided a familiar target while GNU’s implementation could remain independent.
The goal also connected compatibility with software freedom. The freedoms to use, study, modify, and redistribute software were central to the GNU Project. A free Unix-compatible operating system could preserve a useful operating model without depending upon the proprietary software that implemented UNIX.
GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.
GNU was not another branch of the Bell Labs source tree, and its purpose did not depend upon permission to use the UNIX trademark. The goal was to build a new operating system that provided a compatible Unix environment using freely available source code.
That is where we can leave GNU for now. The project had established its goal and shown that a Unix-like system could be built independently. How GNU attempted to complete that operating system is the next part of its story.
UNIX continued after its early fragmentation as a genuine source-code family. System V and the commercial UNIX systems carried that lineage into workstations, servers, and enterprise computing. Some branches survived in specialized markets, while others disappeared or passed through acquisitions as the commercial UNIX market contracted.
Source ancestry was no longer the only way an operating system could be related to UNIX. POSIX defined interfaces that could be implemented independently. The Single UNIX Specification and UNIX certification provided a standards-based meaning for the UNIX name. A system could share UNIX ancestry, provide standardized Unix interfaces, qualify to use the UNIX trademark, or combine those relationships in different ways.
Unix ideas could also spread without the original source code. A Unix-like system could reproduce familiar interfaces, tools, and conventions through an independent implementation. The GNU Project made that distinction explicit in its own name: GNU’s Not Unix. Its goal was not another proprietary UNIX descendant, but a complete free operating system compatible with Unix.
UNIX had become more than a line of source code descending from Bell Labs. It was a historical family, a standardized environment, a certified name, and a model for independently developed Unix-like systems. Keeping those meanings separate gives us a clearer way to follow the operating-system families that developed from them.
]]>UNIX gives us an opportunity to see those effects across an entire family of operating systems. AT&T licensed UNIX source code to universities and computer companies, allowing different organizations to study, modify, and adapt the system under the terms of those licenses. That helped UNIX spread, but it also helped create distinct branches as licensees developed UNIX for different hardware, customers, and purposes. Licensing continued shaping those branches: Berkeley eventually worked to remove AT&T-controlled code from BSD so that its own work could be distributed more freely. Licensing did not merely determine who could receive UNIX. It helped shape what the UNIX family became.
The code did not travel alone. As the UNIX family grew, ideas and capabilities moved between its branches, and eventually UNIX concepts traveled beyond systems descended from AT&T source. New operating systems could reproduce UNIX interfaces and conventions without containing UNIX code. The ideas had begun to spread farther than the code.
That success created a new problem. If UNIX could refer to descendants of the original source, systems assembled from different UNIX traditions, and independently developed systems that behaved like UNIX, what did it mean for an operating system to be UNIX? Standards such as POSIX emerged as part of the answer, defining common interfaces across an increasingly diverse UNIX and Unix-like world.
UNIX began at Bell Labs, but it did not stay there. During its early development, AT&T operated under restrictions that limited its ability to enter the computer business. Instead of treating UNIX like a conventional commercial software product, AT&T made it available under license to universities, government organizations, and eventually commercial organizations. Many of those licenses provided access to the source code.
That gave UNIX an unusual path outward. Organizations receiving the source did not merely receive an operating system they could run. They could study it, adapt it to their computers, and develop it for their own purposes. As more organizations did so, UNIX was becoming something larger than the system being developed at Bell Labs.
Source access became particularly useful because UNIX had already gained another important characteristic: portability. Rewriting much of UNIX in C reduced its dependence on the assembly language of one particular computer. Moving UNIX to another architecture still required work, but it no longer meant rewriting the entire operating system for every new machine.
Licensing and portability solved different parts of the same problem. Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations. Together, they made it possible for UNIX to appear on hardware and in institutions far removed from Bell Labs.
Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations.
Those organizations did not all need the same operating system. Universities could experiment with UNIX and develop new capabilities. Computer manufacturers could adapt it to their own hardware and customers. Other organizations could modify it around their particular requirements. Once those changes began accumulating independently, UNIX no longer had to develop in only one direction.
The licenses that helped UNIX spread also created the conditions for different branches to develop. Organizations could begin with related AT&T code and produce increasingly different systems. UNIX was becoming a family because its source had been allowed to travel.
One of the most important destinations was the University of California, Berkeley. Berkeley began working with licensed UNIX in the 1970s and distributed additions and modifications as the Berkeley Software Distribution, or BSD. Over successive releases, those changes became increasingly substantial.
Berkeley contributed tools and operating-system capabilities that would become important well beyond the university. Its networking work became particularly influential as UNIX systems became connected to networks and eventually to the growing Internet. BSD was no longer simply a few local modifications to UNIX; it had become a major branch of UNIX development.
At this stage, however, BSD was still a branch in the literal sense. It had grown from licensed UNIX source, and its distributions contained AT&T-controlled code. Receiving Berkeley’s additions did not erase the licensing requirements attached to the UNIX code underneath them.
That distinction will become increasingly important as we follow the UNIX family. BSD was not merely an operating system designed to resemble UNIX. Its history ran directly through the original UNIX source tree.
The same licensing arrangement that allowed Berkeley to build on UNIX also placed limits on how Berkeley could distribute the resulting system. Berkeley could make its own work available under its own terms, but it could not simply treat AT&T’s portions of the operating system as Berkeley code.
That gave Berkeley a reason to separate the two. Developers progressively replaced AT&T-controlled portions of BSD with implementations that could be distributed under Berkeley’s terms. What had begun as modifications to licensed UNIX gradually moved toward a system that no longer required the original AT&T source to function.
Licensing gave Berkeley access to UNIX code. The restrictions attached to that code later gave Berkeley a reason to replace it.
The process took years and eventually became part of a larger legal dispute over UNIX and BSD code. We will return to that history when we follow the BSD family itself. Here, the important point is the relationship between the two developments: AT&T’s licensing helped create the BSD branch, while the restrictions attached to AT&T code helped give Berkeley a reason to remove that code.
BSD therefore shows why the UNIX family cannot be understood as a simple tree. UNIX source traveled outward and created a new branch, but that branch began replacing parts of the code from which it had grown. Meanwhile, AT&T and commercial vendors continued UNIX development along other paths. The code had spread, and the branches were beginning to take on lives of their own.
While Berkeley was developing BSD, UNIX continued changing at AT&T. Changes in AT&T’s business environment opened the way for the company to treat UNIX more directly as a commercial product. That created another major path for the code that had begun at Bell Labs.
The result was not simply an AT&T operating system competing with BSD. Computer manufacturers wanted UNIX for their own hardware, and AT&T’s commercial UNIX became a foundation on which vendors could build. The UNIX family expanded across machines ranging from workstations to larger commercial systems.
The UNIX developed at Bell Labs had gone through a series of Research UNIX editions, but AT&T increasingly consolidated work intended for commercial use. UNIX System III, released outside Bell Labs in 1982, brought together development from several earlier AT&T UNIX efforts. It was followed in 1983 by UNIX System V.
System V became the principal commercial UNIX line associated with AT&T. It continued through several releases, adding capabilities while providing a common starting point for commercial UNIX implementations. Vendors could license AT&T technology and adapt UNIX to the computers and markets they served.
This produced another kind of UNIX branch. Berkeley had grown from a university research environment, while commercial vendors built systems around particular hardware platforms and customers. The underlying UNIX code could be related even when the resulting operating systems were sold by different companies for very different machines.
IBM entered the UNIX family with AIX. Like other vendor UNIX systems, AIX was not simply AT&T UNIX with a different name. IBM developed it around its own hardware and enterprise requirements while drawing from established UNIX traditions.
AIX 3 shows how those traditions were already beginning to overlap. Its foundation drew from AT&T System V while incorporating features associated with BSD. IBM could build a commercial UNIX whose source history ran through the AT&T line while also adopting capabilities developed elsewhere in the UNIX family.
AIX also demonstrates how far UNIX had moved into commercial computing. AT&T code could provide the foundation, while a major computer manufacturer developed that foundation into its own long-lived operating system.
Hewlett-Packard followed a similar path with HP-UX. Early HP-UX development drew from AT&T UNIX, including System III and later System V, as Hewlett-Packard adapted UNIX to its own computer systems.
HP-UX also incorporated capabilities associated with BSD, including networking interfaces that had become important in the Berkeley branch. Its history therefore cannot be understood simply by drawing a line from AT&T and ignoring the rest of the UNIX family.
AIX and HP-UX show why the spread of UNIX was different from distributing identical copies of one operating system. Vendors received UNIX technology, adapted it to their hardware, selected capabilities useful to their customers, and continued developing their systems over many years. The AT&T code provided ancestry, but it did not require every descendant to remain the same.
Sun Microsystems makes the relationship between the major UNIX branches even clearer. Early SunOS was strongly rooted in the BSD tradition. Sun became an important commercial home for technology that had developed through Berkeley rather than primarily through AT&T’s System V line.
Sun later worked with AT&T as the major UNIX traditions began moving back toward one another. Its operating-system line would eventually move from the earlier BSD-derived foundation to one based on System V Release 4.
Sun therefore crossed between two of the most important UNIX traditions. A company whose operating system had been rooted primarily in BSD became directly involved in bringing BSD and System V technology together.
The same pattern was already visible in AIX and HP-UX. UNIX systems had distinct histories, but those histories no longer developed in isolation. The family tree was beginning to acquire connections between its branches.
A family tree is useful for showing where an operating system came from. AT&T UNIX led to multiple lines of development, Berkeley built BSD from licensed UNIX source, and vendors developed their own commercial systems. If each branch had continued independently, a tree might be enough to describe the UNIX family.
That is not what happened. Once different groups began improving UNIX for their own purposes, useful work could travel between them. The UNIX source had created branches, but the branches began contributing back to the larger UNIX world. Ancestry still mattered, but ancestry alone could no longer explain what was inside a particular UNIX system.
Berkeley had received UNIX code through AT&T licensing, but Berkeley did not simply consume what Bell Labs produced. Researchers and developers added their own tools and capabilities, and some of that work became valuable to UNIX users outside Berkeley.
Networking is one of the clearest examples. BSD became an important home for the development and implementation of TCP/IP networking, along with the sockets interface applications could use to communicate over networks. As networking became increasingly important, BSD-derived networking technology appeared in commercial UNIX systems as well.
The direction had reversed. AT&T code traveled outward to Berkeley, where it helped create BSD. Technology developed in the BSD branch then traveled outward again and became part of systems whose primary lineage ran through commercial UNIX.
AIX and HP-UX already gave us examples of that mixture. Both belonged to the commercial UNIX world while incorporating capabilities associated with BSD. A system could have one primary ancestry while containing technology that had traveled through another branch of the family.
A UNIX family tree can show ancestry. It cannot show every movement of technology between the branches.
Microsoft also participated in the early commercial UNIX world. It licensed UNIX from AT&T and developed Xenix, which was adapted to several hardware platforms and eventually became closely associated with the growing market for microcomputers.
Xenix developed along its own commercial path and incorporated technology from more than one UNIX tradition. Microsoft eventually shifted its operating-system attention elsewhere and transferred ownership of Xenix to the Santa Cruz Operation in 1987. Xenix nevertheless remained part of the larger UNIX story because UNIX technology had continued developing there outside AT&T.
That became important when several of these paths met again. Xenix was not a dead branch disconnected from the rest of the UNIX family. Technology associated with it became one of the ingredients considered when AT&T and Sun attempted to bring major UNIX traditions back together.
By the late 1980s, the existence of competing UNIX variants had become a problem as well as a sign of UNIX’s success. Different vendors and development traditions had produced systems with different capabilities and interfaces. Shared ancestry did not guarantee that software or administrative knowledge would transfer cleanly between every member of the UNIX family.
AT&T and Sun collaborated on System V Release 4, released in 1989. SVR4 brought together technology from several important UNIX traditions, including AT&T System V, BSD, and Xenix. Rather than representing another clean split in the family tree, it deliberately recombined work that had developed along different paths.
Sun’s operating-system history makes that crossing particularly visible. Earlier SunOS had been rooted primarily in BSD. The later SunOS 5 foundation used for Solaris 2 was based on SVR4, moving Sun onto a system that combined the AT&T System V tradition with technology that had traveled through BSD and other UNIX branches.
A simple family tree was no longer enough. A tree can still tell us something important about ancestry, but it cannot show every movement of code between related systems. UNIX had become a web: code traveled outward, branches developed independently, and useful work could cross between those branches or be brought together again.
With UNIX code spreading through so many branches, it is easy to lose track of the line AT&T itself continued developing. That line did not disappear with System V Release 4. Instead, the UNIX business and the rights associated with it began passing between companies.
AT&T placed its UNIX business in Unix System Laboratories, or USL, which continued developing and licensing System V. UnixWare emerged from Univel, a joint venture between USL and Novell, and was built on the System V Release 4 lineage. Novell acquired USL in 1993, bringing both the AT&T commercial UNIX business and UnixWare under Novell.
In 1995, Novell transferred its UnixWare operating-system business to the Santa Cruz Operation, commonly known as SCO. The transaction did not amount to a simple transfer of everything associated with the word UNIX. Novell retained important rights and continued receiving revenue associated with older UNIX System V source licenses, while SCO received the UnixWare business and continued developing and selling UNIX systems. Those distinctions would become important years later when ownership of UNIX copyrights became part of the SCO litigation.
The business changed hands again. The original Santa Cruz Operation sold its server software and services divisions, including UnixWare and OpenServer, to Caldera Systems in 2001. Caldera later adopted the SCO name. After bankruptcy and further transfers, the UnixWare and OpenServer product line eventually reached Xinuos, which continues that commercial operating-system lineage today.
The UNIX name followed a different path. UNIX became increasingly defined through standards rather than ownership of AT&T’s operating-system source, and responsibility for the UNIX trademark passed from Novell to X/Open in the 1990s. X/Open later became part of The Open Group. Ownership of a particular UNIX-derived codebase, historical rights associated with System V code, and the right to certify an operating system under the UNIX trademark are therefore different things.
When following UNIX history, ask which relationship you mean: source ancestry, ownership of a particular codebase, compatibility with a standard, or the right to use the UNIX trademark. They are not the same thing.
AT&T left the UNIX operating-system business without bringing the UNIX story to an end. Its code had already spread throughout the family, its own commercial lineage continued through other companies, and the UNIX name was becoming separated from any single implementation. There was no longer one piece of code we could point to and say that everything called UNIX had to descend from it.
By the 1980s, UNIX had spread far beyond Bell Labs. AT&T source could be found in university systems, commercial UNIX products, and vendor-specific branches. Code developed in one branch could cross into another, making the UNIX family increasingly difficult to describe as a simple tree.
But source code was no longer the only thing spreading. UNIX had been studied, taught, documented, and used for years. Developers understood many of its interfaces and conventions, and programmers had learned to expect a particular kind of operating environment. It was becoming possible to reproduce the ideas behind UNIX without inheriting the original AT&T code.
That creates a different relationship to UNIX. BSD, System V, AIX, and HP-UX can be followed through source ancestry. Other systems could instead connect to UNIX through compatible interfaces, familiar tools, architectural ideas, documentation, education, or influence.
Andrew Tanenbaum developed MINIX as a small Unix-like operating system for teaching operating-system concepts. Earlier UNIX source had been used in university operating-systems courses, but AT&T licensing restrictions eventually made that increasingly difficult. Tanenbaum responded by writing a new system from scratch that could provide a Unix-like environment without using AT&T’s UNIX source.
MINIX was therefore fundamentally different from early BSD. Berkeley began with licensed UNIX code and gradually worked toward replacing the portions controlled by AT&T. MINIX was a complete rewrite: neither its kernel nor its utility programs contained AT&T code. Its source could be studied without inheriting the licensing restrictions attached to UNIX source.
The distinction matters because it shows another way UNIX could spread. A developer no longer needed the Bell Labs implementation itself to reproduce important parts of the UNIX operating model. UNIX had become an idea that could be independently implemented.
Similar behavior does not establish source ancestry. A system can reproduce UNIX interfaces and ideas without containing UNIX code.
MINIX also became important for another reason. Its availability on personal computers put a Unix-like operating system in the hands of students and programmers who might never have had access to a commercial UNIX workstation or institutional UNIX system. One of those users was a Finnish computer-science student named Linus Torvalds.
MINIX was not the only project demonstrating that UNIX ideas could exist independently of UNIX source. In 1983, several years before MINIX appeared, Richard Stallman announced the GNU Project. His goal was ambitious: build a complete free software system that would be compatible with UNIX without simply being UNIX.
The distinction was deliberate. GNU stands for “GNU’s Not Unix.” Stallman’s original announcement described a system intended to run UNIX programs while remaining its own implementation. Instead of requiring users to depend on proprietary UNIX software, GNU would recreate the operating environment with software that users could run, study, modify, and redistribute.
UNIX compatibility made that goal practical. Developers did not have to invent every interface from scratch or design an entirely new operating environment before separate pieces could work together. UNIX already provided a model for shells, compilers, utilities, libraries, and other components. Compatible replacements could be developed independently while still following expectations established by UNIX.
GNU therefore represents another way UNIX spread without AT&T source. The project was not trying to continue AT&T’s UNIX product line. It was building a different implementation around many of the same interfaces and expectations.
By 1990, GNU had found or written all of the major components it needed except the operating-system kernel. GNU’s operating environment was already well developed, but its own kernel was not yet ready to complete the system. GNU had nearly recreated the UNIX operating environment without inheriting UNIX itself.
Meanwhile, Linus Torvalds was using MINIX on an Intel 386 computer. He began experimenting with the processor and gradually developed what became an independent operating-system kernel. MINIX provided the environment in which that early work took place, but Torvalds was not modifying MINIX into a new operating system.
The distinction is important: influence is not ancestry. MINIX provided Torvalds with a Unix-like environment, tools, documentation, and a community in which early Linux development could take place. Linux itself was independently written rather than a new branch of the MINIX source tree.
Influence is not ancestry.
On August 25, 1991, Torvalds announced his new operating-system project to the comp.os.minix community. He described a free operating system for 386 and 486 computers and asked MINIX users what features they would like to see. He also made clear that the new system contained no MINIX code. The relationship between MINIX and Linux was real, but it was a relationship of environment and influence rather than inherited source.
Torvalds initially considered the name Freax for the project. When the early files were placed on an FTP server, Ari Lemmke instead used Linux for the directory, and that was the name that survived. The kernel would soon grow far beyond the experiments that produced it, but that belongs to a later part of our story.
For now, GNU and Linux should remain separate. GNU was an established effort to build a complete free Unix-compatible operating system. Linux was a newly written Unix-like kernel emerging from experiments performed in a MINIX environment. Neither needed AT&T UNIX source for UNIX ideas to reach it.
UNIX had first spread because organizations could obtain its code. Now systems could join the broader Unix-like world without inheriting that code at all. The code had created a family; the ideas had escaped the family tree.
By the beginning of the 1990s, the question “What is UNIX?” no longer had a simple answer. Some operating systems descended directly from AT&T source. Others combined code and capabilities from several UNIX branches. Still others, such as MINIX, GNU, and Linux, were being independently developed around UNIX interfaces and ideas without inheriting the original UNIX source.
Shared ancestry was no longer enough to describe the larger UNIX world. Two systems could descend from UNIX and behave differently, while another system could contain no original UNIX code and deliberately provide many of the same interfaces. If software developers wanted their programs to move between these systems, they needed something more useful than a family tree.
They needed agreement about how a Unix-like operating system should behave.
Efforts to standardize UNIX interfaces had already begun while the commercial UNIX branches were developing. One of the most important results was POSIX, the Portable Operating System Interface. The first POSIX.1 standard was published in 1988.
POSIX approached the problem through interfaces rather than ancestry. Instead of requiring an operating system to contain a particular body of UNIX source code, the standard defined interfaces and behavior that software could expect an operating system to provide.
That made POSIX useful beyond systems descended directly from AT&T UNIX. The standard was intended to apply not only to systems derived from original UNIX code, but also to compatible systems developed independently, emulations hosted on other operating systems, and systems running across a broad range of hardware.
POSIX therefore provided a way to describe UNIX compatibility without requiring UNIX ancestry.
That mattered for portability. A programmer targeting standardized interfaces could depend less on the peculiarities of one vendor’s UNIX implementation. Standards could not make every UNIX and Unix-like system identical, but they could establish common ground between systems whose source histories were becoming increasingly different.
POSIX did not completely answer the question of what could officially be called UNIX. During the 1990s, control of the UNIX trademark became separated from the commercial operating-system code that had descended from AT&T.
As Novell moved away from the UNIX business, the UNIX trademark passed to X/Open, which later became part of The Open Group. In 1994, X/Open introduced the Single UNIX Specification, establishing a common specification against which operating systems could be measured.
This changed what UNIX could mean. An operating system no longer had to descend from a particular AT&T code stream to qualify as UNIX. What mattered for use of the UNIX trademark was conformance with the specification and certification under the UNIX branding program.
The family name had effectively separated from the family tree.
That does not make ancestry irrelevant. System V, BSD, AIX, HP-UX, Solaris, and other systems still have histories that can be traced through actual UNIX code. Source ancestry and the UNIX trademark now answer different questions. One tells us where a system came from; the other tells us whether a product has demonstrated the conformance required to use the UNIX name.
This helps explain something that can otherwise sound contradictory. GNU and Linux are deeply connected to the UNIX tradition, but that does not make either one a descendant of UNIX source.
In 1983, Richard Stallman announced his intention to build a complete Unix-compatible software system called GNU. GNU stands for “GNU’s Not Unix,” a recursive acronym deliberately emphasizing that the project was building a Unix-compatible system rather than continuing UNIX itself.
The distinction was practical as well as linguistic. UNIX was proprietary software, and Stallman’s purpose in creating GNU was to build a system that could be used, studied, modified, and shared without accepting the restrictions attached to proprietary UNIX. GNU could reproduce useful UNIX interfaces, tools, and behavior while implementing them independently. GNU wanted UNIX compatibility without UNIX’s licensing restrictions.
Linux reached a similar technical position by a different route. Torvalds developed Linux in a Unix-like environment and deliberately implemented interfaces associated with UNIX and POSIX, but Linux was independently written rather than derived from AT&T UNIX source. When Linux was combined with GNU tools and other software into complete operating systems, those systems could provide a Unix-like environment without acquiring a commercial UNIX source license.
By then, however, UNIX had also become a certification and trademark. A Linux-based operating system could potentially become an official UNIX system by demonstrating conformance with the Single UNIX Specification and completing The Open Group’s certification process. A small number of Linux-based systems eventually did. Most Linux distributions did not need the UNIX name badly enough to take on the cost and work of certification. Unix-like, Unix-compatible, and POSIX compatibility could describe the relationships that mattered without acquiring the right to market the product as UNIX®.
Linux can therefore follow the UNIX tradition closely without being UNIX in either of the senses we have been discussing. Linux did not inherit AT&T UNIX source, and most Linux distributions have not sought certification for the UNIX trademark. What reached Linux instead were the interfaces, conventions, tools, and ideas of the UNIX environment.
GNU and Linux therefore have a different relationship to UNIX than BSD does. BSD can point backward through source ancestry. GNU and Linux point backward through interfaces, conventions, standards, and ideas. All belong to the broader history of UNIX’s influence, but they arrived there by different paths.
That history leaves several related ideas that are easy to collapse into the single word UNIX.
A system can have UNIX ancestry because its source history ultimately descends from the original UNIX code. That is the family tree we have followed through much of this article.
A system can be POSIX-conformant by implementing standardized interfaces. That relationship does not require the system to contain original UNIX source.
A product can be certified UNIX by demonstrating conformance with the applicable Single UNIX Specification and meeting the requirements for use of the UNIX trademark. UNIX in this formal sense is a certification, not simply a description of ancestry.
Finally, a system can be described more generally as Unix-like because it follows UNIX interfaces, conventions, tools, or design ideas without necessarily being descended from UNIX source or certified to use the UNIX trademark.
UNIX ancestry, POSIX conformance, UNIX certification, and being Unix-like describe different relationships. They can overlap, but they are not interchangeable.
These categories can overlap, but they are not interchangeable. A system’s source can tell us one story, its interfaces another, and its certification status another still. As UNIX spread, the meaning of the word had to expand beyond the history of one body of source code.
UNIX first spread because its code could travel. Its branches then exchanged code and capabilities with one another. Eventually its ideas and interfaces traveled beyond systems containing UNIX code at all. Standards provided a way for those increasingly different systems to share a common operating environment.
The UNIX family had become more than a family tree.
UNIX did not become a family simply because people liked the operating system and decided to imitate it. Its source code was allowed to travel. AT&T licensing gave universities and computer companies access to UNIX code they could study and adapt, while the portability UNIX gained from C made those adaptations practical across different hardware. The same licensing system also placed limits on what recipients could do with that code. Berkeley demonstrates both sides particularly well: licensing gave Berkeley access to UNIX, while licensing restrictions eventually gave Berkeley a reason to replace the AT&T-controlled portions of BSD.
Once UNIX had spread, its branches did not remain isolated. Berkeley-developed technology moved into commercial UNIX systems, vendors combined AT&T and BSD traditions with their own work, and System V Release 4 deliberately brought together technology from System V, BSD, and Xenix. The UNIX tree became a web. Even as AT&T left the UNIX business and its commercial operating-system lineage passed through other companies, UNIX technology had already spread too widely to belong to one development path.
Eventually, the ideas traveled farther than the code. MINIX demonstrated that a Unix-like system could be independently implemented for teaching. GNU deliberately pursued a free Unix-compatible system without becoming UNIX, and Linux emerged as another independent implementation shaped by the Unix-like environment around it. POSIX and the Single UNIX Specification helped separate compatibility and the UNIX name from any requirement that a system descend from one particular body of source code. UNIX ancestry, POSIX compatibility, UNIX certification, and being Unix-like could now describe related but different relationships.
That leaves us with more than one path through the UNIX tradition. Some systems can trace their history through the original UNIX source tree; others joined that tradition through interfaces, conventions, standards, and ideas instead. Over the next articles, we can follow those paths individually. We will begin with BSD, the branch that started with licensed AT&T UNIX, grew into one of the major centers of UNIX development, and eventually became independent enough to produce a family of operating systems of its own.
]]>Those are not all the same permission. A program might be available without charge but prohibit modification. Another might include its source code but restrict what can be done with it. A company might sell software while allowing its customers to study, modify, and redistribute it. A developer might even encourage people to copy a commercial program as widely as possible while keeping its source code proprietary. Price, source-code availability, copying, modification, redistribution, and commercial use are related, but they describe different things.
Those distinctions are behind terms such as commercial software, shareware, Free Software, Open Source, proprietary software, permissive licensing, and copyleft. They do not describe mutually exclusive categories. Free Software can be sold, Open Source software can use a copyleft license, and shareware can encourage copying while remaining proprietary. Even two Open Source projects can use licenses that affect how easily code can move between them.
Rather than treating those distinctions only as definitions, we are going to follow them through the histories of real software. Doom will take us from proprietary commercial software through shareware and eventually into Open Source. GNU Emacs will bring us into the GNU Project, Free Software, and copyleft. BSD will show what permissive licensing allows code to become downstream. Red Hat and Debian will demonstrate different ways of building systems from freely available software. Finally, StarOffice, OpenOffice.org, and LibreOffice will show what happens when ownership and stewardship change, a community forks the code, and different licenses affect what happens afterward.
Software licensing uses several terms that are often treated as though they describe mutually exclusive kinds of software. They do not. A program can be commercial and Open Source, or noncommercial and proprietary. Understanding the differences requires separating the business surrounding software from the rights its license gives to users.
Commercial software is software developed, distributed, or supported as part of a commercial activity. A company might sell copies of the program, charge for subscriptions or support, bundle it with another product, or use the software as part of a larger business.
The opposite is noncommercial software: software developed or distributed without a commercial purpose. Universities, hobbyists, volunteer communities, and individual programmers have all produced noncommercial software.
Neither term tells us what users are permitted to do with the software. Commercial software does not have to be proprietary, and noncommercial software does not have to be Free or Open Source. Commercial and noncommercial describe the economic activity surrounding software, not the rights granted by its license.
Proprietary software is software whose owner retains rights that are not granted to its users. A license might permit someone to run a program while restricting copying, modification, access to source code, redistribution, or some combination of those activities.
Proprietary software is frequently commercial, which is why the two terms are sometimes treated as synonyms. They are nevertheless different concepts. A developer can distribute proprietary software without charging for it, just as a company can make money from software that gives its users much broader rights.
Free Software describes software in terms of the freedoms given to its users. The Free Software movement defines those freedoms around the ability to run a program for any purpose, study how it works, modify it, redistribute copies, and distribute modified versions.
The word free refers to freedom, not necessarily price. Free Software can be given away, but it can also be sold. A business can charge for copies, packaging, support, integration, or other services without making the underlying software cease to be Free Software.
Source code is important because some of these freedoms cannot practically exist without it. Studying or modifying a program requires access to the human-readable code from which it was built. Merely making source code visible, however, does not automatically give someone permission to modify or redistribute it.
Open Source Software overlaps substantially with Free Software. Open Source licenses make source code available and provide rights to use, modify, and redistribute the software under defined conditions. As a result, much of the software we encounter can correctly be described as both Free Software and Open Source Software.
The two terms nevertheless come from different movements and emphasize different ideas. Free Software places the freedoms of software users at the center of the discussion. Open Source places greater emphasis on licensing and the development model that allows source code to be examined, modified, and redistributed. The distinction is often one of philosophy and emphasis rather than two completely separate bodies of software.
We can use Free and Open Source Software, or FOSS, when the distinction between the two movements is not important to what we are discussing. When it does matter, as it will when we reach GNU Emacs, we will use the more precise term.
None of these terms tells us how someone actually receives a copy of the software. A proprietary commercial program might be deliberately passed from user to user, while Free and Open Source Software can be sold as part of a commercial product. How software is distributed is a separate question.
Price, source availability, distribution, and licensing answer different questions about the same software.
How much software costs and how it reaches a user are separate from what its license allows the user to do afterward. Software can be sold, given away, or deliberately passed from one user to another while remaining proprietary. Free and Open Source Software can likewise be given away or sold. Several distribution models became particularly important during the personal-computer era.
The most familiar model is to obtain software by paying for a copy or a license to use it. During much of the personal-computer era, that often meant buying a boxed package containing disks and documentation. Software later moved increasingly toward electronic distribution, but the basic relationship remained familiar: payment was part of obtaining the software.
Paying for software does not make it proprietary. Commercial Free and Open Source Software can also be sold. The transaction tells us how the software was distributed, not what rights came with it.
Freeware is software distributed for use without requiring payment. It became common for developers and companies to make useful programs available at no charge, whether as complete products, promotional tools, companion utilities, or software maintained for other reasons.
The important word here is price. Freeware does not necessarily give users access to source code or permission to modify and redistribute it. A freeware program can remain completely proprietary.
This is one reason freeware and Free Software should not be confused. Freeware means that the software is available without charge. Free Software refers to freedoms granted to its users.
Shareware uses copying and evaluation as part of the distribution model. Instead of requiring a potential customer to purchase the software before trying it, developers encouraged users to obtain copies, try the program, and pass copies to other potential users. Payment or registration could then provide additional features, additional software, documentation, support, or continued authorized use, depending on the program.
Bulletin Board Systems made this model particularly powerful. A developer did not have to manufacture and ship every copy. A shareware program could be uploaded to a BBS, downloaded by its users, passed between friends, and uploaded elsewhere. The users themselves became part of the distribution network.
Permission to copy the distributed program did not make shareware Free or Open Source Software. Shareware was commonly proprietary. Its developer could encourage thousands of people to copy a program while still withholding its source code and restricting modification.
That combination will become important when we reach Doom. It was commercial software, it was proprietary, and its shareware release was deliberately designed to be copied. None of those descriptions contradicts the others.
Free and Open Source Software created a different distribution problem. Giving users permission to copy, modify, and redistribute software made it possible for copies to travel freely, but obtaining one program was only part of the problem. A useful computer system might depend on software produced by hundreds or thousands of independent projects.
Early Free and Open Source projects could distribute their own software directly. Source code might be obtained from another user, copied from physical media, or downloaded from an FTP server or project site. Because redistribution was permitted, copies did not necessarily have to come from the original developer.
This decentralized distribution was powerful, but it also left users responsible for obtaining, building, configuring, and updating software from many different sources.
Packaging systems made that collection of independent software easier to manage. Instead of every user finding and installing each program directly from its original developer, software could be prepared as packages that described what was being installed and what other software it required.
Repositories took that idea further by collecting packages into maintained sources from which users could install and update software.
A software distribution goes beyond simply making copies available. It selects software from many projects, integrates it, packages it, establishes defaults, provides installation and update mechanisms, and presents the result as a usable system.
This becomes especially important with GNU/Linux. Linux is the kernel, but what someone installs as a Linux distribution contains software from many independent projects: the Linux kernel, GNU utilities, libraries, shells, servers, desktop environments, applications, and thousands of other components.
The ability to redistribute Free and Open Source Software makes those larger systems possible, but it does not dictate who must assemble them or why. A volunteer community can build a distribution, and so can a commercial company. Debian and Red Hat will let us see both approaches using much of the same larger pool of software.
So far, we have repeatedly mentioned access to source code, but source code is not always included when software is distributed. Most users receive a compiled program: the machine-executable form produced from source code written by programmers. They can run the program without possessing the original human-readable code used to create it.
With proprietary software, the source code is commonly kept by its developer or owner. Users receive the compiled program and whatever rights its license grants them. Even if they are permitted to copy the program—as they might be with freeware or shareware—that permission does not necessarily include access to its source.
Free and Open Source Software works differently because the ability to study and modify a program requires access to its source code. The source therefore has to be available to users entitled to those rights. This does not mean every copy must arrive with a folder full of source files beside it. A distribution can provide ready-to-run binary packages while making the corresponding source available separately.
A developer can also publish source code without granting the rights required for the software to be Free or Open Source. The code may be source available—people can read it—but its license may restrict modification, redistribution, commercial use, or other activities.
Being able to read the source is not the same thing as having permission to modify or redistribute it.
Making software Free or Open Source does not mean giving up copyright or placing the code into the public domain. The copyright holder instead uses a license to grant other people rights to use, study, modify, and redistribute the software. Different licenses can grant those rights under different conditions.
A permissive license, such as the licenses associated with BSD, grants broad rights with relatively few requirements on what happens to modified or redistributed versions. Copyright and license notices generally have to be preserved, but the code can often be incorporated into software distributed under different terms, including proprietary commercial products.
That flexibility helps explain why BSD code has traveled so widely. A company can take permissively licensed code, modify it, combine it with its own code, and distribute the resulting product without necessarily having to release its modifications under the original BSD license.
A copyleft license takes a different approach. It also grants broad rights to use, study, modify, and redistribute software, but it places requirements on certain forms of redistribution so that the freedoms granted by the original license are preserved downstream.
The GNU General Public License, or GPL, is the best-known example. If GPL-covered software is modified and a covered derivative work is distributed, the GPL requires the corresponding source to be made available under the GPL’s terms. Someone can modify the software, sell it, and build commercial products with it, but cannot simply take the covered code, distribute a proprietary version of that covered work, and withhold the freedoms the GPL was designed to preserve.
Permissive and copyleft licenses therefore protect different goals. A permissive license emphasizes giving downstream developers broad freedom over what they build from the code. Copyleft emphasizes preserving particular software freedoms as the code moves downstream. Neither approach makes software inherently more or less Open Source; both permissive and copyleft licenses can qualify as Free and Open Source licenses.
When id Software released Doom in December 1993, it was unquestionably a commercial product. id Software intended to make money from the game, and the complete game was proprietary software. Yet the company did something that might sound strange if commercial and proprietary software are assumed to mean tightly controlled distribution: it encouraged people to copy Doom.
What people were encouraged to copy was the shareware version. The first episode, Knee-Deep in the Dead, could spread from one player to another and across Bulletin Board Systems, while the remaining episodes were part of the registered commercial product. Instead of treating every freely copied disk or download as a lost sale, the shareware model turned those copies into advertising. Someone could play a substantial portion of Doom, give it to a friend, and potentially create another customer.
Doom was commercial because id Software was selling a product. It was proprietary because id retained control over the software and its source code. It was shareware because id deliberately permitted and encouraged redistribution of the shareware release. None of those descriptions conflicts with the others.
But Doom did not remain in that state forever.
On December 23, 1997, John Carmack released the source code for the Doom engine. The release used the Linux version rather than the original DOS code because the DOS sound support depended on the third-party DMX sound library, which was not publicly available and therefore could not be included. The game data—the levels, graphics, sounds, and other assets that made Doom the game—also remained copyrighted and were not simply given away with the engine source.
Publishing the source did not initially make Doom Free or Open Source Software in the sense we use those terms today. The original Doom Source Code License released the code for non-profit use and permitted people to examine and modify it, but it prohibited commercial exploitation and did not permit redistribution of the source itself. The source was available, but the rights attached to it were still restricted.
That changed again in October 1999, when id Software rereleased the Doom source under the GNU General Public License. The GPL allowed the engine to be used, modified, and redistributed under a copyleft license. The commercial game released in 1993 had therefore traveled through several different arrangements: proprietary software distributed partly through shareware, source code made publicly available under restrictions, and finally an engine released as Free and Open Source Software.
The results outlived the original computers for which Doom was written. Developers could port the engine to new operating systems and hardware, fix limitations, add features, and create new source ports. The original game assets still had their own copyright restrictions, so an Open Source Doom engine did not mean that the complete commercial game had suddenly become free to redistribute.
One result has become something of a tradition among programmers and hardware hackers: the Doom Test. If a device contains a processor and a display—or sometimes anything that can be persuaded to act like one—someone will eventually try to make it run Doom. The game has appeared on calculators, watches, cameras, printers, and other devices that were never intended to be gaming machines. Some of these ports are serious demonstrations of hardware and software capabilities; others exist largely because getting Doom to run somewhere unexpected is fun. The availability of the engine’s source code helped make that experimentation possible. A commercial game from 1993 became not only something people continued to play, but a familiar challenge for demonstrating what an unusual piece of hardware could be made to do.
Doom gives us a useful first lesson because the software itself changed categories while remaining recognizably the same project. How software is sold, how copies are distributed, whether its source can be seen, and what its license permits are separate properties—and each of them can change over the life of a program.
A program can change its distribution model, source availability, and license without ceasing to be the same software project.
The story of GNU Emacs begins before GNU. Its ancestry reaches back to the MIT Artificial Intelligence Laboratory in the 1970s, where Richard Stallman worked on an extensible editor built around TECO. Rather than treating an editor as a fixed collection of commands, Emacs could be customized and extended. Users could change how the editor behaved and add new capabilities instead of waiting for the original developer to provide them.
That extensibility became one of Emacs’s defining characteristics. GNU Emacs would eventually use Emacs Lisp as its extension language, allowing the editor to become considerably more than a place to type text. Email, calendars, games, development tools, and other applications could live inside Emacs. It even includes M-x doctor, a conversational psychotherapist program in the tradition of ELIZA.
By then, however, Stallman was confronting a larger problem than how a text editor should work. The cooperative software culture he had known at MIT was changing as software increasingly became proprietary and source code became less freely shared. In September 1983, he announced the GNU Project: an effort to create a complete Unix-compatible operating system whose users would be free to use, study, modify, and share its software. Development began in 1984.
GNU needed an editor, and Stallman already knew what kind of editor he wanted. He began writing GNU Emacs in September 1984. By early 1985 it was usable, and other people wanted copies.
That created an interesting distribution problem. People connected to the Internet could obtain GNU Emacs through anonymous FTP, but many potential users were not online. Stallman offered another option: for $150, he would mail GNU Emacs on tape. The software remained Free Software, and recipients remained free to copy it for someone else. What Stallman charged for was the service of providing a physical copy.
GNU Emacs therefore gives us an early example of something our terminology already allows: Free Software could also be commercial software. Charging money for a copy did not determine whether the software was Free. The freedoms accompanying that copy did.
There was still another problem. Giving someone permission to modify and redistribute software did not necessarily guarantee that those freedoms would survive into later versions. A developer could take freely available code, modify it, and distribute the resulting program under proprietary terms if the original license permitted it.
Stallman’s answer was copyleft. Instead of abandoning copyright, copyleft uses copyright and a software license to grant users broad freedoms while placing conditions on redistribution intended to preserve those freedoms downstream. Someone can use the software, study it, modify it, share it, and even sell it, but covered derivative works that are distributed must remain available under the required copyleft terms.
GNU Emacs became an important early application of that idea. Early versions used a program-specific GNU Emacs General Public License, while the licensing work surrounding GNU software eventually developed into the GNU General Public License, or GPL. GPL version 1 appeared in 1989 and provided a reusable copyleft license for GNU software and other projects. Rather than every GNU program needing its own separately written licensing arrangement, the GPL could express the same basic set of downstream requirements across many programs.
This is the central difference between simply releasing source code and using copyleft. Source availability makes it possible to examine code. Permission to modify it makes further development possible. Copyleft adds the requirement that particular freedoms accompany covered code as it continues downstream.
Copyleft is not merely permission to modify code. It is a way of making particular freedoms travel downstream with covered code.
GNU Emacs also entered one of computing’s longest-running arguments: Emacs versus vi. The two editors grew from different traditions. vi came from Bill Joy’s work at Berkeley and the BSD world, while GNU Emacs became closely associated with GNU and Free Software. Their different interfaces and philosophies inspired decades of arguments over which editor programmers ought to use.
Plenty of users simply found something that worked for them. I largely avoided the Emacs-versus-vi argument by using Pico. As GNU/Linux distributions became more important, however, Pico’s license became a problem. Debian treated Pine and Pico as non-free, and the license did not permit Debian to distribute modified binaries, so users had to build the software from source and Debian’s patches rather than install it as a normal binary package. I moved to JOE instead.
By the time nano appeared as a GPL-licensed Free Software replacement for Pico, I had already moved on from that family of editors. The appearance of nano nevertheless demonstrates the practical effect of the licensing problem. Pico remained a useful editor, but its license affected whether distributions could package and redistribute it under their rules, and the resulting gap helped create demand for a Free Software replacement.
The editor war is mostly computing culture, but the histories behind the editors bring us back to licensing. GNU Emacs shows one answer to the question of what should happen when freely modifiable software moves from one developer to another: the freedom to modify the code should travel with the code. BSD, coming from the other side of the old editor rivalry, will give us a different answer.
The other side of the old Emacs-versus-vi rivalry brings us back to Berkeley. vi was created by Bill Joy as part of the software work surrounding the Berkeley Software Distribution, or BSD. As we saw last week, BSD began as modifications and additions to AT&T UNIX at the University of California, Berkeley, and eventually became one of the major branches of the UNIX family.
BSD’s influence spread well beyond the systems that carried its name. Berkeley developed important UNIX tools and, especially with 4.2BSD, helped establish the TCP/IP networking software that became enormously influential. Commercial UNIX systems incorporated Berkeley software, while BSD itself continued developing at the university.
There was a complication, however. BSD had grown from UNIX, and early BSD distributions still contained AT&T-owned UNIX code. Receiving those distributions therefore required an appropriate UNIX source license. Berkeley could distribute the software it had written, but it could not simply give everyone the proprietary AT&T portions of the system.
By the late 1980s and early 1990s, Berkeley’s Computer Systems Research Group began separating its own work from the AT&T code. Networking Release 1 made Berkeley’s networking code separately redistributable, and Networking Release 2 pushed much farther toward a complete system. A legal dispute over portions of Net/2 was settled in 1994, after which Berkeley released 4.4BSD-Lite as an unencumbered codebase. The BSD descendants could then continue developing without depending on proprietary AT&T UNIX code.
The license Berkeley used for its own code took a different approach from the copyleft we just encountered with GNU Emacs. A BSD-style license is permissive. It grants broad permission to use, modify, and redistribute the code while imposing relatively few requirements on what a downstream developer must do with a resulting product.
Copyleft is designed to ensure that particular freedoms continue downstream when covered derivative works are distributed. A permissive BSD license allows a downstream developer considerably more discretion. BSD-licensed code can remain in an Open Source project, but it can also be incorporated into a proprietary product without requiring that all of the resulting proprietary code be released under the BSD license.
The code is not in the public domain. Copyright still exists, and BSD licenses still impose conditions, such as preserving copyright notices and disclaimers. What the license does not generally require is that someone who incorporates the code into a larger product must release that larger product’s source code under the same terms.
That choice helped BSD technology travel into some very different systems.
| Product / System | BSD Connection |
|---|---|
| OPNsense | Built on FreeBSD |
| OpenBSD | Forked from NetBSD |
| DragonFly BSD | Forked from FreeBSD 4.8 |
| macOS / Darwin | BSD layer derived primarily from FreeBSD |
| Force10 FTOS | Built on NetBSD |
These are not all the same kind of system. OpenBSD and DragonFly BSD became independent Free and Open Source operating systems. OPNsense uses FreeBSD as the foundation for a specialized firewall and routing platform. Apple’s Darwin combines BSD technology with other components as the foundation beneath macOS, while Force10 used NetBSD as the foundation for a commercial network operating system.
The table only shows the immediate connection. The BSD family has a much larger and more complicated family tree, which deserves its own story. What matters here is what happened to the code after it was released under permissive terms. It could remain within Free and Open Source projects, become the foundation of new operating systems, power specialized appliances, or become part of larger commercial and proprietary products.
This is the other major answer to the downstream question. GNU’s copyleft approach says, in effect, you may build on this code, but the freedoms attached to covered code must continue with it. The permissive BSD approach says, you may build on this code, and you have broad freedom to decide how your own resulting work will be distributed.
Both approaches produce Free and Open Source Software. They differ in what kind of freedom they emphasize downstream. BSD’s history shows one consequence of the permissive choice particularly well: the code was free to travel, even into systems whose developers chose a very different licensing model for what they built around it.
Permissive licensing gives downstream developers broad freedom over what they build. Copyleft puts more emphasis on preserving freedoms as covered code moves downstream.
The software freedoms we have been following do more than allow an individual program to be modified or redistributed. They also allow people to assemble software from many independent projects into something larger. Debian shows what can happen when a community takes responsibility for doing exactly that.
Ian Murdock founded the Debian Project in August 1993, when the idea of a Linux distribution was still relatively new. Linux provided a kernel, GNU provided many of the tools needed around it, and other Free Software projects supplied still more pieces. Turning all of those pieces into a usable operating system required someone to select them, package them, keep track of their dependencies, integrate them, distribute updates, and decide what belonged in the system.
Debian was intended from the beginning to be developed openly. Instead of belonging to a company producing a Linux product, it grew from a small group of Free Software developers into an organized international community. Individual developers became responsible for packages, while the project developed policies and technical processes for making thousands of independently developed pieces of software behave as one distribution.
That organization matters because a distribution is itself a substantial piece of engineering. Debian does not write every program it distributes. Much of its work happens between the original software project—the upstream project—and the person installing Debian. Debian developers package upstream software, describe dependencies, integrate it with the rest of the system, apply or forward fixes, test combinations of packages, and maintain repositories from which complete systems can be installed and updated.
As Debian grew, its package-management system became increasingly important to that work. Early Debian releases had relatively primitive package handling, but the project developed dpkg and increasingly detailed information about relationships between packages. A user no longer needed to treat every program as an isolated piece of software obtained directly from its developer. The distribution could manage a collection of software as a system.
Building a Free Software distribution also created a question that compiling and packaging alone could not answer: what counts as Free Software?
In 1997, Debian adopted its Social Contract and the Debian Free Software Guidelines, or DFSG. The Social Contract states commitments the Debian Project makes to the Free Software community, while the DFSG provides criteria Debian can use when deciding whether a software license is sufficiently free for software to be included as part of Debian.
Those guidelines include requirements such as allowing free redistribution, permitting modification and derived works, and not restricting use of the software to particular people, groups, or fields of endeavor. They do not require one particular licensing strategy. Debian explicitly recognizes licenses including the GPL and BSD licenses as examples of Free Software licenses.
Debian can contain software under both copyleft and permissive licenses. The distribution does not require every component to make the same choice about downstream licensing. Instead, each component’s license must provide the freedoms necessary to satisfy Debian’s guidelines.
Software that does not meet those requirements has historically been handled in separate archive areas rather than as part of the Debian system itself. Debian can therefore help users obtain some non-free software without redefining that software as part of Debian’s Free Software distribution.
The DFSG would also have an influence beyond Debian. Bruce Perens, who drafted the Social Contract and DFSG with input from other Debian developers, later removed the Debian-specific language from the guidelines to form the basis of the Open Source Definition. A set of rules created to answer the practical question of what software Debian could include therefore became part of the larger history of the term Open Source.
Because Debian itself can be copied and modified, the distribution can also become an upstream source for another distribution. Someone does not have to begin again with the Linux kernel, GNU utilities, and thousands of unrelated projects. They can begin with Debian’s already integrated system and build something different from it.
That has produced a large extended Debian family. Among its descendants are:
Linux Mint Debian Edition builds a general-purpose desktop system directly on Debian, while Kali Linux specializes that foundation for penetration testing and security work. The same freely redistributable base can therefore support projects intended for very different audiences.
Ubuntu adds another dimension to the story. It is built from Debian but developed with commercial backing from Canonical. Debian itself is a community project, yet the freedoms attached to its software allow a company to take that work downstream, integrate and develop it further, and build a commercially supported distribution around it.
That does not mean a company simply takes Debian and owns what came before it. The individual components retain their respective copyrights and licenses. Copyleft requirements still apply where copylefted components are involved, permissive licenses retain their own conditions, and changes can move between upstream and downstream projects when their licenses and development practices permit it.
Debian therefore gives us a different view of software distribution. A community can take thousands of independently developed Free and Open Source components, integrate them into a complete operating system, and make that integrated system available for still other communities and companies to build upon.
Free and Open Source licensing did not merely make individual programs easier to share. It made it possible for communities to assemble complete systems that could themselves become foundations for whatever came next.
A distribution can become an upstream project too. Debian is not only assembled from other projects; other distributions can begin with Debian.
Debian showed how a community could assemble thousands of independently developed pieces of Free and Open Source Software into a complete operating system. The same freedoms also left room for a company to do much of the same work commercially. Red Hat would demonstrate that selling a Linux distribution did not require turning Linux into proprietary software.
Red Hat’s story began in the early 1990s with Marc Ewing’s Red Hat Linux distribution and Bob Young’s ACC Corporation, which sold Linux and UNIX software and accessories. Young began distributing Ewing’s work, and the two joined forces in 1995 to form Red Hat Software.
There was an apparent contradiction in the business. Much of the software Red Hat distributed could already be copied legally. A customer did not necessarily have to buy Linux from Red Hat to obtain Linux, GNU utilities, or the many other Free and Open Source components included in the system.
That meant the value of the product could not depend entirely on controlling access to the underlying software. Red Hat could instead sell the work required to turn that software into something organizations could reliably use.
One of the less pleasant ways Linux users learned the value of that integration was RPM Hell. RPM made it possible to install, remove, and track packaged software, but obtaining an RPM did not necessarily mean that everything required to run it was already installed. A package might depend on several other packages, each of which introduced dependencies of its own. Users could find themselves searching the Internet for one RPM after another, only to discover that the next package required still another library or a different version of one they already had.
One solution came from a descendant of Red Hat Linux. Yellow Dog Linux was an RPM-based distribution developed primarily for PowerPC computers, including Apple Macintosh systems. Yellow Dog developed YUP, the Yellowdog Updater, to work with software repositories rather than requiring users to locate every RPM individually.
Developers at Duke University built on YUP to create YUM, the Yellowdog Updater, Modified. YUM could use repositories to determine which packages were required to satisfy dependencies and retrieve them as part of an installation. Fedora adopted YUM, and it eventually became familiar to generations of Fedora, Red Hat Enterprise Linux, CentOS, and related-system users. Yellow Dog Linux itself eventually disappeared, but its name survived in yum.
Red Hat Linux helped provide the foundation for Yellow Dog Linux. Yellow Dog’s solution to an RPM problem was expanded by other developers, then flowed back into Fedora and the Red Hat ecosystem.
Packaging a Free and Open Source operating system therefore involves more than collecting freely available programs. Someone still has to decide which versions belong together, describe their dependencies, organize repositories, test combinations, and provide updates. Better tooling can automate much of that work for the user, but only because the distribution has already done the integration work behind it.
That work includes:
None of those activities requires taking away the freedoms granted by the underlying software. They provide value around software that customers may already have the right to copy, inspect, modify, and redistribute.
This distinction became increasingly important as Linux moved from hobbyist computers and Internet servers into businesses and large organizations. A company might be perfectly capable of downloading source code without being interested in assembling, testing, maintaining, and supporting an operating system itself. What it could purchase from Red Hat was not simply permission to possess Linux, but a maintained product and a relationship with an organization willing to support it.
Red Hat eventually changed how it organized its Linux distributions. Red Hat Enterprise Linux, or RHEL, had been introduced in 2002 as the company’s commercially supported enterprise distribution. The original Red Hat Linux line was discontinued in 2003, and the Fedora Project was introduced for users and developers who wanted a faster-moving community distribution.
The ability to use and redistribute Free and Open Source Software also allowed other projects and companies to develop systems around the Red Hat ecosystem. A few examples show that movement in different directions:
Fedora represents the community side of Red Hat’s own development ecosystem. Newer software and technologies can develop in Fedora before some of that work moves through CentOS Stream and eventually into Red Hat Enterprise Linux. The community project is therefore not merely a free copy of the commercial product; it participates upstream in the development path that can eventually lead toward RHEL.
Rocky Linux demonstrates movement in the other direction. It is a community-developed enterprise Linux distribution designed to be compatible with RHEL. The existence of a commercial enterprise distribution does not prevent a separate community from using the available Free and Open Source code to build its own compatible system.
Oracle Linux takes that possibility into the commercial world again. Oracle is not Red Hat, yet it can offer its own commercially supported Linux distribution designed for compatibility with RHEL. Free and Open Source licensing therefore permits an unusual commercial relationship: one company’s commercial software ecosystem can provide much of the foundation for another company’s competing commercial product.
Fedora shows a community project feeding toward a commercial distribution, Rocky Linux shows a community project appearing downstream from it, and Oracle Linux shows another commercial product appearing downstream. Commercial and community development are not opposite ends of a line. Free and Open Source licensing allows software to move among both.
Red Hat Enterprise Linux is commercial software, but that does not make the Free and Open Source components from which it is built proprietary. Customers pay Red Hat for an enterprise product assembled from those components and for the services surrounding that product.
The distinction is easier to see if we separate the software from the business built around it. Linux can remain licensed under the GPL. BSD-licensed components can retain their permissive licenses. Thousands of other packages can retain the licenses chosen by their respective projects. Red Hat can still select versions, integrate them, test the resulting system, provide updates, certify hardware and software, maintain releases for years, and sell support for the complete product.
A company can build a commercial product from software that its customers have substantial rights to copy and modify. The company does not necessarily make its money by preventing those freedoms. It can make money by doing work around the software that customers consider valuable.
Debian and Red Hat consequently arrive at complete operating systems through different organizations. Debian demonstrates that a community can integrate Free and Open Source Software into a distribution that later becomes the foundation for both community and commercial descendants. Red Hat demonstrates that a company can take much of the same larger pool of Free and Open Source Software and build a commercial product and support business around it.
Free and Open Source Software does not eliminate commercial software. It changes what a software company can sell and where the value of that commercial product can come from.
When customers already have substantial rights to the software, commercial value can move toward integration, maintenance, support, certification, and trust.
The office suite we now know as LibreOffice began as proprietary commercial software. Its roots reach back to StarWriter, created by Marco Börries in Germany in the 1980s. StarDivision developed the program into a larger suite, and by 1992 it had become StarOffice.
StarOffice was eventually available on several operating systems, including Windows, OS/2, Solaris, and Linux. It was still StarDivision’s product, however. The company controlled its development and distribution in much the same way another software company might control any proprietary office suite.
Then the owner changed.
Sun Microsystems acquired StarDivision in 1999. The following year, Sun did something more significant than simply continue selling StarOffice: it announced OpenOffice.org and released the StarOffice source code for the new project on October 13, 2000. OpenOffice.org 1.0 followed on April 30, 2002. A proprietary commercial software family now had an Open Source branch that other developers could study, modify, and help develop.
Sun did not have to stop selling an office suite in order to do this. StarOffice continued as a commercial product while OpenOffice.org developed as an Open Source project. Once again, commercial and Open Source were not opposites. The same software family could participate in both models.
For several years that arrangement continued with Sun as the principal corporate sponsor of OpenOffice.org. The community could contribute to the project, while Sun remained an important center of its development and stewardship.
Then the owner changed again.
Oracle acquired Sun Microsystems in January 2010. That acquisition meant that OpenOffice.org, along with the other technology Sun had accumulated, now sat under a different corporate owner. Members of the OpenOffice.org community did not have to wait to discover what Oracle would eventually choose to do with the project.
They could fork it.
On September 28, 2010, members of the OpenOffice.org community announced The Document Foundation, an independent organization intended to provide a community-governed home for the office suite. Unable to obtain the trademarked OpenOffice.org name from Oracle, the new project was called LibreOffice.
LibreOffice was not a rewrite created from nothing. It began as a fork of OpenOffice.org. The developers already had access to the source and, more importantly, the software’s license gave them the rights necessary to take that source in another direction.
That is where the right to fork becomes more than an abstract freedom written into a license. The community did not need to purchase the project from Oracle, persuade Oracle to transfer ownership, or abandon years of existing code and begin again. Developers could take the code they were already working on and continue developing it under different stewardship.
Oracle later stopped developing OpenOffice.org and, in June 2011, contributed the source code and trademarks to the Apache Software Foundation. OpenOffice therefore continued as Apache OpenOffice, while LibreOffice continued independently under The Document Foundation.
One software family had now passed through several very different arrangements:
The names alone do not explain what happened. StarOffice began as proprietary commercial software. Sun opened its source to create OpenOffice.org. The OpenOffice.org community later exercised its right to fork the code and created LibreOffice. Oracle then transferred OpenOffice.org to Apache, producing another independently governed Open Source branch.
The ability to fork did not guarantee which branch would attract developers, users, or institutional support. A software license cannot determine whether a project will succeed. What it can determine is whether people have the legal ability to continue the software when they disagree with the decisions of whoever currently controls a project.
The split also produced a subtler licensing lesson. Apache OpenOffice and LibreOffice are both Open Source, but they do not use the same licensing model.
Apache OpenOffice uses the permissive Apache License 2.0. LibreOffice is currently distributed primarily under the Mozilla Public License 2.0, with new contributions also licensed under the LGPLv3+ according to the project’s contribution policy. Those differences affect how code can move between the two projects.
Apache-licensed code can be incorporated into LibreOffice under the applicable licensing arrangements, and LibreOffice has incorporated code originating in Apache OpenOffice. The reverse direction is more difficult. Code contributed only under LibreOffice’s copyleft licenses cannot simply be incorporated into Apache OpenOffice and redistributed solely under Apache’s permissive license.
The result is an asymmetric relationship. Apache OpenOffice can develop a feature under a permissive license that LibreOffice may be able to incorporate. If LibreOffice develops a change under licensing terms that impose copyleft requirements, Apache OpenOffice cannot simply take that code and place it into its Apache-licensed codebase.
Open Source does not mean that code can move freely between every Open Source project. Two projects can both provide their source code, both permit modification, and both permit redistribution while still using licenses that place different requirements on what happens when their code is combined or redistributed.
Commercial software can become the source of an Open Source project. Commercial and Open Source versions can coexist. A change in corporate ownership does not necessarily give that corporation complete control over the future of previously released Open Source code. A community with the right to fork can continue development independently. And even after a fork, the licenses chosen by the resulting projects can affect which direction code is able to travel between them.
Open Source does not guarantee who will control a project tomorrow. It gives others rights that can prevent one owner from being the only possible future for the code.
The right to fork does not guarantee that a fork will succeed. It guarantees that continued development does not have to depend on one owner saying yes.
Software does not fit neatly into a single category. Whether software is commercial, whether someone pays to obtain it, whether its source code is available, how copies are distributed, and what users are permitted to do with those copies are separate questions. Shareware can be proprietary. Freeware can restrict modification. Free Software can be sold commercially. Open Source software can be developed by volunteers, businesses, or both. Understanding software licensing begins by separating those questions rather than assuming that one answer determines all the others.
The histories of Doom, GNU Emacs, and BSD show how much the rights attached to software can differ. Encouraging people to copy Doom did not initially give them its source code, and publishing that source did not immediately make it Open Source. GNU Emacs demonstrated how copyleft could use copyright to preserve particular freedoms as software moved downstream. BSD licenses made a different choice, granting broad freedoms while generally allowing downstream developers to decide how their larger resulting works would be licensed. Both copyleft and permissive licenses can produce Free and Open Source Software, but they do not impose the same obligations on what comes next.
Those permissions become even more significant when individual programs become parts of larger systems. Debian shows how a community can assemble thousands of independently developed components into a complete operating system that can itself become the foundation for other projects. Red Hat shows how much commercial value can be created around software that customers already have substantial rights to use, study, modify, and redistribute. The history from StarOffice through OpenOffice.org and LibreOffice shows why the right to fork matters when ownership or stewardship changes—and why even two Open Source projects may not be able to exchange code equally when their licenses differ.
Licensing is therefore more than a statement about whether software costs money or whether its source code can be downloaded. It establishes permissions and obligations that help determine where code can travel, what can be built from it, and what rights accompany it along the way. Those choices helped UNIX cross organizational boundaries, allowed BSD code to spread into an enormous range of systems, and made it possible to assemble the Free and Open Source components surrounding Linux into complete operating systems. As we continue following the modern UNIX family, those licensing decisions will remain part of the explanation for why BSD and Linux developed into the ecosystems we know today.
]]>UNIX did not begin as a networking operating system in the modern sense. It developed in an environment where computing resources were shared among multiple users and where multiple programs needed to operate within the same system. Users, processes, permissions, files, and small programs that could work together were part of its operating model from relatively early in its development. As networking became more important, many of those existing assumptions translated naturally into computers that increasingly needed to interact with other computers.
The same characteristics that helped UNIX adapt to changing uses also helped it spread. Rewriting much of UNIX in C reduced its dependence upon a particular machine, allowing it to move across hardware architectures more readily than an operating system closely tied to one computer. Universities, researchers, and commercial vendors could encounter UNIX, adapt it to different environments, and develop it in different directions. Berkeley became particularly important to that development, while AT&T continued its own UNIX lineage and commercial vendors created systems for their hardware and markets.
UNIX became more than the operating system originally developed at Bell Labs. It became a family of related systems with common ancestry but increasingly distinct implementations, purposes, and identities. Understanding how that happened requires returning to UNIX’s beginning, examining the operating model that developed around it, and following the branches that appeared as UNIX moved beyond the machines and organization where it began.
UNIX did not appear in isolation. Its development followed Bell Laboratories’ participation in one of the most ambitious computing projects of the 1960s: the Multiplexed Information and Computing Service, better known as Multics. Developed jointly by MIT, General Electric, and Bell Labs, Multics was intended to create a large time-sharing system in which many people could interact with a computer at the same time.
Time-sharing represented a different way of thinking about access to a computer. Instead of preparing a job, submitting it, and waiting for the results, users could work interactively through terminals while the operating system managed access to the underlying machine. Multics took that idea considerably further. It was designed around multiple users, processes, protection between users and programs, a hierarchical filesystem, and an operating environment that could remain continuously available while serving a changing workload.
Those goals made Multics influential, but they also made it extraordinarily ambitious for the computers and software-development practices of the period. Bell Labs became dissatisfied with the project’s progress and withdrew in 1969. Its researchers no longer had Multics, but they had gained experience with both the possibilities and difficulties of building an interactive, multi-user computing environment.
Ken Thompson was one of the Bell Labs researchers who had worked with Multics. After Bell Labs withdrew, he continued experimenting with operating-system ideas on a much smaller DEC PDP-7. The machine was considerably more limited than the hardware intended for Multics, which forced a different scale of development. Rather than attempting to reproduce the larger system, Thompson began assembling the pieces of a useful computing environment on the hardware available to him.
Dennis Ritchie soon became another central contributor, along with other researchers at Bell Labs. The new system acquired a filesystem, processes, a command interpreter, utilities, and the ability to support multiple users. Many of these concepts were not unique to UNIX, and some reflected lessons learned from Multics and other time-sharing systems. What distinguished the emerging system was the particular way those pieces were assembled into a comparatively small and practical operating environment.
The relationship with Multics even appeared in the new system’s name. The earliest name, Unics, was a play on Multics. The spelling eventually became UNIX, and the joke became the name of an operating system that would develop far beyond the PDP-7 on which its earliest form had been assembled.
The PDP-7 system demonstrated the idea, but UNIX did not remain an experiment on obsolete hardware. Bell Labs acquired a DEC PDP-11, and UNIX development moved to the newer machine. The system continued to gain capabilities as it began supporting work within Bell Labs, giving its developers a practical reason to improve an operating environment that people were actually using.
UNIX was not designed once and then released as a finished operating system. It grew through use. Researchers added capabilities as they encountered problems to solve, while the system itself provided an environment in which they could build additional tools. Features that would later be recognized as characteristic of UNIX developed over time rather than appearing together in a single original design.
Many of the commands used by UNIX and UNIX-like operating systems are separate programs rather than functions built into the operating system itself.
By the early 1970s, UNIX had moved beyond its beginning as Thompson’s PDP-7 project. It was becoming a practical multi-user operating system and a development environment in its own right. The next question is what kind of operating environment UNIX had become—and which characteristics would allow it to move beyond Bell Labs and eventually develop into an entire family of systems.
By the early 1970s, UNIX had become more than a small operating-system experiment. It provided an environment in which multiple users could run programs, organize files, communicate with the system through a command interpreter, and combine programs to perform more complicated work. Many of these capabilities existed elsewhere, but UNIX brought them together in a form that could grow while remaining comparatively understandable.
UNIX is not defined by a single feature. Multi-user computing existed before UNIX. Hierarchical filesystems existed before UNIX. Command-line interfaces, processes, and eventually networking were not unique to it either. What became characteristic of UNIX was the way these mechanisms worked together and the operating model that developed around them:
UNIX grew from the time-sharing tradition, so multiple users were part of its environment from early in its development. Each user could have an identity, own files, run programs, and work within the same computer while the operating system managed the resources underneath them. Rather than treating the computer as belonging to whichever person happened to be sitting in front of it, UNIX assumed that the system itself might be shared.
Processes extended that model to running programs. The operating system could keep track of multiple processes and allocate processor time among them, allowing more than one program to make progress without requiring one program to finish before another could run. Users could interact with their own programs while other users and system processes were doing work on the same machine.
Ownership and permissions helped make that sharing manageable. Files and directories could belong to users and groups, with permissions controlling who could read, modify, or execute them. These mechanisms were not merely security features added to a single-user computer. They were part of operating a system in which different people and processes were expected to coexist.
That assumption would become increasingly useful as computers became networked. UNIX did not need networking to make multi-user operation relevant; it already came from a world of shared computing. Networking would eventually provide additional ways for users and systems to reach those shared resources.
UNIX also used the filesystem as an abstraction for more than ordinary data. Ordinary data was stored in files arranged within a hierarchical directory structure, but the file interface could represent more than documents and program data. Devices could also be exposed through file-like interfaces, allowing programs to interact with hardware using many of the same operations they used when working with ordinary files.
This did not mean that everything inside UNIX literally worked the same way. Different devices and system resources still had different capabilities and underlying implementations. UNIX could provide a relatively small set of common interfaces instead of requiring every program to understand every device independently.
The result was an operating environment in which programs could often concentrate on reading input, transforming it, and producing output while the system handled where that input came from or where the output went.
The UNIX shell provided the command environment through which users interacted with the system. Rather than requiring every command to be implemented as a permanent part of the shell or operating-system kernel, many commands were independent executable programs. When a user entered a command, the shell could locate the corresponding program, start it as a process, and connect it to the appropriate input and output.
That separation made the command environment extensible. Adding a new utility did not necessarily require changing the shell or rebuilding the operating system. A program that followed the expected conventions could become another tool available from the command line.
The shell itself could then provide mechanisms for connecting those tools. Redirection allowed input and output to come from files instead of the terminal. Pipes went further by allowing the output of one program to become the input of another.
This ability to compose programs became one of the most recognizable characteristics of UNIX. Instead of requiring one large program to anticipate every possible operation, smaller utilities could perform focused transformations and be connected when a more complicated task was required.
Consider three familiar UNIX tools: grep, sed, and awk. Each is useful independently, but they can also participate in a pipeline:
grep "error" system.log | sed 's/^/LOG: /' | awk '{print $1, $2, $3}'
The command can be read from left to right:
grep searches system.log and outputs lines containing error.|) sends those lines to sed instead of displaying them on the terminal.sed adds LOG: to the beginning of each matching line and sends the result onward.awk.awk prints the first three whitespace-separated fields from each resulting line.None of these programs needs to know that the others exist. grep produces text. sed receives text, transforms it, and produces text. awk receives that text and performs another operation. The shell connects them.
A user can construct a new operation from existing programs without modifying any of them. Programs become building blocks, while standard input, standard output, and pipes provide conventions through which those blocks can work together.
The often-repeated idea that UNIX programs should do one thing well is a useful description of this style, but it should not be mistaken for a complete specification handed down with the first version of UNIX. UNIX developed over time, and so did the tools, conventions, and philosophy associated with it. What matters here is the operating pattern that emerged: programs could remain relatively independent while common interfaces allowed them to participate in larger workflows.
One of the most consequential characteristics of UNIX was not something a user necessarily saw at the command line. Early UNIX was written in assembly language for the PDP hardware on which it ran. During the early 1970s, Dennis Ritchie developed the C programming language, and UNIX was subsequently rewritten largely in C.
Operating systems were commonly written substantially in assembly language because systems software needed direct access to the underlying machine. Assembly provides that access, but instructions written for one processor generally cannot simply be moved to another architecture. An operating system written primarily for a particular processor carries a substantial hardware dependency.
C did not make hardware differences disappear. Some portions of an operating system still needed architecture-specific implementations, and a C compiler had to exist for the target machine. What changed was how much of UNIX had to be rewritten when the operating system moved.
Much of the system could now be expressed in a language that was not itself tied to one processor’s instruction set. Porting UNIX to another architecture could concentrate more heavily on the machine-dependent portions while retaining much of the operating system above them.
Rewriting UNIX largely in C helped separate the operating system from the hardware on which it had been created.
This portability would have consequences far beyond making UNIX easier to maintain. An operating system that could move between different kinds of computers could also move between organizations. As UNIX left its original hardware and spread beyond Bell Labs, new groups would encounter the system, modify it for their own purposes, and eventually carry its development in different directions.
Portability made it possible for UNIX to move between computers, but hardware was only part of the story. UNIX also began moving between organizations. Universities were particularly important because they provided environments where researchers and students could study the system, modify it, and use it as a foundation for additional work.
AT&T’s position in the regulated telephone industry shaped how this happened. Bell Labs could develop software for its own purposes, but AT&T faced restrictions on entering other commercial markets. Rather than initially treating UNIX as a conventional commercial software product, AT&T licensed the system to universities, government organizations, and other institutions. Academic licenses could include source code, giving researchers an unusual opportunity to examine and change a working operating system.
UNIX began reaching universities during the early 1970s. For computer-science departments, access to the source code was particularly valuable. Students and researchers could do more than learn how to operate the system. They could examine how an operating system was constructed, modify it, develop new utilities, and adapt it to the equipment and research taking place around them.
Bell Labs remained an important center of development, but it was no longer the only place where UNIX was being used and changed. Improvements could emerge from institutions with different hardware, different research interests, and different problems to solve.
Portability reinforced that spread. Because much of UNIX was written in C, moving the system to another computer did not necessarily mean beginning again from assembly language. UNIX could reach additional hardware while carrying much of the same operating environment with it.
Portability allowed UNIX to move between computers. Source availability allowed people outside Bell Labs to understand and change what moved with it.
One of the most important destinations was the University of California, Berkeley. UNIX arrived there in the 1970s, where faculty and students began modifying and extending the system. Those additions eventually became substantial enough to be distributed as the Berkeley Software Distribution, or BSD.
BSD did not begin as an independently created replacement for UNIX. It grew from AT&T UNIX while adding software and changes developed at Berkeley. As those distributions continued to evolve, Berkeley became one of the major centers of UNIX development.
That work included improvements to the operating environment, performance, utilities, and eventually networking. BSD became more than a collection of convenient additions. It developed into a major UNIX lineage whose work would influence other UNIX systems and whose descendants would continue independently.
Networking became one of the areas in which Berkeley’s UNIX work proved particularly important. During the development of BSD, researchers incorporated and developed support for the TCP/IP protocol suite and created the sockets programming interface that applications could use to communicate across networks.
BSD did not invent TCP/IP, and UNIX had not originally been created around TCP/IP networking. The significance was the combination. A portable, multi-user operating environment was gaining a practical networking implementation and programming interface at a time when computer networks were becoming increasingly important.
Many of UNIX’s existing assumptions continued to make sense as interaction expanded beyond a single computer. Processes could provide network services. Users could connect remotely. Permissions could control access to shared resources. Small programs could communicate through established interfaces while networking provided another way for computers and users to reach one another.
Networking did not make UNIX relevant. Networking made a set of assumptions UNIX already possessed increasingly useful.
Networking did not make UNIX relevant. Networking made a set of assumptions UNIX already possessed increasingly useful.
Berkeley was important, but UNIX development had not simply moved from Bell Labs to a university. AT&T continued developing UNIX as well. Other universities, research organizations, and eventually computer vendors also adapted UNIX to their own hardware and requirements.
That meant UNIX was beginning to develop in more than one direction at the same time. Changes made in one branch could influence another, but the systems did not remain identical. Different organizations had different priorities, release schedules, hardware, and users.
The portability that had allowed UNIX to spread had another consequence. Once UNIX could move between machines and organizations, the people receiving it could take it somewhere new. The next stage of UNIX history would not be the development of a single system, but the emergence of distinct branches.
Once UNIX could move between machines and organizations, the people receiving it could take it somewhere new.
As UNIX spread, development no longer occurred within a single organization. Bell Labs continued developing the system, Berkeley built increasingly substantial distributions from it, and computer manufacturers adapted UNIX to their own hardware. These systems shared ancestry and continued exchanging ideas and technology, but they did not remain identical.
Two lineages became particularly important to the history that followed. BSD developed from the UNIX work taking place at Berkeley, while AT&T continued developing the original Bell Labs lineage toward what became UNIX System V. The distinction was never completely clean: technology moved between the branches, and later systems could incorporate substantial work from both. Still, BSD and System V provide useful reference points for understanding how UNIX developed into a family.
The Berkeley Software Distribution began as additions to an existing AT&T UNIX system. Early BSD releases included software developed at Berkeley rather than constituting an entirely separate operating system. As Berkeley continued its work, however, BSD accumulated increasingly substantial changes to the underlying system.
Berkeley’s work included new utilities, improvements to the filesystem and virtual-memory system, performance work, and the networking development discussed earlier. BSD developed characteristics that distinguished it from the UNIX releases continuing through AT&T, even though the two remained historically connected.
BSD also demonstrated what could happen when UNIX spread through universities. Researchers were not limited to writing applications that ran on top of an operating system supplied by someone else. With access to UNIX source code, they could change the operating system itself. A university distribution could become the basis for further research and, eventually, another major branch of UNIX development.
Development also continued within Bell Labs and AT&T. Research UNIX progressed through a series of editions, with Version 7 UNIX, released in 1979, becoming an especially important point in the family tree. Version 7 was widely distributed and became an ancestor of several later UNIX systems.
AT&T’s own development moved beyond the numbered Research UNIX editions. UNIX System III appeared in the early 1980s, combining work from several internal AT&T UNIX efforts. It was followed by UNIX System V, which became the principal commercial AT&T UNIX lineage.
System V continued through several major releases and became an important foundation for commercial UNIX. Computer manufacturers could license UNIX, adapt it to their hardware, and add the features needed for their customers and markets. UNIX was becoming not only a research and academic family, but also the basis for commercial operating systems tied to particular vendors and computer platforms.
As computer manufacturers adopted UNIX, the family grew wider. Vendors had reasons to provide an operating environment that customers could recognize while still adapting that environment to their own processors, workstations, minicomputers, and larger systems.
IBM developed AIX. Hewlett-Packard developed HP-UX. Sun Microsystems developed SunOS, initially with strong BSD ancestry, and later Solaris, which incorporated the System V lineage while retaining important BSD-derived technology. The Santa Cruz Operation developed commercial UNIX systems for increasingly important microcomputer hardware. Other vendors and organizations produced their own implementations as well.
These systems could differ substantially while still belonging to the broader UNIX family. They might use different hardware architectures, administration tools, filesystems, utilities, or combinations of BSD and System V technology. Software written for one UNIX system could not automatically be assumed to compile or behave identically on every other UNIX.
The name UNIX described something increasingly complicated. It could refer historically to the operating system developed at Bell Labs, to systems descended from that source, or more broadly to an operating tradition shared across a growing collection of implementations. Later standards and trademark requirements would provide more precise meanings, while systems designed to behave similarly without sharing UNIX ancestry would commonly be described as UNIX-like.
Branching did not mean the different UNIX lineages stopped interacting. BSD and AT&T development influenced one another, and vendors incorporated technologies that originated elsewhere in the UNIX world. A feature developed in one branch could prove useful enough to appear later in another.
This makes UNIX history difficult to represent as a simple sequence. A family tree can show where systems descended from earlier systems, but it cannot cleanly represent every piece of code, interface, utility, or idea that moved between them. Those exchanges are part of the history, but they are different from descent.
The distinction will matter when we build the UNIX family tree later in this article. The tree will follow where systems came from, while the surrounding history explains why related branches could continue learning from and borrowing from one another.
UNIX had reached a very different position from the small PDP-7 system developed at Bell Labs. Portability had allowed it to cross hardware boundaries. Licensing and source availability had allowed it to cross organizational boundaries. Once different groups began changing UNIX for their own purposes, those movements produced something more enduring than a series of ports: they produced a family.
Portability had allowed UNIX to cross hardware boundaries. Licensing and source availability had allowed it to cross organizational boundaries.
By the late 1980s and early 1990s, UNIX had become difficult to describe as though it were still a single operating system. Different branches shared ancestry, exchanged technology, and retained enough similarities to remain recognizably related, while vendors and research groups continued developing their own implementations. The result could be complicated even for people who worked with computers.
An old computer-industry joke imagined operating systems as airlines. UNIX Express had its passengers arrive carrying pieces of an airplane and tools. They argued about what they were building, split into groups, and ultimately produced several different aircraft bearing the same name.
The joke worked because people could picture it. UNIX had begun as one operating system, but portability and continued development had allowed different groups to carry pieces of that system in different directions. By following the major lines of descent, those relationships become easier to see.
A UNIX family tree can quickly become difficult to read. UNIX systems did not develop as completely isolated branches. Code, utilities, interfaces, and ideas moved between implementations, and some later systems incorporated substantial work from more than one part of the UNIX family.
The tree below has a narrower purpose: it shows descent. It does not attempt to document every exchange of code, feature, standard, or idea between UNIX systems. Where multiple lines of descent are important enough that placing a system beneath only one parent would be misleading, the relationship is broken into a smaller tree rather than duplicating the same descendants in several places.
The earliest part of the tree begins with the UNIX editions developed at Bell Labs. The first several editions remained closely associated with the PDP-11, while Version 6 became particularly important because it spread widely outside Bell Labs. Version 7 followed in 1979 and became one of the major ancestors of the UNIX systems that followed.
Research UNIX
│
├── First Edition (1971)
│ └── Second Edition
│ └── Third Edition
│ └── Fourth Edition
│ └── Fifth Edition
│ └── Version 6 (1975)
│ ├── Version 7 (1979)
│ │ └── UNIX/32V
│ │
│ └── 1BSD
│ └── 2BSD
│
└── later Research UNIX editions
The apparent split between Version 7 and the early BSD releases needs some explanation. 1BSD was not originally a complete replacement operating system. It was a collection of Berkeley software added to Version 6 UNIX. The BSD lineage became increasingly independent as Berkeley continued developing it.
Version 7 also led to UNIX/32V, a Bell Labs port for the DEC VAX. UNIX/32V becomes particularly important because Berkeley used it as part of the foundation for the next stage of BSD.
Berkeley combined the VAX-based UNIX/32V system with the software it had been developing through the earlier BSD releases. The result was 3BSD, a complete VAX operating system that included Berkeley’s virtual-memory work and the utilities developed through the earlier BSD lineage.
That gives 3BSD two useful lines of descent to show:
UNIX/32V ──┐
├── 3BSD
2BSD ──────┘
│
└── 4BSD
└── 4.1BSD
└── 4.2BSD
└── 4.3BSD
This is where BSD becomes one of the major branches of the UNIX family rather than simply a collection of additions distributed for an existing UNIX installation. Later BSD development would continue beyond 4.3BSD, but those descendants deserve their own treatment when we follow the BSD family in greater depth.
Several commercial UNIX systems also grew from the BSD side of the family. SunOS was strongly BSD-derived, while Digital Equipment Corporation’s Ultrix was based primarily on BSD while incorporating some System V features.
4BSD / 4.xBSD
│
├── SunOS
│
└── 4.2BSD
└── Ultrix
Those systems also show why the tree does not attempt to include every influence. Ultrix incorporated System V features, and SunOS would later participate in development that crossed the BSD and System V branches. Those relationships matter, but they are not the same thing as simply identifying a parent and descendant.
Version 7 also contributed to the commercial UNIX lineage developed by AT&T. UNIX System III combined several internal AT&T UNIX developments, including Version 7 and UNIX/32V, into a system intended for distribution outside Bell Labs. System III was followed by UNIX System V in 1983.
The resulting line became one of the major commercial trunks of the UNIX family:
Version 7 UNIX ──┐
├── UNIX System III
UNIX/32V ────────┘
│
└── UNIX System V
├── SVR2
├── SVR3
└── SVR4
System V became the basis for numerous commercial UNIX implementations. Rather than every customer running an identical AT&T operating system, vendors could adapt the System V codebase to their own hardware and products.
Among the important descendants were HP-UX, AIX, and SCO UNIX. Their exact histories contain influences and additions from elsewhere in the UNIX family, but their primary commercial ancestry can be followed through System V.
UNIX System V
│
├── SVR2
│ └── HP-UX
│
└── SVR3
├── AIX
└── SCO UNIX
The Santa Cruz Operation had already become important in microcomputer UNIX through its work with Xenix before releasing SCO UNIX, a System V Release 3.2-based UNIX for Intel hardware.
System V Release 4 illustrates why UNIX descent eventually becomes more complicated than a single vertical tree. AT&T and Sun Microsystems worked together on SVR4, combining the System V lineage with substantial technology from BSD, SunOS, and Xenix.
For purposes of descent, SVR4 remains part of the System V line:
UNIX System V
│
├── SVR2
│
├── SVR3
│
└── SVR4
But the history behind that branch includes several already-established parts of the UNIX family:
System V ──┐
BSD ───────┤
SunOS ─────┼── SVR4
Xenix ─────┘
SVR4 provides a useful example of the difference between a family tree and the complete history of UNIX development. The first tree tells us where the release belongs. The second shows why describing its ancestry requires acknowledging more than one established branch.
Sun Microsystems subsequently moved from its BSD-derived SunOS foundation to the SVR4-based system marketed as Solaris. The family tree crosses between the previously separate branches again here.
SVR4 ──────┐
├── Solaris
SunOS ─────┘
These diagrams deliberately leave out many UNIX releases and implementations. Their purpose is not to catalog every system that has carried UNIX code or behaved like UNIX. They document the major lines of descent needed to understand how the operating system developed from the Bell Labs editions into BSD, System V, and the commercial UNIX systems surrounding them.
They also do not include every operating system described as UNIX-like. An operating system can reproduce UNIX interfaces, conventions, or behavior without descending from the original UNIX source code. Descent and compatibility are different relationships, and treating them separately keeps the history clearer.
UNIX became a family not because every branch remained the same, but because different systems continued developing from shared ancestry.
About the family tree: These diagrams were assembled primarily from the histories presented across Wikipedia’s UNIX-related articles, with major dates and branch points checked against The Open Group’s UNIX history. They focus on lines of descent rather than every exchange of code, features, standards, or ideas between systems. Complex relationships have been divided into smaller diagrams where doing so makes the ancestry easier to follow.
UNIX began as a comparatively small operating system developed at Bell Labs after the laboratory withdrew from the much more ambitious Multics project. What began on a PDP-7 grew into a practical multi-user operating environment with processes, a hierarchical filesystem, a shell, independent utilities, and conventions that allowed those tools to work together. Rewriting much of UNIX in C then helped loosen the connection between the operating system and the particular hardware on which it had been created.
Portability allowed UNIX to move to new computers, while licensing and access to source code allowed it to move into universities and other organizations. Researchers could study the operating system, modify it, and build upon it rather than treating it as an inaccessible layer beneath their applications. Berkeley became particularly important through BSD, including networking work that helped make UNIX increasingly useful as computers themselves became more connected.
That spread also meant UNIX no longer developed along a single path. Bell Labs and AT&T continued their own lineage, Berkeley developed BSD, and commercial vendors adapted UNIX to different machines and markets. Those branches continued exchanging technology even as they became increasingly distinct. UNIX had changed from one operating system developed for a particular environment into a family of related operating systems with shared ancestry.
The UNIX family grew from many of the same characteristics that made the original system successful. It could move between hardware, be adapted to different purposes, and provide a recognizable operating environment even as individual implementations changed. The result was not one UNIX frozen in time, but a collection of related systems whose common ancestry remained visible even as their branches continued developing in different directions.
]]>That distinction creates a problem for the computer classifications we have been using throughout this series. Mainframe, minicomputer, microcomputer, and supercomputer are useful categories because they describe real differences in architecture, scale, cost, access, and intended use. For much of computing history, those characteristics were also closely connected to what a computer was expected to do.
Networking began to weaken that relationship. A computer could still be classified according to its hardware and architecture, but those characteristics no longer necessarily described its function within a larger system. Two computers built around similar hardware could perform very different jobs depending upon their operating systems, software, configuration, and relationship to other computers.
The older classifications did not disappear. Instead, another way of understanding computers became increasingly important. We could still ask what kind of computer a machine was, but we also needed to ask what role it performed.
The computer classifications discussed earlier in this series developed because hardware, economics, and use were closely related. A computer’s architecture and resources placed practical limits on what it could do, while its cost helped determine who could afford to own and operate it. Those constraints contributed to recognizable classes of computers that tended to be used in recognizable ways.
Knowing that a system was a mainframe, minicomputer, microcomputer, or supercomputer told us more than what hardware it contained. The classification also suggested who used the machine, how it was operated, and what kinds of work it was likely to perform.
Mainframes were expensive centralized systems designed to support institutional workloads and many users. Minicomputers brought shared computing into departments, laboratories, businesses, and smaller organizations. Microcomputers reduced the scale further, placing relatively inexpensive computing resources directly in front of an individual user. Supercomputers followed a different path by concentrating substantial resources on specialized computational workloads.
These distinctions involved more than raw performance. Each class represented a combination of characteristics that influenced how the machine could reasonably be used:
A machine’s class also carried expectations about its function. A personal computer was generally expected to serve the person sitting in front of it. A mainframe or minicomputer provided computing resources to multiple users. A supercomputer performed computational work that justified its specialized architecture and expense.
These classifications were never absolute. Their boundaries changed as technology improved, and individual systems did not always fit neatly within them. A powerful microcomputer could overlap with the capabilities of lower-end minicomputers, while newer generations of smaller machines could outperform older systems from supposedly larger classes.
That overlap did not make the categories useless. Hardware characteristics and operational function remained closely related enough that the classification provided a reasonable starting point for understanding the system.
Networking made that starting point less complete. A computer no longer needed to contain all of the resources used by the person sitting in front of it, and the resources contained within a computer no longer needed to be used only by that person.
The workstation illustrates this transition particularly well. It provided substantial computing resources directly to an individual user while commonly operating as part of a larger networked environment. Computing could occur locally without requiring the machine to remain operationally isolated.
The workstation combined characteristics of two earlier computing models. It retained the local independence associated with the microcomputer while taking advantage of shared resources traditionally associated with larger systems.
A traditional terminal primarily provided an interface to computing resources located elsewhere. The processor, programs, storage, and operating environment belonged to the central system. The terminal allowed the user to interact with those resources but did not normally provide an independent general-purpose computing environment of its own.
A workstation did. It contained its own processor, memory, storage, operating system, and applications. A user could perform substantial work without sending every operation to another computer.
In this respect, the workstation shared an important characteristic with the personal computer. Meaningful computation happened locally.
The workstation, however, was commonly intended to participate in a network. Files might reside locally or on another machine. Printers could be shared. Data could be retrieved from remote systems. Programs could execute locally while relying upon resources provided elsewhere.
The difference can be summarized through four general models:
The boundaries between these models were not absolute. What mattered was that networking allowed local and shared computing to coexist within the same environment.
These models describe where computing resources are located and how they are used. They do not necessarily describe four different kinds of hardware.
Workstations from companies such as Sun, Apollo, DEC, HP, and SGI formed a recognizable market. They often provided hardware and capabilities that distinguished them from ordinary personal computers of the same period, so workstation could legitimately describe a class of computer.
At the same time, the term said something about how the machine was used. A workstation provided an individual computing environment while remaining part of a larger networked system.
As personal-computer hardware became more capable, the distinction became less obvious. PC-compatible machines increasingly performed work that had previously justified specialized workstation hardware. The hardware still mattered, but hardware alone was becoming less useful for determining the machine’s place within the larger system.
A standalone personal computer primarily provides resources to its local user. Its processor executes that user’s programs, its storage contains the user’s files, and its peripherals exist primarily for that user’s use. The machine can perform many different kinds of work, but its operation remains centered upon the person sitting in front of it.
Networking allows those resources and functions to cross machine boundaries. The physical location of a resource no longer needs to correspond with the physical location of the person using it.
A file does not necessarily need to reside on the user’s local disk. A printer does not need to be attached directly to the computer sending it a document. Applications and databases can operate on another system. Authentication and other shared functions can be provided centrally.
Functions can be divided among machines:
The network becomes more than a connection between otherwise independent computers. The machines begin forming a larger computing system in which resources can be provided and consumed across computer boundaries.
A PC-compatible machine might sit on someone’s desk and operate primarily as an individual’s computer. Another machine based upon similar hardware might sit elsewhere and provide files, applications, or other resources to everyone on the network.
The underlying hardware lineage has not necessarily changed. The job assigned to the machine has.
The hardware may remain substantially the same while the machine’s role changes.
The server role discussed in the previous article illustrates the same change from another direction. If server describes a role rather than a fundamental hardware class, knowing the hardware class alone cannot tell us whether a particular machine is acting as a server.
Terms such as client, workstation, file server, print server, and database server describe computers according to what they do and how they relate to other computers.
That differs from describing a system as a microcomputer, minicomputer, mainframe, or supercomputer. Those classifications tell us something about the machine itself. Operational roles tell us something about its function within a larger computing environment.
The same computer can be described in both ways. It belongs to a hardware lineage while also performing one or more operational roles.
Hardware places limits on what a computer can do, but hardware capability alone does not determine how effectively a machine can perform a particular role. The operating system determines how the processor, memory, storage, processes, users, and network connections are managed. As PC hardware became increasingly capable, the operating environment became an important part of determining how that hardware could be used.
PC operating systems provide a useful example.
MS-DOS reflected the personal-computer environment from which it emerged. Its operating model assumed one person using one computer, with programs and resources primarily located on that machine.
DOS computers could participate in networks. Network software allowed them to communicate with other systems and access shared resources, and specialized software could make PC hardware provide resources to other machines. Networking itself was not the problem.
DOS had not been designed around the multi-user and multitasking environment traditionally associated with systems providing shared services. A capable PC might possess the processor, memory, storage, and network interface needed for a particular role while its operating environment made that role difficult to implement effectively.
Hardware capability does not guarantee that the operating environment is well suited to every role the hardware could theoretically perform.
The first generations of Microsoft Windows 1.x, 2.x, and 3.x did not replace DOS. They provided a graphical and increasingly capable environment that operated with DOS underneath it. They expanded how the personal computer could be used, but they remained connected to an operating model that originated with the standalone PC.
Windows 95, 98, and Me moved considerably further. Windows increasingly appeared to the user as the operating system itself, while networking, multitasking, hardware support, and resource sharing became normal parts of the environment. These systems could participate effectively in networks and provide some resources to other machines, but they still retained substantial architectural ties to DOS and the earlier Windows lineage.
Windows NT represented a different approach. Rather than continuing the DOS architecture, NT was designed as an independent operating system with preemptive multitasking, protected memory, user accounts, security, networking, background services, and support for workstation and server operation. Its early POSIX subsystem also reflected an effort to support established operating-system standards beyond the DOS and Windows environment.
The distinction became visible even in Microsoft’s product names. Windows NT Workstation and Windows NT Server used closely related operating-system technology on PC-derived hardware while explicitly identifying different intended roles.
Windows NT Workstation and Windows NT Server made the distinction visible in their names: closely related technology could be configured around different operational roles.
UNIX did not emerge from this development of DOS and Windows. It belonged to the older world of shared computing that we examined earlier in this series.
UNIX developed in the world of shared computing, initially on minicomputer hardware, and spread across larger systems and technical workstations. Multi-user operation, simultaneous processes, permissions, shared resources, and remote access were not additions to a personal-computer model. They were part of an operating tradition that had developed while computing resources were commonly shared among users.
As hardware became smaller, faster, and less expensive, that operating model could move with it. UNIX systems appeared on workstations, BSD-derived systems became available on increasingly accessible hardware, and Linux eventually brought a UNIX-like operating environment directly into the rapidly expanding world of PC-compatible machines.
While Microsoft was developing its own operating-system lineage, UNIX and UNIX-like systems were moving onto increasingly accessible hardware. Different operating traditions could now operate on similar classes of machines.
Microcomputer-derived hardware was moving upward in capability while an operating model developed for shared computing was moving onto smaller and less expensive machines. Networking gave those developments a place to meet.
Why UNIX fit this environment so naturally is a larger question. For now, its movement onto increasingly accessible hardware demonstrates how far the relationship between hardware class and operational function had changed.
The older computer taxonomy had not disappeared. A mainframe remained different from a PC-compatible computer, and a supercomputer remained different from a workstation. Those classifications continued to describe meaningful architectural and practical differences.
They no longer described the whole system.
Networked computing increasingly required looking at a system in layers. The physical hardware remained one part of the system, while the operating environment determined how that hardware was managed. Above that, applications and services determined what the computer actually provided, while the network defined how those functions became available to other systems. Each layer described something different, but all of them contributed to the behavior of the computer as a whole.
| Layer | What It Helps Describe |
|---|---|
| Hardware classification | What kind of physical and architectural system the computer is |
| Operating environment | How hardware, processes, users, storage, and networking are managed |
| Operational role | What functions the computer performs |
| Network relationship | Which resources the computer provides to or consumes from other systems |
These layers interact. Hardware constrains which operating systems and workloads are practical. The operating system manages capabilities that allow the machine to perform particular roles. Those roles help determine how the computer participates in the network around it.
Hardware describes the machine. The operating environment manages its capabilities. Operational roles describe what it does. Network relationships describe how those functions connect it to other systems.
Operational roles do not necessarily correspond one-to-one with physical machines. A computer might provide file storage while also handling authentication, printing, or remote access. Another might function as someone’s workstation while simultaneously making some of its own resources available to other computers.
Calling a machine a server does not necessarily tell us that it performs only one function. It tells us that at least some of its resources or services are being provided for use elsewhere.
The same applies in the other direction. A workstation can consume network services while still providing substantial local computing resources. Client and server describe relationships that can coexist with other descriptions of the same machine.
Role does not erase differences between hardware classes. A PC-compatible computer and a mainframe might both provide applications, storage, or other services to users without becoming equivalent systems.
Their architectures, capacities, reliability characteristics, I/O capabilities, and expected scales can remain substantially different. What they share is a function within their respective environments.
Hardware classification and operational role answer different questions. One describes the machine. The other describes what that machine is doing.
The emergence of operational roles does not make hardware irrelevant. Processor performance, memory capacity, storage, I/O bandwidth, reliability, expandability, and architecture continue to place practical limits on what a system can reasonably accomplish.
A PC providing files to several users does not become equivalent to a mainframe merely because both machines are acting as servers. Likewise, calling two systems workstations does not imply that their capabilities are identical. Operational role describes function, not equivalence.
Hardware tells us what kind of machine we have. The operating environment helps determine what that machine can do. Operational role tells us what it is doing within the larger system.
These descriptions become increasingly useful together because networked computers are no longer understandable solely as isolated physical machines.
Earlier computer classifications encourage us to begin with the machine. We examine its architecture, resources, scale, and capabilities and use those characteristics to understand what kind of computer it is. That perspective remains useful, but networking requires us to widen the frame.
A networked computer exists in relation to other computers. It may provide resources, consume resources, or do both. Its local hardware matters, but so do its operating system, software, configuration, and connections. Understanding the machine increasingly means understanding its place within the system around it.
We can still ask, What kind of computer is this? But that question is no longer sufficient by itself. We must also ask what the computer does, which resources it provides, which resources it consumes, and how it interacts with the other systems around it.
This is one consequence of the transition from isolated personal computers to networked computing. Mainframes, minicomputers, microcomputers, and supercomputers remain useful classifications, but networking adds another perspective.
The computer is both a machine and a participant in a larger computing system.
Traditional computer classifications developed because architecture, scale, economics, and expected use were closely related. Mainframes, minicomputers, microcomputers, and supercomputers described more than physical machines; the categories also suggested how those machines would normally be operated and what kinds of work they would perform.
Workstations and networked personal computers began weakening that connection. A computer could possess substantial local resources while also consuming resources from other systems, and increasingly similar hardware could be configured for very different purposes. The machine’s place within the network became another important part of understanding what the computer was doing.
Operational role became an additional way of describing computers rather than a replacement for the older taxonomy. Hardware classification describes characteristics and lineage of the machine, while operational role describes what that machine does within a larger system. The operating system sits between those ideas, helping determine which roles the available hardware can effectively perform.
That relationship brings us to another development in networked computing. If similar hardware can perform very different roles depending partly upon its operating environment, then the design of the operating system becomes increasingly important. UNIX and the systems derived from its model were particularly well suited to this environment, bringing ideas developed for shared multi-user computing into a world increasingly built from networked computers.
]]>Earlier in this series, we looked at mainframes, minicomputers, and microcomputers as distinct approaches to computing. Mainframes provided shared computational resources to large numbers of users, while minicomputers brought many of those capabilities to departments and smaller organizations. The microcomputer changed that arrangement by placing the processor, memory, storage, applications, and peripherals directly in front of an individual user. Computing became increasingly personal and decentralized, but organizations still needed many of the shared resources that mainframes and minicomputers had provided.
Networking gave those functions a way to return on new hardware. Shared files could reside on one computer, printing could be handled by another, and applications or databases could be made available across the network. Instead of concentrating every shared function in one larger computer, a network of microcomputers could divide those responsibilities among several machines. Shared organizational computing was re-emerging, but its functions could now be distributed by role.
This is where the server begins to emerge as a role rather than another class of computer. A machine built from the same basic hardware as the personal computers around it could provide files, applications, databases, or other resources to the network. As those roles became more demanding, the machines performing them would gain more memory, storage, processing power, and eventually hardware designed specifically for reliability and continuous operation. The shared functions once associated with much larger computers had not disappeared. They were beginning to take new forms on descendants of the microcomputer.
The move toward personal computing changed where computation happened, but it did not eliminate the problems shared computers had been solving. Organizations still needed common data, shared applications, centralized storage, access to expensive peripherals, and ways for multiple users to work with the same resources. Those requirements existed before the microcomputer and continued after computers began appearing on individual desks.
Mainframes addressed these needs by concentrating substantial computing resources in a central system shared by many users. Processing, storage, applications, and access to organizational data could all be managed in one place. Administration was concentrated there as well. Users might interact with the computer through terminals, but the important resources remained under the control of the central machine.
Minicomputers brought a similar model to a smaller scale. A department, laboratory, university group, or smaller organization could operate a shared computer without requiring the scale and expense of a mainframe installation. Multiple users could still share applications, files, processing capacity, and peripherals.
This placed the minicomputer particularly close to territory that network servers would later occupy. The hardware would change considerably, but the need for departmental and organizational resources shared among multiple users would remain.
The arrival of the microcomputer did not cause organizations to immediately abandon their mainframes and minicomputers. Those systems already held applications and data they depended upon, and they continued to provide capabilities that early personal computers could not easily replace. For many organizations, the first step was connecting the new machines to the larger computers already in use.
A PC could take the place of a dedicated terminal while still accessing applications and data running on a mainframe or minicomputer. Terminal emulation and other connectivity software allowed the personal computer to perform its own local work while providing access to existing shared systems. Mainframes, minicomputers, and PCs could coexist in the same computing environment for years.
I saw this overlap firsthand in 1995, when I worked in a college computer lab. The college had two labs filled with PCs, but in the corner was still a VAX terminal used by the administrators. The PCs had clearly become the everyday computers for the students, but that did not mean every function of the older system had moved with them.
As networking among microcomputers matured, that relationship began to change. Local networks increasingly allowed PCs to share files, printers, applications, and other resources among themselves. Mainframes and minicomputers remained important, but some of the responsibilities that had kept them at the center of organizational computing could now move onto networks of smaller machines.
Mainframes and minicomputers represented recognizable classes of computer, but shared storage, multi-user applications, common data, and centralized administration were functions rather than properties of a particular kind of hardware. Those machines had been the practical way to provide them. As microcomputers and their networks became more capable, the functions could move to new hardware without disappearing.
The microcomputer gave individual users computing resources of their own. Instead of connecting to a larger shared system, a user could have a processor, memory, storage, applications, display, keyboard, and peripherals sitting on a desk. As these machines became more capable, more work could be performed locally without depending on a central computer.
This independence was one of the great strengths of personal computing. A program running slowly or failing on one computer did not necessarily affect everyone else. Users could install different software, store their own files, and configure the machine for their own needs. Organizations could also add computers incrementally rather than concentrating all of their computing capacity in a single large system.
For the individual user, this represented a significant change. Processing and storage were no longer resources that had to be requested from a shared system. Much of the computing environment was sitting on the desk and belonged, at least operationally, to the person using it.
Putting those resources on individual desks also scattered things that had previously been kept together. As personal computers spread through an organization:
These were consequences of distributing resources that had previously been concentrated within shared systems. Personal computing provided independence, but that independence came with a new kind of isolation.
Local networks provided a way around some of that isolation. Once the machines were connected, resources distributed onto individual desks could begin to be shared again. The microcomputer had pulled computing apart; the network provided a way to put some of those pieces back together without giving up the individual computers themselves.
Once microcomputers were connected, a resource no longer had to reside on the computer that used it. Files stored on one machine could be accessed from another. A printer connected to one system could serve users throughout an office. Applications, databases, and other resources could likewise be placed on a machine where multiple users could reach them across the network.
This brought shared computing back into an environment built around personal computers. Mainframes and minicomputers had generally concentrated many shared functions within the same computer. A network of microcomputers allowed those functions to be separated.
As shared resources moved onto networked computers, several recognizable server roles began to emerge:
A file server provided a common place to store files that could be accessed from other computers on the network. Instead of documents and other data existing only on individual hard drives, users could work with shared storage available to everyone who had permission to use it.
A print server managed access to one or more printers. This allowed a printer to be shared among many computers while print jobs could be queued and managed in one place.
A database server provided access to common data. Rather than maintaining separate copies on individual computers, applications and users could work with information stored and managed by a shared database system.
An application server moved some of the application workload away from the individual PC. Depending on the software, the server could provide an application itself, perform processing on behalf of clients, or provide services used by applications running on other computers.
An authentication server provided a common place to manage identities and access. Instead of every computer maintaining completely independent user accounts, authentication could become another shared network service.
These roles did not necessarily require five separate computers. A single machine could provide several services, particularly on a smaller network. The functions themselves no longer had to reside together.
Users retained the processors, memory, applications, and storage available on their own computers while gaining access to resources provided elsewhere on the network. Local and shared computing could coexist.
This allowed organizations to centralize particular resources without centralizing the entire computing environment. Files might reside on a shared machine while processing remained on individual PCs. A database could be available throughout an organization without requiring every application to run on the same computer. Resources could be placed where sharing made sense while other work remained on the user’s machine.
As these shared resources became more important, particular machines could be given particular responsibilities. Instead of a user’s computer merely sharing a directory or printer when needed, an organization could dedicate a machine to providing that resource. Functions once concentrated within larger shared computers were becoming distinct roles distributed across the network.
Once resources could be provided across the network, the distinction between a personal computer and a server was not necessarily a distinction between fundamentally different kinds of hardware. A server was defined primarily by what it provided to other systems.
A computer storing files for other machines was acting as a file server. The same computer might also manage printers or authenticate users. Another machine might request files from that server while providing a different service of its own.
Server and client described roles rather than permanent categories. A computer could act as a client when requesting a resource from another system and as a server when providing a resource to others. A single computer could also perform several server roles at the same time.
This differed from the older mainframe, minicomputer, and microcomputer taxonomy. Those terms described recognizable classes of computer with meaningful differences in scale, construction, cost, and typical use. Calling a computer a server described what that computer was doing within the network.
Early network servers could have a great deal in common with the personal computers around them. They used the same families of processors, memory, storage devices, expansion buses, network adapters, and other components found throughout the growing PC ecosystem.
A machine did not need to belong to a new hardware class before it could become a server. It might simply have a larger hard drive, more memory, a network adapter, and software configured to provide resources to other computers.
I’ve practiced system administration on plenty of “servers” built from discarded PCs over the years. They did not have redundant power supplies, error-correcting memory, hot-swappable drives, or many of the other features associated with dedicated server hardware. Once configured to provide files, web pages, or other network services to other computers, they were servers because of the role they performed.
The distinction was operational before it was necessarily physical.
An ordinary PC could therefore be a perfectly legitimate server. As more users began depending on a particular machine, there were increasingly good reasons to dedicate that computer to the role.
A computer did not have to be dedicated exclusively to a server role. A workstation could share files or a printer while still being used by the person sitting in front of it, and one machine could provide several services at the same time. For a small network, that might be entirely sufficient.
The situation changed as more people began depending on those services. A shared directory used occasionally by two or three people placed very different demands on a computer than storage used throughout an organization. The consequences of that computer being unavailable also became greater.
Using someone’s workstation to provide a network service introduced some obvious problems. If the computer was turned off, the service disappeared with it. Maintenance, software problems, or hardware failures could affect everyone depending on the resource rather than only the person using the computer.
Server workloads could also compete with the person sitting at the machine for:
At some point, dedicating a computer to the service became more practical than asking one machine to serve both as someone’s personal computer and as an important shared resource.
A machine could become the file server, while another became the database server or the mail server. Smaller networks might continue combining several roles on one computer, while larger environments could separate them as workloads and requirements increased.
An organization could centralize its files on one machine and its database on another while users continued running applications and performing much of their processing on individual PCs. Shared computing no longer required concentrating everything in one place.
The network was becoming a distributed environment assembled from computers with different responsibilities. Administrators could decide which machines should provide particular services rather than expecting one class of computer to provide all of an organization’s shared computing.
Once a computer supported many users or an important service, those responsibilities began influencing more than its configuration. Performance, capacity, reliability, and availability would increasingly shape the hardware itself.
An ordinary PC could perform a server role, but a machine supporting many users faced different demands from one sitting on an individual desk. More users meant more simultaneous requests for files, applications, or data. Some workloads placed heavy demands on storage and networking, while others needed substantially more memory or processing power.
As those demands increased, the hardware began to change with them.
Different server roles placed pressure on different parts of the system. A file server benefited from fast storage and greater disk capacity. A database server might need considerably more memory and processing power. A heavily used network service could require faster network interfaces and greater I/O capacity.
As workloads increased, servers could be equipped with:
A server could become considerably more powerful than the computers it served while still using processors, memory, storage, and expansion technologies from the same general hardware families. The PC hardware model provided plenty of room to grow before a server needed to look substantially different from the machines around it.
Capacity and performance were not the only concerns. Once people depended on a server, keeping it running became increasingly important.
A failed desktop computer might interrupt one person’s work. A failed file server could prevent an entire department from reaching its files. Hardware features that prevented failures or reduced their consequences became more valuable as the number of people depending on the machine increased.
Server systems increasingly incorporated features such as:
Some of these features helped keep a hardware failure from bringing down the entire system. Others made failed components easier to replace with less disruption to the people depending on the server.
Manufacturers eventually produced systems specifically designed for server workloads. Larger memory capacities, multiple processors, rackmount cases, remote-management hardware, redundant components, and greater expansion capabilities made these machines visibly different from the PCs sitting on users’ desks.
The relationship still worked in both directions. I once bought an old Pentium III-based server from my college. Later, when my PC died, I installed a desktop environment on the server and used it to do my homework. It had been built and sold as a server, but underneath the features intended for that role was still a computer closely related to the PCs of the same era.
By this point, it was easy to look at specialized server hardware and think of it as a different class of computer. In practical terms, it certainly was built for a different workload. The difference was not as fundamental as the older divisions between mainframes, minicomputers, and microcomputers.
Server hardware had become specialized because its role demanded greater capacity, reliability, and availability. Change the role, and even a purpose-built server could sometimes become a rather unusual desktop PC.
The rise of the microcomputer did more than move computing onto smaller hardware. It separated functions that mainframes and minicomputers had often provided together. Processing moved onto individual PCs. Files moved onto local disks. Applications ran on individual machines, and peripherals could belong to individual users.
LANs allowed those functions to be reorganized. Some remained on the personal computer, while others became shared resources provided across the network:
The functions were familiar, but their organization had changed. They could now be separated and recombined according to the needs of the network rather than being tied together by the class of computer providing them.
The correspondence with the minicomputer was particularly easy to see. A minicomputer could provide a department, laboratory, university group, or smaller organization with shared storage, applications, databases, user accounts, peripherals, and processing resources.
A network of PCs and servers could provide many of those same functions, but they no longer had to reside on the same machine. Files might reside on one server, a database on another, and authentication on a third. Smaller organizations could combine several roles on one machine, while larger environments could separate them as workloads increased.
The users’ computers were different as well. Instead of terminals depending on the minicomputer for most of their computation, PCs could perform substantial amounts of work locally and reach across the network when they needed a shared resource.
This makes the minicomputer an especially useful comparison for the dedicated server. Both could provide shared resources to a group of users, but the server existed within an environment where many other functions had already moved elsewhere. What had once been bundled together in the departmental computer could now become several distinct server roles.
The same reorganization happened at a larger scale with functions associated with mainframes. Organizational databases, applications, storage, authentication, processing, and other shared resources no longer had to reside within one central computer. Some could move onto separate servers, some could remain on a mainframe, and still others could move onto users’ PCs.
A collection of PC-derived servers was not automatically equivalent to a mainframe. Mainframes continued to serve workloads where their reliability, I/O capabilities, capacity, and architecture remained valuable. The change was that large-scale shared computing no longer required every function to reside within a computer belonging to a particular hardware class.
This also helps explain why the transition was gradual. Organizations could move individual functions without replacing their entire computing environment at once. An established application might remain on a mainframe while file storage moved elsewhere. A minicomputer might continue supporting another application while PCs handled everyday work. New server roles could be added as the need arose.
The mixture of mainframes, minicomputers, PCs, and servers was therefore more than an intermediate stage between generations of hardware. It allowed individual computing functions to migrate at different times.
By this point, the functions that had once helped define different classes of computer were becoming less closely tied to the hardware that provided them.
Shared storage could come from a server built on PC-derived hardware. Applications and databases could move to their own systems. Processing could remain on individual PCs or be performed elsewhere on the network. Mainframes and minicomputers could continue operating where their particular capabilities were still needed.
The functions survived even as their connection to particular classes of computer began to weaken.
For the network administrator, the practical question was increasingly not what historical class a computer belonged to, but what role it needed to perform.
The microcomputer changed computing by moving processing, storage, applications, and peripherals away from shared mainframe and minicomputer systems and onto individual machines. The need for shared resources remained. Older systems continued operating alongside PCs, and as networking matured, many of the functions they had provided could move onto microcomputer-derived hardware.
LANs allowed functions once bundled together inside mainframes and minicomputers to become separate network roles. Files could reside on one server, databases on another, and authentication somewhere else, while users continued performing much of their work on their own PCs. Shared computing had returned in a form that could coexist with personal computing.
A server therefore emerged primarily as a role rather than a new class of computer. At first, the hardware performing that role might differ very little from an ordinary PC. As more people and more important services depended on it, the demands of the role encouraged dedicated machines and eventually specialized server hardware designed for greater capacity, reliability, and availability.
The shared functions of the mainframe and minicomputer had survived the transition to personal computing. They had moved among different machines and been reorganized through the network. That leaves an important question for the old mainframe, minicomputer, microcomputer, and supercomputer taxonomy we have used throughout this series: what happens when the functions that once helped define those classes are no longer tied to the hardware that originally provided them?
]]>As personal computers became more common, users naturally began looking for ways to communicate with one another. Bulletin board systems and, later, dial-up Internet services demonstrated that computers no longer had to remain completely isolated. A modem allowed two computers to establish a temporary connection, exchange information, and disconnect when the session was complete. For the first time, computing extended beyond the boundaries of a single machine.
The history of personal computer networking is the story of increasing connectivity—from isolated systems, to temporary communication, and finally to persistent networks.
Temporary communication, however, was only the beginning. If computers could exchange information for a few minutes over a telephone line, what would happen if they remained connected all the time? That question changed personal computing. Instead of treating communication as an occasional event, computers could begin sharing files, printers, storage, and eventually Internet access through persistent local connections.
This week we’ll examine how computing evolved from isolated systems, to temporary point-to-point communication, and finally to persistent networking. Along the way, we’ll explore the competing networking hardware, communication protocols, and operating systems that shaped this transition, why organizations invested in local area networks, how networking eventually entered our homes, and why Ethernet and the TCP/IP protocol suite became the common foundation that modern networks still rely upon today.
For the first decade of the personal computer revolution, most computers existed in isolation. Programs were loaded from floppy disks, files were stored on local media, and printers connected directly to the computer sitting on the desk. Although multiple people might own the same model of computer, each machine functioned as an independent system with little awareness that other computers even existed.
The introduction of affordable modems began changing that model. By converting digital data into audio signals that could travel across the public telephone network, two computers could exchange information without occupying the same physical location. Bulletin board systems became one of the earliest practical demonstrations of this capability, allowing users to download software, leave messages, participate in discussions, and upload files from their own homes. Later, dial-up Internet service expanded those possibilities even further, connecting personal computers to a growing collection of online resources and services.
Despite these advances, communication remained temporary. A computer established a connection with another system, exchanged information, and disconnected when the session ended. Each connection served a specific purpose, whether retrieving a file, reading messages, or accessing a remote system. Once the telephone call ended, both computers returned to operating independently. Networking had introduced communication, but it had not yet transformed the computer into part of a larger, continuously connected environment.
Temporary communication proved that computers no longer had to remain isolated. The next question was whether they needed to disconnect at all.
Even so, these temporary connections represented an important conceptual shift. Personal computers were no longer confined to the software and information stored locally. Data could move between machines, users could interact across distance, and computing itself began extending beyond the boundaries of a single system. The isolated personal computer had taken its first step toward becoming part of a network.
The next logical question was difficult to ignore. If temporarily connecting two computers could make both of them more useful, what might become possible if computers remained connected all the time? That question would drive the development of local area networks and change how personal computers were deployed in businesses, schools, and eventually homes.
Temporary communication demonstrated that computers could exchange information, but it also revealed the limitations of point-to-point connections. Every session required establishing a connection, completing a specific task, and disconnecting when finished. While this model worked well for bulletin board systems, terminal sessions, and early Internet access, it was not an efficient way for multiple computers within the same organization to communicate throughout the day.
A local area network (LAN) introduced a different model. Rather than connecting only when information needed to be exchanged, computers remained connected continuously. Communication was no longer a separate activity—it became part of the normal operation of every computer on the network. Files, printers, and other shared resources could be accessed whenever they were needed, without placing a telephone call or manually transferring disks between systems.
A local area network didn’t simply connect computers. It changed communication from an occasional event into a permanent part of everyday computing.
This persistent connectivity also changed how computers related to one another. A personal computer was no longer simply a standalone machine that occasionally communicated with another system. It became one participant in a larger environment where multiple computers could exchange information, share resources, and cooperate as part of the same network. While each computer continued running its own operating system and applications, it no longer existed in complete isolation.
The transition from temporary communication to persistent networking changed how organizations thought about computing. Instead of purchasing duplicate hardware and maintaining separate collections of files on every workstation, they could share resources across an entire office or campus. Computers were beginning to work together rather than merely communicate with one another.
Once organizations recognized these advantages, local area networks spread rapidly through businesses, schools, and universities. Building those networks, however, was far from straightforward. During the 1980s and early 1990s, there was no universally accepted way to connect computers. Different hardware technologies, communication protocols, and network operating systems all competed to become the standard, creating a diverse and often incompatible networking landscape.
The earliest local area networks were not built because networking was an exciting new technology. Organizations invested in networks because they solved practical business problems. As personal computers became more common in offices, schools, and universities, administrators quickly discovered that managing dozens or even hundreds of completely independent systems was both expensive and inefficient.
One of the earliest advantages was printer sharing. High-quality laser printers represented a significant investment, often costing far more than an individual workstation. Rather than purchasing a printer for every employee, a single network printer could serve an entire department. This reduced hardware costs while making higher-quality printing available to everyone connected to the network.
File sharing provided an equally important benefit. Before networking became commonplace, users often exchanged files by copying them to floppy disks and physically carrying them between computers, a practice that eventually became known as sneakernet. Local area networks allowed documents, spreadsheets, and other files to be stored in shared locations where multiple users could access the same information without constantly copying disks from one workstation to another. Collaboration became easier because everyone worked from the same collection of files.
Networking succeeded because it solved practical problems and saved money.
Networks also simplified many routine administrative tasks, including:
Instead of maintaining every computer independently, administrators could perform many of these tasks from a central location. As networks grew larger, these operational advantages often became just as valuable as the hardware savings.
By the late 1980s, the advantages of local area networking were becoming difficult to ignore. The challenge was no longer deciding whether computers should be connected, but determining how those connections should be built. A growing number of hardware technologies, communication protocols, and network operating systems competed for adoption, each offering a different solution to the same fundamental problem.
Once an organization decided to build a local area network, the next challenge was determining how to connect its computers. Today, Ethernet is so common that it is easy to assume networking has always worked the same way. During the 1980s and early 1990s, however, there was no universally accepted approach. Organizations could choose from a variety of competing hardware technologies, each with its own advantages, limitations, and target market.
Early local area networks used a surprising variety of physical media and network designs. Organizations could choose from technologies such as:
Each represented a different philosophy of network design, balancing factors such as cost, performance, reliability, ease of installation, and compatibility with existing systems. The diversity of available options reflected an industry that was still exploring the best way to build a local area network.
During the 1980s, there was no single “correct” way to build a local area network. Every major computing ecosystem had its own approach.
Choosing the physical network was only part of the decision. Computers also needed a common language for exchanging information. Each protocol reflected the priorities of the ecosystem that developed it.
Hardware, communication protocols, and operating systems often evolved together. Choosing a networking solution frequently meant choosing an entire networking ecosystem rather than a single technology. Common ecosystems included:
Although many of these systems eventually learned to communicate with one another, interoperability was often far more difficult than users expect today.
This diversity encouraged innovation, but it also created fragmentation. As organizations exchanged more information and the Internet continued to grow, the advantages of common standards became increasingly apparent. Over time, Ethernet emerged as the dominant physical networking technology, while the TCP/IP protocol suite became the common language that allowed computers from different manufacturers and operating systems to communicate across the same network.
Competition encouraged rapid innovation throughout the early years of local area networking, but it also created significant complexity. Organizations purchasing networking equipment often committed to an entire ecosystem that included specific network hardware, communication protocols, and network operating systems. As long as computers remained within a single environment, these solutions worked well. The challenge arose when businesses wanted to connect different systems together or exchange information with organizations using different technologies.
Ethernet gradually emerged as the preferred physical networking technology because it combined flexibility with broad industry support. Rather than remaining closely tied to a single manufacturer or operating system, Ethernet evolved as an open standard that hardware vendors across the industry could adopt. As Ethernet equipment became faster, less expensive, and easier to deploy, many organizations concluded that the advantages of a common networking standard outweighed the benefits of competing proprietary solutions.
Open standards allowed computers from different manufacturers and operating systems to communicate more easily, reducing the fragmentation that had defined early networking.
A similar transition occurred with communication protocols. While NetBEUI, IPX/SPX, AppleTalk, and other protocol families continued serving their respective environments, TCP/IP offered a broader vision. Designed to interconnect different types of networks rather than operate within a single proprietary ecosystem, TCP/IP made communication between diverse computer systems far more practical. As universities, businesses, government agencies, and eventually the public Internet expanded, the value of a common protocol suite became increasingly difficult to ignore.
It is also worth remembering that TCP/IP is not a single protocol but a family of related protocols, each designed for a specific purpose. The Transmission Control Protocol (TCP) provides reliable, ordered communication for applications where accuracy is essential, while the User Datagram Protocol (UDP) favors lower overhead and reduced latency for applications that benefit from faster, connectionless communication. Together with the Internet Protocol (IP) and other supporting protocols, they formed a flexible foundation capable of supporting a wide variety of network applications.
By the late 1990s, Ethernet and the TCP/IP protocol suite had become the common language of local area networking. Organizations no longer needed to choose entirely separate networking ecosystems based on their operating systems or hardware vendors. Computers running different operating systems could increasingly communicate across the same physical network using the same protocol suite. The fragmented networking landscape of the previous decade had largely converged into the interoperable foundation that still underpins modern networks today.
For many years, local area networks remained primarily a business technology. Organizations justified the cost by sharing printers, files, software, and other expensive resources across dozens or even hundreds of computers. Schools and universities also embraced networking, giving many students their first experience with computers that could communicate continuously rather than operating in isolation.
As networking became more common in professional and educational environments, enthusiasts began recreating those experiences at home. One of the most visible examples was the rise of the LAN party, where friends physically connected their computers to play multiplayer games, exchange files, and explore the capabilities of local networking. Although these gatherings were often centered around entertainment, they introduced an entire generation of computer enthusiasts to network adapters, cables, communication protocols, and the practical challenges of building and troubleshooting a local area network.
Broadband Internet didn’t invent the home network. It gave ordinary households a compelling reason to build one.
Even so, home networks remained relatively uncommon throughout the era of dial-up Internet. Dial-up connections established a temporary link between one computer and one remote system, whether a bulletin board system, an online service, or an Internet service provider. While a home network could certainly be built during this period, most households had little practical reason to do so because only one computer could actively use the telephone line at a time.
Broadband Internet fundamentally changed that equation. Cable, DSL, and later fiber connections remained available continuously, allowing multiple computers to share a single Internet connection without interrupting telephone service. The question was no longer, “How do I connect this computer to another computer?” Instead, it became, “How do I connect every computer in my home to the Internet?” The local area network, once primarily a business tool, became an increasingly common feature of everyday households.
Over time, home networking expanded well beyond desktop computers. As networks became part of everyday life, an increasing variety of devices joined the home network, including:
What began as a way for organizations to share expensive resources gradually evolved into the connected home environment that many people now take for granted.
The history of personal computer networking is the story of increasing connectivity. Early personal computers operated almost entirely in isolation, with programs, files, and peripherals belonging to a single machine. Modems introduced the ability to communicate across telephone lines, allowing temporary point-to-point connections that demonstrated computers no longer had to remain completely independent. Local area networks took the next logical step by making those connections persistent, transforming communication from an occasional activity into part of the normal operation of everyday computing.
Networking did more than connect computers. It transformed isolated machines into participants within larger computing environments.
As organizations recognized the advantages of shared printers, centralized files, and collaborative computing, local area networks spread rapidly through businesses, schools, and universities. During those early years, however, networking was far from standardized. Competing hardware technologies, communication protocols, and network operating systems reflected an industry still searching for the best approach. Over time, Ethernet and the TCP/IP protocol suite emerged as the common foundation that allowed computers from different manufacturers and operating systems to communicate more easily.
Standardization also made networking accessible beyond the workplace. Home enthusiasts experimented with local area networks through multiplayer gaming and file sharing, while broadband Internet gave ordinary households a compelling reason to connect multiple computers to the same network. What had once been specialized business infrastructure gradually became an expected part of everyday life, eventually expanding beyond desktop computers to include countless connected devices throughout the home.
The transition from isolated computers to persistent networks changed the environment in which personal computers operated. Networking became an essential part of modern computing, providing a common foundation upon which increasingly sophisticated systems could be built. In the next article, we’ll examine how this shared networking foundation changed the role of individual computers, allowing them to become specialized participants within larger computing environments.
]]>Many of the bulletin board systems discussed in that article ran on DOS. The operating system also powered business software, communications programs, development tools, utilities, and many of the games that defined personal computing throughout the 1980s and 1990s. Although DOS has largely disappeared from everyday computing, its influence remains visible in the systems we use today.
In this article, we’ll recreate that environment by building a virtual DOS computer with FreeDOS and VirtualBox. Along the way we’ll install FreeDOS, explore its directory structure and command-line interface, examine how DOS configures itself during startup, and learn how software was commonly installed and organized.
We’ll finish by running DOOM in the environment it was originally written for. Today, DOOM has become an informal benchmark for whether almost any device can run software at all, but here it serves a different purpose. It lets us experience one of the most influential DOS programs of the 1990s in the operating system it was designed for while confirming that the DOS environment we’ve built is working correctly.
There are still several good ways to experience DOS today. Each emphasizes something different, depending on whether your goal is historical authenticity, software compatibility, or learning how the operating system itself works.
If your goal is historical authenticity, original hardware is difficult to surpass. One of my long-term goals is to purchase an IBM PCjr or XT and a 486DX system.
Original hardware provides the complete experience, including the limitations, quirks, and performance characteristics of the computers DOS was originally written to support. It also means maintaining aging hardware, locating compatible peripherals, and dealing with the realities of computers that are now decades old. For many enthusiasts, those challenges are part of the experience rather than an inconvenience.
Installing FreeDOS directly on newer hardware is another option. If you have an unused computer available, you can skip the virtual machine entirely and install FreeDOS on the physical system.
Installing FreeDOS on dedicated hardware provides a complete DOS environment while avoiding the cost and maintenance of vintage hardware. Compatibility depends on the computer you choose, particularly its storage controller, graphics hardware, sound hardware, and input devices, but many older PCs still make excellent dedicated DOS systems.
DOSBox-X is a convenient choice when your primary interest is running classic DOS games. It emulates much of the hardware those games expect, including graphics cards, sound hardware, processors, and timing characteristics that can be difficult to reproduce on modern computers.
Although DOSBox-X provides a DOS environment, its primary strength is software compatibility. If your goal is simply to play DOS games, DOSBox-X is often the easiest solution.
DOSEMU2 takes a different approach by allowing DOS programs to run from within Linux rather than creating a completely separate computer.
I use DOSEMU2 on Cyber Sword BBS to run several DOS door games. It allows original DOS software to coexist with a modern Linux server, making it an excellent solution when DOS applications need to become part of a larger Linux system.
For learning DOS itself, a virtual machine provides the best balance between authenticity, convenience, and flexibility.
A virtual machine gives us a complete DOS computer that we can install, configure, restart, and experiment with without affecting the operating system installed on our physical computer. We can experience the DOS boot process, examine its configuration files, install software, and make changes without worrying about damaging our everyday system.
A virtual machine is an ideal environment for learning DOS, which is the approach we’ll use throughout the rest of this article.
There are many ways to experience DOS today. You can install FreeDOS on an unused computer, run it on original hardware, use DOSEMU2 under Linux, or choose another virtualization platform. Each approach has advantages, and any of them can provide a working DOS environment.
For this article, our goal is to learn DOS itself. A virtual machine gives us a complete DOS computer that we can install, configure, restart, and experiment with without affecting the operating system on our physical computer. If something goes wrong, we can recreate the virtual machine and begin again.
We’ll use VirtualBox because it is free, widely available for Windows, Linux, and macOS, and well suited to creating the kind of virtual DOS computer we need. If you already use VMware, KVM/QEMU, Hyper-V, or another virtualization platform, use it. The concepts covered throughout this article remain the same regardless of which virtual machine software you choose.
A virtual machine also has another advantage: portability. A virtual machine is essentially a collection of files that can be copied, backed up, and often converted for use with other virtualization platforms. That makes it easy to preserve your DOS computer and return to it later without keeping a dedicated physical machine.
Throughout this article, remember that VirtualBox is only the tool we’re using to reach DOS. The operating system—and the ideas it teaches—is the real subject of this project.
Before we can install FreeDOS, we need a computer to install it on. Rather than using a physical computer, we’ll create a virtual one inside VirtualBox. The virtual machine gives us a clean DOS system that we can experiment with, recreate, and expand without affecting the operating system already installed on our computer.
A virtual machine is exactly what its name suggests: a computer that exists entirely as software. It has virtual hardware such as memory, storage, a CD-ROM drive, and a processor, all provided by the virtualization software instead of physical components. To FreeDOS, it appears to be an ordinary computer.
A virtual machine offers several advantages. We can build the DOS computer from scratch, experiment with its configuration, install software, and even make mistakes without risking the computer we use every day. When we’re finished, the virtual machine can be copied, backed up, or deleted like any other collection of files.
Before creating the virtual machine, update your computer and install VirtualBox. The installation method depends on the operating system you use, and we do not need any unusual extensions or optional components for this project.
Download the current FreeDOS LiveCD ISO from the FreeDOS project. We are using FreeDOS 1.4, which is the current release as this article is being written.
With VirtualBox installed, we’re ready to create our virtual DOS computer.
Create a new virtual machine. In the VirtualBox operating-system selection, choose Other, then select DOS.
Allocate 1 GB of memory and create a 2 GB virtual hard disk. FreeDOS itself requires only a small fraction of those resources, but these values provide enough room for the complete FreeDOS installation and the software we’ll add throughout this series while remaining modest by modern standards.
Leave the remaining VirtualBox settings at their defaults. For the purposes of this project, they provide a suitable virtual DOS computer without requiring additional configuration.
Finally, attach the FreeDOS 1.4 LiveCD ISO to the virtual CD-ROM drive. This allows the virtual machine to boot from the installation media just as a physical computer would boot from a CD-ROM during installation.
At this point, our virtual DOS computer is assembled and ready for its operating system.
With our virtual DOS computer assembled, we’re ready to install FreeDOS. The installer is straightforward and asks only a handful of questions before copying the operating system and the selected software to the virtual hard disk.
Start the virtual machine. Because the FreeDOS LiveCD ISO is attached to the virtual CD-ROM drive, the system will boot directly into the installer.
When the installation menu appears, choose to install FreeDOS to the hard disk. The installer will prepare the virtual hard disk and guide you through the remaining setup process.
When prompted for the installation type, select the Full Installation. With a 2 GB virtual hard disk, there is plenty of room for the complete operating system along with the utilities, development tools, games, and applications included with FreeDOS. A smaller installation would work, but the Full Installation gives us more software to explore throughout this article and future projects.
Allow the installation to complete using the default settings unless you have a specific reason to change them. For our purposes, the default configuration provides everything we need.
Once the installation finishes, shut down the virtual machine.
Before starting it again, open the VirtualBox settings and remove the FreeDOS ISO from the virtual CD-ROM drive. Removing the ISO is the virtual equivalent of removing the installation CD from a physical computer. If the ISO remains attached, the virtual machine may boot back into the installer instead of the operating system we just installed.
Start the virtual machine again.
If everything completed successfully, FreeDOS will boot from the virtual hard disk and eventually stop at a familiar-looking prompt:
C:\>
Although it doesn’t look like much, you’ve just built a working DOS computer. In the next section, we’ll begin exploring the operating system itself, learning how to move around the filesystem, examine directories, and run programs from the command line.
You’ve created the virtual machine, installed FreeDOS, watched it boot, and now you’re sitting at the C:\> prompt. If you’ve never used DOS before, it may not be immediately obvious what to do next.
The best place to begin is by looking around. Type the following command and press Enter:
DIR
The DIR command displays the contents of the current directory. You’ll see the files and subdirectories stored in your current location on the C: drive.
To move into another directory, use the CD command. For example:
CD GAMES
Once you’ve changed directories, use DIR again to see what’s inside. As you explore the system, you’ll quickly become familiar with how DOS organizes files and directories.
DOS commands and filenames are not case-sensitive. DIR, dir, and DiR all perform exactly the same command. Throughout this article, commands are shown in uppercase because that was the convention used in many DOS books and manuals, but DOS itself does not require it.
Like Windows, DOS identifies storage devices with drive letters. The operating system is normally installed on the C: drive. Historically, floppy disk drives occupied A: and B:, while CD-ROM drives and additional storage devices were assigned the remaining letters.
If you’re already comfortable using Linux or another command-line operating system, many DOS concepts will feel familiar even though some of the command names differ.
| Task | DOS | Linux |
|---|---|---|
| List directory contents | DIR |
ls |
| Change directories | CD |
cd |
| Display the current directory | CD |
pwd |
| Clear the screen | CLS |
clear |
| Copy a file | COPY |
cp |
| Move or rename a file | MOVE / REN |
mv |
| Delete a file | DEL |
rm |
| Create a directory | MD / MKDIR |
mkdir |
| Remove a directory | RD / RMDIR |
rmdir |
| Display memory information | MEM |
free |
Try a few additional commands:
VER
HELP
MEM
CLS
VER displays the FreeDOS version. HELP provides information about commands and many of the programs included with FreeDOS. MEM reports how DOS is using conventional, expanded, and extended memory. CLS clears the screen if things become cluttered.
As you browse the directories, you’ll find files ending in .EXE, .COM, and .BAT. These are executable files. In most cases, you can start one simply by typing its name and pressing Enter.
For example, if you see EDIT.EXE, you can start it with:
EDIT
EDIT is the text editor included with FreeDOS. We’ll use it in the next section to examine the startup files that DOS reads every time the computer boots.
At this point, you’ve done more than install an operating system. You’ve started exploring it the same way many people first learned DOS: by looking around, experimenting with commands, and discovering what was already on the computer.
Although DOS is a relatively small operating system, it still follows a predictable startup process each time the computer boots. Unlike many modern operating systems that may start hundreds of services behind the scenes, DOS performs only a handful of steps, making it much easier to understand what happens before the command prompt appears.
Traditional Microsoft DOS systems use two startup files named CONFIG.SYS and AUTOEXEC.BAT. FreeDOS uses slightly different names: FDCONFIG.SYS and FDAUTO.BAT. Although the filenames differ, they serve the same purposes.
The startup sequence follows a simple order:
Understanding this sequence makes it much easier to understand how DOS prepares the computer for use.
The first configuration file processed by FreeDOS is FDCONFIG.SYS.
Open it with:
EDIT C:\FDCONFIG.SYS
This file configures the operating system before you ever reach the command prompt. It can load device drivers, configure memory managers, create boot menus, and perform other low-level tasks that DOS needs before applications begin running.
If you’ve worked with Linux before, you can think of this stage as configuring the operating system before user-space programs begin executing.
You don’t need to understand every line yet. For now, notice that DOS is assembling the environment it needs before accepting commands from the user.
After the operating system finishes processing FDCONFIG.SYS, DOS loads COMMAND.COM.
COMMAND.COM is the DOS command interpreter. It displays the command prompt, accepts the commands you type, executes programs, and provides the built-in commands such as DIR, CD, COPY, and CLS.
Without COMMAND.COM, DOS would boot, but there would be no interactive command-line interface.
Once COMMAND.COM has started, it automatically executes the startup batch file.
Under FreeDOS this file is named FDAUTO.BAT.
Open it with:
EDIT C:\FDAUTO.BAT
A batch file is simply a text file containing DOS commands that are executed one after another. Rather than typing the same commands every time the computer starts, DOS performs them automatically during boot.
FDAUTO.BAT typically configures the command search path, sets environment variables, customizes the command prompt, loads utilities, starts mouse support, and performs many of the tasks users expected to happen automatically whenever the computer started.
Like FDCONFIG.SYS, you don’t need to understand every command yet. Instead, look through the file and notice how it builds the working DOS environment one command at a time.
By the time FDAUTO.BAT finishes, DOS has completed its startup process and is ready for you to begin working.
Although simple by modern standards, this startup sequence illustrates one of DOS’s greatest strengths: nearly everything the operating system does during boot is visible, understandable, and controlled by ordinary text files. Rather than hiding the startup process, DOS encourages you to examine it, learn from it, and modify it as your understanding grows.
Few computer programs have had the lasting influence of DOOM. Released by id Software in 1993, it quickly became one of the defining games of the decade. Its graphics, networking, shareware distribution model, and technical achievements influenced both game development and personal computing for years afterward.
Over the decades, DOOM has been ported to countless operating systems and hardware platforms. Eventually, people began asking a simple question:
Can it run DOOM?
The question became something of a tradition. Rather than asking whether a device should run DOOM, people began asking whether they could make it run. The result has been an impressive collection of unusual ports demonstrating both technical skill and the surprising capabilities of modern hardware.
Among the more unusual examples are graphing calculators, John Deere tractors, and even internet-connected toasters. None of these devices were designed to play first-person shooters, yet each has become part of the long-running tradition of proving that almost anything with enough computing power can eventually be persuaded to run DOOM.
For this project, we’re doing exactly the opposite.
Instead of forcing DOOM to run on hardware it was never intended for, we’re returning it to the environment it was originally designed to use. DOS was the operating system for which DOOM was written, and running it here gives us an opportunity to experience the game much as players did in the early 1990s.
DOOM also serves one final purpose.
If the game starts successfully, displays graphics correctly, responds to the keyboard, and produces sound, it demonstrates that the DOS environment we’ve built is functioning as expected. In that sense, DOOM is more than simply the final program we’ll run—it becomes the final validation of everything we’ve built throughout this article.
There’s one more historical note.
According to id Software’s long-running backstory, the DOOM Marine is a descendant of Billy Blaze, the young hero of the Commander Keen series. Billy Blaze himself is the grandson of William “B.J.” Blazkowicz, the protagonist of Wolfenstein 3D. Although this family relationship has little impact on the games themselves, it’s a fun bit of id Software history that loosely connects three of the company’s most influential series.
If you’ve never played Commander Keen or Wolfenstein 3D, they’re well worth exploring. Together with DOOM, they illustrate the rapid evolution of PC gaming during the late 1980s and early 1990s.
If you selected the Full Installation when installing FreeDOS, you may have noticed that FreeDOOM is already included. It can be found under:
C:\GAMES
FreeDOOM is an open-source project that provides freely distributable replacement game data compatible with the DOOM engine. It is an excellent project in its own right and provides an easy way to experience the DOOM engine without the original commercial game data.
For this article, we’ll also install the original DOOM shareware release.
The shareware version includes the complete first episode, Knee-Deep in the Dead. It is freely redistributable and provides everything we need for this project.
One limitation of DOS virtual machines is that VirtualBox Guest Additions are not available for DOS. Unlike modern guest operating systems, FreeDOS cannot mount a shared folder directly from the host computer.
Extract the DOOM shareware archive on your regular computer, then use your preferred ISO creation tool to build a CD-ROM image containing the extracted files.
Attach the ISO to the virtual machine’s CD-ROM drive and boot FreeDOS. The virtual CD-ROM will appear as another drive letter. Throughout this example, we’ll assume it is D:.
First, create a directory for DOOM.
MKDIR C:\GAMES\DOOM
Next, copy the files from the CD-ROM into the new directory.
COPY D:\ C:\GAMES\DOOM
Now change into the directory.
CD C:\GAMES\DOOM
One characteristic I have always appreciated about DOS software is how self-contained most programs were. Installing software often meant little more than creating a directory and copying the files into it. There was no registry to update, no background services to install, and usually no dedicated uninstaller. If you no longer wanted the program, deleting its directory was often enough.
I especially appreciated this when sharing a family computer. I could organize my own software into whatever directory structure made sense to me without affecting anyone else’s programs. Because DOS applications generally kept everything they needed together, it was easy to understand what belonged to each application and to keep the system organized.
If the shareware distribution includes the setup program, run:
SETUP
Configure the sound and input devices, then return to the DOS prompt.
Finally, start the game.
DOOM
If DOOM starts successfully, you’ve accomplished considerably more than simply running a classic game. You’ve built a virtual DOS computer, installed an operating system, explored its filesystem, learned how DOS configures itself during startup, and run one of the most influential DOS programs of the 1990s in the environment for which it was originally written.
You have now built a virtual DOS computer from the ground up. Starting with VirtualBox, you installed FreeDOS, explored its directories and commands, examined the files that control its startup process, and finished by running DOOM in the operating system it was originally designed for. Along the way, you experienced many of the same workflows that defined personal computing throughout the 1980s and much of the 1990s.
Although DOS is no longer a mainstream operating system, many of the ideas it introduced remain part of modern computing. Command-line interfaces, startup configuration files, executable programs, directory structures, environment variables, and system configuration all continue to exist in today’s operating systems, even if they are presented differently. Learning DOS provides historical context for understanding why many modern systems behave the way they do.
You’ve now experienced DOS rather than simply reading about it. You have seen the operating system boot, explored its filesystem, examined how it configures itself, copied software into place, and run one of the most influential DOS applications ever written. Those experiences provide a foundation that will make future articles in this series easier to understand because they build upon concepts you’ve now used yourself.
If this article has sparked your interest, thousands of DOS programs, utilities, programming languages, and games are still available to explore. You can also visit Cyber Sword BBS, where I maintain a growing collection of DOS software from the 1980s and 1990s available for download. Whether you’re revisiting software you once used or discovering it for the first time, there is still much to learn from the operating system that helped define an era of personal computing.
]]>This time, I’d like to look beneath the surface at one of the most interesting parts of the project: the door system. While callers simply choose a game or application from a menu, there’s a surprising amount of infrastructure working behind the scenes to make that experience feel seamless. Supporting classic DOS doors, modern Linux console games, Interactive Fiction, remote DoorParty games, and native Synchronet JavaScript doors required solving a series of different problems, each of which influenced the design of the next solution.
Like much of Cyber Sword BBS, this architecture didn’t appear fully formed. It evolved one challenge at a time. I started with Interactive Fiction because I wanted Infocom and modern Z-Code games to behave like traditional BBS doors. That led to BBSZCodeRunner. Later, I realized many Linux console applications had almost identical requirements, resulting in BBConsoleRunner. When it came time to bring classic DOS doors back to life under Linux, I encountered an entirely new set of challenges involving DOSEMU2, dropfiles, COM ports, FOSSIL support, and decades-old software that still expected to be running on a real DOS machine.
In this article, I’ll walk through that evolution, explaining not only the final architecture but also the ideas, experiments, dead ends, and small discoveries that shaped it. Along the way, we’ll explore how doors communicate with a BBS through dropfiles, why I chose specific technologies, how the wrapper scripts evolved from one-off utilities into reusable infrastructure, and why the classic BBS door model remains flexible enough to support software spanning more than forty years of computing history.
Before diving into the architecture behind Cyber Sword BBS, it’s worth taking a step back to understand what a door actually is. The term is frequently associated with classic DOS games like Legend of the Red Dragon and TradeWars 2002, but those games represent only one chapter in the history of doors. To understand why the architecture in this project works, we first need to understand the concept itself.
A door is an external program that a bulletin board system temporarily launches on behalf of a caller. While the door is running, the user interacts directly with that program instead of the BBS. When the user exits the door, control returns to the BBS exactly where they left off, allowing them to continue browsing message boards, downloading files, or launching another application.
The important point is that a door is defined by its relationship with the BBS, not by the operating system it runs on. Throughout the history of bulletin board systems, doors have existed on DOS, Commodore 64, Apple II, Amiga, OS/2, Unix, Linux, Windows, and other platforms. The BBS simply needed a standardized way to launch an external program, provide it with information about the current caller, and regain control when the program exited.
A door is defined by its relationship with the BBS, not by the operating system it runs on.”
During the 1990s, DOS-based doors became the dominant implementation. The widespread popularity of MS-DOS, combined with an explosion of creative door developers, produced classics such as Legend of the Red Dragon, TradeWars 2002, Barren Realms Elite, Usurper, and hundreds of other games and utilities. Because these titles became synonymous with the golden age of dial-up BBSing, many people today equate the term door with DOS door. Historically, that’s understandable—but technically, DOS was simply the most successful platform for a much broader concept.
Doors transformed bulletin board systems from collections of message boards and file libraries into interactive communities. Multiplayer games encouraged users to log in every day, role-playing games fostered long-running rivalries and alliances, and utilities expanded the capabilities of the BBS far beyond what the base software provided. Many sysops became known as much for their collection of doors as for the BBS software they were running.
This flexibility also encouraged experimentation. Sysops weren’t limited to software written by the authors of their BBS package. If someone could write a program that followed the conventions expected by the BBS, it could become another feature of the system. That openness helped create a rich ecosystem of games, educational software, productivity tools, and online experiences that continued to evolve for decades.
The more I worked on Cyber Sword BBS, the more I realized that this flexibility—not DOS itself—was the real legacy of the door model. My goal wasn’t simply to run classic DOS doors under Linux. It was to preserve the idea that a BBS can temporarily hand control to another application and then seamlessly resume the user’s session when that application exits. In many ways, that philosophy mirrors ideas I’ve written about before in articles such as Ports for Everyone, where understanding the interface between systems is often more important than the systems themselves.
If the BBS temporarily hands control to another program, the obvious question becomes: How does that program know who the caller is?
Long before modern APIs or inter-process communication became commonplace, BBS developers adopted a remarkably simple solution. Before launching the door, the BBS writes a small text file containing information about the current session. The door reads that file, learns who the user is, how much time remains, what node they’re connected through, and other details needed to operate correctly.
These files became known as dropfiles, because the BBS “dropped” them into a location where the door could find them before execution.
Typical information found in a dropfile includes:
Once the door has finished reading the dropfile, it has everything it needs to behave as though it were part of the BBS itself.
DOOR.SYS and XTRN.DATOver the years, several dropfile formats emerged, but two are particularly relevant to Cyber Sword BBS.
DOOR.SYS became the de facto industry standard and is still recognized by many classic DOS doors. Its widespread adoption means that software written decades ago can often still run today without modification, provided the environment around it is recreated accurately.
Synchronet also provides its own native format, XTRN.DAT. Compared to DOOR.SYS, it is smaller, simpler, and easier to parse. Whenever I write new wrappers or native applications, I generally prefer XTRN.DAT. However, many classic DOS doors expect DOOR.SYS, so supporting both formats allows modern software and legacy applications to coexist without compromise.
Understanding dropfiles turned out to be one of the key insights behind the entire architecture described in this article. Whether the external program is:
the launch process always begins in essentially the same way. The BBS prepares the session information, launches an external program, and waits for control to return. Everything that follows in this article is simply a different way of adapting that remarkably durable interface.
Although classic multiplayer door games were always part of my long-term plans for Cyber Sword BBS, the first type of door I actually implemented wasn’t a DOS game at all. It was Interactive Fiction. Looking back, that turned out to be a fortunate decision because it allowed me to solve many of the architectural problems of running external applications before adding the additional complexity of DOS emulation.
Before choosing specific games, I decided to start with the Z-Code format itself. Originally developed by Infocom, the Z-machine has matured into one of the longest-lived virtual machines in computing. Modern interpreters such as Frotz are well-tested, stable, and capable of running thousands of story files spanning more than forty years of Interactive Fiction.
From an engineering perspective, that made Z-Code an ideal place to begin. The interpreter was already mature, the file format was well documented, and I could concentrate on solving the problem I was actually interested in: making a modern Linux application behave like a traditional BBS door. Rather than debugging an immature runtime, I could focus on integrating it cleanly with Synchronet.
I’ve enjoyed Infocom’s games for many years. Titles such as Zork, Planetfall, Trinity, Moonmist, and The Hitchhiker’s Guide to the Galaxy represent an important part of computer gaming history. While these games were traditionally played locally, I wanted callers to experience them as first-class citizens of the BBS alongside traditional door games.
Interactive Fiction also presented an interesting technical challenge. A BBS door needs to know who the current user is, where to store save files, how to restore previous progress, and how to return cleanly to the BBS when the game exits. Solving those problems would establish patterns that could later be reused by other types of doors.
In many ways, Interactive Fiction became my proof of concept. If I could successfully make a modern Linux application behave like a traditional BBS door, then the same architecture could likely be adapted to other applications as well. Like several of the scripting projects I’ve written about before, including Why Update Scripts, the real lesson wasn’t solving one specific problem—it was building something reusable enough to solve the next one as well.
The result was BBSZCodeRunner, a wrapper designed specifically for Synchronet. Rather than simply launching Frotz, the wrapper reads Synchronet’s XTRN.DAT dropfile, determines which user is currently logged in, creates or locates that caller’s save directory, maps the BBS user to a consistent filename, and then launches the requested Z-Code story.
Each caller receives their own persistent save directory, allowing them to continue games across multiple sessions without interfering with other users. From the caller’s perspective, the experience feels much like a traditional door game: choose a title from the menu, play, save when finished, and continue where you left off the next time you log in.
One design decision that proved particularly useful was separating game files, save files, and user mappings into their own directories. That organization made the project easier to maintain as additional games were added and also established a directory structure that I would later reuse in other wrappers.
Originally, BBSZCodeRunner maintained its own log directory alongside the application. As the project expanded, however, it made more sense for every wrapper to write into Synchronet’s central log directory. Today, all wrapper logs are written to /opt/sbbs/sbbs/logs/, making troubleshooting much simpler because everything related to the BBS is collected in one place.
Current directory layout:
/opt/sbbs/doors/zcode/
├── bbszcoderunner.sh
├── games/
├── saves/
└── usernames.map
The wrapper keeps detailed log files, maintains a simple username mapping so save files remain consistent even if a user’s alias changes, and automatically creates the directory structure needed for each caller. These are relatively small implementation details, but together they make the system considerably more reliable for long-term use.
If you’d like to use BBSZCodeRunner on your own Synchronet system, the complete source code, installation instructions, and documentation are available in the BBSZCodeRunner GitHub repository.
One of the biggest surprises was realizing that very little of BBSZCodeRunner was actually specific to Interactive Fiction. Reading a dropfile, identifying the caller, creating user-specific directories, maintaining save files, logging activity, and launching an external Linux application are tasks that many different applications need.
Instead of viewing BBSZCodeRunner as simply an Interactive Fiction launcher, I began seeing it as the first piece of a much larger architecture.
The wrapper had solved the general problem of integrating Linux applications into Synchronet, and only a relatively small amount of code was truly specific to the Z-machine itself. Once that realization clicked, I stopped thinking in terms of games and started thinking in terms of reusable infrastructure.
I stopped thinking in terms of games and started thinking in terms of reusable infrastructure.
By the time BBSZCodeRunner was working reliably, I realized I hadn’t really solved an Interactive Fiction problem—I had solved a Linux application integration problem. Reading a dropfile, identifying the caller, preparing a user-specific environment, launching an application, and returning cleanly to Synchronet weren’t unique to Z-Code. Those same requirements applied to many Linux console applications as well.
That realization fundamentally changed the direction of the project. Instead of writing another wrapper specifically for one game, I began thinking about how to integrate an entire category of software into the BBS.
One advantage of running Synchronet on Linux is that an enormous ecosystem of software is immediately available. Thousands of applications already run inside a terminal, and many of them feel perfectly at home on a text-mode bulletin board system.
Classic roguelikes such as Rogue, NetHack, Angband, and Moria naturally fit the BBS environment. So do lighter games like Moon Buggy, Vitetris, Nudoku, Pacman4Console, nInvaders, and many others. Unlike DOS doors, these applications are actively maintained, portable, and already run natively under Linux.
The challenge wasn’t getting the games to run—it was making them feel like doors instead of shell commands.
It’s also worth noting that not every Linux console application needs a wrapper. Many programs can simply be launched directly by Synchronet and work perfectly well without any additional infrastructure. BBConsoleRunner exists for applications that maintain per-user state, such as save files, configuration files, or other persistent data. Those applications need to know who the current caller is and where their personal files belong, making a wrapper the simplest way to bridge that gap.
Rather than starting from scratch, I used BBSZCodeRunner as the template for the new wrapper. Much of the underlying infrastructure was already there: reading Synchronet’s XTRN.DAT dropfile, identifying the current caller, preparing user-specific resources, logging activity, and returning cleanly to the BBS when the application exited.
As I adapted the script, I removed everything that was specific to the Z-machine and replaced it with code capable of launching arbitrary Linux console applications. That naturally led to a more configuration-driven design. Instead of embedding game-specific behavior directly into the wrapper, individual applications define their executable, command-line arguments, save locations, and other options through a shared configuration file.
That decision dramatically reduced the amount of code required to add new games. As the infrastructure improved, supporting another application often became little more than adding another configuration entry rather than writing another wrapper.
Current directory layout:
/opt/sbbs/doors/consolegames/
├── bbsconsolerunner.sh
├── bbsconsolegames.conf
├── games/
│ └── dwarf-fortress-ascii (and other locally installed games)
├── saves/
└── usernames.map
Like BBSZCodeRunner, game files remain separate from user data, while logging has been centralized under /opt/sbbs/sbbs/logs/ alongside the rest of the Synchronet infrastructure. Keeping every wrapper’s logs in one location has made troubleshooting considerably easier as the project has grown.
If you’d like to use BBConsoleRunner on your own Synchronet system, the complete source code, installation instructions, and documentation are available in the BBConsoleRunner GitHub repository.
Looking back, BBConsoleRunner confirmed something I had only suspected while building BBSZCodeRunner. The wrapper itself contains very little game-specific logic. Most of its responsibility is simply acting as an adapter between Synchronet and another Linux application.
By this point, I had stopped thinking about adding games individually. Instead, I was building reusable infrastructure capable of integrating entire categories of software into the BBS. Every successful wrapper reinforced the same architectural pattern, making the next integration easier than the last.
Perhaps more importantly, each wrapper required less code than the one before it. Once the underlying architecture existed, I was no longer solving the same problems repeatedly. I was simply extending an infrastructure that had already proven itself, which is exactly what I had hoped to achieve when I first began experimenting with Interactive Fiction as BBS doors.
By this point, Cyber Sword BBS could launch native Linux applications, but there was still one major category of software I wanted to support: remote multiplayer door games. While many classic doors can still be run locally, some are actively maintained on dedicated DoorParty servers, allowing multiple bulletin board systems to share the same persistent game worlds. That means callers from different BBSes can interact with one another while each sysop avoids the work of maintaining a separate installation.
Rather than replacing local doors, DoorParty complements them. It expands the available library of games while allowing Cyber Sword BBS to focus on the titles I wanted to host locally.
One of the strengths of the classic BBS community has always been sharing resources. Not every sysop wants to install, configure, patch, and maintain dozens of multiplayer games. DoorParty solves that problem by hosting the games centrally while allowing individual BBSes to present them as though they were local doors.
From the caller’s perspective, the experience is almost seamless. They select a game from the Synchronet menu, play as they normally would, and when they exit they are returned directly to the BBS. The fact that the game is actually running on another server is almost completely transparent.
One detail I particularly like about DoorParty is how it separates responsibilities. Synchronet never connects directly to the remote DoorParty servers. Instead, Synchronet establishes a local RLogin connection to the DoorParty Connector service running on the same machine. The connector then authenticates with DoorParty and establishes the secure connection to the remote game server.
The overall architecture is surprisingly straightforward:
Caller
│
Synchronet
│
Local RLogin
│
DoorParty Connector
│
Secure Connection
│
DoorParty Game Server
This separation keeps the responsibilities of each component well defined. Synchronet manages the caller’s session, while the DoorParty Connector handles authentication and communication with the remote infrastructure.
The JavaScript module inside Synchronet is intentionally small because most of the work has already been delegated to the connector service.
// Sensitive values replaced with placeholders.
load("sbbsdefs.js");
var HOST = "localhost";
var PORT = 9999;
var USER_PREFIX = "BBS";
var PASSWORD = "<password>";
var username = USER_PREFIX + user.alias;
var tag = argv.length ? argv[0] : "lord";
bbs.rlogin_gate(
HOST + ":" + PORT,
PASSWORD,
username,
tag
);
One part of this project that reflects its organic development is that I didn’t install a new DoorParty Connector specifically for Synchronet. Earlier in the project, while experimenting with Mystic BBS, I had already configured the connector service. It was reliable, well understood, and already did exactly what I needed.
Rather than replacing a perfectly good component simply because I had changed BBS software, I kept using the existing installation. Synchronet simply connects to the local connector, and the connector continues handling communication with DoorParty exactly as it always had.
The service itself remains remarkably simple:
# Sensitive values replaced with placeholders.
[Unit]
Description=DoorParty Connector Service
After=network.target
[Service]
ExecStart=/path/to/doorparty-connector
WorkingDirectory=/path/to/doorparty
Restart=always
User=<user>
Group=<group>
Environment=PATH=/usr/bin:/bin:/usr/sbin:/sbin
Environment=HOME=/path/to/doorparty
[Install]
WantedBy=multi-user.target
Looking back, this turned out to be one of the better engineering decisions in the project. The connector already worked well, so there was no value in replacing it simply because the surrounding infrastructure had changed.
Working with DoorParty reinforced another lesson that had been emerging throughout this project. Good systems don’t require every component to be written from scratch. Sometimes the best solution is to understand how existing software works, connect reliable components together, and let each one do the job it was designed to do.
That philosophy has quietly shaped much of Cyber Sword BBS. Frotz interprets Z-Code stories. BBConsoleRunner adapts Linux applications into doors. DoorParty hosts multiplayer games. My contribution wasn’t replacing those tools—it was designing an architecture that allows them to work together as though they were all part of a single, cohesive bulletin board system.
After building wrappers for Linux applications and integrating remote DoorParty games, it would have been easy to assume that every door required some kind of adapter or supporting infrastructure. One pleasant surprise was discovering that Synchronet’s native JavaScript doors require neither. They already live inside the BBS itself, giving them direct access to Synchronet’s APIs without the need for dropfiles, wrapper scripts, connector services, or emulators.
That made them a natural addition to Cyber Sword BBS. While much of this project focused on adapting external software to behave like traditional BBS doors, Synchronet’s JavaScript doors reminded me that not every problem needs another layer of infrastructure. Sometimes the simplest solution is already built into the platform.
Unlike every other door system discussed so far, Synchronet JavaScript doors don’t require a wrapper, connector, or emulator. Synchronet simply loads the JavaScript application directly, allowing it to interact with the current caller through the BBS’s own APIs.
That means a JavaScript door already has access to information about the current user, the terminal, messaging, file areas, and other Synchronet services. Instead of communicating through a dropfile like DOOR.SYS or XTRN.DAT, it communicates directly with the BBS itself.
From an architectural perspective, these are the simplest doors on the system. The application starts, interacts with the caller, exits, and returns control directly to Synchronet without any additional layers between the two.
Synchronet ships with a surprisingly large collection of native JavaScript doors and utilities. Rather than recreating functionality that already existed, I simply enabled many of the applications that best fit the style and goals of Cyber Sword BBS.
Today the BBS offers a mixture of classic and modern experiences. Alongside DOS doors, Linux console games, Interactive Fiction, and DoorParty titles are Synchronet’s own JavaScript games and utilities, including Wordle, 2048, Sea Battle, Gooble Gooble, and many others.
Including these applications was an intentional decision. One goal of Cyber Sword BBS is preserving classic bulletin board software, but another is showcasing that Synchronet remains an actively developed platform. Its JavaScript ecosystem demonstrates that new BBS software is still being written and that modern development can coexist alongside software that is several decades old.
As the project grew, one design philosophy kept resurfacing: choose the simplest integration that solves the problem.
If an application already runs natively inside Synchronet, there is no reason to wrap it. If it is a Linux application that needs per-user save data, BBConsoleRunner provides that infrastructure. If it is Interactive Fiction, BBSZCodeRunner fills that role. If it is hosted remotely, DoorParty bridges the connection. Each solution exists because it solves a different problem rather than forcing every application into the same architecture.
Looking back, that may be one of the biggest lessons of the project. Good architecture isn’t about making every component work the same way. It’s about understanding each technology well enough to integrate it using the simplest solution that accomplishes the goal.
After spending so much time building wrappers, adapters, and connector services, it was genuinely refreshing to simply enable software that was already designed to work within Synchronet. Sometimes the best engineering decision isn’t writing another script—it’s recognizing when the platform already provides exactly what you need.
By the time I reached this stage of the project, Cyber Sword BBS could already launch Interactive Fiction, native Linux console games, DoorParty titles, and Synchronet JavaScript doors. Each of those technologies presented its own challenges, but they all shared one important advantage: they were designed for modern operating systems. DOS doors were different. They weren’t simply older software—they expected to run in an environment that had effectively disappeared decades ago.
My goal with DOS Doors is not to run every possible door. I am building a currated collection of the best remembered doors. I am relying on services like DoorParty to offer the full range of DOS Doors.
Bringing those applications back to life meant recreating enough of that environment that they still believed they were running on a multi-node DOS BBS. That required understanding not only the games themselves, but also dropfiles, virtual COM ports, FOSSIL communication, DOSEMU2, and the assumptions that door developers made in the early 1990s. Looking back, this was easily the most technically demanding part of the entire project.
One of the interesting discoveries during this project was realizing that a DOS door is much more than a DOS executable. Games such as Legend of the Red Dragon and TradeWars 2002 don’t simply start and run. They expect to be launched by a bulletin board system that has already prepared their environment.
That environment includes a dropfile, usually DOOR.SYS, containing information about the current caller, the communication port, remaining session time, ANSI capabilities, and many other details. The game also expects to communicate through a COM port, often using a FOSSIL driver, while assuming it has exclusive control of the terminal until it exits back to the BBS.
None of those assumptions are true on a modern Linux server.
Unlike the Linux applications discussed earlier in this article, DOS doors couldn’t simply be launched from a wrapper script. They needed an entire DOS environment capable of convincing software written more than thirty years ago that it was still running on the hardware it expected.
That challenge made DOS doors fundamentally different from every other type of door on Cyber Sword BBS.
Although my long-term goal was supporting both Legend of the Red Dragon and TradeWars 2002, I deliberately started with LORD.
There were two reasons for that decision. First, LORD has long been regarded as one of the classic BBS door games, making it an obvious title to include. More importantly, however, it presented a simpler technical target than TradeWars 2002. If I couldn’t reliably launch LORD under Linux, there was little reason to believe the more complex TradeWars installation would succeed.
That made LORD my proof of concept for DOS doors.
The goal wasn’t to build the perfect wrapper or support every feature immediately. The goal was simply to reach the point where a caller could launch LORD from Synchronet, play normally, save their game, and return cleanly to the BBS.
Like many engineering projects, that first success would provide the foundation for everything that followed.
Once I had decided to begin with LORD, the next question became how to run DOS software under modern Linux. Several DOS emulators are available today, but DOSEMU2 stood out because it was specifically designed for running DOS applications inside a Linux environment while maintaining good compatibility with classic software.
Like most of this project, I didn’t discover the solution entirely on my own. One of the most useful resources I found was BBSWordle’s guide to running DOS doors under DOSEMU2. It provided a straightforward explanation of how to install the current packages and pointed me toward the official DOSEMU2 package repository.
With DOSEMU2 installed and the directory structure in place, I finally reached the point where I could begin launching an actual DOS door. As planned, Legend of the Red Dragon became my first target. My goal wasn’t to solve every problem at once—it was simply to get one classic door running reliably before attempting anything more complicated.
That decision proved to be the right one.
The first few attempts were exactly what I expected from software written more than thirty years ago. Some things worked immediately, others failed in unexpected ways, and many small problems only revealed themselves one at a time. Rather than trying to solve everything simultaneously, I treated each successful step as progress. If one change got me a little farther than the previous attempt, I kept it and moved on to the next problem.
One lesson became obvious fairly quickly: most of the work wasn’t running LORD itself. DOSEMU2 had no trouble executing the program. The difficult part was convincing LORD that it was running inside a real multi-node bulletin board system.
That meant making sure the dropfile was correct, the communication settings matched what the game expected, the DOS environment behaved normally, and Synchronet handed control to the game in exactly the right way. Every piece was relatively small by itself, but they all had to work together before the game became stable.
Some solutions came from experimentation. Others came from reading documentation or studying how other sysops had approached the same problems. More often than not, the project moved forward because of a series of small discoveries rather than one dramatic breakthrough.
Before changing emulator settings, verify that your dropfile is correct. Many classic DOS door problems originate in incorrect session information rather than DOSEMU2 itself.
One of the most useful discoveries came from tsali’s dosemu2-bbs-doors project. While comparing my own setup against that project, I noticed a discussion about normalizing lines 18 and 19 of DOOR.SYS before launching certain DOS doors.
That wasn’t something I would have expected to matter, but at this point in the project I was willing to try anything that had worked for someone else.
My wrapper now normalizes the dropfile before every launch, limiting the reported baud rate and remaining session time to values that older DOS software expects while also ensuring the file uses proper DOS-style line endings.
It was a surprisingly small change, but one that solved a compatibility problem I had spent considerably longer trying to understand.
Even after normalizing DOOR.SYS, there were still problems to solve. DOS doors expect to communicate through a COM port, frequently using a FOSSIL driver, and getting those expectations to line up with a modern Linux environment required a considerable amount of experimentation.
This was probably the least scientific part of the project.
I adjusted configuration files, experimented with virtual COM ports, compared behavior between different launches, and gradually removed variables until the remaining configuration became increasingly stable. There wasn’t a single moment where everything suddenly made sense. Instead, the system slowly reached a point where each successful change built on the last.
Looking back, I don’t think I ever consciously decided that I had found the “correct” configuration. Eventually I reached a point where LORD simply worked reliably, and I stopped changing things. That may not be the most satisfying engineering answer, but it’s an honest description of how many real projects evolve. Sometimes stability is discovered incrementally rather than designed all at once.
Getting LORD running successfully was much more important than adding a single game to the BBS. It demonstrated that classic DOS doors could still run naturally under Linux without requiring users to think about emulation or compatibility layers.
Just as importantly, it established the foundation for everything that followed. Once one DOS door was working reliably, I no longer had to wonder whether the overall approach was possible. The remaining challenge became making that infrastructure reusable for additional doors instead of solving the same problems from the beginning each time.
With LORD running reliably, it was finally time to tackle the game that had inspired much of this project from the beginning: TradeWars 2002.
At first, I expected the process to be largely the same. After all, both games were classic DOS doors that relied on DOOR.SYS, virtual COM ports, and the same DOSEMU2 environment. While that assumption proved mostly correct, TradeWars introduced one important difference that reflected its own history.
Like many sysops in the 1990s, I originally began experimenting with the shareware version of TradeWars 2002. That version supports only a single node, so its startup script naturally assumed every caller would always be running on Node 1.
The original START.BAT looked something like this:
SET TWNODE=1
TW2002.EXE
That worked perfectly well while I was experimenting with a single node, but it obviously wasn’t suitable for the registered ten-node version I eventually licensed for Cyber Sword BBS.
Once I upgraded, the startup script needed to become dynamic:
SET TWNODE=%1
TW2002.EXE
Instead of assuming a fixed node number, the wrapper now passes the appropriate Synchronet node as a command-line argument, allowing every caller to launch the correct TradeWars node automatically.
It was a small modification, but it transformed a single-node DOS game into one that fit naturally within a modern multi-node BBS.
TradeWars also expects each node directory to contain the appropriate DOOR.SYS file before the game starts.
Fortunately, by this point the wrapper infrastructure already understood which Synchronet node had launched the door. That made it straightforward to copy the freshly generated DOOR.SYS file into the correct TradeWars node before starting the game.
Once the game exited, Synchronet simply resumed control of the caller’s session exactly as it had with LORD.
From the user’s perspective, all of that preparation is invisible. They choose TradeWars 2002 from the menu, the game starts, and when they leave they return directly to the BBS. Behind the scenes, however, the wrapper has already prepared the DOS environment, selected the correct node, copied the appropriate dropfile, and launched the game inside DOSEMU2.
Originally, LORD and TradeWars 2002 each had their own wrapper script.
That seemed perfectly reasonable at first. They were different games, installed in different directories, maintained different log files, and required slightly different startup commands. Writing two separate scripts felt like the simplest solution.
After both wrappers were working, however, I happened to compare them side by side.
The differences were surprisingly small.
Nearly all of the code was identical. Both wrappers validated the Synchronet node, located the correct DOOR.SYS file, normalized the dropfile, configured virtual COM ports, launched DOSEMU2, logged the session, and returned control to the BBS. The only meaningful differences were things like the game’s installation directory, startup batch file, and log filename.
That realization immediately suggested a better approach.
Instead of maintaining two nearly identical scripts, I merged them into a single wrapper that selects the appropriate configuration using a simple case statement.
If two wrappers differ only in configuration values, they’re probably one reusable wrapper waiting to be written.
case "$DOOR" in
lord)
...
;;
tw2002|tw)
...
;;
esac
The wrapper simply populates a handful of variables—such as the game directory, startup command, and log file—before executing the common launch sequence shared by every supported DOS door.
Looking back, this refactoring feels very similar to what happened earlier with BBSZCodeRunner and BBConsoleRunner. Once I had solved the general problem, there was very little value in maintaining multiple copies of nearly identical code. The better solution was to identify the small pieces that actually varied and make everything else reusable.
That single decision simplified the rest of the project considerably.
Adding another DOS door no longer meant copying an entire wrapper and modifying it by hand. In many cases, it became little more than adding another branch to the case statement and providing a few door-specific values.
The result was dosdoor.sh, a single wrapper capable of launching multiple DOS doors while sharing one common implementation for logging, node handling, DOOR.SYS normalization, COM port configuration, and DOSEMU2 execution.
If you’d like to use dosdoor.sh on your own Synchronet system, the complete source code and documentation are available as part of this project’s supporting files on GitHub.
More importantly, the wrapper represented another step in the same architectural evolution that had been unfolding throughout the project. Rather than writing increasingly specialized scripts, I found myself writing increasingly general solutions that could support entire categories of software with only small amounts of configuration.
dosdoor.shBy the time I merged the LORD and TradeWars wrappers, the resulting script had grown beyond a simple launcher. dosdoor.sh became the piece that tied Synchronet, DOSEMU2, and the individual DOS doors together. Every caller, regardless of which DOS game they selected, passed through the same sequence of preparation before the game was launched.
Rather than trying to make the games aware of Linux, the wrapper adapts Linux to look enough like a traditional DOS BBS that the games simply continue behaving as they always have.
The launch process follows a consistent sequence:
DOOR.SYS.Each of those steps is relatively simple by itself, but together they recreate the environment expected by software originally written for bulletin board systems decades ago.
The first task performed by the wrapper is determining which door the caller requested.
Rather than maintaining separate launch scripts for each game, a simple case statement selects the appropriate configuration before the common launch process begins.
case "$DOOR" in
lord)
DOOR_NAME="LORD"
DOOR_BASE="$DOSEMU_DRIVE_C/LORD"
START_COMMAND="START.BAT"
;;
tw2002|tw)
DOOR_NAME="TradeWars 2002"
DOOR_BASE="$DOSEMU_DRIVE_C/TW2002"
START_COMMAND="START.BAT"
;;
esac
Everything that follows uses those variables. The remainder of the wrapper doesn’t really care whether it’s launching LORD, TradeWars 2002, or another DOS door added in the future.
Before DOSEMU2 is ever started, the wrapper performs a considerable amount of validation.
It verifies that the requested Synchronet node exists, confirms the game directory is present, checks that DOOR.SYS has been generated, ensures the DOSEMU2 configuration file is available, validates the game’s startup batch file, and records the launch in Synchronet’s central log directory.
These checks don’t make the games run any faster, but they do make failures much easier to diagnose. Instead of wondering why a door silently failed to start, the logs generally point directly to the missing file or configuration problem.
Over time, those validation steps became just as valuable as the launch process itself.
One of the wrapper’s most important responsibilities is preparing DOOR.SYS before the game ever sees it.
Every launch normalizes the file by ensuring DOS-style line endings, replacing blank fields with placeholder values where appropriate, and limiting certain values to ranges expected by older DOS software.
By handling that work automatically, every supported DOS door receives a consistent environment without requiring individual games to implement their own compatibility fixes.
It’s a good example of the wrapper quietly solving a problem once instead of forcing every game to solve it independently.
Once the environment has been prepared, the wrapper finally launches DOSEMU2.
If the selected door requires a virtual COM port, the wrapper adds the appropriate configuration automatically before executing the game’s startup batch file.
Conceptually, the launch process looks like this:
Synchronet
│
▼
dosdoor.sh
│
▼
Normalize DOOR.SYS
│
▼
Configure Virtual COM Port
│
▼
DOSEMU2
│
▼
START.BAT
│
▼
DOS Door
Looking at the project now, it’s remarkable how much work occurs before the game itself ever starts. From the caller’s perspective, selecting a DOS door appears almost instantaneous. Behind the scenes, however, the wrapper has already prepared the node, validated the environment, normalized the dropfile, configured communication, and launched an entire DOS environment.
Perhaps my favorite part of dosdoor.sh is that it no longer feels like a LORD wrapper or a TradeWars wrapper.
Instead, it has become a DOS door wrapper.
Adding another supported game rarely requires changing the launch logic itself. Most of the infrastructure already exists. New doors typically need little more than another entry in the configuration section and whatever installation files are unique to that particular game.
That’s exactly where I hoped the project would eventually arrive. Rather than accumulating a collection of unrelated scripts, Cyber Sword BBS now has a reusable piece of infrastructure capable of launching an entire class of software.
The complete dosdoor.sh wrapper, along with installation instructions and supporting files, is available in the project’s GitHub repository for anyone interested in adapting it for their own Synchronet system.
Looking back, bringing classic DOS doors back to life turned out to be the most technically demanding part of the entire Cyber Sword BBS project. Not because DOS software is unusually complicated, but because it expects an environment that modern operating systems no longer provide. Every small compatibility issue represented another assumption that had been perfectly reasonable in the early 1990s but now had to be recreated under Linux.
One of the biggest lessons was that incremental progress matters. I never sat down and designed the final solution from the beginning. Instead, the project advanced through a long series of small improvements. One day it was getting DOSEMU2 installed. Another day it was understanding symbolic links. Later it was discovering how DOOR.SYS needed to be normalized. Eventually it became COM ports, FOSSIL communication, and finally consolidating multiple wrappers into a single reusable script.
Perhaps the most honest thing I can say is that I never reached a moment where everything suddenly made sense. There wasn’t a breakthrough where I knew I had solved DOS doors once and for all. Instead, the system gradually became more reliable as each experiment removed another obstacle. Eventually I reached a point where everything was working consistently—and I simply stopped changing things.
That experience also reminded me of the importance of learning from the work of others. The articles from BBSWordle and the tsali/dosemu2-bbs-doors project saved me countless hours of experimentation. Neither provided my final solution, but both contained pieces of the puzzle that helped me move the project forward. Open source software and technical communities have always worked this way: each person contributes another piece that makes someone else’s project possible.
At the same time, the project reinforced something that had already become a recurring theme throughout this article. Good architecture evolves. I didn’t begin with a reusable DOS wrapper. I began with a wrapper for LORD. Then I built another for TradeWars 2002. Only after both were working did it become obvious that they were solving almost exactly the same problem. The reusable design emerged naturally from experience rather than from careful planning.
Good architecture evolves.
That same pattern appeared throughout the entire project. BBSZCodeRunner became the foundation for BBConsoleRunner. Two DOS wrappers became dosdoor.sh. Logging gradually moved into a centralized location. Existing components like Frotz, DOSEMU2, and the DoorParty Connector were reused instead of replaced. Looking back, Cyber Sword BBS wasn’t built by writing everything from scratch—it was built by understanding good tools, connecting them together, and gradually improving the infrastructure between them.
Perhaps that’s the biggest lesson I took away from rebuilding a modern BBS. The goal was never simply to preserve old software for the sake of nostalgia. It was to demonstrate that good ideas have remarkably long lives. The door model is more than forty years old, yet it still provides a clean and flexible way to integrate software written across multiple decades, operating systems, and programming languages.
Today, callers to Cyber Sword BBS can move seamlessly between native Synchronet JavaScript applications, Linux console games, Interactive Fiction, remote DoorParty games, and classic DOS doors. To them, they’re all simply doors. Behind the scenes, however, each one reaches that point through a different combination of technologies, wrappers, adapters, and services.
That invisible complexity is exactly how it should be. The best engineering often goes unnoticed by the people using it. If this project succeeds, callers won’t spend time thinking about DOSEMU2, wrapper scripts, symbolic links, or dropfiles. They’ll simply enjoy the games—and that’s exactly what the bulletin board systems of the 1980s and 1990s were always trying to achieve.
Over the course of this project, I set out to solve what initially seemed like a fairly straightforward goal: bringing classic BBS doors to a modern Linux-based Synchronet system. Along the way, however, the project became something much larger. What began with Interactive Fiction evolved into reusable wrappers for Linux console applications, integration with remote DoorParty games, native Synchronet JavaScript doors, and finally a complete environment capable of running classic DOS doors under DOSEMU2. Each stage built on the lessons learned from the one before it, gradually transforming a collection of individual solutions into a cohesive architecture.
One of the biggest insights from the project was realizing that not every door should be integrated the same way. Native Synchronet applications don’t require wrappers at all. Linux console games benefit from lightweight adapters that manage per-user state. Remote multiplayer games are better served by specialized connector software, while classic DOS applications require an environment that faithfully recreates the expectations of the original hardware and operating systems. Rather than forcing every application into a single model, Cyber Sword BBS uses the simplest integration that best fits each technology, allowing software spanning more than four decades of computing history to coexist naturally on the same system.
Perhaps the most rewarding part of the project wasn’t getting individual games to run—it was watching the architecture mature. Wrapper scripts evolved from one-off utilities into reusable infrastructure. Existing components such as Frotz, DOSEMU2, and the DoorParty Connector were reused instead of reinvented. Helpful articles, open-source projects, and years of accumulated knowledge from the BBS community all contributed small pieces that eventually came together into a stable and maintainable system. Looking back, the finished architecture wasn’t something I designed all at once. It emerged gradually through experimentation, refactoring, and a willingness to improve each piece as new ideas presented themselves.
Today, callers to Cyber Sword BBS can move seamlessly between Interactive Fiction, native Linux console games, remote DoorParty titles, Synchronet JavaScript applications, and classic DOS doors without ever needing to think about the layers of technology making that possible. That’s exactly how it should be. The best engineering often goes unnoticed because it allows people to focus on what they came to do rather than the infrastructure supporting it. If this project accomplishes anything, I hope it demonstrates that the classic BBS door model remains every bit as flexible today as it was decades ago—and that with a little creativity, these remarkable programs can continue entertaining and connecting people for many years to come.
]]>Before the Internet became a single connected system, online communication existed as separate networks. They overlapped, competed, and eventually merged into what became the modern Internet.
The familiar story of the Internet is a straight line toward TCP/IP and the Web. The reality was messier. Bulletin Board Systems, FidoNet, commercial services, and early Internet access all coexisted, each shaping how people experienced being online.
What follows is that overlap period: how people connected, how messages moved between systems, and how dial-up Internet bridged isolated communities into a shared network.
“Each BBS was its own world, reachable only by dialing into it directly.”
Bulletin Board Systems were where online life first felt local. Each system ran on a single machine, usually in someone’s home or office, connected through dial-up modems and telephone lines.
There was no central platform. Each BBS stood alone.
Discovery was simple and uncertain. Listings in magazines or local newsletters provided only a name and a phone number. In Sacramento, California Computer News listed nearby systems in the back pages. You dialed first and learned what the system was.
That uncertainty shaped the experience more than anything else.
Tip: Early online discovery was not search-based — it was trust-based dialing.
Systems like Colossus and Third Rock were discovered through repetition rather than description. They became familiar only after repeated visits. Colossus later turned out to be run by a teacher at a local high school, which blurred the line between online space and real life in a way that felt natural at the time.
Use often became involvement. For a time, I helped manage user uploads on a local BBS, organizing files and maintaining system flow. Users were often part of the system’s operation rather than separate from it.
Every system reflected its operator. Some were strict, others informal, but all of them were personal in a way modern platforms rarely are. The sysop defined structure, tone, and culture more than any software layer.
The personality of a BBS mattered as much as its features. Some systems felt open and conversational, while others were tightly moderated or focused on specific communities. You did not learn “the BBS experience” once—you learned a different version every time you dialed a new number.
“Messages did not travel instantly — they moved on schedules, not demand.”
As BBS systems expanded, they began exchanging messages through scheduled dial-up connections. That coordination became FidoNet.
Each system acted as a node in a larger chain. Some systems functioned as hubs, collecting messages and forwarding them onward. Messages moved from local systems to regional hubs and then across broader networks, eventually reaching other countries.
Nothing traveled instantly. Everything moved in batches shaped by timing.
Transfers happened during scheduled windows, often overnight when phone rates were lower and lines were free. Connectivity was not continuous — it was planned.
Routing was configured by sysops who determined who called whom and when. The network scaled through coordination rather than centralized infrastructure.
In practice, message delivery varied depending on geography and timing. Local messages might appear within hours, while international transfers could take days. Communication followed rhythm rather than immediacy.
Tip: FidoNet scaled like a postal system made of phone calls — delay was part of the design.
Commercial services developed alongside BBS culture but followed a more centralized model. Systems like CompuServe, AOL, Prodigy, and GEnie created structured environments where messaging, forums, downloads, and content libraries lived inside a single controlled boundary.
These systems were easier to access, but far less flexible. Everything existed inside a managed ecosystem rather than a distributed network.
“The platform was the boundary — everything happened inside it.”
Even within these controlled environments, communities formed that felt distinct from the platform itself. Users often identified more with specific forums or groups than with the service as a whole.
Over time, gateways connected these services to email and Usenet. The separation between closed services and open networks gradually dissolved.
Dial-Up Internet still relied on telephone lines, but the model shifted. Instead of calling a specific system, users connected to an Internet Service Provider that acted as a gateway into a larger network.
Connections were temporary. A session began with a dial-in, a handshake, and a short window of use before disconnection. The Internet only existed while the line was active.
Tip: “Always-on Internet” did not exist yet. Being online was an intentional act, not a background state.
Dial-up shaped usage in practical ways. Pages loaded slowly, downloads took time, and interruptions were normal. In many homes, the phone line could not be used for anything else while online.
“Being online meant occupying the phone line — and everything else paused.”
Connections dropped without warning, and busy signals were part of everyday experience. Even installing early Linux distributions, including Red Hat releases, often required repeated attempts over unstable connections.
The modem handshake itself became recognizable—a sequence of tones marking the shift from a private phone line into a shared network. Some users could tell from the sound alone whether a connection would hold.
Some users combined multiple modems or accounts to increase speed. It worked, but only as an adaptation to constraint rather than a designed feature.
The Internet did not emerge as a single invention but through convergence. Separate networks gradually adopted shared protocols, especially TCP/IP, allowing them to interconnect.
ARPANET evolved into NSFNET, and commercial providers expanded access. Standardization created compatibility, but not immediate unification.
The Web later simplified everything into pages and links, hiding most of the underlying network structure from everyday users.
Tip: Convergence did not erase older systems — it made them interoperable until they gradually faded from use.
For a long period, older and newer systems existed at the same time. BBS networks, AOL, Usenet, IRC, email, and the early Web all operated in parallel.
Users moved between systems depending on need, cost, and access. No single system replaced the others immediately.
“For years, ‘the Internet’ was not one thing — it was a collection of ways to connect.”
Some BBS systems persisted into the Internet era, while others adapted by adding Internet connectivity while preserving their original structure.
Change happened through overlap, not replacement.
Many modern communication patterns come directly from these systems. Forums carry forward the structure of BBS message boards. IRC shaped real-time chat. File areas became the foundation for modern sharing systems. Even usernames and handles reflect earlier identity systems.
Communication was slower and more deliberate, and systems shaped interaction as much as users shaped them.
Tip: Many modern patterns are not inventions — they are compressions of older network behavior.
BBS systems still exist today. Modern software such as Synchronet and Mystic BBS runs on current infrastructure while preserving the original structure of message boards, file areas, and sysop-controlled communities.
These systems are not recreations. They continue the same model using modern transport layers like telnet, SSH, and web access.
One example is bbs.excalibursheath.com, a modern BBS modeled after 1980s and 1990s systems. It preserves structure while running on modern infrastructure.
“A modern BBS is not nostalgia — it is the same architecture running on different wires.”
Online communication developed through overlapping systems rather than a single unified design.
BBS networks, commercial services, academic systems, and early Internet access all coexisted before converging into a shared structure.
Dial-Up Internet acted as the transition layer between isolated systems and always-on connectivity. It was slow and unreliable, but it connected systems that previously did not interact.
Many of the patterns established during that period still shape modern communication. Some systems continue to operate today, preserving the structure of early online communities in updated form.
]]>