1:搭建开发环境,转换工程到ce
见: http://blog.csdn.net/cuibo1123/article/details/8744225
2:解决api兼容问题。
win32下很多api与ce不兼容,需要一个一个找替换方案,没有替换方案就去找第三方,没有第三方就悲剧了,只能自己实现。
3:解决连接dll兼容问题。
系统dll解决方法类似API,找,找不到自己写相应功能。自己写的dll,像移植程序一样移植。第三方dll,那祝你好运,希望他提供了ce版。
4:界面布局/资源
ce和32的资源文件不通用,必须删掉重建,有经验的编辑代码,自己改吧, 一点一点改,怎么也比重写快。编辑时 提示.h无法打开,通常因为 _WIN32_WCE没定义,定义他到.rc里面即可。另外布局大小都不一样(任务栏高度,状态栏高度等等),所以只能自己慢慢改位置。
5:界面刷新机制不太相同,尤其是使用gdi的地方。
寻找替换方案。
6:字符集,只能 Unicode
如果你用了 多字节编码 ,那么恭喜你,慢慢来。如果你写的是工控程序,那大部分通信协议都是 多字节编码 的,所以,注意不要全部改成 Unicode, 或许3年,或许5年,总有一天能改好的。
7:优化
如果你的ce板子特别弱,那么,性能很重要了。ce一般都是arm,精简指令的。和x86没得比。所以主频不能说明任何问题。
建议:
1:如果项目要同时支持win32/wince,最好不要做两个版本,使用一个版本,用预编译控制版本编译。否则项目升级将是个灾难。
2: 如果你用了多字节编码, 所有界面更新的动作都做一个自己的封装,这样切换字符编码会容易的多。否则只能做一个协议转换的接口了。用 多字节编码的好处是:如果你的程序逻辑复杂,界面简单,那么所有逻辑都可以c语言,到界面时候转换一下即可。如果用了Unicode,那么处理协议类操作会变得复杂。。
见: http://blog.csdn.net/cuibo1123/article/details/8744225
2:解决api兼容问题。
win32下很多api与ce不兼容,需要一个一个找替换方案,没有替换方案就去找第三方,没有第三方就悲剧了,只能自己实现。
3:解决连接dll兼容问题。
系统dll解决方法类似API,找,找不到自己写相应功能。自己写的dll,像移植程序一样移植。第三方dll,那祝你好运,希望他提供了ce版。
4:界面布局/资源
ce和32的资源文件不通用,必须删掉重建,有经验的编辑代码,自己改吧, 一点一点改,怎么也比重写快。编辑时 提示.h无法打开,通常因为 _WIN32_WCE没定义,定义他到.rc里面即可。另外布局大小都不一样(任务栏高度,状态栏高度等等),所以只能自己慢慢改位置。
5:界面刷新机制不太相同,尤其是使用gdi的地方。
寻找替换方案。
6:字符集,只能 Unicode
如果你用了 多字节编码 ,那么恭喜你,慢慢来。如果你写的是工控程序,那大部分通信协议都是 多字节编码 的,所以,注意不要全部改成 Unicode, 或许3年,或许5年,总有一天能改好的。
7:优化
如果你的ce板子特别弱,那么,性能很重要了。ce一般都是arm,精简指令的。和x86没得比。所以主频不能说明任何问题。
建议:
1:如果项目要同时支持win32/wince,最好不要做两个版本,使用一个版本,用预编译控制版本编译。否则项目升级将是个灾难。
2: 如果你用了多字节编码, 所有界面更新的动作都做一个自己的封装,这样切换字符编码会容易的多。否则只能做一个协议转换的接口了。用 多字节编码的好处是:如果你的程序逻辑复杂,界面简单,那么所有逻辑都可以c语言,到界面时候转换一下即可。如果用了Unicode,那么处理协议类操作会变得复杂。。
3:移植项目后先编译,把错误都先弄掉,然后至少能调试了,在慢慢处理兼容。