前几天重操旧业，为了做测试又装了个windows xp的kvm虚拟机。一年没碰过这东西了，明显忘记了一些细节，比如安装完系统后，发现VNC中的鼠标走得总是比本地系统中的鼠标要慢，不同步，往往实体机中的鼠标都移出vnc窗口外边了，虚拟机中的鼠标指针还没移到需要点击的位置。

为此在网上找了半天，也没只找到一种法子：

在控制面板中选择鼠标设置，在指针设置中去掉“提高鼠标灵敏度”的选择。

试用了下，只解决一般的问题：此时，虚拟机中的鼠标和实体机中的鼠标运动速度同步了，但是默认在打开VNC之后，虚拟机中的鼠标指针和实体机鼠标指针不重合。每次都必须努力移动鼠标指针到VNC边上，把实体机和虚拟机的鼠标指针弄得重合了，才能正常使用。

我突然想到，我们的业务系统中用的kvm虚拟机怎么就没有这问题呢？马上在virsh下查看了下业务系统中虚拟机的配置，才发现，这些虚拟机在输入设备中加了这么一句：

   <input type=’tablet’ bus=’usb’/>

（该句位于<devices>配置中）

我不想讨论前几年的宏观调控措施是否正确，因为过去的事情已经过去，再论也于事无补。我想要讨论的是当下应对危机的实用手段，这要讲求可行性、可操作性，不能过于理论化、理想化。我的观点以及推理逻辑基于如下两条“公理”（我的世界观中的公理，呵呵），如果这两条公理您不认可，那就不需要继续往下看了。

1. 任何国家、政府都会追求社会稳定，即使奥玛·美帝也是这样。因此当自身或者外部环境发生大变动的时候，政府应该出台补偿政策，使得变化趋于缓和。这就跟生病了就要打针吃药，天冷了就要加衣服是一个道理。

2. 小时候在教课书里看到万恶的资本家宁可把牛奶倒入河里，也不肯分给穷人，感到十分气愤。长大了，学会从资本家的角度去考虑，觉得这么作对于他们来说或许利益是最大化的。现在我认为，从社会财富角度去讲，这无疑是一种巨大浪费，应该尽力避免。

一、讨论方法。经济学、金融学通常以货币——就是钱——作为研究对象，然而我认为有时候从很宏观的角度去思考问题时，绕过货币，直接考虑财富可能更容易看清本质。这里的“财富”是指人所需要的各种物品如粮食、衣服、房子、计算机、各种服务等等，不特指金银珠宝。货币只是社会财富分配的辅助工具，是表面现象，而财富才是人所需的本质东西。因而在考虑宏观问题，特别是国与国之间的问题时（不同货币），直接考虑财富有时是一条捷径。

二、中美财富关系。中国在这两年俨然已成为世界工厂，中国生产物质财富，出口到美国并赚取外汇；美国向中国借美元，然后购买财富并消费。中美之间的财富关系就是财富从中国净流出到美国，累积价值已超过2万亿美元。这个关系可以比喻为：A(merica)先生很能干，但是生活奢侈，一直靠C(hina)先生救济过日子；C先生勤劳朴实，宁可自己缺衣少食，也笑着把最好的东西借给A先生以维持他的生活标准。直到有一天，A先生决定要改变一下生活方式。

三、双方危机的实质。如今借钱的是孙子，欠债的是爷。美国危机的本质（主要矛盾）是债务太多，那么接下来自然的处理办法之一就是勒紧裤腰带，勤奋工作，自食其力，增加储蓄。美国自食其力，必要要显著减少进口。中国危机的本质（主要矛盾）是出口受阻，外贸企业面临倒闭。简单地说就是人家不要我们给他打工了，我们被炒鱿鱼了。最理想的办法是出口转内销，给自己人以“最惠国民”待遇。然而这个转变需要时间，甚至个别产业可能无法转变。这个过程是个大课题，在此就不深入讨论了。

四、中国应对危机。由于出口锐减，是外部环境的突变，根据公理1，政府应该出台补偿性措施，以缓和冲击，避免相关产业出现工人大量失业。于是提高出口退税、结构性减税、XX下乡等措施相继出台。但是这些还不够，因为再怎么补贴也只能救急，出口量最终一定会减少的。为了进一步补偿出口下降的影响，同时也尽量避免让产品、产能闲置浪费，国家应该大力投资，以消费这些产品。

为了避免大量失业，工厂就要开工，产品就要有销路。当前只有政府来充当这个“冤大头”买入这些产品，比如钢铁、水泥。那么买入之后呢？根据公理2，闲置浪费当然不如修路架桥，即便这些路在10年之内都没有多少人走，也比水泥闲置结块，钢铁闲置生锈强！

