CN102364435A

CN102364435A - WinCE API的实现方法

Info

Publication number: CN102364435A
Application number: CN2011101739750A
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: 2012-02-29
Anticipated expiration: 2031-06-24
Also published as: CN102364435B

Abstract

本发明公开了WinCE API的实现方法，该方法中，对于在Win32 API中有对应物的WinCE函数，对WinCE函数进行封装以使WinCE函数映射或调用相应的Win32 API中的函数；对于在Win32 API中没有对应物的WinCE函数直接进行实现，并将其添加到对应的函数库中以供WinCE应用程序调用；对于仅存在于Win32 API而不存在于WinCE API中的函数进行删除。本发明通过利用、修改、添加Win32API来实现WinCE API，从而使Windows Mobile上的应用程序能够直接运行于OMS平台之上。

Description

WinCE API的实现方法

技术领域

本发明涉及通信领域，尤其涉及WinCE API的实现方法。

背景技术

操作系统是当代计算机的核心部分之一，作为计算机资源的管理者操作系统掌管着所有的硬件资源，并对运行其上的应用软件提供相应的服务。而操作系统为应用程序提供服务的接口被称作应用编程接口(API，Application Program Interface)。API提供了基本的编程环境，应用程序的开发者通过调用这些API函数来调用操作系统提供的服务，从而对计算机系统的硬件资源进行访问和控制。同样，硬件操作的结果也是通过这些函数返回给相应的应用程序的。操作系统的这种机制有着诸多优点，它使得应用程序的开发者无需理会复杂的硬件工作原理，同时由于用户无法直接控制硬件从而避免了用户程序有意或无意的不安全操作。简而言之，对于应用程序的开发者而言，API简化了程序开发的复杂度同时保证了软件的安全性。然而，不同的操作系统提供了不同的API函数接口，这一特性使得同一应用程序很难不加修改地运行于不同的操作系统之上。这在一定程度上增加了应用程序开发者的劳动量。尤其是对那些开发需要运行于不同平台之上的应用程序的开发者而言。并且这种重复劳动的意义是十分有限的。

智能手机的发展使得手机设备同个人电脑一样具有独立的操作系统，可以由用户自行安装软件、游戏等由厂商或第三方服务商提供的程序。与典型的计算机系统一样，应用程序也是通过API函数并在操作系统的辅助下实现对硬件资源的控制的。从市场的角度来看，应用程序的数量与质量会在一定程度上影响到智能手机的用户数量。因此，如果能将经典手机平台上的应用程序直接运行于新平台上，对于新型手机平台的快速推出无疑是有着巨大的吸引力的。

开放管理平台(OMS)平台是基于ARM微处理器、Linux内核和安卓(Android)操作系统的手机平台。本发明的目的在于将流行的智能手机平台Windows Mobile上的应用程序直接运行于OMS手机平台。其基本的实现方法是将Linux上的开源软件Wine移植到OMS平台上，在Wine的支持下实现直接运行WinCE应用程序的目的。然而，Wine主要面向x86体系的微处理器，并且所实现的是Win32 API。这使得运行在手机移动设备之上使用WinCE API的手机应用程序无法直接运行于Wine上。

发明内容

针对现有技术中存在的上述问题，本发明提供了WinCE API的实现方法。

本发明提供了WinCE API的实现方法，对于在Win32 API中有对应物的WinCE函数，对WinCE函数进行封装以使WinCE函数映射或调用相应的Win32API中的函数；对于在Win32 API中没有对应物的WinCE函数直接进行实现，并将其添加到对应的函数库中以供WinCE应用程序调用；对于仅存在于Win32API而不存在于WinCE API中的函数进行删除。

在一个示例中，WinCE API通过Wine应用程序在安卓操作系统中运行。

在一个示例中，通过实例增量的方法得到WinCE API集合。

本发明通过利用、修改、添加Win32 API来实现WinCE API，从而使Windows Mobile上的应用程序能够直接运行于OMS平台之上。

附图说明

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

图1是Wine与Windows应用程序的关系示意图；

图2是WinCE API与Win32 API关系示意图。

具体实施方式

Wine提供了一个用来运行Windows程序的平台，它是Windows应用软件与Linux内核之间的适配层。从实际角度上讲Wine是win32库在Linux上的实现，它体现为一个Wine服务进程(Wine server)和一组动态链接库(等价于Windows的众多DLL)。Wine与Windows应用程序的关系如图1所示。其中X-Server是一个体积较大、功能比较齐全的GUI服务进程，对于手机一类的平台而言则显得有些过分浪费资源，因此在OMS系统上采用的是一个缩减版本TinyX。

服务进程Wine server用于为Windows应用提供某些应该由Windows内核提供的功能、服务和管理(例如进程管理等)，并把这些功能和服务转嫁到Linux内核中去。这样，在Linux内核的基础上，Wine server为Windows应用程序提供了一个虚拟的Windows内核。因此，Wine server进程的存在独立于Windows应用，Windows的应用在启动时要建立与Wine server的连接。

