工控机上位机开发：wince和winxp程序开发有很大的差异性

 

很多用户搞不清楚wince工控机和windows工控机在程序开发的区别，以为两种操作系统的程序可以相互兼容，其实是不可能，两种工控机系统的程序运行机制有很大的差异性。

    对于近年才接触WinCE开发的朋友来说，见到EVB这个字眼可能会觉得非常陌生。想当年WinCE 3.0的时代，EVB可是和EVC是WinCE开发的两把利器。只不过后来估计微软看着EVB不顺眼，在4.0开始，就将EVB横扫出门，只剩下EVC一枝独秀。只不过EVC王者独尊的态势注定不可能太久，从5.0开始，VS就已经开始支持其开发。后辈VS支持STL开发的完善程度，编译器的效率等等，都是EVC所无法企及的。随着时间的推移，EVC注定也只能退出历史的舞台。只不过，EVC4.0很可能和接下来要说的VC6.0成为一个永恒的经典。

 

 

 

    转移到桌面Windows的开发，大家最熟悉不过的就是vc6.0。这款软件，堪称是经典，无论是执行速度，还是编译速度，在当年都是无望而不可及的高峰。即使是现在，很多人对此还津津乐道，特别是很多高校，教导C++采用的还是VC6.0，可见其影响力。只不过，技术是不停地发展的，微软注定不会让VC6.0舒服，后续又逐渐推出VS系列。

 

 

 

    我一直认为，VS2005是微软开发工具的一个里程碑，它结束了之前微软旗下编程工具的混乱局面，全部统一到vs这个大家族里面：

 

 

 

　　用EVC开发WinCE应用程序？NO，NO，请使用vs2005！

　　

　　用PB编译WinCE系统？NO，NO，请使用vs2005！

　　

　　用VC开发WinXP程序？NO，NO，请使用vs2005！

　　

　　你所能想到的开发方式，vs2005都可以帮你解决。更为有意思的是，在此之前，同一套代码，分别适用于WinCE和WinXP，那么你就必须为这两个系统建立不同的工程：一个是给EVC用的，另一个是给VC。但如果你使用VS2005之后，那么一切都不同了。虽然一开始会强制让你选择开发的平台，但实际上生成工程之后，你可以手动添加不同的SDK。换句话来说，你只要简单地在vs2005上选择不同的SDK，就可以编译不同平台的程序。相对以前，这无疑是一个巨大的进步。

　　

　　扯谈完开发工具，我们再来看看调试的方式。在WinXP里，调试的环境和开发的环境是共用的。这个比较好理解，不就是本机编译的程序会直接在本机上运行嘛。只不过有一些危险的操作，估计没几个人会调试，比如说软件上有全盘格式化功能，我想没几个人会在本机上调试吧？WinCE就安全点，反正直接在WinXP上点击WinCE程序会给你弹出一个错误的运行框。所以，要调试WinCE程序，你只有两种途径，一个是使用模拟器，另一个就是通过ActiveSync连接到开发板。而这两种方式，最好的自然是后者，毕竟模拟器，顾名思义，就是"模拟"，很多实际上会发生的问题很可能会被屏蔽。只不过，如果是开发消费类电子，在还没有板子回来前，模拟器确实是唯一的选择。

　　

　　具体到API函数代码方面，也确实有意思。WinXP有的函数，WinCE不一定具备；同样，WinCE随处可见的，也不一定在WinXP上有其身影；即使是两者都有的，其参数也不一定相同。

　　

　　不信？你在WinCE下给我找找SystemTimeToTzSpecificLocalTime，然后在WinXP下也搜搜SetEventData，最后比较一下ReadFile最后一个形参试试？如果你不需要代码横跨两个平台，那么这些都不是问题；如果你需要互相移植，那么前面的两个问题也不是什么大问题，大不了自己重新写一个同名函数即可。最郁闷的是最后一个，两个系统都有相应的函数，只是形参不同。像ReadFile这样算是好的，最后一个形参WinCE明令指出必须设置为NULL，你将该代码原封不动移植到WinXP下，也能正常工作。但有的函数就没有那么好的运气了，比如说CreateProcess的倒数第二个形参psiStartInfo，在WinCE下必须设置NULL，但如果你还是不加更改照搬到WinXP，那么迎接你的将是程序的崩溃--因为在WinXP下，该形参不能为NULL！

　　

　　不仅API函数需要留意，其实消息处理机制也必须注意。因为WinCE是一个精简的系统，实时性要求高，所以在WinCE下面消息处理机制有点点和WinXP不同。很可能在WinXP下跑得很正常的代码，在WinCE下会哑火；同样的道理，能在WinCE完美表现的代码，也许在WinXP下是一团糟。如果遇到这种情况，不妨从消息处理函数入手，说不定能有意外的惊喜。