Episode 79 – 80 – OS/2

Clean desktop where we see the Control Center’s (Object Desktop) information area (drive space, swap size, time, can also have CPU meter, etc.). Those 4 “bitmaps” up there are virtual desktops.
The Tab Launchpad (Object Desktop) and Control Center can be arranged, placed and duplicated at will. Object Desktop’s Window List also includes a command history, for frequently executed commands.
Both MOD and MID (on Desktop) are shadows of actual folders somewhere else (you can locate them in a click) containing the data, but they act exactly like their big brother folder.
CC – https://www.os2world.com/

OS/2 is a series of computer operating systems, initially created by Microsoft and IBM under the leadership of IBM software designer Ed Iacobucci. As a result of a feud between the two companies over how to position OS/2 relative to Microsoft’s new Windows 3.1 operating environment the two companies severed the relationship in 1992 and OS/2 development fell to IBM exclusively. The name stands for “Operating System/2”, because it was introduced as part of the same generation change release as IBM’s “Personal System/2 (PS/2)” line of second-generation personal computers. The first version of OS/2 was released in December 1987 and newer versions were released until December 2001.

OS/2 was intended as a protected-mode successor of PC DOS. Notably, basic system calls were modeled after MS-DOS calls; their names even started with “Dos” and it was possible to create “Family Mode” applications – text mode applications that could work on both systems. Because of this heritage, OS/2 shares similarities with Unix, Xenix, and Windows NT.

IBM discontinued its support for OS/2 on 31 December 2006. Since then, OS/2 has been developed, supported and sold by two different third-party vendors under license from IBM – first by Serenity Systems as eComStation since 2001 and later by Arca Noae LLC as ArcaOS since 2017.

Development History
1985-1989: Joint Development

The development of OS/2 began when IBM and Microsoft signed the “Joint Development Agreement” in August 1985. It was code-named “CP/DOS” and it took two years for the first product to be delivered.

OS/2 1.0 was announced in April 1987 and released in December. The original release is textmode-only, and a GUI was introduced with OS/2 1.1 about a year later. OS/2 features an API for controlling the video display (VIO) and handling keyboard and mouse events so that programmers writing for protected-mode need not call the BIOS or access hardware directly. Other development tools included a subset of the video and keyboard APIs as linkable libraries so that family mode programs are able to run under MS-DOS and, in the OS/2 Extended Edition v1.0, a database engine called Database Manager or DBM (this was related to DB2, and should not be confused with the DBM family of database engines for Unix and Unix-like operating systems). A task-switcher named Program Selector was available through the Ctrl-Esc hotkey combination, allowing the user to select among multitasked text-mode sessions (or screen groups; each can run multiple programs).

Communications and database-oriented extensions were delivered in 1988, as part of OS/2 1.0 Extended Edition: SNA, X.25/APPC/LU 6.2, LAN Manager, Query Manager, SQL.OS/2 1.1 was the first version to feature the Presentation Manager GUI.

The promised user interface, Presentation Manager, was introduced with OS/2 1.1 in October 1988. It had a similar user interface to Windows 2.1, which was released in May of that year. (The interface was replaced in versions 1.2 and 1.3 by a look closer in appearance to Windows 3.0).

The Extended Edition of 1.1, sold only through IBM sales channels, introduced distributed database support to IBM database systems and SNA communications support to IBM mainframe networks.

In 1989, Version 1.2 introduced Installable Filesystems and, notably, the HPFS filesystem. HPFS provided a number of improvements over the older FAT file system, including long filenames and a form of alternate data streams called Extended Attributes. In addition, extended attributes were also added to the FAT file system.

The Extended Edition of 1.2 introduced TCP/IP and Ethernet support.

OS/2- and Windows-related books of the late 1980s acknowledged the existence of both systems and promoted OS/2 as the system of the future.

1990 – Breakup

The collaboration between IBM and Microsoft unraveled in 1990, between the releases of Windows 3.0 and OS/2 1.3. During this time, Windows 3.0 became a tremendous success, selling millions of copies in its first year. Much of its success was because Windows 3.0 (along with MS-DOS) was bundled with most new computers. OS/2, on the other hand, was available only as an additional stand-alone software package. In addition, OS/2 lacked device drivers for many common devices such as printers, particularly non-IBM hardware. Windows, on the other hand, supported a much larger variety of hardware. The increasing popularity of Windows prompted Microsoft to shift its development focus from cooperating on OS/2 with IBM to building its own business based on Windows.

Several technical and practical reasons contributed to this breakup.

The two companies had significant differences in culture and vision. Microsoft favored the open hardware system approach that contributed to its success on the PC; IBM sought to use OS/2 to drive sales of its own hardware, including systems that could not support the features Microsoft wanted. Microsoft programmers also became frustrated with IBM’s bureaucracy and its use of lines of code to measure programmer productivity. IBM developers complained about the terseness and lack of comments in Microsoft’s code, while Microsoft developers complained that IBM’s code was bloated.

The two products have significant differences in API. OS/2 was announced when Windows 2.0 was near completion, and the Windows API already defined. However, IBM requested that this API be significantly changed for OS/2.Therefore, issues surrounding application compatibility appeared immediately. OS/2 designers hoped for source code conversion tools, allowing complete migration of Windows application source code to OS/2 at some point. However, OS/2 1.x did not gain enough momentum to allow vendors to avoid developing for both OS/2 and Windows in parallel.

OS/2 1.x targets the Intel 80286 processor and DOS fundamentally doesn’t. IBM insisted on supporting the 80286 processor, with its 16-bit segmented memory mode, because of commitments made to customers who had purchased many 80286-based PS/2s as a result of IBM’s promises surrounding OS/2. Until release 2.0 in April 1992, OS/2 ran in 16-bit protected mode and therefore could not benefit from the Intel 80386’s much simpler 32-bit flat memory model and virtual 8086 mode features. This was especially painful in providing support for DOS applications. While, in 1988, Windows/386 2.1 could run several cooperatively multitasked DOS applications, including expanded memory (EMS) emulation, OS/2 1.3, released in 1991, was still limited to one 640 kB “DOS box”.

Given these issues, Microsoft started to work in parallel on a version of Windows which was more future-oriented and more portable. The hiring of Dave Cutler, former VAX/VMS architect, in 1988 created an immediate competition with the OS/2 team, as Cutler did not think much of the OS/2 technology and wanted to build on his work on the MICA project at Digital rather than creating a “DOS plus”. His NT OS/2 was a completely new architecture.

IBM grew concerned about the delays in development of OS/2 2.0. Initially, the companies agreed that IBM would take over maintenance of OS/2 1.0 and development of OS/2 2.0, while Microsoft would continue development of OS/2 3.0. In the end, Microsoft decided to recast NT OS/2 3.0 as Windows NT, leaving all future OS/2 development to IBM. From a business perspective, it was logical to concentrate on a consumer line of operating systems based on DOS and Windows, and to prepare a new high-end system in such a way as to keep good compatibility with existing Windows applications. While it waited for this new high-end system to develop, Microsoft would still receive licensing money from Xenix and OS/2 sales. Windows NT’s OS/2 heritage can be seen in its initial support for the HPFS filesystem, text mode OS/2 1.x applications, and OS/2 LAN Manager network support. Some early NT materials even included OS/2 copyright notices embedded in the software. One example of NT OS/2 1.x support is in the WIN2K resource kit. Windows NT could also support OS/2 1.x Presentation Manager and AVIO applications with the addition of the Windows NT Add-On Subsystem for Presentation Manager.

1992: 32bit era

OS/2 2.0 was released in April 1992. At the time, the suggested retail price was U.S. $195, while Windows retailed for $150.

OS/2 2.0 provided a 32-bit API for native programs, though the OS itself still contained some 16-bit code and drivers. It also included a new OOUI (object-oriented user interface) called the Workplace Shell. This was a fully object-oriented interface that was a significant departure from the previous GUI. Rather than merely providing an environment for program windows (such as the Program Manager), the Workplace Shell provided an environment in which the user could manage programs, files and devices by manipulating objects on the screen. With the Workplace Shell, everything in the system is an “object” to be manipulated.

DOS Compatibility

OS/2 2.0 was touted by IBM as “a better DOS than DOS and a better Windows than Windows”. It managed this by including the fully-licensed MS-DOS 5.0, which had been patched and improved upon. For the first time, OS/2 was able to run more than one DOS application at a time. This was so effective, that it allowed OS/2 to run a modified copy of Windows 3.0, itself a DOS extender, including Windows 3.0 applications.

