CN102364433B

CN102364433B - 在ARM处理器上实现Wine构建工具移植的方法

Info

Publication number: CN102364433B
Application number: CN201110173679.0A
Authority: CN
Inventors: 毛德操; 王承志; 徐鼎鼎; 陈天洲; 马建良
Original assignee: INSIGMA TECHNOLOGY Co Ltd
Current assignee: INSIGMA TECHNOLOGY Co Ltd
Priority date: 2011-06-24
Filing date: 2011-06-24
Publication date: 2014-01-01
Anticipated expiration: 2031-06-24
Also published as: CN102364433A

Abstract

本发明公开了在ARM处理器上实现Wine构建工具移植的方法，包括：步骤1，修改Wine的配置工具，以使用arm-linux的交叉编译器和arm-linux的库文件来替换X86平台下的gcc编译器和库；步骤2，修改Wine的构建工具，以将Windows目标应用程序生成对应于ARM处理器的PE格式映像；步骤3，修改Wine中的其他与CPU相关的代码，使得所有Wine的代码适用于ARM处理器；步骤4，将修改后的Wine源代码安装到ARM处理器上。本发明实现了Wine的移植，使Wine能够在OMS智能手机上运行。

Description

在ARM处理器上实现Wine构建工具移植的方法

技术领域

本发明涉及软件移植领域，尤其涉及在ARM处理器上实现Wine构建工具移植的方法。

背景技术

以手机为代表的智能化移动终端设备既是计算机技术的一个重要发展方向，又是一个竞争十分激烈的市场。自从谷歌公司和开放手机联盟推出安卓(Android)操作系统和基于Android的手机以来，很快就在世界手机市场上占有了不小的份额，各种Android手机层出不穷。中国移动开发并推出的OPhone(OMS智能手机)也是基于Android的手机。

所谓Android操作系统，实际上是对Linux操作系统的一种改编和扩充，它的内核基本上就是Linux的内核，但是在用户空间却专门针对手机和移动终端设备的特点作了大幅的改进和增强，这些改动大都与编程模式和图形界面，即图形化用户界面(GUI)有关。

另一种常用于手机的操作系统是微软的WinCE和WM(即WindowsMobile)，这是在微软的Windows操作系统上发展起来的。基于WinCE/WM的手机也在市场上占不小的份额，并且开发出了数量不小的WinCE/WM应用软件。如果能把这些应用软件拿到OMS智能手机上运行，对于提高OMS智能手机的市场占有率显然是有利的。

为了能把WinCE/WM应用软件移植到OMS智能手机上运行，需要把开源软件Wine移植到OMS手机上，把本应由Windows提供的支撑嫁接到Linux上，并对其加以扩充、使其支持WinCE/WM，可以让WinCE/WM应用软件直接在OMS手机上运行(实际上是在OMS手机的Linux内核上运行)。这样，原来熟悉WinCE/WM软件开发的人就可以按原来的模式、在原来的开发环境中、使用原来的开发工具、像开发WinCE/WM软件一样地开发OMS软件，而且开发出来的软件既是WinCE/WM软件又可以在OMS手机上运行，这对于开发者也是很有利的。

可是，OMS手机是基于ARM处理器的手机平台。然而，目前的Wine主要是面向x86系统结构微处理器的，虽然也支持PowerPC、Sparc等别的微处理器，但是却不支持ARM。因此，想要在OMS智能手机上运行Wine，需要对Wine软件移植到ARM处理器上。

发明内容

针对现有技术中存在的上述问题，本发明提供了在ARM处理器上实现Wine构建工具移植的方法，实现Wine的移植。

本发明提供了在ARM处理器上实现Wine构建工具移植的方法，包括：

步骤1，修改Wine的配置工具，以使用arm-linux的交叉编译器和arm-linux的库文件来替换X86平台下的gcc编译器和库；

步骤2，修改Wine的构建工具，以将Windows目标应用程序生成对应于ARM处理器的PE格式映像；

步骤3，修改Wine中的其他与CPU相关的代码，使得所有Wine的代码适用于ARM处理器；

