跨平台应用软件移植技术：改进的接口映射算法

由于只是提供映射函数的函数型构，程序员仍然需要负担大量的代码工作量，而且系统调用函数在代码中可能多次被调用，每次都重复修改工作，显然是不合适的，因此在之前工作的基础上，增加了一个函数模板库，将每个系统调用在另一个平台上的对应实现制作成模板，以函数名命名统一保存至模板库中。因此，改进后的映射系统（简称为OntoAPITransA）的基本框架较之前的框架增加了一个与文件夹交互的部分，如图23 所示。

图23　改进的基于本体的系统调用映射系统的基本框架图

工作流程也随之发生了变化，对于代码中定位到的系统调用，不再先从接口映射模型中获取映射类型和映射的系统调用序列，而是先判断该系统调用是否是首次在代码中出现（第2 行），若是，根据系统调用函数的名称，在模块库中查找它的对应实现模板，然后将模板中的代码读出，添加至源代码的末尾（第3 行）。若在模板中没有找到与之对应的实现模板，则采用之前的算法，从接口映射模型中获取映射类型和映射的系统调用序列，然后再从接口模型中逐个获取系统调用的详细信息，恢复函数型构，添加至被定位的系统调用所在行（第5 行）。

这么做的好处是，明显提高了代码移植的效率，理想的情况下，程序员不需要做代码修改，只需要检查编辑器中高亮显示处的代码即可。图24 中给出的是改进后的系统调用映射算法运行效果图，从图中可以看出，从函数CreateDirectory开始，源代码中出现的所有Windows API的对应实现都添加到了源代码的末尾。

(www.xing528.com)

图24　改进的系统调用映射算法运行效果图

编辑器中映射后的代码可以在几乎不修改的情况下运行于Linux平台上，图25 给出的是映射后的代码在Linux上运行的输出显示。

图25　测试代码运行截图

从图中可以看出，代码不仅通过了编译，并正确执行了对当前工作路径的获取和修改操作，对文件的创建、打开、读写、复制、移动、属性设置、删除等操作的执行也都与预期相符。