许多人担心这些投资的收益问题，担心投资几万亿成为坏账。其实这些观点都是从基于货币的资源、财富分配角度考虑的，而如前所述，货币只是表象。在浪费货币（坏账核销）和浪费财富（产品废弃）之间，我们当然毫不犹豫地选择浪费货币。

货币是什么？就是一张小纸片，甚至连纸片都不是，就是数据库中的一条记录而已。这样的投资并不会带来通胀，因为整个外贸业并没有得到更多的货币，相反还在不断萎缩；国内的物质财富也没有减少，而且增加得更快（出口转内销）。通胀是什么？就是货币相对财富变多，或者财富相对货币变少。

（上半年的天量信贷目的为何我并没有太清楚，财政不够？转移支付？烘托股市楼市？支持国进？避免大量企业被国外收购？或许都有吧。）

五、未来之路。当出口产能过剩的问题基本解决，推动国民最终消费增长才能成为主要矛盾。投资、出口、消费三架马车现在坏了一辆，现在只能指望投资和消费。政府在危机爆发的瞬态响应是增加投资弥补出口量跌以及提高退税补贴出口盈利，但长久之计还是要增加消费，因为各国危机之下，贸易保护主义必将抬头，补贴出口不可持久，而且政府主导的投资效率较低。提高国民最终消费，就牵扯到两个问题：1要让群众有更多的钱来消费，2要让群众无后顾之忧地消费。这是两块硬骨头，前者要减少政府和企业所得的蛋糕份额，后者要解决教育、医疗、住房三座大山，不知道D要如何作为，但可以肯定这是一个长期的过程。中国政府是一个中央集权的强势政府，估计即使到达了稳态，政府投资的比例也仍然会较高，因为政府有钱有意愿。

本来写完了，突然又想起一个“妙招”：把居民消费作为官员考核指标即可，呵呵，GDP指标取消还不能取消，要稳定，稳定。

Ogre的全称是面向对象的图形渲染引擎（Object-oriented Graphics Rendering Engine），它直接支持从文件系统或者zip档案中加载资源，同时也支持用户自定义档案格式。我基于StormLib为Ogre添加了MPQ格式支持。如图1所示，在Ogre中新增档案格式需要扩展ArchiveFactory、Archive和DataStream等几个类，具体来说，我新增了MpqArchiveFactory、MpqArchive和MpqDataStream三个类，其中工厂类（MpqArchiveFactory）用于向档案管理器注册（未画出），同时告诉管理器新增档案的类型（"Mpq"），并提供相应档案类的创建、销毁函数；档案类（MpqArchive）代表实际的MPQ档案，它提供了档案内的文件查找、元信息查询以及文件打开的功能；文件打开后得到的是DataStream的派生对象（MpqDataStream），负责文件内的数据读取工作。 这三个新增类的具体定义如图2所示。

图1 Ogre中的档案模块理结构

图2 Mpq档案相关类的类图

由于MPQ档案内不包含文件名和路径名，我目前的实现要求所打开的档案内必须包含"(listfile)"文件，并从中读取文件名全集，并排序以便于后续检索。由于Archive中的find(), findFileInfo(), list()以及listFileInfo()函数的功能较为相似，我实现了一个filter()函数，用于从文件名全集中按需过滤出指定子集，同时还实现了一个details()函数，用于添加文件详细信息。这两个函数的适当组合便能实现上述四个函数的功能。由于MpqDataStream类功能较为简单，基本上是直接调用StormLib中的相应功能，完全实现只用了20余行代码。

Ogre自带了一个读取Quake3地图(zip档案)的例子。我用现成工具将pk3档案转换为MPQ格式，并修改该例配置文件，读取MPQ文档成功。有截图为证（其加载过程和地图漫游）：

小花絮：Stream中的陷阱 

MpqDataStream的实现过程让我走了许多冤枉路。当我快速实现这个类之后，实际运行却会导致一个访问异常的错误。这个错误发生在Ogre内部，我没有装Ogre源代码，无法精确定位错误，只能猜测可能的原因。由于Stream类、Factory类都很简单，所有函数都不超过3行，在目测“无误”后我就紧盯MpqArchive类的实现。由于MPQ文件是平板模式，在物理上没有目录树的结构，而Archive类假定档案是有结构的，我起初怀疑问题出在文件名和路径名的处理上，然而经过仔细编写并多次重构之后问题依旧，一筹莫展。尝试了debug、release两套配置，都报告错误。

