Changing OS/2 to Run on Linux

Disclaimer
I have no connection with OS/2 development, and no knowledge of any OS/2 development plans. This article expresses my own personal opinions.

The Current OS/2 Situation
OS/2 has achieved pretty wide-spread use. By 1996 over 15 million copies of OS/2 had been sold, according to IBM figures. Unfortunately the rate of OS/2 sales has declined to only about 1,5% of PC sales, according to a recent IDC survey. Windows on the other hand enjoys more than 90% share of the PC market (although senior MS offcials have argued that it depends on how you define a PC - and what you call a market), and hence Microsoft have plenty of revenue to further develop it. IBM must fund OS/2 development primarily from maintenance revenues. This makes it expensive to keep OS/2 up-to-date with the fast rate of technical innovation in PC technology. The new Merced 64 bit processor due from Intel in 1999 is just one example. Modifying OS/2 to fully exploit this new processor would take a large investment, and it is not clear that subsequent sales would justify this investment. But IBM cannot afford to neglect its OS/2 customers, since they include many large financial institutions. Any pain that they feel as a result of lack of OS/2 development would quickly translate into even greater pain for IBM in other areas of our business relationships with them.

Open Source Software (OSS)
There is currently a very strong groundswell of interest in Open Source Software (OSS). This concept has been around for many years in the shape of the GNU project that develops UNIX application software and gives it away for free. The Apache web server is another example of an OSS project. It is the most widely used web server on the Internet, and yet it's free. The hottest OSS product around today is the Linux operating system. It too is free, and many are convinced that it makes a better network operating system than Windows NT. Some believe that it may soon start to challenge Windows for space on the desktop. Linux lacks the huge range of popular end-user applications that Windows enjoys. There are a number of very interesting options coming onto the market such as StarOffice, ApplixWare, and WordPerfect from Corel, but at this stage Linux can't compete in the consumer applications arena.

Recognising this, the Linux developer community has embarked on an ambitious program to build a capability called Wine on top of Linux. This allows Windows 16 and 32 bit binary executables to run unchanged under Linux. At this stage the range of Windows applications that run successfully under Wine is limited, but the Wine developers are confident that they will be able to run a very large fraction of existing Windows applications within the space of a year. Recently Corel announced that it would donate to the Wine project a substantial amount of knowledge and technology that it has in the area of porting Windows applications to other platforms.

There are many other OSS technologies of impressive scale under active development by volunteers on the Internet. Another that is relevant to this paper is the free X Windows system developed by the XFree86 organisation. It runs on a number of different UNIX systems including Linux, and on a number of different hardware platforms apart from Intel x86. It fully implements the X GUI that is a standard part of UNIX, including the facility to allow application execution and GUI delivery to take place on separate platforms.

The SAMBA OSS provides Linux platforms with both NT client and NT server capabilities to share files and printers using the NETBEUI over TCP/IP protocol. And Netscape have decided that their Navigator browser will become OSS.

Hitching a Ride on OSS
Extending OS/2 to accommodate the constant stream of new PC technology is expensive, and the return for doing so is uncertain. We could greatly reduce the cost of these extensions if we adapt OS/2 to hitch a ride on some key OSS technologies such as: Linux kernel to control the hardware TCP/IP 	to provide IP network connectivity NFS 	to provide UNIX-style file and printer sharing XFree86 	to provide the X Windows GUI interface Apache 	to provide the web server functions Samba 	to provide NT Server style file and printer sharing Navigator 	at last, a state-of-the-art web browser for OS/2!

To achieve this goal, existing parts of OS/2 would have to be removed and replaced with simpler code that maps the normal OS/2 functions that control hardware onto equivalent APIs in the OSS components shown above. We would need to develop an execution environment for OS/2 applications under Linux, just as Wine provides one for Windows applications. Perhaps we could call the OS/2 execution environment Roses, for Restructured OS/2 Execution Subsystem.

