OS/2 to Linux Porting Package

Package: OS2Linux

Version: 0.2.0

Author:  W. David Ashley
         IT Architect
         IBM Linux Technology Center
         dashley@us.ibm.com

You should carefully read this documentation before installing or using the OS2Linux Package.

This software is subject to the terms of the GNU General Public License. You must accept the terms of this license to use this software. Refer to the file COPYING for more information.

This package provides a set of OS/2 header files to be used to recompile your OS/2 application and a Linux Shared Object library that supplies the application with the OS/2 Application Programming Interfaces (APIs).

The goals if this package are as follows:

• Supply a partial runtime environment for an OS/2 console application.
• Provide the porting programmer with as much compliation help as is possible with the GCC compiler including informational, warning, and error messages concerning areas of the application that may need attention during the porting process.
• Try to cover as many of the OS/2 base APIs as feasible.

Many people have contributed to this effort and I want to thank some of them here.

Table of Contents

What is OS2Linux

OS2Linux is a runtime shared object library for Linux (think DLL) for console based applications. It provides the OS/2 base set of APIs in a dynamically linked runtime library. It also supplies a set of custom OS/2 header files to be used in place of the standard OS/2 header files during the compilation of your source code with the GCC compiler.

OS2Linux is a very powerful package that can allow your console-based OS/2 program to be ported to Linux with minimal modifications. The runtime shared library provides most of the APIs used in such applications and the compliation process will warn you when you attempt to compile a feature that is not available.

The following are some of the implementation goals for the OS2Linux Project.

1. The OS/2Linux library is NOT a complete OS/2 emulation environment (no matter how much you wish it was one). It is a porting tool.
2. The library covers as many of the base OS/2 APIs as feasible in a Linux environment.
3. POSIX standards are used wherever possible in the implementation of the APIs, even at the cost of lost functionality.
4. Shared memory is NOT used in the implementation of the OS/2 APIs.
5. Exact functional mapping for APIs is the goal of the implementation but it is not always attained. It may not even be needed by most OS/2 applications.
6. It is not reasonable to expect an OS/2 application to run under the library without some modifications. Some applications may not run without significant modifications.

Linux Package Installation

To install the package on Linux, unzip/untar the contents to a temporary subdirectory. Copy/move the following files to these locations:

   libos2.so      ->     /usr/lib
                              or
                         any location in the LD_LIBRARY_PATH

   *.h            ->     /usr/include
                              or
                         any location in the system include file search path

Be sure the libos2.so file is marked executable. Be sure the header files have the proper permissions.

To recompile your application you can use the OS2Linux test suite as an example. See the test suite makefile and C source files.

After recompiling your OS/2 application you are now ready to execute it.

Linux Information

The package was compiled under Fedora Core 1 using the standard GCC compiler installed from that distribution. You should compile your own module for your version of GCC and Linux.

The package was tested using

• Red Hat Linux version 9
• Fedora Core 1

Version History

 Date       Author      Description
 ---------- ----------- -----------------------------------------------------
 2004-09-06 WD Ashley   v0.2.0 Alpha release  

Known Problems

1. The Named Pipe APIs still need some work to support message mode.
2. The Kbd, Vio and Mou APIs are still mostly only stubs. What is implemented uses curses to perform its work. I am still not sure I want to tackle these. Someone else want to give it a shot?
3. More comprehensive test programs need to be created.
4. The documentation still needs a lot of work.

Future Enhancements

See the section Known Problems above.