用户应用程序在服务进程的管理下运行于Wine上。Wine所支持的应用有两种，一种是“原装”的Windows应用，另一种是要支持的WinCE应用。从API的角度上看，前者直接使用Win32 API而后者需要使用WinCE API。

因此对于一个WinCE应用程序而言，其在OMS平台上的工作方式如下：

1)、通过Wine的服务进程(Wine server)获得基本的系统内核服务；

2)、需要使用系统资源时调用相应的WinCE API函数；

3)、通过修改或重新实现的WinCE API来获得操作系统的支持，从而访问、控制相应的硬件资源

4)、通过修改或重新实现的WinCE API得到硬件处理结果。

由上述执行步骤不难看出，对WinCE API的修改和实现是WinCE应用程序能否直接运行于OMS平台上的关键。

Wine所提供的DLL结合实现了Windows的Win32 API，它是面向桌面应用程序的。而手机应用程序所要求的是WinCE API，因此这里有两个问题：

首先，实现这两个API的DLL集合不一样。Windows应用程序要求装载并动态链接的是诸如Advapi32.dll、Comctl32.dll、Shell32.dll、Kernel32.dll、User32.dll、Ntdll.dll等DLL；而WinCE应用程序要求装载并进行动态链接的则是诸如Coredll.dll、Aygshell.dll等DLL。这种对于 DLL的不同需求会导致程序的链接错误。比如WinCE上的应用程序根本不知道有Advapi32.dll、Kernel32.dll等DLL的存在；同样的，由于Wine实现的是Win32DLL，因此它也无法为WinCE应用程序提供正确的库文件，如Coredll.dll、Aygshell.dll等。这种差异存在于DLL的命名与实现中，即或者DLL的实现有所差异或者仅仅是命名上的习惯不同。尤其对于后一种情况，即使Coredll.dll中有个函数与Advapi32.dll中的某个函数的实现完全相同，WinCE应用序也不会要求装载Advapi32.dll并动态连接这个函数的。

其次是这两个API中的库函数集合不一样。根据库函数集合的不同，从API函数功能的角度上大致可分为如下三种情况，如附图2所示：

WinCE API中的有些库函数在Win32 API中有基本等价的对应函数；

WinCE API中的有些库函数在Win32 API中没有对应的函数；

Win32 API中有许多函数在WinCE API中不存在。

针对如上三种情况，本发明采取下列处理方式：

首先，对于有等价库函数的这类情况，仅需对WinCE API中的函数做简要修改，使其映射或调用到相应的Win32 API即可；

其次，对于仅存在于WinCE API中而不存在于Win32 API中的函数，将其单独实现，并将其添加到对应的函数库中，以供WinCE应用程序调用；所述对应的函数库是WinCE独有的，为了支持WinCE程序在Win32中运行，将这个函数单独实现后，添加到Win32中用于支持WinCE这个独有API函数运行的库中，这个库存在于Win32系统中，但独立于Win32 API。

最后，对于仅存在于Win32 API中而在WinCE API中没有出现的库函数，为了减小代码的体积，对其进行必要的删除。

除上述情况之外，在具体的API实现上，采取实例增量的方法。由于DLL中存在大量的库函数，但在具体应用上这些库函数并不是以相同的频率被调用到。因此，一次性实现所有的库函数是一种低效的方式。针对此种情况，采取实例增量的策略，即把对库函数的实现与具体的应用挂钩。例如具体应用pword.exe，只需将pword.exe中用到的DLL和库函数进行整理和实现，来保证其正确运行。当更换另一个应用时，例如“五子棋”，可对“五子棋” 所调用的DLL和库函数进行实现。由于先前实现了pword.exe的库函数，因此对于“五子棋”应用来讲，只需修改或实现其与pword.exe程序不同的那部分DLL与库函数。在这种增量实现的方法下，通过对足够多应用程序的库函数进行实现后，最终可得到一个简洁高效的WinCE API集合。由于各个应用程序会共享一些常用的API，因此这种通过具体应用增量实现的方法可预期为一种收敛的过程。

根据Wine的工作方式，WinCE应用程序在执行时会动态连接相应的DLL，并使用其提供的库函数。对于仅存在于Win32中的DLL予以适当的裁剪。而对于仅存在于WinCE中的DLL，则需要进行实现。实现的方法为通过与实例应用程序挂钩来进行增量式实现。下面是本专利方法中对仅存在于WinCE中的Coredll.dll的实现，在这个例子中应用了“五子棋”和pword应用程序。

Coredll.dll的实现

就目前针对pword和“五子棋”的移植来看，最重要的DLL是Coredll.dll。这个动态连接库在WinCE中是底层的DLL，它不依赖于别的DLL。换言之，Coredll.dll所提供的所有的库函数都是在其内部实现的。