Because of the limitations of the Intel 80286 processor, OS/2 1.x could run only one DOS program at a time, and did this in a way that allowed the DOS program to have total control over the computer. A problem in DOS mode could crash the entire computer. In contrast, OS/2 2.0 could leverage the virtual 8086 mode of the Intel 80386 processor to create a much safer virtual machine in which to run DOS programs. This included an extensive set of configuration options to optimize the performance and capabilities given to each DOS program. Any real-mode operating system (such as 8086 Xenix) could also be made to run using OS/2’s virtual machine capabilities, subject to certain direct hardware access limitations.The OS/2 2.0 upgrade box

Like most 32-bit environments, OS/2 could not run protected-mode DOS programs using the older VCPI interface, unlike the Standard mode of Windows 3.1; it only supported programs written according to DPMI. (Microsoft discouraged the use of VCPI under Windows 3.1, however, due to performance degradation.)

Unlike Windows NT, OS/2 always allowed DOS programs the possibility of masking real hardware interrupts, so any DOS program could deadlock the machine in this way. OS/2 could, however, use a hardware watchdog on selected machines (notably IBM machines) to break out of such a deadlock. Later, release 3.0 leveraged the enhancements of newer Intel 80486 and Intel Pentium processors—the Virtual Interrupt Flag (VIF), which was part of the Virtual Mode Extensions (VME)—to solve this problem.

Windows 3.x compatibility

Compatibility with Windows 3.0 (and later Windows 3.1) was achieved by adapting Windows user-mode code components to run inside a virtual DOS machine (VDM). Originally, a nearly complete version of Windows code was included with OS/2 itself: Windows 3.0 in OS/2 2.0, and Windows 3.1 in OS/2 2.1. Later, IBM developed versions of OS/2 that would use whatever Windows version the user had installed previously, patching it on the fly, and sparing the cost of an additional Windows license. It could either run full-screen, using its own set of video drivers, or “seamlessly,” where Windows programs would appear directly on the OS/2 desktop. The process containing Windows was given fairly extensive access to hardware, especially video, and the result was that switching between a full-screen WinOS/2 session and the Workplace Shell could occasionally cause issues.

Because OS/2 only runs the user-mode system components of Windows, it is incompatible with Windows device drivers (VxDs) and applications that require them.

Multiple Windows applications run by default in a single Windows session – multitasking cooperatively and without memory protection – just as they would under native Windows 3.x. However, to achieve true isolation between Windows 3.x programs, OS/2 can also run multiple copies of Windows in parallel, with each copy residing in a separate VDM. The user can then optionally place each program either in its own Windows session – with preemptive multitasking and full memory protection between sessions, though not within them – or allow some applications to run together cooperatively in a shared Windows session while isolating other applications in one or more separate Windows sessions. At the cost of additional hardware resources, this approach can protect each program in any given Windows session (and each instance of Windows itself) from every other program running in any separate Windows session (though not from other programs running in the same Windows session).

Whether Windows applications are running in full-screen or windowed mode, and in one Windows session or several, it is possible to use DDE between OS/2 and Windows applications, and OLE between Windows applications only.

1994 – 1996: The “Warp” Years

Released in 1994, OS/2 version 3.0 was labelled as OS/2 Warp to highlight the new performance benefits, and generally to freshen the product image. “Warp” had originally been the internal IBM name for the release: IBM claimed that it had used Star Trek terms as internal names for prior OS/2 releases, and that this one seemed appropriate for external use as well. At the launch of OS/2 Warp in 1994, Patrick Stewart was to be the Master of Ceremonies; however Kate Mulgrew of the then-upcoming series Star Trek: Voyager was substituted at the last minute.

OS/2 Warp offers a host of benefits over OS/2 2.1, notably broader hardware support, greater multimedia capabilities, Internet-compatible networking, and it includes a basic office application suite known as IBM Works. It was released in two versions: the less expensive “Red Spine” and the more expensive “Blue Spine” (named for the color of their boxes). “Red Spine” was designed to support Microsoft Windows applications by utilizing any existing installation of Windows on the computer’s hard drive. “Blue Spine” includes Windows support in its own installation, and so can support Windows applications without a Windows installation. As most computers were sold with Microsoft Windows pre-installed and the price was less, “Red Spine” was the more popular product. OS/2 Warp Connect—which has full LAN client support built-in—followed in mid-1995. Warp Connect was nicknamed “Grape”.

In OS/2 2.0, most performance-sensitive subsystems, including the graphics (Gre) and multimedia (MMPM/2) systems, were updated to 32-bit code in a fixpack, and included as part of OS/2 2.1. Warp 3 brought about a fully 32-bit windowing system, while Warp 4 introduced the object-oriented 32-bit GRADD display driver model.

In 1996, Warp 4 added Java and speech recognition software. IBM also released server editions of Warp 3 and Warp 4 which bundled IBM’s LAN Server product directly into the operating system installation. A personal version of Lotus Notes was also included, with a number of template databases for contact management, brainstorming, and so forth. The UK-distributed free demo CD-ROM of OS/2 Warp essentially contained the entire OS and was easily, even accidentally, cracked meaning that even people who liked it did not have to buy it. This was seen as a backdoor tactic to increase the number of OS/2 users, in the belief that this would increase sales and demand for third-party applications, and thus strengthen OS/2’s desktop numbers.  This suggestion was bolstered by the fact that this demo version had replaced another which was not so easily cracked, but which had been released with trial versions of various applications. In 2000, the July edition of Australian Personal Computer magazine bundled software CD-ROMs, included a full version of Warp 4 that required no activation and was essentially a free release. Special versions of OS/2 2.11 and Warp 4 also included symmetric multiprocessing (SMP) support.

OS/2 sales were largely concentrated in networked computing used by corporate professionals; however, by the early 1990s, it was overtaken by Microsoft Windows NT. While OS/2 was arguably technically superior to Microsoft Windows 95, OS/2 failed to develop much penetration in the consumer and stand-alone desktop PC segments; there were reports that it could not be installed properly on IBM’s own Aptiva series of home PCs. Microsoft made an offer in 1994 where IBM would receive the same terms as Compaq (the largest PC manufacturer at the time) for a license of Windows 95, if IBM ended development of OS/2 completely. IBM refused and instead went with an “IBM First” strategy of promoting OS/2 Warp and disparaging Windows, as IBM aimed to drive sales of its own software as well as hardware. By 1995, Windows 95 negotiations between IBM and Microsoft, which were already difficult, stalled when IBM purchased Lotus SmartSuite, which would have directly competed with Microsoft Office. As a result of the dispute, IBM signed the license agreement 15 minutes before Microsoft’s Windows 95 launch event, which was later than their competitors and this badly hurt sales of IBM PCs. IBM officials later conceded that OS/2 would not have been a viable operating system to keep them in the PC business.

Workplace OS

In 1991, IBM started development on an intended replacement for OS/2 called Workplace OS. This was an entirely new product, brand new code, that borrowed only a few sections of code from both the existing OS/2 and AIX products. It used an entirely new microkernel code base, intended (eventually) to host several of IBM’s operating systems (including OS/2) as microkernel “personalities”. It also included major new architectural features including a system registry, JFS, support for UNIX graphics libraries, and a new driver model.

Workplace OS was developed solely for POWER platforms, and IBM intended to market a full line of PowerPCs in an effort to take over the market from Intel. A mission was formed to create prototypes of these machines and they were disclosed to several Corporate customers, all of whom raised issues with the idea of dropping Intel.

Advanced plans for the new code base would eventually include replacement of the OS/400 operating system by Workplace OS, as well as a microkernel product that would have been used in industries such as telecommunications and set-top television receivers.

A partially functional pre-alpha version of Workplace OS was demonstrated at Comdex, where a bemused Bill Gates stopped by the booth. The second and last time it would be shown in public was at an OS/2 user group in Phoenix, Arizona; the pre-alpha code refused to boot.

It was released in 1995. But with $990 million being spent per year on development of this as well as Workplace OS, and no possible profit or widespread adoption, the end of the entire Workplace OS and OS/2 product line was near.


A project was launched internally by IBM to evaluate the looming competitive situation with Microsoft Windows 95. Primary concerns included the major code quality issues in the existing OS/2 product (resulting in over 20 service packs, each requiring more diskettes than the original installation), and the ineffective and heavily matrixed development organization in Boca Raton (where the consultants reported that “basically, everybody reports to everybody”) and Austin.