步骤4，将修改后的Wine源代码安装到ARM处理器上。

在一个示例中，步骤1中，所述配置工具包括Configure文件、Configure.ac文件、Make.rules文件和Makefile文件。

在一个示例中，所述构建工具包括Winegcc工具和Winebuild工具。

在一个示例中，Winegcc工具的函数get_translator()能够识别arm-linux的交叉编译器。

在一个示例中，Winebuild工具用于生成PE可执行映像的头部及其各个段，以及为每个PE格式的可执行映像生成用于ARM处理器上装载的PE头部和除代码段和数据段之外的各个段的映像。

在一个示例中，启动Winebuild的命令行中具有选择项“--save-temps”，以保存用于动态连接库的汇编代码。

在一个示例中，步骤3中，将wine_call_on_stack()和wine_switch_to_stack()用ARM汇编语句实现；增加文件signal_arm.c，用于实现对ARM的CONTEXT数据结构操作；对函数copy_context()扩充针对ARM CONTEXT的代码；增加文件context_arm.c，用于针对ARM处理器实现文件context_i386.c的功能；在kernel32/process.c中增加识别参数IMAGE_FILE_MACHINE_ARM和IMAGE_FILE_MACHINE_THUMB的功能；修改函数ILGetSize()和ILGetNext()，以在ARM处理器访问内存时对齐长字或字的边界。

本发明实现了Wine的移植，使Wine能够在OMS智能手机上运行。

附图说明

下面结合附图来对本发明作进一步详细说明，其中：

图1是Wine移植到ARM处理器的流程。

具体实施方式

本发明提供了在ARM处理器上实现Wine构建工具移植的方法。在用本发明的方法移植后，Wine工具能够正确移植到ARM处理器上，因此可以使基于ARM处理器的OMS智能操作系统运行Wine工具，进一步可以在此基础上把WinCE/WM应用软件移植到OMS智能操作系统中。

为了把Wine工具正确移植到ARM处理器上，本发明的方案是。

在特定处理器上构建Wine时，先需要进行配置工作。因此，本发明首先针对ARM处理器对Wine开源软件的配置工具进行扩充和移植，才能编译/汇编/连接出运行于ARM的二进制代码。

其次，在ARM处理器上构建Wine时，除ARM工具链以外，Wine的构建(编译、汇编、连接)还需要Winegcc，Winebuild，Widl，Wrc和Wmc这5个Wine构建工具的参与，本方案需要对其中的Winegcc和Winebuild针对ARM处理器进行修改/移植。

本发明中，将Wine工具正确移植到ARM处理器上的流程如图1所示，主要包括六个步骤，首先要下载Wine开源软件源码并解压缩；然后运行./configure，通过此命令对Wine进行配置；第三步需要对Wine的配置工具进行修改，以增加对ARM处理器的支持；第四步需要对Wine的构建工具进行修改，以增加对ARM处理器的支持；第五步，修改移植Wine中的其他与CPU相关的代码，以增加对ARM处理器的支持；最后一步把修改好的源码移植到ARM处理器上编译安装。当然在安装过程中可能会出现一些错误，需要根据实际情况进行调试。

下面详细对每个步骤进行说明。

第一步：下载Wine开源软件源码并解压缩。可以从开源Wine工程网站http://www.winehq.org/下载Wine源码到X86平台下的Linux操作系统上，本实施例中Wine源码版本为Wine-1.3.13，平台为Intel Xeon CPUE53101.60GHz，Linux操作系统为Unbuntu 10.4版本。然后解压到本地文件夹，解压命令为tar-jxvfwine-1.3.13.tar.bz2。

第二步：运行./configure，通过此命令对Wine进行配置，它会针对各种不同的CPU生成相应的编译器选项，并决定某些源文件的取舍。目前的Wine支持x86、PowerPC、Sparc、Apple等处理器，通过系统配置，就可以使编译/汇编/连接工具产生出针对具体处理器的二进制可执行代码。然而，目前的Wine并不支持ARM。所以，要将Wine移植到ARM处理器上，首先就要对其配置工具加以扩充和移植。这样，结合对有关代码、特别是汇编代码的移植，才能编译/汇编/连接出运行于ARM的二进制代码。

