How to migrate a OS/2 application to a Linux operating system

What are the key programming issues when porting from OS/2 to Linux?

Before you switch to Linux, notice that the traps are discovered earlier. The LANDP team leads you to understand the difference between OS/2 and Linux so that your transplant project can be done more smoothly.

This article is an overview of the problems encountered by the LAN distributed Platform (LANDP) for Linux team when porting LANDP from OS/2 to Linux. This article should be helpful for other teams that are porting OS/2 applications to Linux. When the decision was made to migrate the OS/2 version of LANDP to Linux, the team had the experience of migrating from OS/2 to NT. NT porting includes two main approaches: the mapping layer, the abstraction layer.

The abstraction layer is a little bit simpler than the mapping layer. The abstraction layer is a thin layer of software abstraction that abstracts function names, parameters, and their return codes, while the mapping layer attempts to mimic the behavior of OS/2.

For Linux porting, we start with the development abstraction layer. The abstraction layer will require a lot of additional functionality, which is already obvious. The abstraction layer develops into a mapping layer. The mapping layer is a shared object that has an interface just like the OS/2 interface and attempts to mimic the exact behavior of the OS/2. However, LANDP needs only a subset of the OS/2 functionality, so the mapping layer is not a full implementation.

The following sections outline the most functional differences between the two operating systems and provide some suggestions for dealing with these differences.

The obvious difference

System calls are the most obvious differences between OS/2 and Linux. Some calls are easily mapped (for example, Dosopen), while other calls are not easily mapped (for example, Doscreatequeue). In addition to system calls, the return value and return value have different meanings. Similarly, some return values can be accurately matched, like the File not found, but other return values require an approximate match.

A type is another place that produces a difference. The difference arises because OS/2 renames the type of C and uses the structure of the function arguments. For example, the type UINT on OS/2 is defined as unsigned integers. We must redefine the majority of these types for the Linux environment.

Operational differences

The main difference is in conceptual behavior, which is even more important than porting system calls and redefining types. Most operating systems have the same concepts, memory, files, interprocess communication (IPC), and so on. OS/2 and NT have very similar concepts and their differences are not wide (except shared memory). However, Linux and OS/2 show a number of conceptual differences. The following sections outline these differences and provide some solutions for dealing with these differences.

Thread

A thread in a Linux environment is a special type of process. Therefore, you create a new process for each thread that you use. Also, the thread is implemented by using the Clone function or a separate library called Pthread. There are other forms of threading, but Pthread is a POSIX-defined standard.

Because threading is a relatively new concept for Linux, the operating system is not as thread-safe as other operating systems. As a result, some standard libraries are not really thread safe. In addition, the thread can affect the behavior of the signal. A particular thread will receive a signal sent to the process, and this particular thread is unknown. Note that pthread have their own way of transmitting signals between each thread in a process.

The use of Getpid and getppid will be affected. For example, a thread that invokes Getpid, whose process identity (not the application's process identity) will be returned, because the thread is implemented as a process.