That study, tightly classified as “Registered Confidential” and printed only in numbered copies, identified untenable weaknesses and failures across the board in the Personal Systems Division as well as across IBM as a whole. This resulted in a decision being made at a level above the Division to cut over 95% of the overall budget for the entire product line, end all new development (including Workplace OS), eliminate the Boca Raton development lab, end all sales and marketing efforts of the product, and lay off over 1,300 development individuals (as well as sales and support personnel). $990 million had been spent in the last full year. Warp 4 became the last distributed version of OS/2.

2001: Fading out

A small and dedicated community remained faithful to OS/2 for many years after its final mainstream release but overall, OS/2 failed to catch on in the mass market and is little used outside certain niches where IBM traditionally had a stronghold. For example, many bank installations, especially automated teller machines, run OS/2 with a customized user interface; French SNCF national railways used OS/2 1.x in thousands of ticket selling machines. Telecom companies such as Nortel used OS/2 in some voicemail systems. Also, OS/2 was used for the host PC used to control the Satellite Operations Support System equipment installed at NPR member stations from 1994 to 2007, and used to receive the network’s programming via satellite.

Although IBM began indicating shortly after the release of Warp 4 that OS/2 would eventually be withdrawn, the company did not end support until December 31, 2006. Sales of OS/2 stopped on December 23, 2005. The latest IBM OS/2 Warp version is 4.52, which was released for both desktop and server systems in December 2001.

IBM is still delivering defect support for a fee. IBM urges customers to migrate their often highly complex applications to e-business technologies such as Java in a platform-neutral manner. Once application migration is completed, IBM recommends migration to a different operating system, suggesting Linux as an alternative.

Third-Party Development

After IBM discontinued development of OS/2, various third parties approached IBM to take over future development of the operating system. The OS/2 software vendor Stardock made such a proposal to IBM in 1999, but it was not followed through by the company. Serenity Systems succeeded in negotiating an agreement with IBM, and began reselling OS/2 as eComStation in 2001. eComStation is now sold by XEU.com, the most recent version (2.1) was released in 2011. In 2015, Arca Noae, LLC announced that they had secured an agreement with IBM to resell OS/2. They released the first version of their OS/2-based operating system in 2017 as ArcaOS. As of 2021, there have been multiple releases of ArcaOS, and it remains under active development.

Petitions for Open Source

Many people hoped that IBM would release OS/2 or a significant part of it as open source. Petitions were held in 2005 and 2007, but IBM refused them, citing legal and technical reasons. It is unlikely that the entire OS will be open at any point in the future because it contains third-party code to which IBM does not have copyright, and much of this code is from Microsoft. IBM also once engaged in a technology transfer with Commodore, licensing Amiga technology for OS/2 2.0 and above, in exchange for the REXX scripting language. This means that OS/2 may have some code that was not written by IBM, which can therefore prevent the OS from being re-announced as open-sourced in the future. On the other hand, IBM donated Object REXX for Windows and OS/2 to the Open Object REXX project maintained by the REXX Language Association on SourceForge.

There was a petition, arranged by OS2World, to open parts of the OS. Open source operating systems such as Linux have already profited from OS/2 indirectly through IBM’s release of the improved JFS file system, which was ported from the OS/2 code base. As IBM didn’t release the source of the OS/2 JFS driver, developers ported the Linux driver back to eComStation and added the functionality to boot from a JFS partition. This new JFS driver has been integrated into eComStation v2.0, and later into ArcaOS 5.0.

Features and Technology

User Interface

The graphic system has a layer named Presentation Manager that manages windows, fonts, and icons. This is similar in functionality to a non-networked version of X11 or the Windows GDI. On top of this lies the Workplace Shell (WPS) introduced in OS/2 2.0. WPS is an object-oriented shell allowing the user to perform traditional computing tasks such as accessing files, printers, launching legacy programs, and advanced object oriented tasks using built-in and third-party application objects that extended the shell in an integrated fashion not available on any other mainstream operating system. WPS follows IBM’s Common User Access user interface standards.

WPS represents objects such as disks, folders, files, program objects, and printers using the System Object Model (SOM), which allows code to be shared among applications, possibly written in different programming languages. A distributed version called DSOM allowed objects on different computers to communicate. DSOM is based on CORBA. The object oriented aspect of SOM is similar to, and a direct competitor to, Microsoft’s Component Object Model, though it is implemented in a radically different manner; for instance, one of the most notable differences between SOM and COM is SOM’s support for inheritance (one of the most fundamental concepts of OO programming)—COM does not have such support. SOM and DSOM are no longer being developed.

The multimedia capabilities of OS/2 are accessible through Media Control Interface commands. The last update (bundled with the IBM version of Netscape Navigator plugins) added support for MPEG files. Support for newer formats such as PNG, progressive JPEG, DivX, Ogg, and MP3 comes from third parties. Sometimes it is integrated with the multimedia system, but in other offers it comes as standalone applications.

Application development

OS/2 also includes a radical advancement in application development with compound document technology called OpenDoc, which was developed with Apple. OpenDoc proved interesting as a technology, but was not widely used or accepted by users or developers. OpenDoc is also no longer being developed.


The TCP/IP stack is based on the open source BSD stack as visible with SCCS what compatible tools. IBM included tools such as ftp and telnet and even servers for both commands. IBM sold several networking extensions including NFS support and an X11 server.


Hardware vendors were reluctant to support device drivers for alternative operating systems including OS/2 and Linux, leaving users with few choices from a select few vendors. To relieve this issue for video cards, IBM licensed a reduced version of the Scitech display drivers, allowing users to choose from a wide selection of cards supported through Scitech’s modular driver design.


OS/2 has historically been more difficult to run in a virtual machine than most other legacy x86 operating systems because of its extensive reliance on the full set of features of the x86 CPU; in particular, OS/2’s use of ring 2 prevented it from running in VMware. Emulators such as QEMU and Bochs don’t suffer from this problem and can run OS/2. A beta of VMware Workstation 2.0 released in January 2000 was the first hypervisor that could run OS/2 at all. Later, the company decided to drop official OS/2 support.

VirtualPC from Microsoft (originally Connectix) has been able to run OS/2 without hardware virtualization support for many years. It also provided “additions” code which greatly improves host–guest OS interactions in OS/2. The additions are not provided with the current version of VirtualPC, but the version last included with a release may still be used with current releases. At one point, OS/2 was a supported host for VirtualPC in addition to a guest. Note that OS/2 runs only as a guest on those versions of VirtualPC that use virtualization (x86 based hosts) and not those doing full emulation (VirtualPC for Mac).

VirtualBox from Oracle Corporation (originally InnoTek, later Sun) supports OS/2 1.x, Warp 3 through 4.5, and eComStation as well as “Other OS/2” as guests. However, attempting to run OS/2 and eComStation can still be difficult, if not impossible, because of the strict requirements of VT-x/AMD-V hardware-enabled virtualization and only ACP2/MCP2 is reported to work in a reliable manner.

ArcaOS supports being run as a virtual machine guest inside VirtualBox, VMware ESXi and VMWare Workstation. It ships with VirtualBox Guest Additions, and driver improvements to improve performance as a guest operating system.

The difficulties in efficiently running OS/2 have, at least once, created an opportunity for a new virtualization company. A large bank in Moscow needed a way to use OS/2 on newer hardware that OS/2 did not support. As virtualization software is an easy way around this, the company desired to run OS/2 under a hypervisor. Once it was determined that VMware was not a possibility, it hired a group of Russian software developers to write a host-based hypervisor that would officially support OS/2. Thus, the Parallels, Inc. company and their Parallels Workstation product was born.


Some problems were classic subjects of comparison with other operating systems:

  • Synchronous input queue (SIQ): if a GUI application was not servicing its window messages, the entire GUI system could get stuck and a reboot was required. This problem was considerably reduced with later Warp 3 fixpacks and refined by Warp 4, by taking control over the application after it had not responded for several seconds.
  • No unified object handles (OS/2 v2.11 and earlier): The availability of threads probably led system designers to overlook mechanisms which allow a single thread to wait for different types of asynchronous events at the same time, for example the keyboard and the mouse in a “console” program. Even though select was added later, it only worked on network sockets. In case of a console program, dedicating a separate thread for waiting on each source of events made it difficult to properly release all the input devices before starting other programs in the same “session”. As a result, console programs usually polled the keyboard and the mouse alternately, which resulted in wasted CPU and a characteristic “jerky” reactivity to user input. In OS/2 3.0 IBM introduced a new call for this specific problem.

