您的位置:控制工程论坛网论坛 » 嵌入式系统 » win95程序向wince移植【经典转载】

jane_liang

jane_liang   |   当前状态:离线

总积分:30  2024年可用积分:0

注册时间: 2007-04-20

最后登录时间: 2007-05-03

空间 发短消息加为好友

win95程序向wince移植【经典转载】

jane_liang  发表于 2007/4/26 20:42:55      2494 查看 1 回复  [上一主题]  [下一主题]

手机阅读

Microsoft  Corporation
September  1997  
介绍

许多Microsoft  Windows  95应用程序可被移植到Microsoft  Windows  CE,其所需的劳动远小于重新开发这些程序的努力。将程序移植到Windows  CE所需要处理的主要问题包括:
· Microsoft  Win32  API  (Application  Programming  Interface,应用程序编程接口)  和Windows  CE应用APIs之间的不同
· Microsoft  MFC(Foundation  Class  Library,基本类库)标准和MFC  for  Windows  CE标准之间的不同
· 存储器的限制和存储器溢出的恢复
· 能量的限制
· 存在广泛不同的硬件特性和限制
· 测试和调试的不同  
Win32  API和Windows  CE  APIs间的不同

Windows  CE  API与Win32  API的不同体现在几个重要的领域:
· 更小。Windows  CE  API  只支持Win32  API的一个子集,而且其中部分函数的功能已精简-支持的窗口风格更少。例如,对颜色和字体的支持更加有限。
· 具有对Windows  CE的特定扩展功能。其中的一些功能-包括触摸屏(touch  screen)和通告(notification)-支持各种设备的硬件功能,而另一些-例如,命令条(command  bar)-已代替了Win32中的相应元素。
· 对异常处理的使用具有限制。虽然支持Win32的结构化异常处理,Windows  CE却并不支持C++异常处理。
当从PC平台移植已有的Win32应用程序到Windows  CE时,主要的问题通常是更少的API。应用程序需要满足Windows  CE  API以及目标系统功能限制。

标准MFC和用于Windows  CE的MFC的不同

Microsoft标准类库(Foundation  Class  Library)正逐渐成为高级Windows应用程序开发  的流行工具。MFC为图形用户界面、数据操作和系统接口设计提供了功能强大而全面的类集。

用于Windows  CE的MFC已设计得紧密遵循标准MFC的功能和特性,但是其在所提供的类和每个类的功能上还是具有很大的不同。除了这些与标准MFC存在的不同外,在用于Windows  CE的MFC中提供的某些特性是专用于Windows  CE平台的。例如,在Windows  CE中一个重要的新特性就是命令条(command-bar)控制类。

如果你的应用程序是用标准MFC编写,你需要仔细检查你的应用程序使用的类、方法和属性并确认它们在Windows  CE的MFC中兼容。

存储器的限制

通常,Windows  CE设备具有的RAM要比台式PC少得多。而且,它们大部分都没有磁盘或其它大容量存储设备。在大多数情况下,一个应用程序要成功的移植到Windows  CE就需要减小其尺寸。

当移植一个应用程序到Windows  CE时,你应该着眼于其最频繁使用的功能。Microsoft  Pocket  Word和Microsoft  Pocket  Excel就是两个在减少应用程序功能的同时保持了核心功能的例子。

编写的应用程序应该使用尽可能少的存储器和存储介质。这些程序必须能够与系统一道处理存储器不足的问题。

能量的限制

Windows  CE设备可能具有非常有限的能量源。例如掌上PC依靠两节AA电池运行。所以程序应该编写的耗用尽可能少的能量。为了节省能量,在一段时间没有使用后许多Windows  CE设备将会关闭。Windows  CE应用程序应能够从关闭以后的地方重新恢复。如果在运行时发生了致命的能量不足情况,应用程序必须能够良好地处理这个问题。

硬件特性

Windows  CE设计运行于通常没有台式PC那么大型和有力的设备。例如:
· 屏幕通常比较小,像素解析度较低并且可能不支持彩色。
· CPU运行速度较慢。
· 诸如键盘等用户接口硬件不很灵活。  
在另一方面,一些设备可能拥有一些在PC上并非标准设备的硬件-例如,H/PC上的红外收发器。无论怎样,不要假定所有基于Windows  CE的设备与台式PC两者是相似的。要将目标设备的硬件特性牢记在心。

