4、无处不在的白痴 UID3
如果你在 EKA2 下开发，那你就会发现有无数多的地方会牵涉到这个该死的 UID3：可执行文件名中有、资源文件名中有、注册资源文件名中有、资源文件资源 ID 所在的头文件（.rsg）中有、帮助文件条目 ID 所在的头文件中有（.hrh）……。

这些还好办，我们可以想办法减少影响。老汉的解决方案是，修改了 Carbide.c++ 自带的工程模板，把其中涉及到 UID3 的内容都集中到了一个 projectNameUid3.h 的头文件中去处理，然后原来各处需要使用 UID3 的文件里都包含这个头文件。这种办法尽管无法彻底消除 UID3 对工程的影响，但也还是极大地简化了移植工作（例如把这个工程作为另一个工程的起点模板）。

不过，上面既然说到了并不是“彻底”地消除，很显然还是有一些麻烦。例如，有的 XML 之类的文件，你是不能使用 #include 之类的指令向其中包含一个宏定义的。还有更糟糕的。假设你有个作用相当通用的 DLL（例如，一些常见算法的实现），这个 DLL 要在多个产品中应用。不久你就会发现这实在是一件非常痛苦的事情。首先，不能使用相同的二进制文件，如果这样做的话，第一个产品安装之后，其他产品的安装就会失败（有文件冲突，系统不知该如何取舍）。那你只好修改 UID3，并同时使用不同的文件名。多个产品安装之后，sys\bin 下就可能出现类似这样的情况：algo_0x00000001.dll、algo_0x00000002.dll、algo_0x00000003.dll。这些动态库，除了 UID3（文件名中的以及文件体中的）之外，事实没有任何不同。更不幸的事情在于，如果你所在公司的测试部经理是一个极端谨慎的人的话，他会把这些模块当做完全不同的文件来测试，他说出的话将是无可辩驳的：二进制文件不同！你很可能会由于这些问题承担来自于高层的压力，认为你在模块化设计以及代码复用方面的努力乏善可陈。

我想有人会提出内嵌 SISX 安装包的方案。我个人确实承认它是一个可以试试的办法，然而你不能忽略用户心血来潮会在安装程序列表中把它删除的风险。一旦这样，那你所有依赖于此的产品就只好统统见鬼了。

另外一个解决方案是采用静态链接库，然而很快你就会接到由客户服务部门以及其它相关部门转来的用户的抱怨，发现使用手机在网络上下载你的产品竟然需要长达半个小时！哦，天哪，产品体积实在是太大了，真是噩梦！