Historical uses

OS/2 has been widely used in Iran Export Bank (Bank Saderat Iran) in their teller machines, ATMs and local servers (over 30,000 working stations). As of 2011, the bank moved to virtualize and renew their infrastructure by moving OS/2 to Virtual Machines running over Windows.

OS/2 was widely used in Brazilian banks. Banco do Brasil had a peak 10,000 machines running OS/2 Warp in the 1990s. OS/2 was used in automated teller machines until 2006. The workstations and automated teller machines and attendant computers have been migrated to Linux.

OS/2 has been used in the banking industry. Suncorp bank in Australia still ran its ATM network on OS/2 as late as 2002. ATMs at Perisher Blue used OS/2 as late as 2009, and even the turn of the decade.

OS/2 was widely adopted by accounting professionals and auditing companies. In mid-1990s native 32-bit accounting software were well developed and serving corporate markets.

OS/2 ran the faulty baggage handling system at Denver International Airport. The OS was eventually scrapped, but the software written for the system led to massive delays in the opening of the new airport. The OS itself was not at fault, but the software written to run on the OS was. The baggage handling system was eventually removed.

OS/2 was used by radio personality Howard Stern. He once had a 10-minute on-air rant about OS/2 versus Windows 95 and recommended OS/2. He also used OS/2 on his IBM 760CD laptop.

OS/2 was used as part of the Satellite Operations Support System (SOSS) for NPR’s Public Radio Satellite System. SOSS was a computer-controlled system using OS/2 that NPR member stations used to receive programming feeds via satellite. SOSS was introduced in 1994 using OS/2 3.0, and was retired in 2007, when NPR switched over to its successor, the ContentDepot.

OS/2 was used to control the SkyTrain automated light rail system in Vancouver, Canada until the late 2000s when it was replaced by Windows XP.

OS/2 was used in the London Underground Jubilee Line Extension Signals Control System (JLESCS) in London, England. This control system delivered by Alcatel was in use from 1999 to 2011 i.e. between abandonment before opening of the line’s unimplemented original automatic train control system and the present SelTrac system. JLESCS did not provide automatic train operation only manual train supervision. Six OS/2 local site computers were distributed along the railway between Stratford and Westminster, the shunting tower at Stratford Market Depot, and several formed the central equipment located at Neasden Depot. It was once intended to cover the rest of the line between Green Park and Stanmore but this was never introduced.

OS/2 has been used by The Co-operative Bank in the UK for its domestic call centre staff, using a bespoke program created to access customer accounts which cannot easily be migrated to Windows.

OS/2 has been used by the Stop & Shop supermarket chain (and has been installed in new stores as recently as March 2010).

OS/2 has been used on ticket machines for Tramlink in outer-London.

OS/2 has been used in New York City’s subway system for MetroCards. Rather than interfacing with the user, it connects simple computers and the mainframes. When NYC MTA finishes its transition to contactless payment OS/2 will be removed.

OS/2 was used in checkout systems at Safeway supermarkets.

OS/2 was used by Trenitalia, both for the desktops at Ticket Counters and for the Automatic Ticket Counters up to 2011. Incidentally, the Automatic Ticket Counters with OS/2 were more reliable than the current ones running a flavor of Windows.

OS/2 was used as the main operating system for Abbey National General Insurance motor and home direct call centre products using the PMSC Series III insurance platform on DB2.2 from 1996-2001.

IBM Products utilizing OS/2

IBM has used OS/2 in a wide variety of hardware products, effectively as a form of embedded operating system.

ProductProduct TypeUsage of OS/2
IBM 3494Tape LibraryUsed as the operating system for the Library Manager (LM) that controlled the tape accessor (robot)
IBM 3745Communications ControllerUsed as the operating system for the Service Processor (SP) and if installed, the Network Node Processor (NNP).
IBM 3890Document ProcessorThe 3890/XP1 was announced November 12, 1988. It initially used OS/2 1.1 Extended Edition on a PS/2 Model 80 to emulate the stacker control software that previously ran on a System 360. IBM later switched to OS/2 Warp.
IBM 473xATMUsed in a range of Automatic Teller Machines manufactured by IBM. Was also used in later 478x ATMs manufactured with Diebold.
IBM 9672MainframeUsed as the operating system for the Support Element (SE). Was also used in later mainframe models such as the IBM 2064 and 2074.





Episode 76 – 77 – 78: Oberon, Plan 9 and Inferno

None of these are Unix

It’s true. None of the Operating System’s I want to talk about today are what We would call UNIX or Linux like Operating Systems. They might have similarities and/or resemblance to UNIX like systems ( Plan9 was made in Bell Labs where UNIX was born and was indeed building on the UNIX Concepts ) but there is a clear connetion between these systems. They are not usual in any way 🙂 no , seriously they are influenced by one another ( or built upon the experience of one another) in order such as:

Oberon >> Plan9 >> Inferno

One screenshot of the Oberon Operating System

The Oberon System is a modular, single-user, single-process, multitasking operating system written in the programming language Oberon. It was originally developed in the late 1980s at ETH Zurich. The Oberon System has an unconventional visual text user interface (TUI) instead of a conventional command-line interface (CLI) or graphical user interface (GUI). This TUI was very innovative in its time and influenced the design of the Acme text editor for the Plan 9 from Bell Labs operating system.

The latest version of the Oberon System, Project Oberon 2013, is still maintained by Niklaus Wirth and several collaborators, but older ETH versions of the system have been orphaned. The system also evolved into the multi-process, symmetric multiprocessing (SMP) capable A2 (formerly Active Object System (AOS),[5] then Bluebottle), with a zooming user interface (ZUI).

The Oberon operating system was originally developed as part of the NS32032-based Ceres workstation project. It was written almost entirely (and since the 2013 version, is described entirely) in the Oberon programming language.

The Web Site to Remember National Semiconductor's Series 32000 Family
Photo of a Ceres workstation // Copyright www.cpu-ns32k.net

The Ceres Workstation was a workstation computer built by Niklaus Wirth’s group at ETH Zurich in 1987. The central processing unit (CPU) is a National Semiconductor NS32000, and the operating system, named The Oberon System is written fully in the object-oriented programming language Oberon. It is an early example of an object-oriented operating system using garbage collection on the system level and a document centered approach for the user interface (UI), as envisaged later with OpenDoc

Lilith workstation based on AMD 2901

Ceres was a follow-up project to the Lilith workstation, based on AMD bit slicing technology and the programming language Modula-2.

The basic system was designed and implemented by Niklaus Wirth and Jürg Gutknecht and its design and implementation is fully documented in their book “Project Oberon”.The user Interface and programmers reference is found in Martin Reiser’s book “The Oberon System”. It was later extended and ported to other hardwareby a team at ETH Zurich and there was recognition in popular magazines. Wirth and Gutknecht (although being active computer science professors) refer to themselves as ‘part-time programmers’ in the book Project Oberon. In late 2013, a few months before his 80th birthday, Wirth published a second edition of Project Oberon.It details implementing the Oberon System using a reduced instruction set computer (RISC) CPU of his own design realized on a Xilinx field-programmable gate array (FPGA) board. It was presented at the symposium organized for his 80th birthday at ETH Zurich. In the meantime, several emulators for this version were implemented.

According to Josef Templ, a former member of the developer group at Swiss Federal Institute of Technology in Zurich and later member of the Institut für Systemsoftware of Johannes Kepler University Linz, where one forked version (V4) was maintained, the genealogy of the different versions of the Oberon System is this:

1985Start of Oberon project
1987V1Internal use at ETHZ simple text editing facilities only
1991V2Extensible text model and a special editor named Write supporting these extensions
1991System 3Kernel extensions supporting persistent objects and object-libraries supporting object embedding and object linking; Gadgets, Script (text editor), Illustrate (graphics editor)
1992Publication of Oberon Trilogy: “Project Oberon”  “The Oberon System” and “Programming in Oberon”
1992V4Functions of Write integrated into standard text editor
Rel. 1.4Desktops
1993Rel. 1.5Generic document model
1994V4Hanspeter Mössenböck appointed at JKU (Linz), V4 development moves there
1995Rel. 2.0Document space extended to the whole internet; improved bitmap editor: Rembrandt; online tutorials
2000ETH-OberonSystem-3 renamed ETH-Oberon
2002AOSActive Object System, also Active Oberon System, later renamed Bluebottle, then A2
2013PO 2013 – V5Re-implementation of the original Oberon System in FPGA