当移植一个应用程序到多类设备时,有必要找到一个"最小公分母"以确保该应用程序能够在其所有的目标系统中成功使用。虽然仿真(emulation)是一个重要的开发工具,但应用程序必须在实际设备上进行测试以确认它能够正常工作。

测试和调试

开发用于Windows  CE的应用程序与开发用于其它Win32目标系统的应用程序非常相似,但有一个重要的不同就是将使用的测试和调试方法。如果你为一个标准的Windows  CE目标系统(比如H/PC)开发应用程序,那么大部分的开发和测试工作就要在开发工具所提供的Windows  CE仿真环境中进行。不过,如果你是为非标准的硬件平台(比如自定义嵌入应用程序)开发应用程序,那你就需要考虑一种替代的办法来检验你的应用程序的正确性。Windows  CE  API包含了用于调试的接口(比如DebugActiveProcess和DebugEvent)客用来建立系统内调试工具。根据你的目标硬件和应用程序,你还可以使用Windows  CE  的Remote  API  (RAPI)功能辅助进行调试。

在任何情况下,你都需要将你的应用程序在所有预计运行该程序的各类设备上进行彻底的测试。不应该依靠仿真环境提供足够的测试。

移植应用程序到Windows  CE的一个系统化的方法

一个能将Windows  95的应用程序移植到Windows  CE  的系统化的方法所生成的应用程序如果不能完全的立刻运行也应该能够接近于立刻运行的状态。

本章节的内容不是对必要的步骤进行详细描述,而是重点说明一些关键的要素。

移植使用Windows  CE  API

如果你的应用程序是基于16位的Windows,第一步就要将其移植到Win32上。虽然Win32通常能够对16位Windows函数提供向下兼容性,但Windows  CE却不行。

下一步,检查应用程序中所有的API引用-包括函数、消息和相关数据类型-然后更改或替换掉不与Windows  CE  API  兼容的引用。下面是一些检查的例子:
· 根本不支持的一些Win32函数-不支持任何16位Windows函数。如果存在替代函数,使用替代函数替换这些函数。否则,创建一个替代函数。例如,MoveTo和LineTo绘图函数在Windows  CE中已不再被支持。其替代品是PolyLine函数。
· 已被Windows  CE等效函数取代的一些Win32函数。例如,工具和菜单条已合成为一个单一的Command  Bar,并具有新的API。
· 支持一些Win32函数,但有限制。一些函数的一个或多个参数已不再使用。其它函数可能其参数的选择范围已减小。例如,虽然支持CreateWindow和CreateWindowEx函数,但Windows  CE只支持Win32窗口风格的一个子集。
· 支持的数据类型可能需要更改。Windows  CE支持所有必要的Win32结构,但一些可能不再使用。而其它结构可能不会接受所有的选项。
· 不支持一些消息-包括许多WM_*和EM_*消息。一些支持的消息也已被更改。例如,wParam  或  lParam  内容可能不同。一些Windows  CE的特定消息被添加进来-比如,WM_HIBERNATE。
管理Windows  CE的存储器

可用存储器的数量与设备有关,所以要注意你的目标平台的能力。Windows  CE在使用大容量存储介质(例如临时文件)和使用RAM上没有区别。

在你的Windows  CE应用程序中减少存储器和大容量存储介质的使用。要考虑简化或消除使用像位图图象一样的耗用大量存储器的功能。除非必要,不要使用临时文件。在一些时候,可以重写代码以较低的运行速度为代价而减少存储器的使用,这是一种可接受的折衷方案。

如果存储器资源变得紧张,Windows  CE通过一个过程来减少存储器的使用并使可用存储器恢复到可接受的水平。该过程的一个关键是WM_HIBERNATE消息,该消息并非标准的Win32消息。

注意  一个运行良好的程序必须实现对WM_HIBERNATE的处理并在存储器资源变得紧张时根据需要进行处理。

管理可用的能量

许多Windows  CE设备都因依靠电池运行而只有非常有限的能量来源。

一个活动的(正在运行的)CPU消耗了主要的能量,所以要避免代码中对的CPU周期的不必要的使用。特别要注意PeekMessage函数的使用,因为它能使CPU几乎持续的运行。

当电池开始电力不足时Windows  CE会显示警告信息,但不会对应用程序发送任何警告。对于许多应用程序,这些消息可能已足够确保用户采取适当的操作以避免数据丢失。

不过,一些硬件-例如,modem-能够很快的耗完电池的能量。如果你的程序对电池将有较大的能量需求,应先检查电池的状态。如果电量太低而不足以完成该过程,可建议用户采取适当的操作。电池状态的检测可以通过系统轮回检测完成。

