All Stories

划分脚本插件架构的职责面临的问题

划分脚本插件架构的职责面临的问题

  今天整理了一下项目中使用的第三方框架、库的列表,很多,有C++的,有Lua的,突然面临一个迫切需要解决的问题:怎么决定某个功能应该由C++实现还是由Lua实现?  最早决定让项目成为一个由C++构建主体框架,由Lua脚本扩展实现其他的业务逻辑时,只是单纯得想让C++完成一部分最核心的功能。但现在的问题是,怎么判定一个功能是否够核心,以及即使够核心了,还得考虑其他一些因素,包括实现难度,安全保护,代码架构合理性,代码和逻辑共享等。  众所周知,用不同的语言实现相同的功能,难度和工作量可能差别很大。以前听同事和领导不止一次说起过,一行脚本顶得上一百行C++代码。这也许有点夸张的成分,但正好说明差异巨大这个事实。引起这种差异的主要原因就我自身角度出发来看,在于对语言的掌握程度,不同的语言风格就对不同开发任务的适应度,以及可利用的现成的库和代码的丰富度和成熟度。  说起安全保护,是今天看到Lua的maillist上讨论LuaJIT时Mike Pall说起源代码保护时才提醒了我。一般说来,用C++编写的代码,经过编译生成二进制代码,比起用脚本语言写的代码生成的字节码(中间码)反编译要困难得多。而我本来考虑让众多功能都通过脚本实现,这就面临一个问题,如何保护自己觉得重要的代码。最早的时候想用Lua的官方编译器编译一把就行了,现在看来这个保护弱得可以。而最近又面临另外一个短期内不可能解决的问题是,我打算嵌入LuaJIT 2.0的解释器,而刚刚才知道LuaJIT 2.0不兼容Lua官方的字节码,只提供源代码级的兼容,似乎LuaJIT也没提供一个自己的编译器,同时即使有这样的编译器,万一某种情况下需要用Lua官方编译的文件,那么处理就不一致了!Mike Pall的意见是,用个zip之类的东西打包加密就行了,呃,怎么说,确实是个方案,但使得本方案只能自己使用的了,不能让第三方的开发者参与了!所以除非有其他比较完善的解决方案,不然那样的代码只能用C++实现了。  再说架构合理性,总的说来,到目前为止的进度,自我感觉这样的架构还是比较满意的,当然现在只是一个空壳,只能支持让主菜单、工具栏按钮和右键弹出式菜单的构建和触发都是由脚本插件扩展而成,接着就而对的问题是,像配置选项功能要由谁来做,这种功能有一定的复杂性,又有GUI界面,又有后台处理逻辑,是全部让C++做,还是全部让Lua做,或者是各做一点,那又是各做哪些和各做多少呢?几乎所有同时涉及界面和后台逻辑的功能点,都有这样的问题,究其原因在于,用C++实现了主界面,而在Lua中目前并不能很方便地操作这些界面。原本天真地以为,C++用了wxWidgets做界面,那么Lua中用wxLua就可以实现无阻碍互通了。现实是残酷的,现在光是想让wxLua中使用C++中创建的主窗口作为父窗口就搞不定!  最后是代码和逻辑的共享。这个问题不是很严重,如果是纯粹的计算逻辑最容易共享,一些常用的底层功能,两种语言都差不多拥有第三方库来解决。除了GUI,其他的代码(逻辑)要共享,通过luabind和SWIG可以比较方便地粘合起来。如果粘合起来还是犹豫不决,那就是架构合理性的问题了。  想不到这次决定构建一个基于C++的脚本扩展框架的应用程序,会引出这么多问题,大大出乎我的意料啊,我是一直以来对风险的估计不足啊!

LuaJIT初体验

LuaJIT初体验

  偶然看到云风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应该还需要一段时间。

无奈啊,还是离不开VC

无奈啊,还是离不开VC

  之前说过,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次,而像重阳登高这种是纯娱乐休闲级别的,那次是下了班转了几次车最后还是打车去的集合地点的。  时间过得真快啊,就这么一年过去了!

提交了100多个网站

提交了100多个网站

  这是这三天来忙碌的成果,其实实打实只有近一天的时间是花在这个上面了。前天差不多提交了50个,昨天休息了,今天则是差不多提交了90个左右。本来说是一个150的列表,其中有重复的,有需要back link的,有类型不合适的,还有其他一些原因的,最终没有提交成功的,所以估计最后的总数在140左右。  今天开始就新的内容了,嗯!

提交也不很麻烦

提交也不很麻烦

  原本我提交的时候,都是老老实实一项一项地填写软件信息的,虽然也知道有PAD,还装过个自动生成软件,但一直没用上。今天突然觉得应该多提交些网站,于是从cnsw论坛里找了批下载站的地址,开始提交,猛然发现大多数站点是只接受PAD方式提交的,于是没办法咯,只好老老实实生成各个PAD,再提交。  不过这样下来,发现用PAD提交,既然没有软件自动提交,纯粹人肉也不是很费时间啊!