Oberon has a text user interface (TUI), which is very different from a terminal user interface. It combines the point and click convenience of a graphical user interface (GUI) with the linguistic strength of a command-line interface (CLI) and is closely tied to the naming conventions of the Oberon language. Text appearing almost anywhere on a screen can be edited and used as command input. Commands are activated by a middle-mouse click on a text fragment of the form Module.Command (optionally followed by parameters, which are terminated by ~). A command is defined by any procedure which is exported and has an empty argument list. Parameters to the command must be defined before executing the middle click, and must be explicitly scanned and retrieved by the procedure. No checks or questions occur during command execution. This is sometimes called a non-modal user interface (UI). Nothing like a command prompt is needed.

Although very different from a command line, the TUI is very efficient and powerful. A steep ascent in the early learning curve makes it a bit difficult at first. No questions are asked: this is a deliberate design decision, which needs getting used to. Most editors ask the user when closing a modified text: this is not the case in the Oberon System. The use of the TUI and programming interface is fully documented in Martin Reiser’s book “The Oberon System”. A short introduction to the user interface can be found on Niklaus Wirth’s home page. The later Versions of System Oberon, Oberon V4 (V4, sometimes also named Linz-Oberon) and Oberon System 3 (or S3, sometimes also named ETH-Oberon or Spirit of Oberon), enhanced the basic interface with different but incompatible implementations for buttons, drop down menus, and other active elements. V4 used for that purpose a dedicated control character embedded in normal text in contrast to System 3, which extended the kernel by introducing persistent objects. Both extensions include a large set of user interface elements.

Mastering the Oberon user interface, both the purely textual and the so-called Gadgets System (under S3), is non-trivial. Thus, after successfully installing Oberon System 3, it is recommended to study André Fischers Oberon System 3 Tutorial. An expanded version of this tutorial was published as a book which it is out of print now. The whole book is available in electronic form under one user license in every installed version of System 3 (Windows, Linux, or Native, i.e., also with the Gadgets toolkit of OLR). More information how to get your own copy of the Oberon Companion may be found in the Getting Started section of the Oberon Wikibook.

Similar user Interfaces have yet to appear in more commonplace operating systems. Rob Pike’s Acme system for Plan 9 from Bell Labs was strongly inspired by the Oberon TUI. Whether the worksheet interface of the Macintosh Programmer’s Workshop influenced Oberon’s TUI or vice versa is difficult to decide: the Oberon System was based on Wirth’s prior computer design the Lilith, and both the Apple Macintosh (and its precursor Lisa) and the Oberon System (on Ceres and its precursor Lilith) have the same roots: they were all inspired by the Alto developed at Xerox PARC.

Versions and Availability

V1 was the first usable version some time before the Oberon Trilogy was published. A major change in the text model together with the editor named Write yielded V2. As foreshadowed in the table in section History above, there was a major fork in the early 1990s: V4 vs. System 3: The group around Jürg Gutknecht introduced persistent objects and object-libraries thereby extending the kernel. The group around Hanspeter Mössenböck realized similar features by introducing active elements mapped to a special character thereby extending fonts without changing the kernel. System 3 was sometimes also named Spirit of Oberon and later renamed ETH Oberon, whereas V4 was sometimes also named Linz Oberon.

As of 2017, the Oberon OS is available for several hardware computing platforms, generally in no cost versions and from several sources, which is quite confusing. The Oberon OS is typically extremely compact. Even with an Oberon compiler, assorted utilities including a web browser, TCP/IP networking, and a GUI, the full package can be compressed to one 3.5″ floppy disk. There are versions which emulated the Oberon OS on another operating system and versions which run on bare hardware. The latter ones are named Native Oberon. There are native versions for the Ceres, Intel IA-32, and ARM platforms. In 2013, Niklaus Wirth adapted the basic system as described in “Project Oberon” to a current FPGA design. According to the preface of the 2013 edition, the whole system compiles in less than 10 seconds on a Spartan-3 board. This version is sometimes also named V5, despite it being much more similar functionally to the original V1 running on the Ceres than any of the later versions.

A version of the Oberon System 3 which was integrated in the Microsoft Windows OS was named Plugin Oberon.[33] Plugin Oberon supported the binary format named Oberon Module Interchange (OMI) or slim binaries, which allowed portable object code between Intel x86, Motorola 68k, and PowerPC architectures. Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple during the transition from 68k to PowerPC architectures. OMI provided portable code based on a compressed version of the abstract syntax tree. The approach of a compressed abstract syntax tree is revived for GraalVM and Truffle.

The version named Oberon V4 (see also History) is closer to the original operating system developed by Wirth and Gutknecht. It was originally developed at ETHZ, but when H.P. Mössenböck went to Institut für Systemsoftware at Johannes-Kepler University in Linz (JKU), the development of V4 moved also. Thus, V4 is sometimes also called Linz-Oberon in contrast to ETH-Oberon. The most recent version of V4 and extensions are available at JKU. Oberon V4 appears to be orphaned, there are almost no changes since 2000. Another repository of V4 is Claudio Nieder’s Oberon V4, which also shows difference between the different V4 implementations. Since 2013 this page moved to/is mirrored at SourceForge. V4 is closer to what would now be called an integrated development environment than an operating system of its own. There were many extensions written for V4, which are still available from the ftp server of SSW at JKU; some documentation can be found on their web-pages, more information is normally included in the packages and it is given in Oberon’s special rich text format.

Around 2010, the computer science department at ETH Zurich began exploring active objects and concurrency for operating systems, and has released an early version of a new language Active Oberon and a new operating system for it, first named Active Object System (AOS) in 2002 then due to trademark issues, renamed Bluebottle in 2005, then renamed A2 in 2008. It is available from ETH Zurich with most source via the Internet. Native versions (A2) run on bare hardware, and are currently possible for Intel IA-32 and x86-64 single- and multi-processor systems, and for the StrongARM CPU family. Versions for other operating systems are available on Windows (WinAos), Unix (UnixAos), Linux (LinuxAos), and macOS (DarwinAos). More detailed information about A2 is on the Russian Wikipedia pages about A2.

As a part of an industrial research project the Native Systems Group of ETH Zurich has developed an application-specific operating system named stailaOS which is based on the latest version Oberon OS. It is intended for uses such as real-time analytics, high performance automated trading system (ATS), main memory based enterprise resource planning (ERP), etc.

Native Oberon

Native Oberon is an Oberon System that runs on bare hardware. PC-Native Oberon is a version that runs on IA-32 (x86-32) PC hardware. There has never been a V4 Native Oberon, so all information in this section implicitly assumes that it is System 3. Native Oberon has small hardware requirements: 133 MHz Pentium, 100MB hard disk, VESA 2 graphics card with resolution minimum of 1024×768 pixels, optional 3Com network card. The basic system runs from one HD floppy disk, and more software can be installed through a network. The full installation includes the Gadgets GUI. It is written fully in the language Oberon.

The Oberon0 installer running on QEMU in Debian Wheezy. The presentation of the partition table illustrates the comprehensibility of the system in general. CC – PeterEasthope

A version named Linux Native Oberon (LNO) uses Linux as a hardware abstraction layer (HAL). Its goal is to be as compatible as possible to PC-Native Oberon. Other versions of the Oberon System, without Native in the name, had partly modified interfaces of low level modules. In 2015, Peter Matthias revitalized LNO under the name Oberon Linux Revival (OLR) as a multi-platform distribution running seamlessly on Intel x86, ARM, MIPS, and RISC-V. It runs well on the Raspberry Pi and on the low cost CHIP computer; with some tweaking (adjusting group membership or/and permissions on some devices) it runs well on Tiny Core Linux. OLR interfaces with Linux kernel by direct system calls. As of June 2017, OLR lacks a network layer.

Project Oberon 2013

In 2013, Wirth and Paul Reed completed a re-implementation of the original Oberon System for the Digilent Xilinx Spartan 3 FPGA Starter Board. The work includes a revision of “Project Oberon” identified as Project Oberon (New Edition 2013). In 2015, Reed collaborated with Victor Yurkovsky to create OberonStation, a Xilinx Spartan 3-based computer designed specifically to run Oberon. The system has since been ported to a Xilinx Spartan 6 FPGA Pepino development board by Saanlima Electronics, and a Xilinx Artix 7-based Digilent Nexys A7-100 FPGA Trainer board by CFB Software. Peter de Wachter implemented an emulator for it, which was also ported to Java and JavaScript by Michael Schierl, running in modern browsers, and ported to Free Pascal/Ultibo by Markus Greim. Andreas Pirklbauer maintains an experimental version and extensions of Project Oberon 2013 at GitHub.

