20个月前我换下老的Sony PCG-K23，开始用Sony VGN-FW235J。但是老机器一直没有停止维护使用，因为我需要VC6编译AR1688和PA1688 Windows下的工具。在这个过程中，执着的微软自动升级终于成功地把我的老机器改造成了光跑VC6一个程序都嫌太慢的废物。我不得不开始用新机器上的VC2008来编译AR1688工具。
很快我发现已经有人做过了这个升级工作，所有工具都能在multi-byte设置下成功编译，但是最明显的问题是，在我64位Vista系统下，Manager.exe的调试信息输出不正常。
我决定全部改用缺省的新的unicode选项编译。结果这个工作大大超出了我的预期时间。原来代码中混合使用memcpy/strcmp和CString的编程方式在unicode下带来了无穷无尽的麻烦问题。
从目前测试来看升级结果还算好。尤其让我觉得有趣的是，用multi-byte编译时，所有hex2bin.exe这样的命令行工具都比以前小了30%，而改用unicode后又减小了10%。图形界面的Manager.exe也比以前小了一点点。结果现在总的压缩后软件API小了10%，从2.4M字节降到了2.2M字节。
接下来我试图把SDCC 2.9.0也从VC6升级到VC2008，但是折腾了几个小时后被迫放弃。问题实在太多了，无论是multi-byte还是unicode都无法编译成功。目前我们还只能使用VC6编译的SDCC，还好我们不需要经常改动它。等以后SDCC 3.0.0发布的时候，我们就只能用mingw/gcc编译的SDCC了。
在这里顺便宣布发布AR1688 0.48软件的第一个测试版本0.47.021，此版本的软件API已经可以从我们网站下载。0.48正式版本计划在10月1号发布。
因为AR1688工具现在是用Microsoft Visual Studio 2008 (VC9)和Windows SDK v7.1编译的，在运行它们前，用户可能需要从微软下载和安装VC9的可再发行组件包。这个包有1.8M字节，比Microsoft Visual Studio 2010 (VC10)的5M字节可再发行组件包小不少，但是比我熟悉的MFC42.dll可大得太多了。
很快我发现已经有人做过了这个升级工作，所有工具都能在multi-byte设置下成功编译，但是最明显的问题是，在我64位Vista系统下，Manager.exe的调试信息输出不正常。
我决定全部改用缺省的新的unicode选项编译。结果这个工作大大超出了我的预期时间。原来代码中混合使用memcpy/strcmp和CString的编程方式在unicode下带来了无穷无尽的麻烦问题。
从目前测试来看升级结果还算好。尤其让我觉得有趣的是，用multi-byte编译时，所有hex2bin.exe这样的命令行工具都比以前小了30%，而改用unicode后又减小了10%。图形界面的Manager.exe也比以前小了一点点。结果现在总的压缩后软件API小了10%，从2.4M字节降到了2.2M字节。
接下来我试图把SDCC 2.9.0也从VC6升级到VC2008，但是折腾了几个小时后被迫放弃。问题实在太多了，无论是multi-byte还是unicode都无法编译成功。目前我们还只能使用VC6编译的SDCC，还好我们不需要经常改动它。等以后SDCC 3.0.0发布的时候，我们就只能用mingw/gcc编译的SDCC了。
在这里顺便宣布发布AR1688 0.48软件的第一个测试版本0.47.021，此版本的软件API已经可以从我们网站下载。0.48正式版本计划在10月1号发布。
因为AR1688工具现在是用Microsoft Visual Studio 2008 (VC9)和Windows SDK v7.1编译的，在运行它们前，用户可能需要从微软下载和安装VC9的可再发行组件包。这个包有1.8M字节，比Microsoft Visual Studio 2010 (VC10)的5M字节可再发行组件包小不少，但是比我熟悉的MFC42.dll可大得太多了。
Palmmicro 