Isn't This Unnecessary?
It may seem silly to discard many of OS/2's current facilities such as its TCP/IP stack, for example, when they are perfectly serviceable. But suppose the same machine also runs Windows and UNIX applications - it wouldn't make sense to have more than one TCP/IP stack on the machine. And TCP/IP V6 is coming soon. The OS/2 TCP/IP stack would require extensive change to conform to this new level of standard. If OS/2 makes use of the Linux TCP/IP stack instead then the amount of change to OS/2 would be greatly reduced. And the really expensive part of code isn't developing it - it's maintaining it. The large Linux community will test the Linux TCP/IP stack far more rigorously than we could test ours, and they'll fix it too - for free.

Proposed Structure
The diagram below shows the major components that would be required to implement an OS/2 execution environment under Linux. It also shows: Move your mouse over the asterisks in the table below to get more information.
 * The Roses facility to run OS/2 applications under Linux and XFree86.
 * The optional Wine facility to run Windows 16 and 32 bit applications.
 * A variety of OS/2 services that are needed by many existing OS/2 applications.
 * These could be provided by running the existing OS/2 services under Roses, or by porting the AIX equivalents to Linux.
 * The latter approach would make these services accessible to Win32 apps under Wine and native Linux applications as well.
 * It is likely that the AIX versions of these services will exploit 64 bit processors sooner than the OS/2 versions.
 * We could make some money selling native Linux binary versions of these services to non-OS/2 customers.
 * The facility to run native Linux applications at the same time.
 * A variety of UNIX services commonly found on Linux machines.
 * A common desktop manager.
 * Novell have licensed Caldera to implement their network services for use with Caldera's Linux distribution.

The Common Desktop Manager
Most OS/2 applications interact with and require the OS/2 Workplace Shell (WPS), even if only when they are installed. We could run the WPS as an OS/2 PM application under Roses, but if the user also runs Windows and Linux apps on the same box then these will be managed by a separate X Windows desktop manager, and the user will have to commute between desktop managers to launch and manage applications. This is probably the way to go in the early stages of the port. If it proves to be popular then it may make sense to provice the users with a single desktop manager for OS/2, Windows and Linux applications.

Once of the weaknesses of Linux is that there is no complete and easy-to-use desktop manager available. There are many imperfect ones in use, most of them OSS:
 * twm - The original X Windows desktop manager - primitive and bulky. Its appearance and behaviour are governed by an ascii configuration file that is hard to manage.
 * fvwm, fvwm95 - Looks and behaves like Windows 95, but with the same ascii configuration file as twm. No drag and drop or cut and paste across applications.
 * maXimum TM cde - A billable implementation of CDE for Linux, from Xi Graphics.
 * kde - A very beautiful and elegant desktop manager modeled on CDE. It can be configured by end-users. Still under construction with relatively shallow function. It is based on Qt, which is open source but not in accordance with the GPL. This denies it acceptance by some OSS purists.
 * gnome - Still in the early phases of construction. Promises to deliver a CORBA-based imbedded object model to rival COM. Until there are applications written to exploit this, it will be of little use.

A good desktop manager is needed. The OS/2 Workplace Shell (WPS) is a fine piece of work, but as it stands it can't control X Windows. However, CDE was based on WPS and it already runs in conjunction with X Windows on AIX, Solaris and other UNIX systems. It should be quite easy to port CDE to Linux. The Roses environment would have to augment CDE to preserve full compatibility with WPS. This would provide a common desktop manager across OS/2, Windows and Linux applications.

The Linux community is already divided into competing groups around the KDE and Gnome development efforts. They are unlikely to welcome a new contender into this highly competitive arena. That shouldn't particularly concern us, since we would be developing Linux CDE primarily for our OS/2 users. While Gnome has a strong imbedded object model, it is currently very weak in the area of desktop management. We may choose to link our Linux CDE to the Gnome object request broker (called ORBit) rather than the OS/2 SOM/DSOM ORB. This could be an OSS effort supported by the OS/2 development team, other interested IBM employees, and OS/2 users. Between the approximately 300,000 IBM employees and untold millions of OS/2 users it is reasonable to expect that there will be many able and willing to participate in a project of this sort on a voluntary basis. And at the end of the day it may just turn out that our Linux CDE exploits the Gnome infrastructure better than any other desktop manager around. Standards aren't designed - they're acknowledged.