在无奈之际，我又尝试自己编写一个针对文件系统的档案读取套装，实际上就是重新实现了FileSystemArchive系列类。由于这个套装十分简单并且与MPQ档案无关，这个尝试可以快速验证我对Ogre档案格式扩展机制的理解是否正确、全面。结果证明问题果然在这里——我的文件系统档案套装引发了完全一样的错误。

虽然明白错误在这个区域，但仍然无法知道究竟是那里疏忽了。我明白我需要查看故障处的源代码，然而SDK不但没有源代码，而且没有提供PDB（程序的debug数据库），只能重新编译，自己生成。在一通下载、编译、调试和分析之后，终于发现了原因：BSP场景管理器打开了BSP地图，然而却没有从我的MpqDataStream中读出数据，并在没有检查是否读出的情况就使用了“数据”，最终导致访问违例。而之所以未能从MpqDataStream读出数据，是因为DataStream父类中的保护成员mSize没有赋值（默认为0），导致DataStream误认为数据流的长度为0。最终，在MpqDataStream类的构造函数中设值正确的mSize值，解决问题。

一般来说，我在继承类的时候，会比较注意其中的虚函数，尤其是纯虚函数，认为这些是留给我用的钩子。但我以为保护型（proected）成员（尤其是保护型数据成员）一般是可选钩子，或者是留给我的福利，而不应为强加给我的责任。这种角色最好以纯虚函数的方式表达（模板方法模式），这样我一眼就看出我必须做这件事。更为要命的是，我再次查阅Ogre API Reference的时候，发现它并没有说这个mSize必须要设值，只说默认为0。

MPQ是一种针对读取优化的文档，与其他格式（如zip）相比，它最大的特点是没有树形结构，甚至连文件名都不保存。在存取时，它将文件的全路径名称做两次不同的哈希：h1 = hash1(pathname)、h2 = hash2(pathname)，并将这两个哈希值作为索引信息。由于将路径文件名整体作为字符串计算哈希值，整个MPQ包构成平板模式，在物理上没有目录结构。在检索文件时，由于不需要逐级深入目录，MPQ包的读取较为简洁高效。

MPQ是一种古老的包格式，现有许多第三方工具可以读写这种格式，其中很多都公布了源代码，甚至形成了专门的读写库。我找到的各个MPQ相关库总结如下：

名称（标配工具）	作者	备注
Storm.dll	Blizzard	Diablo I附带的Storm.dll可被其他工具调用。
StormLess MPQ Editor	Tom Amigo	提供VC6源代码。最新版本发布与2000年。
StormLib (MPQEditor)	Ladislav Zezula	由Marko Friedemann将其移植到Linux平台。
Libmpq (MPQ-tools)	Maik Broemme	似乎只支持Linux。
SFmpq.dll (WinMPQ)	ShadowFlare Software	SFmpq.dll由VC++编写，WinMPQ应用由VB4编写。
MPQlib (MPQMaster)	Quixotic Yawl Studio	没有找到源代码，不过从它暴露的语言扩展接口来看，似乎是Delphi写的。

Ladislav Zezula同志的StormLib成为使用毫无疑问是Windows平台下C++程序访问MPQ包的最佳选择。我将StormLib的使用心得以要点形式总结如下：

1. 所有的API函数、常量定义、结构体定义都可以在StormLib.h中查到，Zezula的主页上也有大部分函数的介绍，在此就不copy & paste了。

2. 读取文件所需函数：SFileOpenArchive()、SFileCloseArchive()分别为打开、关闭MPQ文件；SFileOpenFileEx()、SFileCloseFile()分别为打开、关闭MPQ包中的文件；SFileReadFile()读取实际数据，隐含解压缩过程。

3. 一个关于FilePointer的小陷阱：SFileSetFilePointer()函数用于设置文件指针，类似于C标准库中的fseek()函数，然而SFileGetFilePos()并不是返回文件指针，而是返回该文件在MPQ包中的物理位置。要得到当前文件指针位置，仍然需要SFileSetFilePointer()函数，将文件指针相对当前位置移动0，其返回值则为当前指针位置，如：

virtual size_t tell() const
{
	return (size_t)SFileSetFilePointer(m_hFile, 0, NULL, FILE_CURRENT);
}

virtual bool eof() const 
{
	DWORD pos = SFileSetFilePointer(m_hFile, 0, NULL, FILE_CURRENT);
	DWORD size = SFileGetFileSize(m_hFile);
	return pos>=size;
}

5. StormLib还提供了创建MPQ包、写入文件、包内搜索文件等功能，本文从略。