移植图形用户接口

大多数PC应用程序具有一个图形设备接口(GDI,Graphics  Device  Interface),在Windows  CE中却并不对应如此,所以必须在移植前进行更改。为了保持小的操作系统,一些Win32  GDI函数不再被支持。而且,许多设备的硬件带来的限制-有限的屏幕尺寸,调色板和纵横比,造成一些-将需要一个不尽相同的方式。

调整位图和图标  
通常,Windows  CE相比台式PC而言具有较小的屏幕和不同的纵横比。你可能需要更改你的应用程序以适应这些更小化的限制。不过,不要使用静态布局,因为不同的目标设备具有不同的屏幕尺寸和纵横比。应该使用GetSystemMetrics函数来获得屏幕尺寸并使用它们定义窗口尺寸。

可用的调色板非常有限。一些设备支持彩色屏幕显示,但与典型的PC相比可能具有非常有限的调色板颜色。而许多设备则只有灰度图像-例如,第一代H/PC就只支持每像素两位的灰度LCD显示器。

要确保位图和图标具有目标设备上的正确格式。LCD的屏幕在一些设置下会难以观看,所以要尽可能调高对比度。

使用Unicode  
Windows  CE是一种Unicode环境-它支持ASCII函数以实现文本文件的交换,但其原有的文本格式是Unicode。将ASCII应用程序转换为Unicode程序的一些通用指导方针包括:
· 包含Tchar.h文件。该文件包含所有必要的转换。
· 使用Win32字符串函数(例如lstrlen)而不是C运行时态(run-time)库的函数。
· 声明中使用TCHAR、LPTSTR和其它类型。这样代码将易于编译为ASCII或Unicode格式。
· 使用TEXT宏进行字符串映射(例如TEXT("Your  Text"))。
· 牢记一个字符在长度上不再是一个字节,而字符串以两个零而不是一个零结尾。
· 当增加一个数组指针或字符记数时,使用sizeof(TCHAR)  以确保能够对ASCII或Unicode都有效。
创建和管理窗口

创建和管理Windows  CE窗口与在Win32中非常相似。不过,所拥有的窗口风格和管理功能将会比较少。

可能最引人注意的不同在于当窗口被移动时,用户不能对其重新设置尺寸(resize)-因为没有可用的resize处理或按钮。一个窗口只能拥有创建时所定义的尺寸。如果另外一个程序占据了前景,在任务栏(taskbar)上将出现一个图标以用于恢复原有窗口。窗口不能被重设尺寸的事实说明一些被公共使用的窗口风格-特别是WS_OVERLAPPEDWINDOW-已不再被支持。

当目标设备具有较小的屏幕时,你的应用程序应该使用全屏化的窗口。不过,不要将静态布局写入代码,因为不同设备具有不同的屏幕尺寸。当前大多数可用的H/PC为240  ×  480像素和大约2.5  ×  4  英寸。一些设备具有240  ×  640像素的比较宽的屏幕,改变了定位和纵横比。调用GetSystemMetrics函数得到相关的屏幕尺寸并使用它们定义窗口尺寸。

使用Windows  CE对话框

Windows  CE支持有模式(modal)和无模式(modeless)对话框以及Windows  95使用的预定义控制。不过,不是所有的控制风格都被支持。消息对话框仍被Windows  CE支持,但相对Windows  95而言具有较少的风格。

Windows  CE支持公共对话框的简单控制方式,Open和Save  As。它们在屏幕上的显示与Windows  95中相似,但可用的控制较少。

移植用户接口控件

大多数标准的Windows控件和公共控件仍然被支持,但具有一定的限制。一个主要的不同是菜单和工具条已合并为一个单一的命令条(command  bar)。命令条占据窗口的顶部并拥有自己的API。其Tool  tips(工具提示)只支持命令条中的按钮。

通常,对可用功能具有更多的限制。

管理Windows  CE线程

Windows  CE是一个多线程操作系统,但是相对Windows  95和Microsoft  Windows  NT  操作系统而言具有一定的限制。或许最大的不同在于它不支持信号量(semaphore)。如果你的应用程序使用了信号量,例如管理设备资源,该程序就需要在线程间使用其它同步方法。比如,你可以更改你的应用程序使用临界区(critical  section)进行线程同步。

更改用户接口

