I choose PRAGMATIC.

那么为什么GOOGLE需要呢？

因为Google是一个服务器密集型企业，要管理好数量如此巨大（目前保守估计100万台）的机器，需要一个合适的解决方案，因为硬件基本上要做的改动很小（只要避免大规模掉电和天灾），所以确切说Google需要一套强大的分布式计算软件平台。这是一个崭新的平台，名字不重要，重要的是一个新平台，我们暂且可以称之为云。

这个平台最大的优点除了提供海量存储，海量计算能力和简单的管理性以外，我认为最最重要的是容错性，也就是说任何一台机器坏了，对使用者没有影响。为什么这点最重要呢？以我们管理几千台服务器的经验来看，网络故障，硬盘故障，操作系统故障，软件故障每天都在发生，但是量不大，一天几起而已，但是想想Google，每天可能几千起，这样的硬件故障量，如果没有一套超级容错的机制，恐怕很难应对。就像早期的晶体管计算机一样，每次只能运行几分钟，因为每几分钟必然有一个晶体管会坏掉，这是无法避免的。这也是为什么晶体管计算机会被淘汰掉。

传统的分布式软件构架对于Google要做的事情，就好比晶体管之于早期计算机，虽然可用，但是只是凑活可用。为了解决这一根本上的矛盾，Google在工程上大胆的采用了全新的分布式结构，将冗余作为主要因素来解决。结果就是Google开发的这些系统。

说了Google为啥需要这样的结构，回到开头的答案，为什么我们不需要呢？

1. Google的软件系统对于我们来说开发成本很高，时间和金钱成本都很高

2. 大量的硬件冗余，可能带来硬件成本的上升，对于利润率不能跟Google相比的公司，有一些风险

3. 最根本的，因为我们每天的故障很少，只要我们的结构能够及时发现故障，然后人工能快速解决还是可接受的。归根到底，这套软件结构最适合的是故障密集型的应用，而不是机器密集型。几千台还远不属于这个范畴。

Google的伟大之处在于他在几万台机器的时候看到了几百万台的未来，因此在硬件的供电，软件的容错上进行了巨大的工程尝试，当他的服务器增长到百万台的时候，他依然能够轻松应对。

我们将来会有上百万台机器吗？不会，几十万台呢？也不会。几万台呢？这个很有可能。故障量是现在的10倍，也许多雇10个人就可以解决这个问题，因此到时候答案可能还是NO。

这款游戏，除了单一的美术元素比较精细。其它方面一无是处。

画面整体感差，手感差，实时移动战斗都感觉很差。

玩起来，似乎比战斧OL要差。

做3D的理由：收购Macromedia的时候有个Director产品，支持3D，收购之后有一点点小动作，让这个产品增加了Mac的支持，支持了DX9，支持了物理引擎，支持了JS，支持了SWF，也就是Adobe有了一款跨平台的支持3D的开发工具和播放器。Director是一个猛兽，可能是一个比Flash更加凶猛，Adobe要驯服它需要更多的时间，也许Director会是一个独立的Flash 3D版本，支持Flash和所有3D相关。

支持3D的遐想：

1. 收购Audodesk，或者收购其它任何一家3D工具开发商，那么毋庸置疑，Flash一定会支持3D的。

2. 收购Unity3d，或者收购其它3D浏览器插件，现在看来Unity3D最靠谱了，它的产品趋势跟Adobe最接近了，支持多种OS，多种浏览器，这不正是Flash做的吗，甚至支持iPhone。甚至有人开发了u3dobject，可以通过Flash在浏览器中通过JS控制unit3d控件。Unity3D和Adobe还有点关系，前面提到的Director当前的产品经理现在就在Unity3d工作。

3. 跨平台也做了（Win/Max/Linux/WM/Symbian/Palm/RIM/Android/iPhone），跨浏览器也做了（IE/FF/Opera/Chrome），跨浏览器和桌面（Flash/AIR），H264都支持了，作为一款客户端技术，除了3D还有其它配得上Adobe身份的事情吗？

设置了这两个选项，所有默认的std::string都是本地编码的多字节字符串，SexyString是utf16编码的宽字符字符串

SexyApp内部对中文的处理是针对wstring的，因此可以认为基本没有问题，只需要修改显示相关代码和字符串的入口代码即可，举几个例子

1. 字体

默认的SysFont用的是ANSI_CHARSET，会导致无论创建什么中文字体都是宋体，需要将ANSI_CHARSET改为GB2312_CHARSET，这样设置的字体才有效

2. 中文输入

比如EditWidget中，处理paste的时候，调用的是

SexyString aBaseString = StringToSexyString(mWidgetManager->mApp->GetClipboard());

这是有问题，需要将GetClipboard的结果用MultiByteToWideString转换为wstring

此外，EditWidget对于默认输入的字符有一个uTheChar<=range的判断，而range的最大值是255，对于中文显然不适用，去掉即可。

3. 其它类似问题，按照以上方案修改即可

比如下面这个奇怪的对话框便是其中之一。

---------------------------
Microsoft Visual Basic
---------------------------
File not found: 'C:\WINDOWS\system32\ieframe.dll\1'
---------------------------
确定   帮助  
---------------------------

问题据种种迹象推断，是VB6太老了，微软已经不支持了，一个IDE用了10多年，已经是奇迹了。VB6与IE8(IE7可能也存在)有些不可调和的冲突，虽然可以通过在VB中注册shdocvw.dll而不是ieframe.dll来部分解决，但是还是会遇到奇怪问题。

最终的解决方案，虚拟机+干净XP+IE6。

这里有一些相关文章，包括游戏和历史的分析