All Stories
增加了浏览脚本源代码和用外部程序打开脚本文件的功能。读文件部分直接用Win32 API 来做，感觉有点怪怪的，还是习惯用C 库，连C++ 标准库都没啥了解，也许过些天心血来潮会把它改掉用iostream 来实现吧。现在插件管理功能基本已经达到预期目标了。
意外地发现，只要对hhctrl.ocx 执行implib 导出的lib 文件就可以直接用在BDS2006 的工程里了，再也不用LoadLibrary 和GetProcAddress 了，再也不用为什么时候FreeLibrary 而发愁了，一切都变得那么美好，意外地发现，sf.net 上还有个叫bccSDK 的项目，专门把MS 新发布的一切库移植到可以用Borland 的C 编译器下使用，其实就是一堆的lib 文件，当然还有那个htmlhelp.lib，不过我没有用，因为我已经自己暂时解决了，只是奇怪的是，以前明明我也这样做过，为什么不行呢？
看起来对应用程序与Tcl/Lua/Python 脚本语言之间的链接没多少问题了。至少到现在为止，给MspEmu 加上了最简单的链接嵌入，运行时从进程的模块列表中可以看到，三个dll 都赫然入目。每一种交互都需要一个初始化和清理扫尾工作，这个似乎都是约定俗成的。稍微抱怨一下，这方面的资料还真是少，google 了一番也没找到多少有用的信息，还是因为我的信息收集能力太弱了。
昨天突然发现，外接硬盘中有个分区打不开了，连卷标都丢失了，很郁闷的是，这个分区里放了些对自己很有纪念意义的照片，以及一些才收集来的文档和资料，所以很不甘心，文档资料可以再去网上找，但丢失的照片是只有这个“孤本”的，所以晚上就睡得有点不舒服。早上起来，还想能不能放到别人的电脑上去看看，能不能读出来，后来想想算了，估计也是没希望的，于是就在Windows 自带的磁盘管理功能里把这个分区删除了再添加上，盘符还是改成和原来的一样。然后尝试打开它，当然打不开了，它提示没有格式化，死马当活马医，就快速格式化了，文件系统也用和以前一样的NTFS，然后很怀旧地建了个一个和以前一样名字的文件夹。突然想起那些数据恢复工具不知道有没有用，于是上网搜了一下，down 下一个EasyRecovery 的专业版来，试图用Unformat 来恢复，搞了半个小时，没找出东西来，用Undelete 也没用。正当要放弃的时候，看到还有个RawRecovery 功能，就试了试，还真能找到一些文件，只是文件名全改乱了。太开心了，下午就出去了，让它自己在那里恢复吧。等晚上回来，重要的那些东西恢复了多数，主要是那些照片，还有些文档也恢复出很多，只是很多都损坏了，不能再打开了。整理了一部分，发现一个现象，ZIP 的包损坏率比RAR 的高出很多，可能是RAR 包的自我修复能力比较强吧。还有些doc 和pdf 文件，打不开了，不过不是很重要，也就随它去了，反正大概估计了一下，那些近期想要的文档都还知道网上从哪里能找到。
afei 她们事业部开“本部之星”的K歌比赛，xcc几天前开始约我有没有时间一起去，我当然欣然同意了。我们可真是翻山越岭啊，跋山涉水啊，历尽千辛万苦啊，转了几次车啊，先从我家门口坐328 到梅林，然后再坐334 到南山海雅，再坐226 到目的地新桃园酒店。结果我们迟到了1个小时，还好，只是前面唱过几个人，afei 还没上台。过了一小会，就是afei 上台了，离上次见到她又是有几个星期了吧，xcc 虽然是跟她一个公司的，但工作地不在一起，所以也应该很久没见过了，路上的时候我还向他介绍说afei 现在变瘦了，变漂亮了。现场的气氛很好，下面的观众都很配合台上的表演者，afei 那首《听海》也是唱得很有水准，有点像张靓颖的风格，嘿嘿，xcc 说不知道什么时候变得这样了，跟平时说话的时候完全不一样了，肯定是练了很久了。前面4个选手没听到，反正后面的6个我都觉得很明显唱得不如afei 好。台下的观众真的很热情，想想我们当时整个光网络产品线搞节目，产品线总裁在台上嘶声力竭地喊“大家一起来”，结果台下的人还是反应平平，木然地摇着手中的道具，傻傻地坐在座位上。
这周考了三场，周一到周五隔一天就一场，每门都是要求85分才算通过，这才是最让人郁闷的。不知道从何时开始，我就对考试怀着一种畏惧的心情，总是给自己心理暗示，说自己不擅长考试。还在大学的时候，60是最后的底线，但往往只要能找到足够数量的比自己还要堕落的人，还要低的分数，就算再低的分数也是能死里逃生的。现在就不行了，反正85分是硬指标，当然同时也是最终结果，至于过程如何，就看各人各显神通了。想起《Naruto》中的中忍考试笔试部分，就被称为是为了考验考生的情报收集能力，隐藏能力云云。结果看来我的情报收集能力似乎还算过得去的，只是自我保护意识薄弱了点，隐藏能力欠缺了点，呵呵。
看了一下把Lua嵌入到MspEmu中去，虽然从官方网站上down 到了据说是兼容BC 的编译器的二进制lib 文件，但实际用的时候似乎还是有点问题，说_errno 的引用找不到之类的。顺便在google 上找了一下Tcl 和Python 的内容，本来这些动态语言在与应用程序交互嵌入的时候都是优先考虑 VC的，有的几乎就根本不考虑其它编译器的情况，包括Borland 的。看了一下，有两种方案，一种是，如果已经有lib文件了，但是用VC编译器生成的，就用Borland 的一个随它的C++ 编译套装一起发布的小工具coff2omf 转一下格式，因为MS的二进制映像是coff格式的，而 Borland的则是omf格式的，这样转一下就可以链接到Borland 的C++ 工具生成的项目里去了，具体我也没实践过，不知道是否能用，总之看起来似乎没什么错，有道理的。另外一种是，找到那个dll 文件，用Borland 的一个小工具impdef 导出DLL 中的函数名，然后有个tcl 写的脚本，把别名处理一下，生成一个新的函数名列表文件，用这个新文件作为参数运行Borland 的另外一个工具implib ，就可以得到一个lib 文件了，直接用implib 也可以从dll 文件导出lib 文件，但也许VC生成的dll 中导出函数名与BCC 有区别，不一定能用。
用BDS2006发现好像编译速度变快了，快了不止一点点，尤其在make 一个project 的时候，如果有好些源代码文件，而其中只有一个文件是改动过了需要编译的话，感觉特别明显，比起用BCB6 时加上pch 插件还快。
昨天，哦不，应该是今天凌晨，熬夜装好的BDS2006，晚上回来就试用一下。把那个写了一半的数据分析程序从BCB6.0 移植过来，很顺利，因为我都没有使用其它任何第三方的控件。传说中改进了内存管理器，但这一点我是没什么切身的感触。有时候我在想，我为什么要升级，从BCB5.0升到6.0的时候，只是看到IDE中编辑器的代码提示功能相对好用了稳定了些，其它的都还没来得及比较，因为对于我来说，根本用不上那么多特性。这次升级到2006，看起来也只是IDE 变得更漂亮了，带来的副作用就是需要更大的内存，更快的CPU……另外的好处就是前面提到的，Borland帮我在后面默默地把内存管理做得比以前更好了，还有就是也许VCL之类的有些小改动，再看一下编译器，从5.6.4升级到5.82了，不知道有多少实质性的进展，更好的标准符合度？更强的代码优化？还有呢，对于我来说，大概就这些是有影响的吧，其它的实在也看不出来多少必要。
