一、MFC的硬伤
在接手现在这个项目之前，我对WINDOWS平台上的UI开发还是个白痴，除了MFC，就只知道GDI了。而且居然大言不惭地说用MFC只能画画灰色的对话框和按钮。但不论如何，在嵌入式这种对成本极度敏感的项目上，我是不会拍板用MFC的。假设极端情况，定制后的系统是31.8M,我放一个ARMV4I上的MFC DLL进去，大概500多K，那么只有两种选择，要么把32M的FLASH换成64M的——我的上司会把我给砍了，要么把应用层的UI代码全部重写——我的下属会把我给剁了。另一方面，WINCE上的应用软件我看过不少开源代码，也接触了一些外包的软件，还真没见过谁用MFC的。网上公论用MFC后会导致程序在不同平台上移植性降低，因为你不能指望别人的平台给你准备好奢侈的MFC。另一方面，多数高手都不屑用。我不是高手，但可以学人家摆谱，于是“不会用”就变成了“不屑用” ^_^
二、GDI的痛苦
把整套UI从CreateWindow开始写起，的确很累人。我写了500多行才勉强实现BUTTON类，另一个同事也用了500行左右才实现了TRACK BAR类，而且还未经测试，也没有很正式的CODE REVIEW。如果工业设计中心多增加几种图样，那么我们就得多些几个基类，然后再赔进去CODE REVIEW的时间、测试时间、BUG FIX的时间。不痛苦，那是不可能滴~。
三、GWES的探路，我不是先锋
群众的智慧是无穷的。当我这组同事的思维都受制于我的GDI方案时，从通信部过来协助完成项目的软件工程师从WINCE500的一个应用SAMPLE CODE里把DialogBox函数给抓出来了。我认为自己在定UI实现方案上很失败的一点就是习惯性思维地从eVC里建立DIALOG RESOURCE后，立刻就要去点Class Wizard, 然后就是关联MFC类。而他却画出来的DIALOG和BUTTON后，拿着RESOUCE ID从DialogBox函数建立起UI。并且我又习惯性思维地认为DialogBox并不在STANDARD SDK 500里面，但他确实从STANDARDSDK_500里不引用其它LIB和DLL就把DialogBox和BUTTON用起来了，然后过来找我谈论如何把图片叠加在DIALOG和BUTTON上。泪奔一百里~ 我应该去找块豆腐撞死~
四、最后的攻关，GWES API能否成为我们需要的坚实地基
GWES系列API能否实现我们所需的所有UI功能呢？没有人知道，需要评估。刚才起草稿时，我把这些都写在同一篇文章里了。现在觉得还是分篇好些，毕竟主题不同。请继续看中篇：GWES方案上几技术难点的解决