第三步：对Wine的配置工具进行修改，本发明的方法具体需要修改的地方为Configure文件、Configure.ac文件、Make.rules文件和Makefile文件，其中Configure文件和Configure.ac文件本来就存在，而Make.rules文件和Makefile文件是./configure命令运行的产物。比如在Makefile文件需要修改的地方为：

CC＝arm-linux-gcc

CFLAGS＝-g-O0-D_arm_

AR＝arm-linux-ar

RANLIB＝arm-linux-ranlib

STRIP＝arm-linux-strip

TOOLSDIR＝/tinyx/wine-tools/

AS＝arm-linux-as

LD＝arm-linux-ld

LINTFLAGS＝-D_arm_

上述修改通过使用arm-linux的交叉编译器和arm-linux的库文件来替换原来的X86平台下的gcc编译器和库，从而提供了ARM处理器的支持。

第四步：需要对Wine的构建工具进行修改。由于Wine通过装载和启动PE格式映像来间接运行Windows目标应用程序，因此此处对构建工具的修改，目标是把一个Windows目标应用程序生成对应于ARM处理器的PE格式映像。在ARM处理器上构建Wine时，除ARM工具链以外，Wine的构建(编译、汇编、连接)还需要一些Wine(构建)工具的参与，这些工具有：

Winegcc 按MinGW的方式使用gcc

Winebuild 生成PE可执行映像的头部及其各个段，为每个PE格式的可执行映像(EXE或DLL)生成用于ARM处理器上装载的PE头部和各个段(除代码段、数据段外)的映像

Widl COM插件接口的IDL Compiler

Wrc Win32 Resource Compiler

Wmc Wine Message Compiler

其中，我们需要对Winegcc和Winebuild工具针对ARM处理器进行修改/移植。

对Winegcc的修改主要是使原来调用标准编译器的地方改成调用交叉编译器。需要修改的有get_translator()和build()两个函数。这两个函数都需要对编译器进行识别，以决定使用哪个版本的编译器，因此在这里需要分别增加对arm-linux交叉编译器的识别，允许使用ARM平台上的交叉编译器，从而增加了对ARM平台的支持。

Winebuild是个关键性的工具。它的作用是为每个PE格式的可执行映像(EXE或DLL)生成PE头部和各个段(除代码段、数据段外)的映像，包括用于动态连接的函数跳转表等等。这部分映像中包含了一些汇编程序，需要加以移植。Winebuild的修改是难度最大的，大部分需要移植的汇编程序都在这里。对Winebuild工具的修改具体包括static voidoutput_import_thunk(const char*name，const char*table，int pos)；static voidoutput_delayed_import_thunks(const DLLSPEC*spec)；static voidoutput_asm_constructor(const char*constructor)和voidBuildSpec32File(DLLSPEC*spec)函数。由于其作用类似，我们仅以staticvoid output_import_thunk(const char*name，const char*table，int pos)函数为例进行详细分析。

Wine所支持的处理器类型原来有CPU_x86、CPU_x8664、CPU_SPARC、CPU_ALPHA、和CPU_POWERPC，现在需要增加一种新的类型CPU_ARM。这是在build.h中定义的：

然后，要把main.c中的全局变量target_cpu设置成CPU_ARM。

#elif defined(_powerpc_)

enum target_cpu target_cpu＝CPU_POWERPC；

#elif defined(_used_by_arm_)||defined(_arm_)/*Added for ARM

processors，by Insigma*/

enum target_cpu target_cpu＝CPU_ARM；

这里的条件编译控制_used_by_arm_或_arm_是由配置工具Configure自动产生的。

需要移植的汇编代码主要在源文件import.c和spec32.c中。其中的一个函数是output_import_thunk()：