Plan 9

Plan 9 from Bell Labs (Installation).png
Installation of Plan9 – CC Bell Labs
Glenda bunny mascot of plan 9 from bell black.jpg
Glenda the Plan9 bunny mascot

Plan 9 from Bell Labs is a distributed operating system, originating in the Computing Science Research Center (CSRC) at Bell Labs in the mid-1980s, and building on UNIX concepts first developed there in the late 1960s. The final official release was in early 2015.

Under Plan 9, UNIX’s everything is a file metaphor is extended via a pervasive network-centric filesystem, and the cursor-addressed, terminal-based I/O at the heart of UNIX-like operating systems is replaced by a windowing system and graphical user interface without cursor addressing, although rc, the Plan 9 shell, is text-based.

The name Plan 9 from Bell Labs is a reference to the Ed Wood 1959 cult science fiction Z-movie Plan 9 from Outer Space (The name of the project’s mascot, “Glenda, the Plan 9 Bunny”, is presumably a reference to Wood’s film Glen or Glenda.) The system continues to be used and developed by operating system researchers and hobbyists.

Plan 9 from Bell Labs was originally developed, starting in the late 1980s by members of the Computing Science Research Center at Bell Labs, the same group that originally developed Unix and the C programming language.The Plan 9 team was initially led by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with support from Dennis Ritchie as head of the Computing Techniques Research Department. Over the years, many notable developers have contributed to the project, including Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup and Bruce Ellis.

Plan 9 replaced Unix as Bell Labs’s primary platform for operating systems research. It explored several changes to the original Unix model that facilitate the use and programming of the system, notably in distributed multi-user environments. After several years of development and internal use, Bell Labs shipped the operating system to universities in 1992. Three years later, Plan 9 was made available for commercial parties by AT&T via the book publisher Harcourt Brace. With source licenses costing $350, AT&T targeted the embedded systems market rather than the computer market at large. Ritchie commented that the developers did not expect to do “much displacement” given how established other operating systems had become.

By early 1996, the Plan 9 project had been “put on the back burner” by AT&T in favor of Inferno, intended to be a rival to Sun Microsystems’ Java platform.In the late 1990s, Bell Labs’ new owner Lucent Technologies dropped commercial support for the project and in 2000, a third release was distributed under an open-source license. A fourth release under a new free software license occurred in 2002.

A user and development community, including current and former Bell Labs personnel, produced minor daily releases in the form of ISO images. Bell Labs hosted the development. The development source tree is accessible over the 9P and HTTP protocols and is used to update existing installations. In addition to the official components of the OS included in the ISOs, Bell Labs also hosts a repository of externally developed applications and tools.

As Bell Labs has moved on to later projects in recent years, development of the official Plan 9 system had stopped. On March 23 2021, development resumed following the transfer of copyright from Bell Labs to the Plan 9 Foundation. Unofficial development for the system also continues on the 9front fork, where active contributors provide monthly builds and new functionality. So far, the 9front fork has provided the system Wi-Fi drivers, Audio drivers, USB support and built-in game emulator, along with other features. Other recent Plan 9-inspired operating systems include Harvey OS and Jehanne OS.

1992Plan 9 1st editionReleased by Bell Labs to universities
1995Plan 9 2nd editionReleased by Bell Labs for non-commercial purposes[24]
2000Plan 9 3rd ed. (Brazil)Released by Lucent Technologies under an open source license
2002Plan 9 4th editionReleased by Lucent Technologies under a new free software license
Design Concepts

Plan 9 is a distributed operating system, designed to make a network of heterogeneous and geographically separated computers function as a single system. In a typical Plan 9 installation, users work at terminals running the window system rio, and they access CPU servers which handle computation-intensive processes. Permanent data storage is provided by additional network hosts acting as file servers and archival storage.

Its designers state that,

[t]he foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol.

— Pike et al.

The first idea (a per-process name space) means that, unlike on most operating systems, processes (running programs) each have their own view of the namespace, corresponding to what other operating systems call the file system; a single path name may refer to different resources for different processes. The potential complexity of this setup is controlled by a set of conventional locations for common resources.

The second idea (a message-oriented filesystem) means that processes can offer their services to other processes by providing virtual files that appear in the other processes’ namespace. The client process’s input/output on such a file becomes inter-process communication between the two processes. This way, Plan 9 generalizes the Unix notion of the filesystem as the central point of access to computing resources. It carries over Unix’s idea of device files to provide access to peripheral devices (mice, removable media, etc.) and the possibility to mount filesystems residing on physically distinct filesystems into a hierarchical namespace, but adds the possibility to mount a connection to a server program that speaks a standardized protocol and treat its services as part of the namespace.

For example, the original window system, called 8½, exploited these possibilities as follows. Plan 9 represents the user interface on a terminal by means of three pseudo-files: mouse, which can be read by a program to get notification of mouse movements and button clicks, cons, which can be used to perform textual input/output, and bitblt, writing to which enacts graphics operations (see bit blit). The window system multiplexes these devices: when creating a new window to run some program in, it first sets up a new namespace in which mouse, cons and bitblt are connected to itself, hiding the actual device files to which it itself has access. The window system thus receives all input and output commands from the program and handles these appropriately, by sending output to the actual screen device and giving the currently focused program the keyboard and mouse input. The program does not need to know if it is communicating directly with the operating system’s device drivers, or with the window system; it only has to assume that its namespace is set up so that these special files provide the kind of input and accept the kind of messages that it expects.

Plan 9’s distributed operation relies on the per-process namespaces as well, allowing client and server processes to communicate across machines in the way just outlined. For example, the cpu command starts a remote session on a computation server. The command exports part of its local namespace, including the user’s terminal’s devices (mouse, cons, bitblt), to the server, so that remote programs can perform input/output using the terminal’s mouse, keyboard and display, combining the effects of remote login and a shared network filesystem.

9P Protocol

All programs that wish to provide services-as-files to other programs speak a unified protocol, called 9P. Compared to other systems, this reduces the number of custom programming interfaces. 9P is a generic, medium-agnostic, byte-oriented protocol that provides for messages delivered between a server and a client. The protocol is used to refer to and communicate with processes, programs, and data, including both the user interface and the network. With the release of the 4th edition, it was modified and renamed 9P2000.

Unlike most other operating systems, Plan 9 does not provide special application programming interfaces (such as Berkeley sockets, X resources or ioctl system calls) to access devices. Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write. Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.

Union directories and namespaces

Plan 9 allows the user to collect the files (called names) from different directory trees in a single location. The resulting union directory behaves as the concatenation of the underlying directories (the order of concatenation can be controlled); if the constituent directories contain files having the same name, a listing of the union directory (ls or lc) will simply report duplicate names. Resolution of a single path name is performed top-down: if the directories top and bottom are unioned into u with top first, then u/name denotes top/name if it exists, bottom/name only if it exists and top/name does not exist, and no file if neither exists. No recursive unioning of subdirectories is performed, so if top/subdir exists, the files in bottom/subdir are not accessible through the union.

A union directory can be created by using the bind command:

; bind /arm/bin /bin
; bind -a /acme/bin/arm /bin
; bind -b /usr/alice/bin /bin

In the example above, /arm/bin is mounted at /bin, the contents of /arm/bin replacing the previous contents of /bin. Acme’s bin directory is then union mounted after /bin, and Alice’s personal bin directory is union mounted before. When a file is requested from /bin, it is first looked for in /usr/alice/bin, then in /arm/bin, and then finally in /acme/bin/arm.

The separate process namespaces thus replace the notion of a search path in the shell. Where Unix shells have a list of directories to search for programs when given a command, the Plan 9 shell only looks in the directory /bin; adding commands is done by binding several directories together to appear as a single /bin.

Furthermore, the kernel can keep separate mount tables for each process and can thus provide each process with its own file system namespace. Processes’ namespaces can be constructed independently, and the user may work simultaneously with programs that have heterogeneous namespaces. Namespaces may be used to create an isolated environment similar to chroot, but in a more secure way.

Plan 9’s union directory architecture inspired 4.4BSD and Linux union file system implementations although the developers of the BSD union mounting facility found the non-recursive merging of directories in Plan 9 “too restrictive for general purpose use”.