用户接口可能是你所要处理的最为困难的问题之一。事实上对于所有PC都拥有一个鼠标和键盘进行输入,并且在所有的计算机上都具有或大或小的屏幕显示输出结果。在一台计算机上运行的程序通常需要使用所有这些设备。而Windows  CE所使用的各类设备不仅与PC在许多方面不同,而且相互之间也有很大的差异。

例如,一个H/PC设备使用的是一个小的LCD触摸屏而不是鼠标。当屏幕被接触到触笔时,会产生一个WM_LBUTTONDOWN消息,其方式与普通PC非常相似。不过并不会出现光标,这是因为如果触笔不接触屏幕的话设备是无法跟踪触笔的轨迹的。在效果上这相当于只有一个鼠标按钮,这是不会产生WM_RBUTTONDOWN消息的-标准的替代方法是在进行触摸时按下ALT键。

其它Windows  CE设备可能比H/PC更加特别,与PC的模式相差更远。用户接口可能会使用语音或手写识别方式,作为传统的鼠标加键盘方式的补充或替代。键盘可能只包含数目较少的按键-例如,足以选择一个菜单即可。而文本的语音输出可能会部分或全部代替信息的屏幕显示。

可视化的显示方式可能多种多样。不同设备的尺寸、纵横比和像素数会有很大的不同。一些设备可能不支持彩色。另外一些支持,但可用的调色板颜色却会变化多样  。

简而言之,没有能够适用于所有Windows  CE设备的简单规则。要成功的移植一个程序,必须了解目标平台的特性,并进行所有必要的更改。虽然基于PC的仿真器是一个很有用的开发工具,但它们自身还是存在限制。要确信用户接口具有良好的设计和功能,基本方法就是在其所欲应用的实际设备上进行测试。

支持Windows  CE通信

Windows  CE支持四种通信APIs:  
· Windows  Sockets  (Winsock)
· 电话应用程序编程接口  (TAPI)
· Remote  Access  Server  (RAS,远程访问服务器)
· 串行通信  
这四种通信APIs是相应Win32  APIs的子集。

支持Winsock
Windows  CE网络栈支持TCP/IP(Transfer  Control  Protocol/Internet  Protocol  ,传输控制协议/网际协议)协议。如果你的程序使用Winsock调用处理网络传输,可能会需要进行一些改动。IRDA  (Infrared  Data  Association,红外数据协会)规范也可通过Winsock附件来使用。但是,在Winsock中有一些限制。特别是,WSA函数只得到了部分的支持。你将需要仔细检查对WSA函数的使用以确定是否需要进行改动。

客户端应用程序可通过点对点协议(PPP,Point-to-Point  Protocol)的一个子集连接到使用IPX、NetBEUI或TCP/IP协议的网络。"ppp_peer"是一个特定的主机名,作为设备所连接计算机的IP地址的代理(proxy)。Windows  CE还支持串行线网际协议(SLIP,Serial  Line  Internet  Protocol)。

支持TAPI
Windows  CE操作系统实现了TAPI  2.0版的要求。Windows  CE中对TAPI的支持主要处理拨向外部的数据调用,对于拨向外部的拨号和地址转换只提供了所需的基本工具。

支持RAS
RAS是一个用于连接远程设备(RAS客户端)和主机PC(RAS服务器)的基于软件的多协议路由器。RAS应用程序通常在客户端设备上执行。Windows  CE支持许多标准Win32  RAS函数,不过它一次只能实现一个点对点连接。该连接可以是直接串行连接或modem拨号连接。RAS电话簿(phone  book)中包含了建立一个连接的必要信息。

支持串行通信
对于串行口通信,Windows  CE支持Win32串行函数和标准文件系统函数。这些函数可用于打开、关闭和操作串行通信端口,并能够对这些端口进行读取和写入。Windows  CE不支持交替式通信操作,但能够实现在一个设备上的多未决读/写操作。

最小化使用注册表

小心使用Windows  CE注册表(registry)以保持最少的存储器需求和最大的访问速度。通过下面的指导方针使注册表项尽可能简单:
· 限制每个项(key)名称组件的长度。
· 限制得到一个值的所需项的数目。
· 不要使用NULL  (默认)值名。
· 不要使用许多较小的项值;应使用一个较大的项值。
· 不要只是为了保持一致性而使用Windows  95的项命名约定。通常这不是最有效的方法。
· 保持项值尽可能的小-不要在注册表中设置数千字节的项值。  
1楼 0 0 回复
总共 , 当前 /