There are at this time, a number of what I would term ‘OS re-creation projects’ (OSRs) in active development. These are OSes that attempt, by varying degrees, to re-implement the features of another operating system. In this article, I’m going to explore some of issues surrounding projects of this type. In the second half of the article, I apply these observations and examine two example platforms (Amiga and OS/2) and the related re-creation OSes.
Every OSR is defined by two criteria:
The choice of inspiration OS (IOS) which serves as the inspiration to the OSR.
The degree of adherence to the design and implementation of the IOS.
Obviously, these re-creation efforts do not seek to create a direct facsimile of the original OS. The reasons for this are two-fold:
Firstly, any OS which was simply a copy of another OS and that did not vary in any way from the original, would be, by definition, redundant. By way of example, let us say that a group of people might set out to create an open source clone of the Microsoft Windows operating system so that they could release it as freeware. In this example, it is the licence and the development model which vary from the original source OS.
This first point is dependent on the motivation of the developers – why do they want to create this new OS? Example motivations and ideological aspirations for such a project might include, in varying amounts, factors such as:
The re-creation of the best parts of an older operating system, but utilising more modern methods of design and software engineering.
The re-implementation of another OS, under a more open development and distribution model.
Secondly, the IOS system must, logically, predate the creation of the OSR; it is therefore natural that some advancement in the field of operating system development and hardware development would have occurred in the time between the release of the the IOS and the start of the re-creation project.
Omission and Addition
The developers who are involved in the actual creation of the new OS will almost certainly have some opinions on the subject of OS design. The two ways in which a thing which is inspired by something else can deviate from the original are by omission and by addition. The creators of a clone OS would have less motive to recreate a feature which they regard as unimportant than they would have motive to create a feature which they regard as relevant. This is not to say that the omission of a feature is evidence that the re-creators felt that it was a mistake in the original OS. An omitted feature may represent a function whose importance has become depreciated by time. For example, an OS created in 1994 might feature a very well designed and comprehensive Internet modem dialler; however, the importance of this feature is depreciated in 2006. An OSR of this sort might place only limited importance on full and comprehensive floppy disk support, for the same reasons.
Also, an omission might represent a compromise on behalf of the developers that was brought on by practical considerations. If a team were to create an a new OS which was similar in function and design to MacOSX, they may decide to stop short of recreating all of the iApps which are bundled within a MacOSX distribution. Having the complete iBundle set of applications might be desirable in a MacOSX clone but its omission could be the result of the practical resource limitations which face any software engineering project.
Internal and External Similarity
All things that can be observed and therefore assessed can be subjected to an analysis from two different standpoints – internal and external – or, the way things look and the way things work. This philosophy can be applied to an assessment of OSR projects.
Some OSRs utilise a ‘ground up’ approach in that the internals of the OSR mirror the internals of the IOS. One motivation behind this approach can be that, in the view of the developers, the design of the internals of the original OS were based on sound principles. The FAQ of the Syllable project states this as a design motivation:
“The BeOS API is undoubtedly a good design though. The Syllable API does use a lot of good ideas from the BeOS API, but we also design and add our own classes.”
Another motivation behind a re-creation of the internal parts of another OS would be in order to maintain some degree of compatibility that OS. This compatibility may take the form of source code or binary compatibility. In other words, in the OSR may be similar enough to the IOS to be able to run programs or even drivers which were created for the OSI (binary compatibility) or it may simply be a design goal that programmers with access to the original source code should easily be able to ‘port’ their existing software to the OSR (source code compatibility).
There is a third, important aspect to the degree of correspondence between the internals of the IOS and OSR and that is architectural similarity. For this reason, it is often an easier job to port a Unix tool to an OS like AmigaOS than to an OS such as RISCOS. This is because AmigaOS shares greater architectural similarity with Unix than RISCOS does. Like Unix, AmigaOS is based around preemptive multitasking. AmigaOS also has a filing system architecture which was inspired by Unix file system concepts to a greater degree than that of RISCOS.
In the same respect, a window manager for Linux which resembled RISCOS wouldn’t be a particularly good target platform for the task of porting RISCOS applications; the reason for this is that, this platform may increase the external similarities between the platforms but would do little, if anything, to increase the internal, architectural similarities between the two OSes.
Any appraisal of the prospects for the long term survival of an OS must include economic assessment. In the case of a FOSS OS, the economic factors are not monetary in nature but rather, concerned with the commodity that is manpower. To be a viable, sustainable project, the amount of manpower that the project can attract must be the same as or greater than the amount of work that needs to be done to maintain the project.
In the case of a purely commercial OS project, the most important considerations are monetary. In a commercial context, the manpower that the project requires has a monetary value attached to it. To be sustainable, the project must have available to it an amount of money that is equivalent to the amount of manpower that the project needs.
So, the question, “Is the project viable, in the long run?” could be reformulated as “Is the project sustainable?”. In commercial or FOSS OS projects, any design decision that increases the amount of manpower needed has impact upon the sustainability of the project. In the case of living things, businesses or operating system projects, the amount that comes out is equal to or less than the amount that is put in.
Whenever I read about a new OS project, I want to know what their plan or model is going to be: I want to know how they are going to attract the amount of resources they need in order to do the work of creating the finished (or ongoing) product. If one guy says that he is going to do all of the work himself, can he? If the originator(s) of the project claim that other people are bound to join in, what is evidence that supports their assertion? Is this assertion backed up by precedent, for example?
Similarly, a design decision which affects the accessibility of the project to developers will impact it’s sustainability. One way in which access ability can be limited is through decisions that tie the platform to unusual hardware. Particularly in the case of open source software, there is a relationship between the accessibility of the platform, the number of users and the number of developers.
In the case of any OS project, any such appraisal must take into account the creation or maintenance of the applications that people are going to want to run.
Some current OSRs
Using the principals I’ve outlined, I’ll focus on two different platforms and their corresponding re-creation projects.
For those who aren’t in the know, OS/2 started life as a joint OS project between Microsoft and IBM. The earliest, 1.x versions of OS/2 were 16 bit and had a front end not dissimilar to early versions of the Windows OS. The popularity of Windows grew at a rate beyond the expectations of Microsoft and as a result, they decided to concentrate their efforts on Windows and to abandon the OS/2 project. IBM on the other hand wanted to continue developing OS/2.
The 2.x versions of OS/2 represented a considerable technological departure from what had gone before. OS/2 2.0 was 32 a bit protected mode OS. The other departure from both the older version of OS/2 and the versions of Windows which were its contemporaries lay in the GUI. Amongst former users, the GUI is the most fondly remembered aspect of this operating system.
Prospects For Revival – The Bad
Whenever the matter of reviving OS/2 is brought up, I find myself asking – why? It is difficult to see which of the technologies that existed in OS/2 and could be brought back to life within a modern implementation. Many of the features, such as industry-leading DOS support, which gave OS/2 its edge, are simply no longer relevant.
OS/2 has some technological problems too. The messaging system of the GUI relies upon something called the ‘single input que’. In a nutshell, this reliance upon a SIQ means that a single crashing application can bring down the entire OS. This manifests itself in a situation in which the user can see programs running but will find his or herself unable to interact with the system. The only solution when this happens is to reset the machine.
Even if a complete, working clone of OS/2 were to be made available tomorrow, at no cost, where would the applications come from? The uptake of this OS would have to be considerable to attract the development manpower needed to develop and maintain software. If a developer dedicates the needed amount of time necessary to create the software that OS/2 needs, he has expended that amount of effort in way that only benefits OS/2 and its users. The same could be said in the case of most operating system but at least number of Linux, Windows or Mac users is considerable.
Another problem with OS/2 is that the API used to create full GUI applications isn’t very compatible with anything else. So, although it is technically possible to port full GUI applications to OS/2 from other OSes, it requires a lot of work; manpower in other words. To use a comparison: If a new Linux distribution were to be released, and if efforts had been made to ensure full compatibility with other Linuxes, the effort required to port an application such as the Firefox web browser should be somewhere between minimal and none.
Some people would point out that OS/2 has quite a lot of existing software. It does, but can anyone reading this article suggest a list of killer apps which aren’t equalled or bettered by the apps on other systems?
What could be salvaged from OS/2 if it were to be re-created?
The final version of OS/2 that IBM actively and extensively developed was OS/2 Version 4. This was released in 1996; consequently, its target hardware is the hardware that was common at that time. It offers a snappy, fairly feature-rich GUI OS that can easily run on a P166 with 64megs of RAM. In extreme conditions, it can be convinced to run quite well with even more meagre resources.
I would rate the Windows 9x of the same era as barely usable in terms of reliability and also somewhat feature poor. On the other hand, despite design flaws which place limits on fault tolerance of applications and subsequent OS reliability, OS/2’s stability is probably better than any of the other client oriented, GUI OSes of that time.
Perhaps a new OS/2 could be a good OS for NGOs and third world countries? Given an early Pentium and the right software, it could form the basis of a nice little word processing, emailing and web browsing station.
It’s GUI contains some elements which haven’t been fully assimilated into other operating systems yet. Many of the GUI concepts are rooted in the object orientated design philosophy of the OS. For example, it is possible to make any file system object into a ‘template’. This object could be a blank text file, an empty .zip file, a standard letter or even a folder containing other file system objects. A web developer might, for example, create a blank ‘website’ template consisting of a root directory which contains an initial ‘index.html’ file, an ‘/images’ directory with all of the .png files that the web developer might normally use and a standard ‘robots.txt’ file to guide search engine spiders. Once this object has been marked as a template, the user can create another with a simple drag operation.
Another useful feature of the OS is the integration of the REXX scripting language. Many applications feature REXX ‘ports’ which mean that users can add their own plug-ins created in the native scripting language.
OS/2 has a few neat features of this sort, and I think that they should live on as add-ons to other operating systems.
In its day, OS/2 struck a good balance between hi-tech features and reasonable performance on the hardware of the time. It was also the first consumer OS to ship with TCP/IP networking and an Internet dialler as standard.
The fact that it never quite broke through to the mainstream wasn’t as much of a handicap as some might think as OS/2 had some high quality shareware, commercial and freeware native apps. OS/2 could also run a lot of software which had been created for other platforms or that had been created in a platform independent manner. For example, it was the first consumer OS to ship with Java support as standard; OS/2 had probably the most comprehensive DOS support of any GUI OS; it could run Win3.x software. In its later years, an impressive project called Odin enabled a OS/2 to run a surprising amount of 32 bit Windows software. In other words, you had access to almost any type of application, even if it wasn’t a native OS/2 application.
However, the very features which made OS/2 the OS of choice for so many have faded in importance. It is with a heavy heart that many of OS/2 former users (myself included) have to admit that they don’t really want to go back to OS/2 anymore than they would trade in their broadband Internet connection for dial-up ANSI BBS access and 320×200 VGA games with ad-lib music. Perhaps IBM could have kept OS/2 relevant but they didn’t make any serious efforts to develop it beyond about 1996.
What features, for example, does the kernel offer that modern operating systems do not? For that matter, does anyone really want to use an OS that uses drive letters?
In conclusion, in my opinion, recreating OS/2 would be more work than starting an OS from scratch, considerably more work than improving another OS and ultimately, produce a less useful result than either.
The website includes a fairly comprehensive outline of what the developer would like to accomplish with this relatively new project. As the project is new, the bulk of materials are design docs as opposed to actual runnable code. Despite this wealth of design documentation, actual design specs are still rather conceptual rather than specific. For example:
The the kernel hasn’t been settled upon yet. It might be based upon a Linux kernel.
The exact nature of GUI is still undecided. In design terms, it will not be based on X Windows but it will make some concessions towards the PM+WPS nature of OS/2. How API compatible it is, is also not specified.
Source and binary compatibility with OS/2 is still undecided.
It’s impossible to make reliable judgements about the viability of a project which is still at the design stage. In its favour, at least the planning stage has been extensive. Also, it’s worth noting that the people associated with the project have a track record for software development on OS/2.
OSFree was initiated in 2000 but as with Voyager, the project exists as a set of design outlines and some test code. It would seem that they have settled on the idea of using the L4 Micro-kernel and have successfully recreated some of the OS/2 CLI tools. The project certainly isn’t dead though, there is some activity in the forum.
The history of the Amiga can be divided into three eras.
In 1985, the Amiga was, conceptually, a Unix-like workstation that could run on custom, inexpensive hardware while still offering cutting-edge multimedia capabilities. It could be scaled from a floppy disk based, basic model, plugged into the TV of a lucky teenager all the way up to a professional class graphics workstation. For the hobbyist user, the most important element of the Amiga design was the use pattern that it engendered; a typical user would read some text files, check on the rendering which was taking place in the background all while listening to some .mod music. Sound familiar? The Amiga was so far ahead of its time that it offered its users a genuine glimpse of what a average geek’s leisure computing experience would consist of 20 years later.
The rival platforms started to catch up but the Amiga arguably held its own throughout the middle period of its history. The platform didn’t stand still: chip giant Motorola kept putting out faster 680×0 series chips while, at the same time, Commodore made incremental improvements to the OS and hardware.
From the perspective of any Amiga fan, the third, current period is the bleakest. The pressure from the rival efforts of Microsoft became absolutely intense while at the same time the Amiga suffered a series of setbacks as the result of mismanagement and simple bad luck.
I would challenge any fan of the Amiga to discuss what happened to the platform next without getting angry. For the purposes of this article, it will have to suffice to say that Commodore went bust, the Amiga properties went on the market and then a succession of companies promised a great deal and delivered very little. The set pattern of events became that a new company would purchase the rights to develop the platform, they would then… actually, I’m not quite sure what they were actually doing… but at the end, they would have nothing to show for it. And then the pattern would repeat again.
Prospects for revival – The bad
The Hardware Advantage
Much of Amiga’s performance superiority came from its incredibly powerful custom chip-set. Needless to say the capabilities which were jaw-dropping in 1985 couldn’t hope to power the typical flash-based banner ad now. If an effort were made to re-create a similar hardware platform that was orientated around a unique graphics architecture like the original Amiga was, its difficult to see how any custom architecture could beat the output of mainstream graphics accelerator chip-sets such as NVIDIA and ATI. In other words, the Amiga regaining the multimedia hardware superiority that it enjoyed upon release is unlikely.
In its current form, AmigaOS has the dubious distinction of being one of the few OSes based around a micro-kernel but operating without memory protection. A typical micro-kernel implementation keeps all of the programs and all but the minimal, low level hardware drivers in their own protected memory. OSes such as Linux, MacOSX and Windows use a type of kernel called monolithic. In a monolithic kernel, drivers exist within the kernel or execute at the same level of privilege; this means that if a driver crashes, the whole system crashes. The micro-kernel design also has security advantages over the monolithic.
Unfortunately, the micro-kernel has a performance cost. On the original 1985 hardware a 20% performance hit was unacceptable and for this reason, AmigaOS uses a micro-kernel but without memory protection. In fact, it makes far less use of memory protection than most monolithic kernels do. If one application crashes, it can bring down the whole system.
Because of the way that the API is designed, a choice has to be made between breaking source and binary compatibility with current software or accepting that the machine is going to crash a bit more than average. One possible, hybrid solution would be to loose standard native app compatibility yet, at the same time run the old applications through a compatibility emulation layer.
In my “My Dream OS” article, I stated:
“I consider stability to be an area in which most modern operating systems have improved over the older generation. Some people seem to have a different memory of these things than I but I seem to remember that my RISC OS, Amiga OS and OS/2 based machines would crash quite often.”
And I stand by that, it would take quite a lot to convince me that a modern AmigaOS could archive the level of stability that most people have to come to expect while still being based on a design model that does not feature extensive memory protection.
On the one hand, the overall architecture of the OS is, in some respects, Unix-like which eases the efforts of programmers porting applications. On the other hand, the Amiga GUI system doesn’t make any concessions towards compatibility with anything else. So, full GUI apps will take a lot of work to port and command line and server type apps less work.
Over the years, the graphics and sound APIs have been updated so that modern applications are no longer tied to the legacy hardware. Amiga OS is also small and fast. Amiga OS has a dedicated community of users and hobbyist developers. The size of this community and their loyalty are a huge asset that should be included in any assessment of the viability of the platform.
In my opinion, the viability of a new AmigaOS hinges on the one Achilles heal of the entire OS, that of the stability and security problems raised by the lack of proper memory protection. It seems quite possible that if a viable, architecturally sound AmigaOS could be created in the near future, a substantial user-base and developer base are guaranteed.
The AROS project is an attempt to create an open source, portable implementation of AmigaOS. It aims for feature set roughly equivalent to that of AmigaOS 3.1. As it is largely source code compatible, Amiga applications can be recompiled for the OS or run under the AROS port of the UAE Amiga emulator. This high degree of compatibility at the source code level is a mixed blessing as it means that the OS has to make some concessions towards the legacy deficiencies of the original Amiga OS. For example, the FAQ has this to say on the subject of memory protection.
Several hundred Amiga experts (that’s what they thought of themselves at least) tried for three years to find a way to implement memory protection (MP) for AmigaOS. They failed. You should take it as a fact that the normal AmigaOS will never have MP like Unix or Windows NT.
However, it should be noted that they do present, in the FAQ, some ideas to work around this lack.
There is good overview/review of the OS in this OSNews article.
And another overview on Wikipedia.
MorphOS is another attempt to create a Amiga-like operating system. It aims for good source code level compatibility with AmigaOS applications. The development uses a combination of open source components with proprietary closed source development. The OS is tied to the PPC platform and can run on either the special Pegasos [see – http://en.wikipedia.org/wiki/Pegasos ] hardware or original hardware Amigas which are equipped with PPC accelerator cards.
See also the wikipedia page.
About the Author:
Once, at school, Mike attempted to explain why Amigas were better than Spectrums to a member of the opposite sex; he’s regretted it ever since. Check out his website to learn more about his never finished writing and music projects.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.