Novell NetWare
Linux should become very attractive to the large population of Novell NetWare users once Caldera has completed their port of Novell's Network Services software to run under Linux. Comes to that, NetWare itself will become far more attractive to these users. NetWare users love the function, performance and stability that NetWare offers them today, but the base operating system functionality offered by NetWare is very thin - it's a souped-up DOS. Novell have lost much ground to NT because NT can do a lot more than just file and print sharing and email. If a company has a small branch that only justifies one server, they find it hard to cost-justify putting in two servers - one for NetWare and another to run other applications. They often solve this problem by kicking out NetWare and putting in a single NT server that does everything. It may not do the file and printer sharing as well as NetWare, but it does it well enough.

Many of our customers use NetWare clients on OS/2 clients. If OS/2 gets ported to run on Linux then native support of Novell's network services by Linux would be a plus for them. We should do the port in such a way that OS/2 no longer needs NetWare client support built into it. The DOS emulator and Wine implementations under Linux allow DOS and Windows applications to access both local and remote files within the Linux file directory hierarchy. A configuration file maps DOS and Windows drive letters such as C: and D: onto specific directories in the Linux file system. That way DOS and Windows apps can access local files directly and remote file systems via NFS as if they were local. Once NetWare runs under Linux, NetWare-accessible files will also be reflected into the Linux directory hierarchy and hence can be made accessible to DOS, Windows and OS/2 applications running under Linux.

Is This Doable?
Making suggestions is easy, but is the idea of implementing OS/2 as a personality under Linux and XFree86 doable? There are no short-cut answers to this question, much detailed study would be needed. But here's a few indications that it should be possible:


 * When IBM brought out OS/2 Warp, a small team of IBMers modified Windows 3.1 to run under OS/2. Microsoft had said that it couldn't be done, but the IBM team did it in a few months of intensive effort. Of course OS/2 is a much more subtantial piece of software than Windows 3.1, but it is also a much better structured system. The same approach could be used again.
 * The fact that the Wine project has already got pretty far implementing an environment for Windows applications to run under Linux suggests that Linux has the right structure to accommodate guest personalities of this sort.
 * The early alpha code of Wine required a copy of WINOS/2, the code developed by IBM to run Windows 3.1 applications under OS/2 Warp. WINOS/2 uses the OS/2 PM and kernel APIs. Clearly the Wine group were able to map this onto equivalent Linux facilities, so they should be able to tell us how to go about it.
 * The design of OS/2's Presentation Manager (PM) was loosely based on that of X Windows, which should help in the mapping of PM APIs onto X Windows APIs.

Where's the Money?
The hackers who contribute to OSS projects are often portrayed as social misfits, hacking free code in a garret instead of leading a real life. IBM employees are different (mainly). They expect to get paid. And IBM stockholders expect profits. So where's the money in porting OS/2 to run under Linux? Will we have to give it all away for free, including the source code, so we lose our intellectual property?

The major figures in the OSS movement tend to have a realistic appreciation for the role of commerce in computing. They are happy to see companies like Red Hat, Caldera, Debian and SuSe distribute copies of OSS software on CDs for money. The OSS community responded with uncritical joy when Oracle, Informix, Corel and IBM announced that they would port and distribute binary versions of some of their products to Linux, whether for money or for free.

There's absolutely no reason for IBM to "give away" OS/2 and its services if we choose to port them to run under Linux. We can distribute binary versions of the code for a fee, retain our intellectual property, and charge money to service the binaries just as we do today.

