32位项目转64位项目的个人体会

       由于项目需要，最近将办公室里的一个学长写的MFC项目从vs2010移植到vs2013，出现了一堆多字节转到Unicode的错误，其实在写这个项目的时候就有想过为什么不用Unicode，《windows核心编程》里面也建议使用Unicode，引用如下：

①Unicode使程序的本地化变得更容易。

②使用Unicode，只需发布一个二进制（.exe或DLL）文件，即可支持所有语言。

③Unicode提升了应用程序的效率，因为代码执行速度更快，占用内存更少。

④Windows内部的一切工作都是使用Unicode字符和字符串来进行的。所以，假如你非要传入ANSI字符或字符串，Windows就会被迫分配内存，并将ANSI字符或字符串转换为等价的Unicode形式。使用Unicode，你的应用程序能轻松调用所有不反对使用（nondeprecated）的Windows函数，因为一些Windows函数提供了只能处理Unicode字符和字符串的版本。

⑤使用Unicode，你的代码很容易与COM集成（后者要求使用Unicode字符和字符串）。

⑥使用Unicode，你的代码很容易与.NET Framework集成（后者要要求使用Unicode字符和字符串）。

⑦使用Unicode，能保证你的代码能够轻松操纵你自己的资源（其中的字符串总是Unicode的）。

       但老板要用多字节，于是结果就是傻傻的改了一下午，可怜的是最后在Microsoft官网看到一个2013安装多字节的小插件。当然由于还是希望用Unicode，所以改了就算了。

       然后现在又说要从32位转成64位，于是一大堆外部符号无法解析，总结了三种可能性：①解决方案里有dll项目但未被exe添加引用；②未添加附加依赖库；③lib与所包含的头文件不匹配。只能重新将引用的dll、lib编译出64位的，再配置环境。本以为最后生成成功的时候就完事了，结果一运行，弹出“应用程序无法正常启动”，为此又折腾了一个星期，在网上搜不到结果，在群里询问也无人解答，最后排除的可能就是64位程序引用了32位的lib，没办法只能重新将lib一个一个替换排除。

       虽然这些都是没什么技术含量的事，但涉及了在着手准备一个新项目时所需要考虑的事应该具备前瞻性，理应根据项目的产业线去部署，当然，可能更多时候为求稳定都不愿使用新事物吧！