在Linux下使用网银的几种可能的途径
Qian Hong
1. wine + MSIE
2. wine + builtin IE
3. wine + Chrome for Win + npactivex
4. wine + MSIE + Chrome for win + IE tab
5. wine + builtin IE + Chrome for win + IE tab
6. CrossOver plugin + Chrome for Linux + npactivex
7. Chrome for Linux as Browser + Winelib + Chrome for win as plugin host
名词解释：MSIE指代微软的IE，可能是IE6，IE7，IE8，IE9 等等； builtin IE是指wine社区开发的开源版本的IE仿制品，核心是gecko
下面我分别介绍我了解的情况。
第一种方案基本可以排除，因为：
* 根据我在第一封邮件中提出的目标，我们希望能够推动标准技术的发展。使用wine+MSIE，仍然脱离不了非标准技术。而在后面我将向大家证明存在其他可能成功的路径。
* 更严重的问题是，wine + MSIE的路线很难实现，这受到了法律方面的限制。
* Wine的开发者都非常注重版权相关的法律问题，因为开发wine有被微软告的风险，所以wine社区绝对不接受任何反汇编代码/泄露代码以及其他可能有风险的逆向工程技术，只接受黑盒分析的结果。已经有人因为反汇编windows
dll的代码而被wine社区拒绝
* 目前Wine+MSIE有很严重的bug，而在不逆向工程的情况下调试这些bug是非常难的，所以这些bug一直留着没有修复
* 使用体验不好，用户日常开着firefox或chrome，使用网银的时候不得不切换浏览器，还会带来cookies丢失等问题
第一种方案尽在特殊情况作为调试和比较的时候有价值。
第二种方案，wine builtin IE，没有法律问题，但是builtin IE要兼容MSIE，工作量很大，我们需要提交很多bug
report。我已经提交了一些，但是目前看不到尽头。
并且，同第一种方案一样，这种方案也对于推动标准化技术没有帮助。同样，这种方案的体验也很不好。
第三种方案 wine + npactivex + chrome for win，我在工行上已经实验成功。但有一些问题：
* chrome 和 wine的变化都非常快，特定版本的chrome和wine的组合比较好，但是一更新就出问题。我提交了一些bug，有一些已经解决，但有的遥遥无期。
* 同样存在需要切换浏览器的问题。
第四种方案，理论上可行，不过太蛋疼了。越多”中间层“，越多问题。不考虑，只供闲得蛋疼的人茶余饭后娱乐。。
第五种方案，同上。
第四和第五我在特定版本的wine和chrome上部分成功过。
总结前面5种方案，造成这么多麻烦的原因主要是：
* activex控件是win32 dll， 是PE32格式的可执行库
* Chrome for Linux是 ELF32格式的可执行库
* Linux上的动态链接器无法装载PE32库
* 即使我们hack了动态链接器，让它能装载dll，那么由于该dll需要调用win32
api，仍需要进一步导入别的dll，最后我们将不得不hack整个wine，这已经变成浙大网新的longene兼容内核项目了
* Linux上的图形句柄和Windows上的图形句柄不一样
为了比较完美（其实很无奈~）地解决这些困难，还有 6和7这两种方案
第六种，CrossOver plugin + Chrome for Linux + npactivex
Crossover plugin 是一个代理，可以让Linux native Chrome加载win32 dll
* crossover plugin 有一个PE32格式的pluginserver.exe和ELF32格式的fake_plugin.so
* Chrome for Linux 可以加载fake_plugin.so
* fake_plugin.so唤醒 pluginserver.exe
* pluginserver.exe 运行在wine创建的进程空间中 ， 而fake_plugin.so在另一个进程空间中
* pluginserver.exe 有能力加载dll，fake_plugin.so 和pluginsrver.exe 通过rpc调用，
把浏览器的函数调用转发给 dll， 把dll的函数调用转发给浏览器
这种途径虽然不完美，但有一些很大的优势，比如不需要切换浏览器，以及可以迂回地推动网银的跨平台和标准化。
详细的情况我会在后面的邮件中解释
第七种，Chrome for Linux as Browser + Winelib + Chrome for win as plugin host
Chrome中，plugin host 和 Browser的渲染进程本来就是独立的，互相直间通过rpc进行通信，
那么，我们是否可能通过一个wine的plugin host来加载dll，而通过linux原生的Chrome进程作为浏览器的其他部分呢？
* 这种方法的工作量很大，而且如果我们没办法说服上游chromium社区将我们hack的结果合并到主分支中，那将来维护的工作量巨大无比。
我对于chromium社区接受这样的hack感觉不乐观。不知Chrome团队的Kun Hu和其他朋友有什么意见？
* 这种方法只支持chrome，为了支持firefox又得做同样的工作
* 技术上，有个叫做winelib[1]的东西，可以编译出混合win32 api和Linux
api的怪胎二进制文件，有助于解决Chrome for win as plugin host 和 Chrome for Linux
之间的rpc问题
（注，winelib无法解决在linux原生进程空间中加载win32 dll的问题，这个问题很容易被误解，如果有需要我在后面会写一点我的理解）
除了以上7种，肯定还有其他的技术路线，折腾永无止境，折到蛋疼就不好了。太不靠普的我们可能就没必要在这里讨论了，不过如果大家有更好的想法千万要提出来交流 :)
先写到这，接下来写一封邮件介绍crossover plugin。 祝大家愉快~
[1]http://www.winehq.org/docs/winelib-guide/index
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/