今天8月15日，距离过来封闭开发一个月了，wmlscript的运行环境算是做完了，由于扩展的库函数也不多，所以工作得以提早一点完成。
比较有成就感的地方在于，这次除了脚本文本=>字节码的过程需要借助gateway的代码之外，字节码的执行环境部分完全是自己设计和编写代码的。
也经过了性能测试和功能测试，而在180M主频的ARM上计算WML Script脚本的MD5算法，只需要90个毫秒左右。
当然，在设计上的瑕疵还是存在的，导致在内存回收上有些不够完美的地方，不过经过一番修补，测试中已经不存在内存泄露的问题了。
对比一下流行的浏览器中用来执行javascript和方式与字节码执行wml script的方式：
javascript的执行是按照文本来进行逐行执行，而wml script则是预编译成字节码，然后像虚拟机一样执行。
从这个角度看，当然是字节码的执行效率更高了。当然，如果把javascript也进行预编译，执行效率应该也是可以的，只不过，编译过程所消耗的时间也会体现在页面加载过程中，这必然会令用户感到不爽。
记得2006年的时候，我还在pax，当时VP Thomas接到一个伊朗的订单，需要POS机上显示菜单和打印文字都是法斯语（Farsi）。
其实我是一点基础都没有的，除了在胡烈的时候认识一个北大阿拉伯语的助教mm之外。
不过还是接了下来。
Farsi语是阿拉伯语的一个变种，在28个字母的基础上增加了4个字母，一个32个字母。阿拉伯语的单词一般由3个字母组成，字母的书写与它所处于单词的位置有关，最多的是有四种：独立，与后连接，与前连接，与前后皆连接。这四种情况的宽度是不一样的。因此，如果在程序中直接打印字符，其宽度不一致会导致出现断裂的空白，而我们知道阿拉伯语都是一条一条的。
由于POS上面的显示点阵和打印点阵的API都是具备的。所以我的想法是基于这些显示点阵和打印点阵的接口去做一个显示和打印中东字符的接口。
剩下就是几个步骤：
1.生成点阵，我是从微软的windows系统中，选择了一款专门用来打印中东字符的字体（具体名称忘了），然后在VC中按照各个字母处于不同位置去生成图片，然后采集成字符点阵。采用一种自描述的数据结构去描述该点阵属于哪个字符的何种位置，宽度如何等等。
2.API封装，将输入的字符串进行分析，判断具体属于哪些字符的何种位置，然后从点阵中取出，拼接成一个长的点阵图，最后调用显示/打印点阵的API与操作。
3.因为API是交给应用开发人员去进行开发的，所以还要培训他们如何在开发环境里把某个Farsi字符串输入到代码中。
整个系统做下来，学习、设计和编码花了两周，测试花了两天，文档写了我两周。然后我偷懒再拖了一个月交货……
