当前页面位置: » 丰搜网 » 文档中心 » 详细内容
将os/2应用程序移植到linux(用c语言)
当从 os/2 移植到 linux 时，关键的编程问题是什么？
kevin bowkett (kevin_bowkett@uk.ibm.com)
ibm 软件工程师
在转换到 linux 之前注意一下，提早发现陷阱。landp 小组带领您了解 os/2 和 linux 之间的差别，以便您的移植工程才能更顺利地进行。
介绍
本文是 lan distributed platform（landp）for linux 小组把 landp 从 os/2 移植到 linux 时所遇到的问题的概述。本文对其他正在把 os/2 应用程序移植到 linux 的小组应该是有帮助的。关于 landp 和 linux 的附加背景信息，参见 ibm.com/software/ts/landp/library/whitepapers/linux.html。
当决定了要把 os/2 版本的 landp 移植到 linux 时，小组已经有了从 os/2 移植到 nt 的经验。nt 移植包含两个主要的途径：
映射层
抽象层
抽象层比映射层稍简单一点儿。抽象层是薄薄的一层软件抽象，它抽象了函数名、参数以及它们的返回码，而映射层则试图模仿 os/2 的行为。
对于 linux 移植，我们从开发抽象层开始。抽象层将需要许多附加功能，这是早就显而易见的。抽象层发展成了映射层。映射层是一个共享对象，有一个恰似 os/2 接口的接口并且试图模仿 os/2 的精确行为。然而，landp 需要的仅是 os/2 功能的一个子集，因此，映射层不是一个完全实现。
下面几节概述了两个操作系统在功能上大部分不同之处，并且提供了一些处理这些差别的建议。
明显的差别
系统调用是 os/2 和 linux 之间最明显的差别。一些调用容易被映射（例如，dosopen），而其它的调用不容易被映射（例如，doscreatequeue）。除了系统调用之外，返回值和返回值的含义也不同。同样，一些返回值能被精确匹配，像 file not found，但是其它的返回值需要近似匹配。
类型是另一个产生差别的地方。因为 os/2 重新命名了 c 的类型且使用函数参数的结构，所以就产生了差别。例如，在 os/2 上类型 uint 被定义为无符号整数。我们必须为 linux 环境重定义这些类型中的大多数。
操作上的差别
最主要的区别在于概念的行为，这甚至比移植系统调用和重定义类型更为重要。大多数操作系统具有相同的概念、内存、文件、进程间通信（ipc）等等。os/2 和 nt 有非常相似的概念且它们的差别不是大范围的（除了共享内存外）。然而，linux 和 os/2 显示了许多概念上的差别。下面这些子节概述了这些差别，并且为处理这些差别提供了一些解决方案。
线程
linux 环境中的线程是一个特殊类型的进程。因此，要为您使用的每个线程都创建一个新进程。而且，通过使用 clone 函数或一个叫 pthread 的单独的库来实现线程。也存在其它形式的线程，但是 pthread 是一个 posix 定义的标准。
因为对 linux 而言线程是一个相对新的概念，所以这个操作系统不是和其它操作系统一样线程安全。因此，一些标准库并不是真正的线程安全。另外，线程会影响信号的行为。特定的线程将接收一个被发送到进程的信号，这个特定的线程是未知的。请注意，pthread 有它们自己在一个进程中的每个线程之间传送信号的方式。
getpid 和 getppid 的使用将受到影响。例如，一个调用 getpid 的线程，它的进程标识（不是应用程序的进程标识）将被返回，因为线程被作为进程来实现。
内存
进程内存在 linux 和其它操作系统中的使用非常类似，但在进程间共享内存的机制不同。linux 提供了一组基于 system v ipc 机制的 api。在这组 api 中处理共享内存。共享内存机制为一个进程可以拥有的段数量以及整个系统的段数量定义了界限。遗憾的是，这个界限限制了一个应用程序能使用的共享内存段的数量。
例如，如果一个 os/2 应用程序创建了 500 个共享内存区域，您就无法使用到 system v 共享内存 api 的直接映射。尽管您可以重新编译内核并设置新的层次，但是必须考虑您的顾客们是否能接受这种改变。
您可以分配一个巨大的共享内存段，然后在这段内分配小一些的块。然而，没有边界检查。没有边界检查，应用程序会损坏已分配给其它进程的段。
实现一个与 os/2 （它进行一些边界检查）类似的行为的另一个方法是使用文件映射。文件映射将一个文件映射到一个进程的内存空间内，以便允许把文件像内存一样来访问。没必要整个文件映射到内存，但可以把文件的一部分映射到一个内存区域。
共享内存机制的另一个差别是：当一个段被加载到一个进程中时，linux 不保证会使用相同的内存地址。在 os/2 上，您可以分配一块内存并将这一块内存传送给另一个进程。内存位于每个进程中相同的地址处。在 linux 上情况并不一定如此。另外，为了访问另一个进程已创建的一个共享内存段，您需要知道这个段的标识。标识是一个独一无二的数字，可以通过使用一个名称（如果该名称作为一个文件存在）来计算这个数字。os/2 提供几个系统调用，使得进程能够给出且获得到基于名字或内存地址的共享内存段的访问。
队列
os/2 队列是一个允许进程把内存指针传给另一个进程的机制。传送进程必须通过 dosgivesharedmemory 给接受进程提供到内存段的访问，然后把内存在段中的位置传送给接收进程。像机制名暗示的一样，队列可以在等待另一个进程读取它们的同时保存大量的这些内存位置。linux 没有这个概念。
在可能的解决方案中，其中之一就是使用 system v 共享内存段。system v 共享内存段的问题是限制了被允许的段的数量。
另一个方法是使用文件映射并使用控制结构，该结构设置元素（内存位置）的顺序和对文件的访问权限。
信号量（semaphore）
os/2 提供三种主要类型的信号量：事件、互斥和多等待。linux 提供一个基于 system v ipc 的信号量机制并且支持信号量作为 pthread 库的一部分。os/2 信号量是一个单独的实体，给您提供一个定义良好的行为。然而，可以将 system v 信号量定义成几组，这是可配置的。在不重新编译内核的情况下，每个组最多可以有 250 个信号量（2.4 内核）。这种系统在系统内只能有一定数量的信号量组（可以通过重编译内核来更改这个数量）。
system v 信号量基本上是计数变量，您可以增加或减少这些变量，并且这为您模仿事件信号量和互斥信号量的行为提供了足够的功能。唯一的问题是执行定时等待。在 linux 上，您只能尝试／等待或等待。不允许超时。为了模仿超时，您需要构建某种定时机制，该机制能发送一个信号来中断正在等待一个事件的线程。
多等待信号量是一个已定义信号量的集合，这些信号量可以作为一组等待。system v 机制利用组，并且能等待许多与同一个组相关的操作。然而，只有应用程序仔细地规划了它对信号量（多等待中的所有信号量都来自于同一个信号量组）的使用，您才能得到期望的结果。我们实现了一个机制，它使线程能够等候这组内的每个信号量来模拟这一行为。
pthread 库提供了能合理模仿 os/2 行为的信号量和互斥（以及条件变量）。然而，还存在缺陷。请注意，pthread 信号量和互斥是不可共享的。换言之，仅在那个进程中保证它们。如果您的应用程序仅使用私有信号量，或者如果没有其它进程需要访问它的信号量，那么使用 pthread 互斥和信号量可能是最好的计划。但是，如果您的应用程序共享这些 ipc 机制，那么您需要用 system v 机制、共享内存和线程来实现这些机制。
信号
在 os/2 上，为了指明某些错误情况，要抛出异常。在 linux 上，这些被称为信号。与异常一样，除了 sigkill 和 sigstop 之外，信号都可以被捕获。在 os/2 上，您可以定义一列在接收到异常时需要执行的函数。应用程序可以在 os/2 上定义不止一个异常处理程序。在 linux 上，因为函数被覆盖了，所以您只能定义一个异常处理程序。
管道
在 os/2 上，管道是双向的，而 linux 上的管道是单向的。为了模仿 os/2 管道的行为，您需要创建两个管道，通过一个文件句柄来索引。
共享对象
linux 共享对象和 dll 非常相似，但是需要注意几个陷阱。应用程序可以在一个共享对象中重写函数。如果一个共享对象有 print_hello 函数并且应用程序有一个叫作 print_hello 的函数，那么无论何时应用程序调用 print_hello，都使用应用程序的版本。您在共享对象中调用一个函数之前（例如，so_print 调用 print_hello），这可能听上去不像什么问题。这种情况中使用的 print_hello 是应用程序中定义的那个。
感觉上的标准函数
您在作关于标准 c 函数方面的假设时应该谨慎一些。例如，kbhit 和 strupr 不是标准函数。尽管它们可能是一个编译器的 c 标准库的一部分，但是假定这些函数和其它函数存在于所有平台上是不安全的。
结束语
前面所述的差别无论如何不包含一个确定的列表。这样一个列表中包含的信息足够写一本书了。然而，当您将一个应用程序从 os/2 移植到 linux 上时，这些差别应该使您可以提前找到需要解决问题的地方。
landp for linux 小组设计了一个映射层来帮助我们从 os/2 向 linux 移植。映射层是一个共享对象，用于从 os/2 移植各个 landp 服务器。可能映射层将为其它项目提供一个起点，也许不会提供。
关于作者
kevin bowkett 是一名在 landp 开发组中工作的 ibm 软件工程师，在 linux、windows 和 os/2 操作系统方面有很好的基础。在过去的一年中，kevin 带领 landp 小组将 landp for linux 投入了市场。kevin 还是一名获 ibm 认证的 db2 应用开发解决方案专家。如果您正在从事从 os/2 到 linux 的移植并且有什么问题的话，尽可以通过 kevin_bowkett@uk.ibm.com 和他联系。