然而，实际上由Coredll.dll所提供的库函数大多能够在Wine所支持的那些DLL中找到对应的函数。这些对应的函数有些是能够直接对应的，有些则需要做一定的转换。因此，对于本例来讲，完全没有必要再来实现一个独立的DLL及其中对应的函数。而是可以将Coredll.dll封装成一个更高层的空壳DLL。它的作用是对Win32中的某些函数进行再次封装，将其置于Coredll.dll内。对WinCE应用程序而言，仍然看到的是Coredll.dll，而在其内部实现而言，则是通过相应的Win32函数完成其操作的。因此，Coredll.dll的作用仅仅是提供WinCE应用程序的动态链接目标，提供WinCEAPI所规定的某些库函数的入口，而其具体实现功能则由别的更底层的DLL来实现，这些更底层的DLL是Wine所提供的。

此外，由于Wine DLL与WinCE DLL的差异，某些函数在Wine DLL中并不存在，对于这部分Wine DLL没有对应物的库函数，则需要自己动手加以实现，并将其添加在Coredll.dll中。当然，也可以放置在其它DLL中。

为此，要为Coredll.dll提供一个Spec文件(Coredll.spec)，来说明各个函数的去向。下面是Coredll.spec文件的一个片段：

stdcall NOP_0252()

stdcall NOP_0253()

stdcall ClientToScreen(long ptr)user32.ClientToScreen

stdcall ScreenToClient(long ptr)user32.ScreenToClient

stdcall SetWindowTextW(long wstr)user32.SetWindowTextW

stdcall GetWindowTextW(long ptr long)user32.GetWindowTextW

在上述spec文件片段中，NOP 0252()在Coredll.spec文件的列表中排在第252位，所以其序号为252。其实这个函数的函数名应该是WindowFromPoint()，但是由于动态链接库在实际上是按照序号连接的，所以函数名不同并没有问题。NOP 0252()表示这个函数尚未实现。在Coredll.dll中，这个函数的代码为：

这样，通过查看LOG文件，就可以知道这个函数是否受到了调用，如果受到调用，那么该函数就要加以实现。

再来看ClientToScreen()函数，这个函数排在滴spec文件的254位，因此序号标识为254。在该spec文件中标识了ClientToScreen()函数的去向为user32.ClientToScreen()，其等同于应用user32.ClientToScreen()来实现ClientToScreen()的功能。而user32.ClientToScreen()函数是Wine所支持的Win32API中的函数。换句话说，调用ClientToScreen()的方法被转嫁到User32.dll中的user32.ClientToScreen()函数。从而实现了通过Wine DLL对WinCE API的支持。

这样，对于在能够于Wine的DLL中找得到对应物的库函数而言，Coredll.dll只是起着中转站的作用，将WinCE的调用转接到Wine DLL中去。即使是在Wine的DLL中找不到对应物的库函数，也可以将其中转到某个Wine的DLL，并在那里增添新的函数实现。

CommandBar的实现

CommandBar是WinCE所特有的一种公共控件，在Windows中没有对应物。在Windows中(也就是在Wine中)，公共控件是由Commctrl.dll实现的，但是在Wine的Commctrl.dll中没有实现CommandBar。针对这种情况，需要添加新的函数实现，并将其添加到对应的DLL中。在此例中，需要将将新创建的CommandBar添加到Commctrl.dll库中。

在WinCE中，与CommandBar有关的函数有：

CommandBar_Create()

CommandBar_Show()

CommandBar_AddBitmap()

CommandBar_InsertComboBox()

CommandBar_InsertMenubar()

CommandBar_GetMenu()

CommandBar_AddAdornment s()

CommandBar_Height()

对这些新增函数进行实现，并将其添加到Commctrl.dll库中。具体函数代码的实现位于dlls/commctrl/commctrl.c中，因此在此处不再赘述。

当移植其它WinCE应用程序时，需要新的API函数时，即可采取上述的两种方法：

对Wine中Win32 API有对应实现的函数进行封装、转嫁，具体实施步骤如Coredll.dll例子中所示，通过spec文件来说明函数去向；

对于Wine中Win32API没有的函数，需要手工进行实现，具体实施步骤如CommandBar例子中所示，实现新的函数，并添加到对应的DLL库中。

此外，对于仅存在于Win32 API中，而在WinCE API中没有用到的那部分函数，为了代码的简短，对其予以裁剪。

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

Claims

1.WinCE API的实现方法，其特征在于，对于在Win32 API中有对应物的WinCE函数，对WinCE函数进行封装以使WinCE函数映射或调用相应的Win32 API中的函数；对于在Win32 API中没有对应物的WinCE函数直接进行实现，并将其添加到对应的函数库中以供WinCE应用程序调用；对于仅存在于Win32 API而不存在于WinCE API中的函数进行删除。

2.如权利要求1所述的实现方法，其特征在于，WinCE API通过Wine应用程序在安卓操作系统中运行。

3.如权利要求1所述的实现方法，其特征在于，通过实例增量的方法得到WinCE API集合。