Here are some suggestions about how we might proceed:


 * We have developed some very valuable services for OS/2 over the years. These include:
 * Communications Server/2 to deliver SNA services
 * DB2, with world-leading functions and performance
 * MQ Series server and client components for messaging
 * CICS server and client components for transaction processing
 * NDM for managing the distribution of code to distributed platforms
 * Notes / Domino groupware


 * We have ported these services to AIX, and more recently to Windows NT. They are worth a great deal to our customers - and to us. There's no reason why we shouldn't port them to Linux and sell and support them just as we do today. Indeed, there are good reasons why we should:
 * The customers who use these services are developing an unhealthy dependency on Windows NT. NT does not provide a stable platform, and our services suffer as a consequence.
 * The next version of NT will be called Windows 2000, and it will contain about 40 million lines of code - much of it new. There is good reason to fear that it will be less stable than the current version.
 * Microsoft seem intent on pushing NT further up the food chain to compete with large-scale UNIX systems and main frames. This is making NT increasingly unaffordable in the small server arena, both in terms of direct cost and the resources that it requires to run. There is a growing gap at the low-end of the server market (see my paper on the SOHO server market). If we don't port our services to a server platform that can service the low-end market then we will lose out in this rapidly growing area. Of course OS/2 itself is a very good candidate for servicing this area, but there is a strong feeling in the market that OS/2 has failed, and a fear that it is just as closed and proprietary as Windows NT. Porting OS/2 to run under Linux would probably do a great deal to allay both of these fears.
 * We could consider making a version of Roses (the OS/2 execution subsystem under Linux) available for free download for evaluation purposes, with no support, just to promote acceptance of the system.
 * We could distribute a version of Linux with binary versions of Roses and selected services code on a CD for a fee. We would ensure that the versions of Linux, Roses, and the services on this distribution work well together. The purchaser of the CD would have the rights to install the Linux components on any number of machines, but Roses on only one (unless they buy extended distribution rights with the CD). They could install the services on a single server only if they purchase the rights to do so. This is consistent with how we sell software today. Red Hat and the other Linux distributers routinely include copies of "one machine only" product binaries in their distributions, so there is a precedent for this approach in the OSS community.
 * We could offer normal defect support for a fee for copies of Roses bought on distribution CDs.
 * We could also offer support for Linux, perhaps in conjunction with a distributer like Red Hat. Linux is just another version of UNIX, and we have plenty of experience and skills in supporting various implementations of UNIX on our products, e.g. AIX, OS/390 Open Edition, and the IBM Network Station.