Special virtual filesystem


Instead of having system calls specifically for process management, Plan 9 provides the /proc file system. Each process appears as a directory containing information and control files which can be manipulated by the ordinary file IO system calls.

The file system approach allows Plan 9 processes to be managed with simple file management tools such as ls and cat; however, the processes cannot be copied and moved as files.[6]

Plan 9 does not have specialised system calls or ioctls for accessing the networking stack or networking hardware. Instead, the /net file system is used. Network connections are controlled by reading and writing control messages to control files. Sub-directories such as /net/tcp and /net/udp are used as an interface to their respective protocols.

Software for Plan9

As a benefit from the system’s design, most tasks in Plan 9 can be accomplished by using ls, cat, grep, cp and rm utilities in combination with the rc shell (the default Plan 9 shell).

Factotum is an authentication and key management server for Plan 9. It handles authentication on behalf of other programs such that both secret keys and implementation details need only be known to Factotum.

Graphical programs

Unlike Unix, Plan 9 was designed with graphics in mind. After booting, a Plan 9 terminal will run the rio windowing system, in which the user can create new windows displaying rc. Graphical programs invoked from this shell replace it in its window.

The plumber provides an inter-process communication mechanism which allows system-wide hyperlinking.

Sam and acme are Plan 9’s text editors.

Storage system

Plan 9 supports the Kfs, Paq, Cwfs, FAT, and Fossil file systems. The last was designed at Bell Labs specifically for Plan 9 and provides snapshot storage capability. It can be used directly with a hard drive or backed with Venti, an archival file system and permanent data storage system.

Software development

The distribution package for Plan 9 includes special compiler variants and programming languages, and provides a tailored set of libraries along with a windowing user interface system specific to Plan 9. The bulk of the system is written in a dialect of C (ANSI C with some extensions and some other features left out). The compilers for this language were custom built with portability in mind; according to their author, they “compile quickly, load slowly, and produce medium quality object code”.

A concurrent programming language called Alef was available in the first two editions, but was then dropped for maintenance reasons and replaced by a threading library for C.

Unix compatibility

Though Plan 9 was supposed to be a further development of Unix concepts, compatibility with preexisting Unix software was never the goal for the project. Many command-line utilities of Plan 9 share the names of Unix counterparts, but work differently.

Plan 9 can support POSIX applications and can emulate the Berkeley socket interface through the ANSI/POSIX Environment (APE) that implements an interface close to ANSI C and POSIX, with some common extensions (the native Plan 9 C interfaces conform to neither standard). It also includes a POSIX-compatible shell. APE’s authors claim to have used it to port the X Window System (X11) to Plan 9, although they do not ship X11 “because supporting it properly is too big a job”.[46] Some Linux binaries can be used with the help of a “linuxemu” (Linux emulator) application; however, it is still a work in progress.Vice versa, the vx32 virtual machine allows a slightly modified Plan 9 kernel to run as a user process in Linux, supporting unmodified Plan 9 programs.

Acme text editor which is more than just a text editor

Plan9 running acme and rc . CC – Bell Labs
acme on Plan9

Acme is a text editor and graphical shell from the Plan 9 from Bell Labs operating system, designed and implemented by Rob Pike. It can use the Sam command language. The design of the interface was influenced by Oberon. It is different from other editing environments in that it acts as a 9P server. A distinctive element of the user interface is mouse chording.

Acme can be used as a mail and news reader, or as a frontend to wikifs. These applications are made possible by external components interacting with acme through its file system interface. Rob Pike has mentioned that the name “Acme” was suggested to him by Penn Jillette of Penn & Teller during a movie night at Times Square when he asked for a suitable name for a text editor that does “everything”.

A port to the Inferno operating system is part of Inferno’s default distribution. Inferno can run as an application on top of other operating systems, allowing Inferno’s port of acme to be used on most operating systems, including Microsoft Windows and Linux. A project called acme: stand alone complex intends to make acme run as a standalone application on the host operating system.

A working port of acme for Unix-like operating systems is included in Plan 9 from User Space, a collection of various ported programs from Plan 9. Currently it has been tested on a variety of operating systems including: Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Solaris and SunOS.

The wmii X window manager was inspired by acme, a text editor from the Plan 9 project.

Impact of Plan9

Plan 9 demonstrated that an integral concept of Unix—that every system interface could be represented as a set of files—could be successfully implemented in a modern distributed system. Some features from Plan 9, like the UTF-8 character encoding of Unicode, have been implemented in other operating systems. Unix-like operating systems such as Linux have implemented 9P, Plan 9’s file system, and have adopted features of rfork, Plan 9’s process creation mechanism. Additionally, in Plan 9 from User Space, several of Plan 9’s applications and tools, including the sam and acme editors, have been ported to Unix and Linux systems and have achieved some level of popularity. Several projects seek to replace the GNU operating system programs surrounding the Linux kernel with the Plan 9 operating system programs. The 9wm window manager was inspired by 8½, the older windowing system of Plan 9; wmii is also heavily influenced by Plan 9. In computer science research, Plan 9 has been used as a grid computing platform and as a vehicle for research into ubiquitous computing without middleware. In commerce, Plan 9 underlies Coraid storage systems. However, Plan 9 has never approached Unix in popularity, and has been primarily a research tool:

[I]t looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

— Eric S. Raymond

Other factors that contributed to low adoption of Plan 9 include the lack of commercial backup, the low number of end-user applications, and the lack of device drivers.

Plan 9 proponents and developers claim that the problems hindering its adoption have been solved, that its original goals as a distributed system, development environment, and research platform have been met, and that it enjoys moderate but growing popularity.Inferno, through its hosted capabilities, has been a vehicle for bringing Plan 9 technologies to other systems as a hosted part of heterogeneous computing grids.

Several projects work to extend Plan 9, including 9atom and 9front. These forks augment Plan 9 with additional hardware drivers and software, including an improved version of the Upas e-mail system, the Go compiler, Mercurial version control system support, and other programs. Plan 9 was ported to the Raspberry Pi single-board computer.The Harvey project attempts to replace the custom Plan 9 C compiler with GCC, to leverage modern development tools such as GitHub and Coverity, and speed up development.

Derivatives and forks

Inferno is a descendant of Plan 9, and shares many design concepts and even source code in the kernel, particularly around devices and the Styx/9P2000 protocol. Inferno shares with Plan 9 the Unix heritage from Bell Labs and the Unix philosophy. Many of the command line tools in Inferno were Plan 9 tools that were translated to Limbo.

  • 9atom augments the Plan 9 distribution with the addition of a 386 PAE kernel, an amd64 cpu and terminal kernel, nupas, extra pc hardware support, IL and Ken’s fs.
  • 9front is a fork of Plan 9. It was started to remedy a perceived lack of devoted development resources inside Bell Labs, and has accumulated various fixes and improvements.
  • 9legacy is an alternative distribution. It includes a set of patches based on the current Plan 9 distribution.
  • Akaros is designed for many-core architectures and large-scale SMP systems.
  • Harvey OS is an effort to get the Plan 9 code working with gcc and clang.
  • JehanneOS is an experimental OS derived from Plan 9. Its userland and modules are mostly derived from 9front, its build system from Harvey OS, and its kernel is a fork of the Plan9-9k 64-bit Plan9 kernel.
  • NIX is a fork of Plan9 aimed at multicore systems and cloud computing.
  • Plan B designed to work in distributed environments where the set of available resources is different at different points in time.


Inferno 4th Edition.png
Screenshot of Inferno 4th edition Operating System

Inferno is a distributed operating system started at Bell Labs and now developed and maintained by Vita Nuova Holdings as free software. Inferno was based on the experience gained with Plan 9 from Bell Labs, and the further research of Bell Labs into operating systems, languages, on-the-fly compilers, graphics, security, networking and portability. The name of the operating system and many of its associated programs, as well as that of the current company, were inspired by Dante Alighieri’s Divine Comedy. In Italian, Inferno means “hell” — of which there are nine circles in Dante’s Divine Comedy.


Inferno is a descendant of Plan 9 from Bell Labs, and shares many design concepts and even source code in the kernel, particularly around devices and the Styx/9P2000 protocol. Inferno shares with Plan 9 the Unix heritage from Bell Labs and the Unix philosophy. Many of the command line tools in Inferno were Plan 9 tools that were translated to Limbo.

