© Amit Singh. All Rights Reserved.
Written in Mid 2003
This page contains operating systems that I could not, or simply did not classify into any of the other categories.
Amoeba is a microkernel-based operating system that turns a collection of computers into a transparent distributed system.
Amoeba came to be at the Vrije Universiteit, Amsterdam, The Netherlands in 1981 as a research project in distributed and parallel computing. It was primarily designed by Andrew S. Tanenbaum and three of his Ph.D. students.
An important distinction between Amoeba and most other distributed systems is that Amoeba has no concept of a "home machine". When a user logs in, it is to the system as a whole, not to a specific machine.
AROS is a freely available desktop operating system that aims to be compatible with AmigaOS 3.x. AROS's goals also include portability to architectures such as x86, PowerPC, Alpha, SPARC, HPPA etc., as well as binary compatibility on Amiga. In order to achieve this, the AROS team uses a hardware independent device driver (HIDD) layer which is used by libraries (instead of the libraries accessing hardware directly).
AROS is available under the AROS Public License (APL), which is based on the Mozilla Public License.
BeOS fans maintain that it was one of the greatest systems ever designed. Apple had offered Be Inc. an intellectual property acquisition deal (for over $100 million) several years ago, but Be declined. Nevertheless, BeOS had a lot of hype when it was announced, and I "tried" all their demo releases, right until version 4.5. BeOS 4.5 installs and runs readily under Virtual PC on the PowerBook.
BeOS is a single-user, preemptively multi-threaded operating system with SMP support. Note that although BeOS is POSIX compliant, it is not a Unix clone! One of BeOS's design goals (and claimed accomplishments) was the ability to handle media streams extremely efficiently. Although designed for custom hardware (the "BeBox"), BeOS was ported to run on the PowerPC and eventually the x86.
After the demise of Be Inc., YellowTAB was formed to get BeOS back on track.
Darwin is the open-source operating system technology underlying Apple's Mac OS X operating system. The goal of the OpenDarwin project is to provide a binary compatible development environment for Mac OS X. Darwin/x86, as the name suggests, is a version of Darwin for x86 computers. This version does not include a number of critical frameworks and subsystems from Mac OS X. In particular, the Quartz layer, Cocoa, Carbon, etc. are not present. The X Window System is included, however.
OpenDarwin 7.2.1 works with Virtual PC (earlier versions most likely don't). Moreover, it is possible that upon installation to the Virtual PC disk drive, OpenDarwin fails to boot from the hard disk. If so, you can boot it by explicitly specifying the root device (the
rd parameter) to the kernel:
Darwin/x86 boot v5.0.
640K conventional / 130048K extended memory
boot: hd(0,a)mach_kernel rd=disk0s1
disk0s1 assumes you installed Darwin on the first partition of the first hard disk.
Everybody (limiting the Universe to Geeks) knows somebody who spends so much time in Emacs that they might as well have Emacs as the operating system. I once played a prank on a die-hard Emacs user friend of mine by rigging one of his Linux machines so that it booted straight into Emacs (Emacs was
init). Of course, it wouldn't be very usable unless you do the necessary start-up work that the regular
init would have caused to happen.
We did create a custom Linux based EmacsOS CD later, that did things more properly but still booted straight into Emacs, "just for fun".
I am primarily a
vi user myself.
:: ETH Oberon
ETH Oberon is a single-user, multi-tasking system that runs on bare hardware or on top of a host operating system. Oberon is also the name of a programming language (along the lines of Pascal and Modula).
ETH Oberon can be installed either on an Oberon partition, or inside a file on a FAT file system. It runs fairly straightforwardly under Virtual PC.
Note that in order to use ETH Oberon properly, you need a 3 button mouse. This is simulated by using
Opt-Click as two of the mouse buttons under Virtual PC on Mac OS X.
GEOS was originally released by Berkeley Softworks as an add-on graphical interface for the Commodore 64. This was followed by GEOS on the Apple II, and subsequently by GeoWorks Ensemble on the PC. GEOS had multitasking capabilities. AOL used it as a graphical interface to DOS. The advent of Windows and its consequent success drove GEOS into oblivion by the time GeoWorks could try to establish a developer base through an SDK, etc.
Today GEOS is licensed by many companies for use on PDSs, cell phones and the like. A "lite" version of Ensemble is available from Breadbox Computer Company's website.
I wrote an operating system implementation of "The Towers of Hanoi" as part of my HanoiMania! project. The OS includes a simple bootstrap loader for the x86, and a very simple kernel. The system boots and presents a shell like prompt. The shell accepts a valid integer as input, which is used by the kernel as the number of disks to solve the puzzle for. The list of moves is thereafter printed.
Please go to the HanoiOS page for more details, including the source code and usage instructions. Note that HanoiOS does not need any disk space, or even a disk, to operate (well, it would need a disk if we were to solve for enough disks ... we don't!)
One more thing: it is actually possible to run HanoiOS in the following "cool" (*cough*) way:
- Run Mac OS X ...
- Run Virtual PC within Mac OS X ...
- Run Linux within Virtual PC within Mac OS X ...
- Run VMware within Linux within Virtual PC within Mac OS X ...
- Run HanoiOS within VMware within Linux within Virtual PC within Mac OS X ...
A good question would be to ask "why". There is no good answer, unfortunately. You may click on the picture for a 720x450 version.
I first heard of HURD (pun unintentional) in late 1994, and shortly afterwards I downloaded a snapshot from alpha.gnu.ai.mit.edu and set up a HURD development machine, primarily because I wanted to experiment with a Mach-like or Mach-derived kernel. On my "high-end" machine (a 33 MHz 486 with 16 MB RAM) HURD was excruciatingly slow. Installation was entirely "manual".
I recently looked at HURD again. Debian packaging has made installation much easier, but it is rather obvious that HURD will most likely not be a mainstream system, ever. HURD certainly can be very valuable as a research/educational test-bed, particularly for microkernel based work.
Debian/HURD does have a rudimentary menu driven installation, though it can still be installed as "manually" as you like. The most convenient installation for Virtual PC would be the following, in my opinion:
- Get the GRUB boot floppy image and the Debian/HURD iso images.
- Boot from the first CD image. You should land in a
dialog based menu.
- Create two partitions, say of sizes 1000 MB (for /) and 256 MB (swap).
- Mount the root file system.
- Activate the swap partition.
- Install the base system.
- Uncapture the CD image and insert the floppy image.
- Choose to boot single-user from the appropriate hard disk in the GRUB menu.
- Once the system boots and you are in a single user shell, run the following commands:
# export TERM
- The secondary installation will go on for a long time. If any devices still need to be created, you can do so by hand now:
# cd /dev
# ./MAKEDEV hd0s2
# ./MAKEDEV kbd
# ./MAKEDEV mouse
- Configure your network device, if necessary. Note that DHCP will probably not work, so if you are using DHCP in Virtual PC, you might still have to use a static IP address within HURD. A Virtual PC instance gets its DHCP address when you start it - even before the guest operating system boots. This address can be seen using the "Get <OSNAME> Info" menu entry. Using this IP address, you can set up a translator when HURD boots as follows:
# settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 \
-a <ip address> -g <gateway> -m <netmask>
- Arrange for installation of the bootloader. Create a directory for GRUB and copy the required files:
# mkdir /boot/grub
# cp /lib/grub/i386-*/* /boot/grub
- Create a bootloader menu file,
/boot/grub. You can just copy the one from the GRUB boot floppy and edit it.
- Reboot using the GRUB floppy, but this time, choose to install GRUB onto the master boot record.
NewOS is a small operating system kernel with some bare-bones user-space libraries and applications. The NewOS home page states its design goals and features, which include cross-platform portability.
The source code for NewOS is available from its web site. Developer toolchains are currently available for multiple platforms: Cygwin, FreeBSD 4.x, Linux, Solaris 9 (SPARC) and Mac OS X.
NewOS currently does not work under Virtual PC on the Mac. It does, however, work with Bochs.
Jobs unveiled the first NeXT Computer (running NEXTSTEP 0.8) on October 12, 1988, in San Francisco, although a mature release of the operating system took another year. The name "NEXTSTEP" has gone through a number of capitalization permutations, so we shall simply use "NEXTSTEP". NEXTSTEP 1.0 shipped on September 18, 1989, over two years later than what Jobs had first predicted and hoped for. NEXTSTEP was based on Mach 2.5 and 4.3BSD, and had an advanced GUI system based on Postscript. It used Objective-C as its native programming language, and included the NeXT Interface Builder.
NEXTSTEP "doesn't work" with Virtual PC 6.x. It does install and run, however, under Virtual PC 5 (I used 5.0.4).
The last version of NEXTSTEP, 3.3, was released in February 1995. A bit earlier, in 1994, NeXT and Sun had jointly released specifications fo OPENSTEP, an open platform (comprised of several APIs and frameworks) tha anybody could use to create their own implementation of *STEP. NeXT' implementation was named OpenStep, the successor to the NEXTSTEP operatin system. Three versions of OpenStep were ever released: 4.0 (July 22, 1996), 4. (December, 1996), and 4.2 (January, 1997). SunOS, HP-UX, and even Window NT had implementations at a point. TheGNUstep Project still exists.
I would like to thank Hussam Qasem for giving away his copy of OPENSTEP 4.2.
:: Plan 9
According to its creators, Plan 9 is "a distributed computing environment assembled from separate machines acting as terminals, CPU servers, and file servers".
I had a great interest in Plan 9 (and later in Inferno) much before I began working at Bell Laboratories. I believe it was mainly because the inventors of Unix were involved in the creat-ion (or create-ion, if you prefer) of Plan 9. If you have not used Plan 9, and you have strong feelings (either way) about Unix, you will most likely have stronger feelings (either way, not necessarily the same way) about Plan 9. In Unix, many objects look like files. In Plan 9, almost all objects look like files!
Plan 9 installation under Virtual PC should go through without any problems, except that the installation would use the fall-back text mode since the Virtual PC video card would not be detected. You can either "fix" this problem before installation (only if you are using a floppy to boot - not a CD), or after Plan 9 has installed. Since I booted from the CD, I fixed the problem post-installation:
- Let Plan 9 boot from the hard disk. Login as user
aux/vga. You will see a hex dump of the VGA BIOS memory. Look at address
0xC0010 - it should have the string
DEO corresponding to it.
- Edit the text file
/lib/vgadb. Locate the block of lines containing
S3 Trio magic strings, and add the following line:
aux/vga attempts to match the specified magic string at the specified address in the VGA BIOS memory. The above steps guarantee that the Virtual PC's card will be identified as an S3 Trio. After this,
rio should work.
According to the ReactOS web site: "ReactOS is an Open Source effort to develop a quality operating system that is compatible with Windows NT applications and drivers." The project also shares programming effort with the WINE project.
The project began in Februrary, 1998. It is interesting to note that the name "ReactOS", according to its documentation, was chosen because "... the operating system's roots grew out of a dissatisfaction with Microsoft's monopoly over the operating system market ..." (dissatisfaction ==> reaction).
At the time of this writing, ReactOS does not have a working GUI.
The current release of ReactOS does not run under Virtual PC on the Mac (there's a kernel panic). It does, however, work with Bochs.
Rhapsody was first demonstrated at the 1997 Apple World Wide Developers Conference (WWDC). It was based on OPENSTEP, and consisted of a kernel based on Mach and BSD, an extended OpenStep API implementation, a Java virtual machine, and a Mac OS like user-interface. Rhapsody was released for the x86 and the PowerPC. The latter also included a Mac OS compatibility subsystem called the Blue Box.
There were two developer releases of Rhapsody, dubbed DR1 and DR2.
Rhapsody's development platform was called the Yellow Box, that included most of OPENSTEP's integrated frameworks (shared object libraries), augmented by a run-time and development environment.
:: Solaris 9
As is the case with most of my other OS introductions, I came across SunOS for the first time in 1994. Since then, I have had access to a SunOS/Solaris system almost everyday (that's not all that much of an exaggeration, actually). I even have a few SPARC machines of my own. The most fun I ever had with Solaris was when I designed an implemented a virtualized version of the OS.
Solaris 9 will install and run fine on Virtual PC (including the X Window System), but there is one "issue" that would thwart any installation attempts and must be dealt with. If you boot from the Solaris x86 installation CD (you can choose to boot from CD 1 as well), the kernel bails out complaining that it detected a 486 processor! 486 is not supported by Solaris 9 and the installation aborts. The reason for this is that Virtual PC reports a processor vendor string that says
ConnectixCPU (instead of something like
AuthenticAMD). Furthermore, the CPU type reported by Virtual PC is
ff/08 (instead of something like
Pentium II). Of course, this is how it should be. Technically speaking, Solaris does not support Virtual PC (rather than the other way round) because it is relying only on hard-coded vendor names etc. to identify the CPU.
Note that this issue does not exist with Virtual PC on Windows (x86). Virtual PC is a virtualizer, not an emulator, on the x86 platform, and reports the real hardware CPUID to a guest instead of a fabricated one.
You have the option of patching Virtual PC, but that would make it work "incorrectly" with certain systems (for example, some BSDs detect
ConnectixCPU and enable workarounds for some Virtual PC quirks). A simple "fix" (credit goes to Paul Day for pointing this out to me) is to simply replace the string
ConnectixCPU in the Installation and CD 1 ISO images. Note that both strings have the same lengths. Similarly,
Pentium II should be replaced with
ff/08..... (the dots are there to make the string lengths equal). Perl (rather than a binary editor) is the most convenient tool to do this:
perl -pi -e 's#GenuineIntel#ConnectixCPU#g' filename.iso
Note that using the simple Perl command lines shown above will change all instances of
Pentium II, which is fine in this case.
Installation should proceed (albeit excruciatingly slowly) once this is done.
Update: If you are using Microsoft Virtual PC 7, the vendor string is no longer "
ConnectixCPU", but is "
Virtual CPU ". There is a trailing space so that the length of the new vendor string is the same as that of the old one. You must use the new vendor string in the "fix" mentioned above.
VSTa is a copylefted system, originally written by Andrew Valencia (it stands for "Valencia Simple Tasker"). According to its web site: " ... [VSTa] uses ideas from several research operating systems in its implementation. It attempts to be POSIXish except where POSIX gets in the way, and runs on a number of different PC configurations. VSTa is also designed to take advantage of SMP right of the box." The 40K in the kernel supports kernel pre-emption, shared memory MIMD multiprocessors, and virtual memory.
VSTa was mainly inspired by two commercial systems, QNX and Plan-9.
VSTa boots and runs fine under Virtual PC.