Benefits
The implementation future versions of OS/2 as an execution environment under Linux would offer many benefits to us and out OS/2 customers:
 * The long-term OS/2 kernel development and maintenance costs would be significantly reduced since we would piggy-back on the development and testing efforts of the Linux and other OSS communities.
 * Over time we will be able to eliminate or greatly reduce in size and complexity many OS/2 components such as:
 * The TCP/IP stack would be much simpler, the Linux stack would do most of the work.
 * Ftp, telnet and other remote access functions would be supplied by Linux.
 * Novell NetWare client could be eliminated - we could use native Linux NetWare support.
 * NetBIOS client function could be replaced by Linux's NFS or SAMBA in most cases.
 * OS/2 won't need a browser or email client any longer, Netscape under Linux can do this work.
 * Remote access to PM applications would be provided by X Windows.
 * OS/2-specific services could be phased out over time and the Linux equivalents used instead:
 * DB2 Server
 * Communications Server
 * CICS Server
 * MQSeries Server
 * Domino Go Server (use Apache under Linux instead)
 * DCE Server
 * UPM (User Profile Management - map onto Linux user directory services)
 * OS/2-specific versions of productivity applications could be phased out and Win32 equivalents under Wine on Linux (or perhaps over time native Linux eqivalents) used instead:
 * Lotus SmartSuite applications
 * Notes client and Domino server
 * Our OS/2 customers would be able to exploit a wider range of technology than we could afford to support on our own. The Linux community are swift to develop device drivers to support most bits of hardware that can be connected to PCs.
 * OS/2 users would be able to run most Win16 and Win32 applications under Wine on the same PC as OS/2, eliminating the greatest cause of frustration that these users experience today, and the greatest disincentive to using OS/2.
 * OS/2 users would be able to run most UNIX applications under native Linux on the same PC as OS/2, giving them together with Wine access to a wider range of applications than straight Windows users have. The boot will be on the other foot for a change.
 * Since the OS/2 user interface would be delivered via X Windows, it could very simply be delivered to a remote workstation making it easier to access OS/2 systems remotely than it is today (and much easier than it is for Windows). This would allow users to access their home or office systems remotely, and systems maintainers to view problems on remote systems without having to travel to them.
 * Since Roses would be an application running under Linux, it would be straight-forward to use normal UNIX facilities such as tar/gzip and FTP or NFS to distribute new versions of Roses and OS/2 components such as DLLs to remote systems; and then to use Telnet or remote X Windows to install, configure and test this software on remote systems. This would give OS/2 administrators very powerful and convenient tools for installing and maintaining OS/2 "operating systems" remotely. They could install new versions in separate directory structures and switch from the current version to the new version by changing a few symbolic file links - and fall back from new to old equally simply if needs be - all without rebooting the underlying Linux OS.
 * A single Linux system with Roses could run multiple independent OS/2 processes at the same time and deliver each one to a separate remote user, giving OS/2 the same multi-user facilities that Citrix Winframe gives toWindows NT 3.51 and TSE gives to NT 4.
 * Linux systems may be booted from a server over a LAN using the UNIX bootp and NFS protocols. Hence the software for Linux and its guest Wine and Roses execution environments and all of the applications that run under them could be resident on a server rather than a hard drive of the Linux machine. This gives Linux many (although not all) of the features of OS/2 Workspace on Demand (WSOD), which has proven to be very attractive to our larger customers.
 * OS/2 servers would benefit from the speed, efficiency and reliability of the Linux kernel and TCP/IP stack while still being able to run existing OS/2 applications and services. This would make OS/2 servers even more cost-effective than NT than they are today.