In the mid-1990s, Plan 9 development was set aside in favor of Inferno. The new system’s existence was leaked by Dennis Ritchie in early 1996, after less than a year of development on the system, and publicly presented later that year as a competitor to Java. At the same time, Bell Labs’ parent company AT&T licensed Java technology from Sun Microsystems.

In March–April 1997 IEEE Internet Computing included an advertisement for Inferno networking software. It claimed that various devices could communicate over “any network” including the Internet, telecommunications and LANs. The advertisement stated that video games could talk to computers,–a PlayStation was pictured–cell phones could access email and voice mail was available via TV.

Lucent used Inferno in at least two internal products: the Lucent VPN Firewall Brick, and the Lucent Pathstar phone switch. They initially tried to sell source code licenses of Inferno but found few buyers. Lucent did little marketing and missed the importance of the Internet and Inferno’s relation to it. During the same time Sun Microsystems was heavily marketing its own Java programming language, which was targeting a similar market, with analogous technology, that worked in web browsers and also filled the demand for object-oriented languages popular at that time. Lucent licensed Java from Sun, claiming that all Inferno devices would be made to run Java. A Java byte code to Dis byte code translator was written to facilitate that. However, Inferno still did not find customers.

The Inferno Business Unit closed after three years, and was sold to Vita Nuova. Vita Nuova continued development and offered commercial licenses to the complete system, and free downloads and licenses (not GPL compatible) for all of the system except the kernel and VM. They ported the software to new hardware and focused on distributed applications. Eventually, Vita Nuova released the source under the GPL license and the Inferno operating system is now a Free/Libre/Open Source Software project.

Design principles

Inferno was created in 1995 by members of Bell Labs’ Computer Science Research division to bring ideas of Plan 9 from Bell Labs to a wider range of devices and networks. Inferno is a distributed operating system based on three basic principles drawn from Plan 9:

  • Resources as files: all resources are represented as files within a hierarchical file system
  • Namespaces: a program’s view of the network is a single, coherent namespace that appears as a hierarchical file system but may represent physically separated (locally or remotely) resources
  • Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remote

To handle the diversity of network environments it was intended to be used in, the designers decided a virtual machine was a necessary component of the system. This is the same conclusion of the Oak project that became Java, but arrived at independently. The Dis virtual machine is a register machine intended to closely match the architecture it runs on, as opposed to the stack machine of the Java Virtual Machine. An advantage of this approach is the relative simplicity of creating a just-in-time compiler for new architectures.

The virtual machine provides memory management designed to be efficient on devices with as little as 1 MiB of memory and without memory-mapping hardware. Its garbage collector is a hybrid of reference counting and a real-time coloring collector that gathers cyclic data.[3]

The Inferno kernel contains the virtual machine, on-the-fly compiler, scheduler, devices, protocol stacks, and the name space evaluator for each process’ file name space, and the root of the file system hierarchy. The kernel also includes some built-in modules that provide interfaces of the virtual operating system, such as system calls, graphics, security, and math modules.

The Bell Labs Technical Journal paper introducing Inferno listed several dimensions of portability and versatility provided by the OS:

  • Portability across processors: it currently runs on ARM, SGI MIPS, HP PA-RISC, IBM PowerPC, Sun SPARC, and Intel x86 architectures and is readily portable to others.
  • Portability across environments: it runs as a stand-alone operating system on small terminals, and also as a user application under Bell Plan 9, MS Windows NT, Windows 95, and Unix (SGI Irix, Sun Solaris, FreeBSD, Apple Mac OS X, Linux, IBM AIX, HP-UX, Digital Tru64). In all of these environments, Inferno programs see an identical interface.
  • Distributed design: the identical environment is established at the user’s terminal and at the server, and each may import the resources (for example, the attached I/O devices or networks) of the other. Aided by the communications facilities of the run-time system, programs may be split easily (and even dynamically) between client and server.
  • Minimal hardware requirements: it runs useful applications stand-alone on machines with as little as 1 MiB of memory, and does not require memory-mapping hardware.
  • Portable programs: Inferno programs are written in the type-safe language Limbo and compiled to Dis bytecode, which can be run without modifications on all Inferno platforms.
  • Dynamic adaptability: programs may, depending on the hardware or other resources available, load different program modules to perform a specific function. For example, a video player might use any of several different decoder modules.

These design choices were directed to provide standard interfaces that free content and service providers from concern of the details of diverse hardware, software, and networks over which their content is delivered.


Inferno programs are portable across a broad mix of hardware, networks, and environments. It defines a virtual machine, known as Dis, that can be implemented on any real machine, provides Limbo, a type-safe language that is compiled to portable byte code, and, more significantly, it includes a virtual operating system that supplies the same interfaces whether Inferno runs natively on hardware or runs as a user program on top of another operating system.

A communications protocol called Styx is applied uniformly to access both local and remote resources, which programs use by calling standard file operations, open, read, write, and close. As of the fourth edition of Inferno, Styx is identical to Plan 9’s newer version of its hallmark 9P protocol, 9P2000.

Most of the Inferno commands are very similar to Unix commands with the same name.


Inferno runs directly on native hardware and also as an application providing a virtual operating system which runs on other platforms. Programs can be developed and run on all Inferno platforms without modification or recompilation.

Native ports include these architectures: x86, MIPS, ARM, PowerPC, SPARC.

Hosted or virtual OS ports include: Microsoft Windows, Linux, FreeBSD, Plan 9, Mac OS X, Solaris, IRIX, UnixWare.

Inferno can also be hosted by a plugin to Internet Explorer. Vita Nuova said that plugins for other browsers were under development, but they were never released.

Inferno has also been ported to Openmoko, Nintendo DS, SheevaPlug and Android.


Inferno 4th edition was released in early 2005 as free software. Specifically, it was dual-licensed under two licenses. Users could either obtain it under a set of free software licenses, or they could obtain it under a proprietary license. In the case of the free software license scheme, different parts of the system were covered by different licenses, including the GNU General Public License, the GNU Lesser General Public License, the Lucent Public License, and the MIT License. Subsequently, Vita Nuova has made it possible to acquire the entire system (excluding the fonts, which are sub-licensed from Bigelow and Holmes) under the GPLv2. All three license options are currently available.

9front and 9legacy

9front is a fork of Plan 9. It was started to remedy a perceived lack of devoted development resources inside Bell Labs, and has accumulated various fixes and improvements.

9legacy is an alternative distribution. It includes a set of patches based on the current Plan 9 distribution.

You can find a lot of information on both 9front’s and 9legacy’s websites and read more about it … the 9front one is definitely full with information

Harvey OS and Jehanne OS ( both inspired by Plan9)

Jehanne OS
Harvey OS | Operating system projects
Harvey OS

Harvey OS description from it’s website:

Harvey is an effort to provide a modern, distributed, 64 bit operating system. A different environment for researching and finding new lines of work.

It runs on x86_64 (amd64) machines. Main work is focused in improving the kernel and userland, trying to bring up a full usable operating system with common tools for development and a USB installation image. It collects many different ideas and concepts that, across many platforms and operating systems, influenced the computing world for years.

Jehanne OS description from it’s website:

Jehanne is a simple operating system.

It shows that few orthogonal abstractions can be composed to provide everything you want from modern operating systems.
And more.

A vision for simplicity

Jehanne is named after a peasant girl that was burned as an heretic and then canonized as a saint.

Everybody can see why it’s an heretic OS: it breaks many traditions of Plan 9 from Bell Labs, it challenges some design decisions and even breaks some common conventions rooted in Unix.

There is no /bin folder. There is no sleep system call.
There is no swap. Markdown replaces troff for documentation.
GCC is the default compiler. 9P2000 is still supported, but replaced.

However, the point of this research is not to disrupt well established habits, but to pursuit a vision for simplicity.

Beware, there’s no glory for simplicity: everybody can do it, after.

More with less

Jehanne is simple in many different ways.

The kernel API is minimal and uniform: 26 system calls control devices, memory, IPC, scheduling and namespaces.
Everthing is a file. Really. Even directories.
The default file system provides a clean taxonomy.
The project scope includes a minimal system: compilers, editors, browsers, games… many useful softwares can be ported to Jehanne through libposix and newlib (and soon musl).

Also, Jehanne is free software. And it will always be.
The kernel and older tools are GPLv2, everything new is AGPLv3.
It’s not only “formally” open, like many other projects from big names: you are wellcome to challenge my assumptions, prove I’m wrong, even remove my code.

You just have to make it both simpler and more useful.