这个函数生成出一些用于DLL动态连接的汇编代码。对于ARM处理器，代码中先以注释的形式列出原始的x86指令，然后是与这些x86指令等价的ARM指令。Winebuild在运行时将这些代码写入一个临时文件，文件名随机生成，后缀为“.S”。经过汇编、连接之后，这些代码就进入了目标可执行映像(例如user32.dll)，然后，这个临时文件就被删除了。所以，对于程序员来说，这些汇编代码是不可见的。不过也可以在启动winebuild的命令行中加用一个选择项“--save-temps”，这样winebuild就不会删除所生成的临时文件。

下面几个函数的作用与此相似，只是所生成的代码作用不同，包括

static void output_delayed_import_thunks(const DLLSPEC*spec)；

static void output_asm_constructor(const char*constructor)，它用于生成“.init”段的代码；

void BuildSpec32File(DLLSPEC*spec)，这个函数与PE头部和导出函数跳转表有关.

上面这些函数实现了目标可执行映像的函数导出和导入，也提供了映像的PE头部。对于PE格式的可执行映像，这些代码是至关重要的。

第五步，修改移植Wine中的其他与CPU相关的代码。首先，Wine代码中的有些片段是以汇编指令写成的，由于所有汇编指令都与处理器相关，因此要把这些片段改写成ARM的汇编指令，除了第三步中涉及的几个片段外，还有wine_call_on_stack()和wine_switch_to_stack()两个函数也是用汇编指令写成的，这两个函数在wine/libs/wine/port.c中，我们需要把函数中对栈的相关操作用ARM汇编语句实现。

不同的CPU具有不同的寄存器集合，所以它们的CONTEXT数据结构也不同，Wine原来不支持ARM，但是winnt.h中却提供了ARM的CONTEXT数据结构定义。虽然winnt.h提供了ARM的CONTEXT数据结构定义，Wine的代码中却并不提供有关的代码，需要加以补充，具体包括：

1.在目录dlls/ntdll下提供一个名为signal_arm.c的文件，作为signal_i386.c的替代，实现里面的一些函数，例如save_context()、restore_context()等等，其作用是实现对ARM的CONTEXT数据结构操作。

2.在dlls/ntdll/thread.c中有个函数copy_context()，需要扩充针对ARMCONTEXT的代码。

3.在WineServer的代码中，需要在目录server下面提供一个名为context_arm.c的文件，作为context_i386.c的替代，实现里面的一些函数，例如copy_context()、get_context_ip()等等(注意WineServer和Ntdll中各有一个copy_context()，并非同一个函数)。context_arm.c文件的作用与context_i386.c类似，但是它是针对ARM处理器的一个实现。

但是这还不是事情的全部，还有些代码并非汇编指令，但是也与具体的CPU有关。

首先，可执行映像的PE头部有个字段，说明这是针对哪一种CPU的可执行映像。对于x86处理器，这个字段的值是IMAGE_FILE_MACHINE_I386、即0x014c。而对于ARM处理器则有两种可能，即IMAGE_FILE_MACHINE_ARM和IMAGE_FILE_MACHINE_THUMB，这两个常数的值分别是0x01c0和0x01c2。原来的Wine不认识这两个“签名”，所以不能装载/运行ARM的可执行映像。现在要用到这两个常数，需要在kernel32/process.c中增加对这两个“签名”的识别功能。

还有个特殊的问题，是与文件操作和COM有关的。在wine/include/shtypes.idl中定义了一种数据结构ITEMIDLIST：

这里数组abID[]的大小可变，其大小记录在字段cb中，这个数组用来存放文件名。当文件名的长度为奇数时，数据结构SHITEMID、从而ITEMIDLIST的大小也是奇数，因而不与长字或字的边界对齐。在实际使用中，好几个SHITEMID数据结构会首尾相连叠在一起，形成一个列表。这样，如果第一个SHITEMID数据结构的大小是奇数，第二个SHITEMID数据结构的起点就不与长字或字的边界对齐了。对于x86处理器，这是允许的，不会造成问题。但是，对于ARM，这就不允许了，ARM只允许与长字或字边界对齐的内存访问(除非访问的对象是字节)，否则就不保证操作的正确性。由于这个原因，当CPU从第二个SHITEMID数据结构中读取其cb字段的数值时，所得到的可能是个错误的数值，从而误认为第二个SHITEMID数据结构中的abID[]很大，因而造成问题。