The Drawbacks
There is no free lunch, and every option has some pitfalls. Here are some:
 * If we introduce our OS/2 customers to Linux via this new version of OS/2 and they find that Linux can deliver all that they need then they may ditch OS/2 (this isn't much of a threat since they're ditching OS/2 for NT anyway).
 * The OSS communities may grow resentful if we use their works, give nothing in return, and prosper. Our early experiences of working with the Apache community show that providing we are prepared to make valuable contributions to their projects, they will be delighted to embrace us. We would need to think of things to give the Linux, XFree86 and other OSS communities if we use their products on a large scale:
 * Porting the OS/2 WPS or AIX CDE to Linux and XFree86 may be a good candidate, since we will need it anyway. We could give the source and object code away - they don't seem to give us compelling advantage.
 * Linux lacks a JVM JIT (just-in-time compiler) and hence runs Java slowly. If we port OS/2 to Linux then we will have to make sure that Java gets a JIT that performs as well as our current OS/2 JIT, which is pretty hot.
 * We should be able to build a JIT for Linux using Jalapeño. We could consider giving the JIT binary code away.
 * We could port our HPJC (High Performance Java Compiler) to Linux so that it can be used to compile Java servlets to native machine code on Linux web servers.
 * Sun have announced that they will release a V1.2 JDK for Linux, but their announcement makes no mention of a JIT. They are in the awkward position that if they make their JVM for Linux really good, it will compete directly with their Solaris operating system. The whole point of Java, as Sun has often told us, is that it gives you platform independence. While they're keen to offer this newfound freedom to Windows users, they may be less excited about offering their Solaris users some really great free alternatives.
 * We could consider porting some aspects of the OS/2 Workspace on Demand technology to Linux and releasing it as OSS. The pieces that support user profile creation and editing, the linking of profiles to resources, and the automatic customisation of the user's Workplace Shell desktop to reflect only those resources that they are authorised to use, would be of great value - to our competitors too, unfortunately. But this would do much to promote the thin client paradigm that we espouse. Sometimes you have to give in order to receive.
 * There is growing concern in OSS circles that Microsoft may seek to buy out patents that cover approaches used by Linux and other UNIX systems, and then seek to suppress Linux. This concern was fueled by a leaked Microsoft internal document published on the web as the Halloween II document. It specifically mentions the possibility of attacking Linux through patents and copyrights. These are known as intellectual property (IP) attacks.
 * Porting OS/2 to Linux would make it dependent on OSS products which could disappear in a puff of smoke if Microsoft finds a way of buying up UNIX patents that these OSSs would then infringe. This risk needs to be carefuly assessed.
 * Are the OSS systems like Linux more susceptible to this form of attack than other major software systems such as OS/2, AIX, or OS/390? It may be so because there is no powerful company behind any OSS that could spend the money required to defend the OSS's rights in court. If IBM stakes the future of OS/2 on Linux, XFree86 and other OSS systems then IBM would have to be prepared to defend these from an IP attack in the same way that IBM would defend OS/2 or OS/390 from such an attack.
 * We may have enough UNIX-related IP of our own to bail Linux out if Microsoft throws them into jail. If not that, we certainly have enough IP of our own to do some horse-trading and secure ourselves the rights to use Linux and other OSS binaries as the basis for OS/2, whether or not they can be publicly distributed in source form.
 * Microsoft is aleady in plenty of trouble with the Department of Justice. An attack on OSS would enrage many.
 * Such an attack may just persuade the US legislature to revisit the wisdom of protecting software ideas through patents. Most countries are content to protect software IP rights through copyright laws, which are easier to apply to software.
 * Some of our more conservative OS/2 customers may be concerned that the present excellent stability of OS/2 would be jeopardised if it becomes dependent on code written by a bunch of long-haired hackers (so who do they think we hire?).
 * We could allay these fears by saying that we have the source code, and will subject it to our normal stringent standards of quality testing before deploying it as OS/2 infrastructure (damn, that's good! I should have been a lawyer).
 * We would probably build our own distribution CD containing Linux (possibly customised) with Roses, the OS/2 execution subsystem, a lot of OS/2 binaries such as DLLs and utilities that are in the current OS/2 distribution, a Linux like Red Hat's, and an OS/2 installation utility.
 * We would ensure that all these pieces work together, and offer defect support for the whole bundle as we do for OS/2 today.

In Conclusion
I don't have a conclusion. There are many complex issues invoved, and it will take a lot of hard work to evaluate them. I would be very happy to receive your comments, complaints and suggestions. I'm happy to incorporate your ideas in this paper if I understand them, and to acknowledge your contributions. Maybe we can get an Open Source Discussion (OSD) going on OSS for OS/2. It works for Linux, maybe it can work for us.

Change History

 * 1998-11-16 Steve Fox questioned whether the OS/2 WPS or AIX CDE desktop managers would be accepted by the general Linux community. I have clarified my discussion of WPS to indicate that existing OS/2 applications will require the full functionality of WPS.
 * Steve also noted that Sun have announced that they will ship a JDK V1.2 for Linux and that this may solve the JIT problem.


 * 1998-11-17 Pierre Fricke reports discussing CDE and WPS as possible bases for desktop managers for Linux with delegates at the Open Group meeting for Linux, and eliciting no interest. I have revised my suggestions.
 * 1998-11-25 Sailesh pointed out that I referred to Jikes when I meant to talk of the High Performance Java Compiler. I have fixed this section.
 * 1998-12-10 J.F. Meyer drew my attention to the availability of maXimum TM cde, a commercial implementation of CDE from Xi Graphics.
 * 1999-02-18 Cam McFarland pointed out some typos in my discussion of Intellectual Property.