All Stories
偶然看到云风blog上讲到LuaJIT2.0 Beta发布了，于是很好奇地到它的官方网站上看了看。以前也是听说过有这个东西的，不过以前根本不用Lua这东西，看过也就忘了。 这个东东据说是从API到ABI都是兼容官方Lua的最新版本的，所以一般说来，用官方Lua做的事情，用LuaJIT也可以做。但是它的强项在于，它执行Lua脚本比官方Lua要快，最慢的是快一点点，大概一点几倍，好的情况下能达到几十倍。 这次说的2.0 Beta版本据说是VM部分跟1.x版本来说完全重写了，效率又是提升了n倍。这个效率有提升，其他代价也几乎没有，这等好事不能错过，于是下载了它的源代码来体验一把。 它的编译方法跟官方Lua的很像，反正很容易。在Windows平台最后会生成一个dll文件一个exe文件，这点跟官方Lua也是很类似。只要在编译的时候保证dll的文件名，这样就可以把这个dll拿到其他嵌入Lua的项目中去用了，那些项目的源代码是不用修改的，因为API兼容嘛，而且好像也不需要重新编译，因为ABI兼容嘛。 经过短暂的体验后，发现Beta果然是Beta啊，直接require那iuplua只报什么call nil value，另外就是我自己的那个嵌入Lua的程序会崩溃，具体就没有定位了。而这些问题在1.1.5版的LuaJIT中是不存在的，所以2.0要能正式Release应该还需要一段时间。
之前说过，wxWidgets程序是用MinGW编译的，所以用到的wxLua就只好用其他编译器了，试了BCC 5.5和OpenWatcom 1.8，都因为不能顺利编译wxWidgets而放弃了，只好再掉头用回VC 2008。 既然用了VC编译wxLua，而前些天用MinGW编译的IUP等用起来又有问题，于是就索性让VC把IUP、IM、CD等其他的库也都编译了好了。因为只有最最核心的功能是用C++写的，其他的功能能用Lua的都用Lua写，所以就需要有比较完善的常用功能的库。除了wxLua、IUP这等GUI库外，剩下还需要数据库访问的，至少是能访问sqlite3的，网络通信的，XML操作的，正则表达式，MD5等散列值计算的这几方面的库。现在暂时还没编译，等到时候真正需要的时候再搞吧。 在编译和使用wxLua和IUP的过程中，遇到不少问题。 Lua脚本在require一个模块时，会去几个固定的路径下搜索名字匹配的文件，于是我照LuaForWindows的做法，把dll都放在exe程序所在目录的clibs子目录中。发现一个一直以来的错误的认识，以为一个dll在载入另一个dll时，会像exe一样首先搜索自己所在目录。错了，一般情况下是不会搜索dll所在目录的，而是搜索载入该dll的exe文件所在的目录。所以一开始总是不能正确地让wx.dll载入wxWidgets的dll，后来将wxWidgets的dll放在exe所在目录后，又报不能载入msvcp90.dll，这是VC的重发布文件，本来exe是通过manifest文件来指定这个文件的搜索路径的。所以经过试验，发现wx.dll和wxWidgets的dll是没有包含manifest资源的，只好用命令行mt.exe -manifest xxx.dll.manifest -outputresource:xxx.dll;2这样把manifest再注入进dll。命令行参数都容易理解，最后个2，我猜测是注入后的资源编号，manifest类型资源在exe中是1，在dll中是2。经过这样处理的dll，都能正确载入msvcp90.dll等重发布文件。 接着再解决dll存在位置的问题。本来这些dll只是为clibs下的dll依赖的，我当然不乐意让它们放在clibs外面，所以在网上找了一下，发现确实可以为单独的exe文件设置dll搜索路径。只要在注册表中 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths 下添加一个新的键，项的名字就是exe文件的名字，比如CodingStudio.exe，然后在这个新键中写入字段，默认字段的值为exe文件的完整路径，再添加个新的字符串，名称为“path”，值为dll所在的目录完整路径。这样不但可以在“开始”-“运行”对话框中直接输入exe文件名来启动该程序，还可以让该exe在载入dll时搜索那些目录。 编译IM时，有个im_capture库，在Windows下是依赖于DirectX的，需要先安装DXSDK，现在MS网站上只能找到2008年发布的，版本至少是9.0以后的了，这里有个问题是，im_capture用到了qedit.h文件，该文件中又包含了dxtrans.h文件，而这个文件是没有的。在网上找的方案基本上有两种，一种是在其他地方找个dxtrans.h文件，然后就行了，不过我没找到，另一个方案是修改qedit.h文件，不要包含这个文件，然后在它的开头定义4个宏：__IDxtCompositor_INTERFACE_DEFINED__、__IDxtAlphaSetter_INTERFACE_DEFINED__、__IDxtJpeg_INTERFACE_DEFINED__、__IDxtKey_INTERFACE_DEFINED__。这样就可以了，im_capture只需要DXSDK的头文件，不需要DX的什么库文件。 还有个im_wmv库，依赖于MS的Media Format SDK，可以在MS的网站上找到。其实只是需要它里面的一个叫wmvcore.lib文件，其他的头文件是不需要的，如果把头文件路径添加到搜索路径，反而编译会出错。 最后是发现，在方能iupimglib时，VC的编译器就占满CPU然后就挂死了，郁闷！只好继续用前些用MinGW编译出来的iupimglib.dll和iupluaimglib51.dll了。
今天完成了右键弹出菜单的插件扩展框架支持，基本上没有遇到什么障碍，跟原来想的一样简单。 除了这个，还把菜单、工具栏的插件扩展支持功能的代码重构了一遍，把这部分功能提取成一个独立的类，在类中完成插件扩展的相关功能，只有最终的事件消息响应函数仍然放在界面类中，这是因为才发现不是随便一个类的成员函数都可以绑定成事件处理器的。 顺便说个可能是wxWidgets的bug，动态创建的菜单，动态添加的菜单项，第一个图标总是显示不出来！ 再一个是原本用SWIG生成的文件，我把它直接作为头文件，包含在另一个源文件中，而该源文件因为某些原因，经常会被重新编译，而恰恰这SWIG生成的文件体积巨大（超过25000行），所以编译要花不少时间。于是又仔细看了一下生成的这个文件，发现其实最终只是需要一个luaopen_libname的函数，这样SWIG生成的文件就可以作为源文件了，不用跟着其他文件编译了。
今天修改了插件扩展的描述方式，把菜单项、工具栏按钮的标题、路径和帮助文本，工具栏按钮的图片等信息，全都写到xml描述文件中，这样一弄，lua脚本确实精简了很多。到现在为止，已经可以正常地通过插件扩展实现主菜单和工具栏的点击响应了，如果要说更新界面状态，也不是很麻烦，也就是多添加一个消息连接而已。 再说右键弹出菜单，我粗略地想了想，应该不是很麻烦，也就是添加到各自的扩展点下即可。其实直到现在，我才想起来，我这种实现方式，其实应该跟Windows传统的GUI资源编程基本思路是一样的。主菜单用一个编号标识，然后是菜单项信息，需要足够多的信息可以标识出菜单项的位置（路径），然后是给菜单项添加消息响应。工具栏的实现也是类似，所以如果要支持右键弹出菜单，也沿用那套思路就行了。 昨天说到，如果在插件扩展中使用wxLua，那么wxLua不能使用宿主程序使用的wxWidgets二进制文件，于是我今天想用IUP来试试。我从CVS里取出IUP的代码，然后用MinGW编译出所有的dll文件，可是用的时候发现总是报IupClipboard符号在指定的dll中找不到，而我用depends看是有的，郁闷！但是用LuaForWindows里的dll是可以的，可是它是用VS2005编译的，要带一个VC2005的redist，不爽啊！ 另外一个问题是，本来以为脚本扩展时用了wxLua，而宿主程序也用了wxWidgets，两个之间可以无阻碍地互相使用各种控件，今天才发现，当时太想当然了。我用SWIG封装了宿主程序中的一些代码，比如wxFrame，在wxLua中是不认识这种封装的，两种不是相同的类型。所以现在只能精心挑选一组必需的，常用的代码来用SWIG封装，现在让它生成的包括scintilla和scilexer以及wxcintilla的声明后，生成的文件有近30000行，编译要花不少时间。说起来，我应该再仔细研究一下SWIG的用法先。 这两天用wxWidgets，有时候感觉它比MFC、VCL要灵活，比WTL要易懂。这也许很偏面。不过我最不满的是它的资料太少，以及运行效率不高。
这两天又用wxWidgets，不得不感叹一下，资料实在太少了，只有一个现成的manual，其他时候就只有看看CodeLite、Code::Blocks的源代码了！ 到今天为止，修改了脚本扩展的功能，可以在一个描述文件中定义多个扩展的信息。对于主菜单来说，倒是勉强够用了，不过当时因为想让描述文件中对扩展的描述尽量通用，将其他的信息都写到脚本里去了，现在看来如果要对工具栏也使用脚本扩展，那么这种方式实在太不方便了点，还是应该把这种静态配置信息的都放在xml格式的描述文件中，脚本中应该只有动态的逻辑。所以还需要修改。 今天又忘了，wxWidgets的程序如果使用Lua扩展，而扩展又装载wxLua的话，wxLua的二进制文件不能用和wxWidgets程序相同的wxWidgets二进制动态链接库，不然会出现各种奇怪的问题。这是让我目前比较头痛的问题。我现在是用MinGW来编译wxWidgets和相关工程，那么一来wxLua就只能用VC或其他编译器编译了，但我今天试了OpenWatcom和Borland C++ 5.5，连wxWidgets都编译不过，郁闷！
今天是重阳节，据说要登高，这个习俗我是去年才知道的。突然想起去年的情景。 去年十一的时候嫌无聊，开始参加网上组织的户外活动组织，一个月要出去2-4次，而像重阳登高这种是纯娱乐休闲级别的，那次是下了班转了几次车最后还是打车去的集合地点的。 时间过得真快啊，就这么一年过去了！
这是这三天来忙碌的成果，其实实打实只有近一天的时间是花在这个上面了。前天差不多提交了50个，昨天休息了，今天则是差不多提交了90个左右。本来说是一个150的列表，其中有重复的，有需要back link的，有类型不合适的，还有其他一些原因的，最终没有提交成功的，所以估计最后的总数在140左右。 今天开始就新的内容了，嗯！
原本我提交的时候，都是老老实实一项一项地填写软件信息的，虽然也知道有PAD，还装过个自动生成软件，但一直没用上。今天突然觉得应该多提交些网站，于是从cnsw论坛里找了批下载站的地址，开始提交，猛然发现大多数站点是只接受PAD方式提交的，于是没办法咯，只好老老实实生成各个PAD，再提交。 不过这样下来，发现用PAD提交，既然没有软件自动提交，纯粹人肉也不是很费时间啊！
昨天跟一个以前的同事在QQ上聊天，说到他有朋友是卖电脑的，问有没有什么软件可以OEM的。想到要OEM，必然要大众，要傻瓜，要新潮。于是我随便想了想，倒也不是真想去OEM，只是最后想到AV类的软件，实在是极其巨大的市场！ 于是我又发散思维地想了想，最后觉得这类型的产品是有利可图，而且网上代码和成品软件很多，开始涉足的技术难度应该不是非常大。 唉，为了快速圈地，只好先投身AV事业了！