为了解决这个问题，需要对有关的函数ILGetSize()、ILGetNext()作修改，需要修改实现的功能为：在只有一个独立的SHITEMID数据结构时，这个函数返回的数据结构长度不是cb字段本身的数值，而是经过_insigma_align()调整的数值。_insigma_align()函数定义如下：

就是说，如果abID[]的大小为奇数的话，就在此数值上加1，使其与长字或字的边界对齐。这样，在一个列表中，每一个SHITEMID数据结构的起点就都是与长字或字的边界对齐的。这就解决了ARM处理器访问内存时边界必须对齐的问题。

从原理上说，这个问题的解决还有另一种方法，就是把SHITEMID数据结构中字段cb的类型改成BYTE(而不是WORD)。但是原来之所以定义为WORD一定有其考虑(例如文件名的长度可能超过255个字节)，所以不宜作这样的修改。

第六步把修改后的Wine源文件移植到ARM处理器上，实际上就是把源文件拷贝过去，本实施例中ARM处理器平台为基于ARM处理器的OMS操作系统。

拷贝完成后运行make install命令，此命令将自动在ARM处理器上进行编译安装，如果该命令能正确运行，则表示Wine已经成功移植到ARM处理器上；否则，需要按照命令出错情况进行debug。实际上，本实施例在在调试中发现了GCC编译器3.4版本的1个BUG，就是计算2个标号地址的相对量出现错误，后改用GCC 4.0版本就正确。改用gcc 4.0后，winebuild在调用arm-linux-as时候需要增加-mfpu＝vfp选项。另外，在调试中发现一个DLL调用另外一个DLL中的函数时出现错误，原因是编译器优化的缘故，将命令行参数-O2改成-O0，不让优化就解决了问题。

以上所述仅为本发明的优选实施方式，但本发明保护范围并不局限于此。任何本领域的技术人员在本发明公开的技术范围内，均可对其进行适当的改变或变化，而这种改变或变化都应涵盖在本发明的保护范围之内。

Claims

1.在ARM处理器上实现Wine构建工具移植的方法，其特征在于，包括：

步骤2，修改Wine的构建工具，以将Windows目标应用程序生成对应于ARM处理器的PE格式映像，包括：

修改Winegcc工具中的get_translator()和build()两个函数，增加对arm-linux交叉编译器的识别；

修改Winebuild工具中的static void output_import_thunk(const char*name,const char*table,int pos)；static voidoutput_delayed_import_thunks(const DLLSPEC*spec)；static voidoutput_asm_constructor(const char*constructor)和voidBuildSpec32File(DLLSPEC*spec)函数；

步骤3，修改Wine中的其他与CPU相关的代码，使得所有Wine的代码适用于ARM处理器，包括：

将wine_call_on_stack()和wine_switch_to_stack()用ARM汇编语句实现；增加文件signal_arm.c，用于实现对ARM的CONTEXT数据结构操作；对函数copy_context()扩充针对ARM CONTEXT的代码；增加文件context_arm.c，用于针对ARM处理器实现文件context_i386.c的功能；在kernel32/process.c中增加识别参数IMAGE_FILE_MACHINE_ARM和IMAGE_FILE_MACHINE_THUMB的功能；修改函数ILGetSize()和ILGetNext()，以在ARM处理器访问内存时对齐长字或字的边界；

步骤4，将修改后的Wine源代码安装到ARM处理器上。

2.如权利要求1所述的方法，其特征在于，步骤1中，所述配置工具包括Configure文件、Configure.ac文件、Make.rules文件和Makefile文件。

3.如权利要求2所述的方法，其特征在于，启动Winebuild的命令行中具有选择项“--save-temps”，以保存用于动态连接库的汇编代码。