The complexity of software comes from two major sources, the complexity of the problem domain itself and the complexity introduced due to imperfection of implementation. As most discussions I found are focusing on the first one, which actually unavoidably mixes with the complexity from the latter one, I would like to focus on the latter one which contributes most to the quality of software from a software engineering perspective.

Entropy can be viewed as a measurement of disorder or ignorance. The latter one is quite helpful to understand the quality of software engineering. I would like to give a semi-definition of software engineering entropy here: assuming you are looking into an immediate context to understand how this context works, every time you have to leave your immediate context to seek some knowledge in order to understand how your immediate context is working, it signifies an instance of ignorance of your context and all instances of such ignorance thus determine the entropy of the context in question. This entropy is called software engineering entropy.

A few clarifications are needed for this interesting definition. First of all, this concept is not a completely new discovery. Software engineering has been a hot study area for the past decades. Many recognitions are obtained and new methodologies are being put into practice. This new concept will provide new insights into existing topics and hopefully improve existing methodologies for higher quality. Secondly, this definition has a strong dependency on observer. For example, an engineer who enters a new project will face maximum entropy because of the complete ignorance and the entropy will decline over time and stay around some value eventually. It's obviously true that the engineering entropy cannot be zero. But the stable value varies based on the engineer. This actually reflects the reality that more experienced engineering can grab key concepts and move forward with certain amount of ambiguity or entropy. Putting those two factors together, entropy comparison can be useful for one observer to measure two different projects. And also, for engineers who have stayed in one project for long enough, the average entropy could reflect the quality of the project. Thirdly, the complexity from problem domain could be a cause of engineering entropy. But this impact is decreasing when an engineer gets more knowledge of the core problem over time. Eventually and ideally no more ignorance from the problem itself. Lastly, it's true that the engineering entropy defined this way has not got practical ways to do real measurement. But high entropy areas could be identified according to the definition and improvements can be found accordingly.

Engineering entropy as a thinking tool
As stated above, this entropy is a new way to see how well engineering is done and we will study a few cases to demonstrate this. It should be emphasized that the entropy idea could be applied at quite different scales. It could be used to evaluate the quality of the implementation of one single function and it could also be used to evaluate the engineering process for a multi discipline engineering group.  We will see cases for both of them.

Case 1
Naming is an important factor for every careful engineer. Many have been discussing the importance of it and the confusions caused by it for years. I'm also one of them. But the arguing of confusions is more or less subjective as it's lack of a definitive answer. This will remain true regardless of what effort is put to resolve it. In this article, we want to discuss why bad naming is causing problem from the perspective of engineering entropy and how this entropy concept could contribute to the rationality of the everyday naming arguing.

Two typical arguments regarding naming problems are variable naming and function naming. Variable naming relates to maintaining invariant in the context of a function. The invariability maintained by the name allows engineers to understand its meaning in a clear way which does not require tracking how the variable changes its meaning in the code path. Thus, it does not require leaving current part of a function to find out the meaning of a variable and this avoids engineering entropy. Contrarily, all kind of bad names could be interpreted in two or more possible ways and when reading some line of implementation, engineer has to leave current context to find the real meaning and thus results in higher engineering entropy. Function naming is another hot area as the name of function is a representation of protocol between caller and callee. For the caller, the intention of making the call should be present in the caller part. It could be simply perceived from the function name or comment elaborating the reason. If one feels the need to go inside the implementation to understand why the caller is making such call, it signifies an ignorance and thus indicates higher engineering entropy. In this case, the name of function always plays an important role. From the callee's perspective, ideally the name of the function should cover no more and no less what the implementation is doing. This is hard to be maintained in everyday work and the bottom line should be that a function name should be specific enough that it could be easily distinguished from others. Putting them together, an experienced developer who has sufficient knowledge about the problem domains and the overall architecture, should be able to understand a problem in its local context. If this is not the case, the switching between contexts should be considered as evident of higher engineering entropy. An effort should be made to identify what is causing the ignorance and correct it so that understanding could be achieved easily. This could be also used as a definition of a good name. A good name should make sure that everyone works on the same codebase can understand what the variable or the function means in local context.

Case 2
We will now discuss the nonadditivity property of engineering entropy.  Suppose that there is a component K. The input and output of this component is very clear so that you can absolutely understand how K works by working with K as your immediate context. It means that component K has value 0 as its engineering entropy. This is definitely an ideal example but it fits this case study very well. There are 2 sub-components of K and let's call them A and B. It turns out that we want to take a closer look at A after understanding that K has an entropy of 0. By studying A, we find out that A is so hard to understand unless we have to know how B is working. The same thing happens to B. This is a situation that sub-systems A and B have a large value of entropy while the parent system K has an entropy of 0. This is the nonadditivity property of software engineering entropy. Such phenomenon is known to physicists as "quantum entanglement". In software engineering, we call it "coupling". While quantum entanglement is the building block of quantum computing, "coupling" is something we absolutely want to avoid in software engineering. This short case study demonstrates how we can use "engineering entropy" as a thinking tool to evaluate the patterns we can observe in everyday engineering work.

Case 3
In the last case study, I want to apply "engineering entropy" to a larger context, say a multi discipline engineering group. In such a group, there are a lot of feature teams who own different things in different layers of the final product. Nowadays, many groups are leveraging Scrum model as a development framework. Scrum model provides the possibility that things are changing in a fast pace. So it should not be surprising that one component layer is changing its implementation dramatically. But such flexibility inevitably introduces engineering entropy, as one's understanding of the dependencies are going out of date pretty soon. This is a topic in project management instead of software engineering as such ignorance is the result of the separation of engineering entities. By understanding the source of such entropy, it could be easily figured out that a careful management of such entropy is needed. One important way to reduce the entropy is to communicate changes in a clear way so developers are aware of them. When certain change starts causing issues, the information of "why and how" about the change should be immediately available, at least contact information should be available so that assistance of resolving the issues could be pursued as early as possible.
Another similar example is what could happen inside a feature group. As developers in the same group are focusing on different areas, the knowledge of the same component/system could gradually become out of date. As time goes, the entropy of the same component will build up and it could require more efforts to resolve it. A planned catch-up could help to reduce this entropy. A catch-up could be a formal one so that everyone in the team can focus on gaining more insights together or it could be informal so that individual developer can arrange his/her own catch-up in a way that fits his/her own flexibility. The key point is that this should be done with a clear goal in mind and the goal is gaining new knowledge of the product which has been changing for a certain period.

作为曾经流行的技术，COM已经渐渐远离了人们的视野。然而作为曾经以此谋生的我，还时常会想起它。特别是那个意味深长的接口，IUnknown。

这是一个非常有意思的设计。一个编程用的接口，回答的，却是每个人心中最深沉的问题。这个接口，只有三个API。一个叫AddRef，一个叫Release。这两个API回答的，是生与死的问题。另一个API叫做QueryInterface，它回答的，则是“我是谁”。

人们用天数计算着自己的生命，IUnknown使用引用计数来决定自己的去留。所以，也不奇怪人们把“AddRef”和“Release”称为“生命”周期管理。

而“QueryInterface”，则是一个接口区别另一个接口的标志。COM世界中，一切都是IUnknown，彼此的不同，便只由QueryInterface的不同的回答来决定。如果说“AddRef”和“Release”赋予了IUnknown生命，那么QueryInterface便赋予IUnknown不同的生存价值。由是，便有了你我之分。如果将接口，看成不同的职责，那QueryInterface区别的，就如同职场上不同的职位。如果讲接口看成生活中的不同角色，那QueryInterface所区别的，就是父母，兄弟，夫妻等不同的身份。

如果你对人生有更深的思考，也许会问，那“什么是我”。也许有人会说，“我是谁”和“什么是我”不是同一个问题吗？真的么？我们每天辛勤工作，在公司，是不同的职责，不同的分工。我是工程师，他是老板等等。这是“我是谁”，但都是工程师，什么才是区分你我的根本呢？即使是同一个工作，也可以不同的人来做，哪一个是我？我们追求的所谓个性，无论是简单的IRect，IElement，还是复杂如IOleDocumentView，哪一个是真正的我所独有？都不是。我们工作，不喜欢别人仅以职能或结果来评价我们，因为那不是真正的“我”。我们生活，朝九晚五，吃喝拉撒，久而久之，都会感慨缺少真正属于自己的一片天地。而那缺少的所谓“自己”，究竟是什么？QueryInterface回答的，或者说界定的，是我所有，不是我。关于这个“什么是我”的问题，COM世界给出了坦诚的回答。这回答，便蕴含在IUnknown的名字里：我不知道。

不知道，其实是个不错的回答。因为不知道，才使得IUnknown的继承者，无所不能。而IUnknown本身，则颇有道可道，非常道的意味。

这就是一个程序员，在养家之余，还很享受的阅读代码的一小段思考。

    其实计算机并不只是technical stuff。人对自身的思考，总会投射到别的事物上。

1.  如果你问计算机生命是什么？答案会很简单:

    while(1)
    {
        something without break and deadlock;
    }

     是呀，人们都称这个是“死”循环。其实呢，使得你的系统能够不停运转的idle，也不过就是这样的“死”循环罢了。所以，生与死并没有一个绝对的边界。正是这样的死循环，使得你的PC得到永生。相反地，任何正常的，非“死”的进程，都有终结之日。生死之交易，由此可见一斑。

    记得刚上初中的时候，老师作过这样的比喻。他说人类制造的其他工具是人类四肢的延伸，唯有计算机是人类大脑的延伸。那节课的主题就是“是电脑，还是计算机”。有人说计算机的神奇并不在于它的计算能力，而是因为它有判断的能力，而这也是作为工具的计算机区别于其它一切工具的特征。我并不反对这种观点。然而我更希望人们看到，循环是计算机中最具活力的地方。看看每一个Windows程序，哪一个不是都有其自已的“消息循环”。如果有coding基础的人都可以想一想，几乎每一个feature无不是处在一个或大或小的循环当中。循环往复，而非简单重复，计算的乐趣与人生的乐趣有了一个共同的落脚点。

     每一个人的生命，从他开始的一天就开始了各种循环。昼夜交替，四季轮回，是小循环；从小到大，从年轻到年迈，是每一个人要走过的大循环。循环，是人生共性的东西。所以回答生命就是如上的循环就不那么奇怪了。然而，每个人的生活都是不一样的。即使是朝夕相处的人们，也都有着属于自己的，与他人迥然不同的生活。而这正是因为每个人的循环当中，有着无数的if。每个人在相同的循环当中，走向不同的分支。对算法有了解的人来想一想，每一个让人感叹的优美的算法，不也通常就是这种循环中带判断的结构么？写算法的人和写小说的人都是在讲述一个不完全真实的故事，只是方法和载体不同罢了。人与人之间，真没有什么不同的地方。

2.  天下大同就是IUnknown。

    其实不只是人与人，世间万物都有相通之处，人们称这个过程叫做抽象。记得很多年前知道一种东西叫TObject，一个让人不太能找到感觉的名字。然而，当你见到IUnknown时，就不免浮想联翩了。在COM的世界里，所有的东西都源自IUnknown，而它只回答了三个问题：什么时间出生，什么时间死亡和“我是谁”。其实真的不只是人们会向天发问：“Who am I？”。你的计算机也在不停地呼喊：“QueryInterface”。是呀，生死总不是在自己的掌控之内，在一个人的逻辑世界里，生与死的问题只能是公理，这意味着你并不能对它说三道四。而“我是谁”这样的问题，却有着千万种的回答。也正是不同的回答，构成了丰富的世界。而万物的源头，永远都是Unknown。我不信上帝，但我勇于面对这个现实。

今天有个同事，被SysWow64搞晕了。这里简单介绍一下。

64位的Windows并不是简单地把所有东西都编译成64位就万事大吉的。关于64位的CPU应该做成什么样子，Intel和AMD曾有各自的打算。AMD的回答直接了当：新的64位处理器，应该能在提高更高处理能力的同时，保持对32位应用程序的兼容性。而Intel则希望借此机会，把下一代的处理器，设计得更完美。于是，就有了AMD的x86-64（后被称为amd64）的处理器和Intel的IA-64（安腾）处理器。和amd64不一样的是，安腾处理器并没有很好地提供对32位应用程序的支持。具体信息，读者在网上应该很容易找到，也就不多说了。

Windows作为一个操作系统，自然希望用户在运行64位操作系统时，也能像以前一样，运行各种32位应用程序。这一点，在amd64处理器上，相对容易做到。而安腾，几乎是另外一回事。（后来Intel也生产了兼容amd64的处理器，但那是后话。）

虽然我说“相对”容易做到，但也不是空手套白狼。当操作系统运行在64位时，怎么才能保证已经存在的32位应用程序以为自己仍然运行在32位系统上呢？微软的解决方案是：Wow64，全称是32bit Windows On 64bit Windows（64位Windows上的32位Windows）。

你也可以这样理解，虽然整个系统是运行在64位模式，但如果一个应该程序是32位的，Windows会在64位的基础上，加载一个“32位的Windows”。这样，这个32位应用程序就以为自己是运行在32位的系统之上的。

于是，你也可以想象，这就意味着，64位的Windows，不但带有64位操作系统应有的系统文件，还带有32位系统应有的系统文件。

我们都知道的是，Windows系统的主要系统文件都是放在一个叫做System32的文件夹中的。为了能同时放下两套系统文件，Windows会在64位的系统上，增加了一个文件夹，叫SysWow64。

这便有了一个问题，System32和SysWow64里面，哪个放的是64位的系统文件，哪个放的是32位的系统文件呢？

如果你还记得Wow64指的是64位Windows上的32位Windows，那么，你就能会想到，SysWow64里放的是32位的系统文件。但你也可能会问，为什么一个明明叫System32的文件夹装的是64位的系统文件，而一个明明叫SysWow64的文件夹装的却是32位的系统文件呢？既然是64位的系统，为什么不能有System64和System32这样的文件夹呢？

这个问题问得很好。答案也很简单：人在江湖，身不由己。

兼容性

如果我问你，可曾有多少机会接触过安腾处理器呢？我想，对于一般人来讲，应该是没有的。那为什么amd64会大行其道，而安腾处理器却鲜为人知呢？还是因为一个软硬件设计上的关键概念：兼容性。

正是因为安腾处理器，没有做好对已有的32位系统提供良好的支持，便其一直处于市场的边缘。这和你不会买一台看不了模拟信号频道的高清电视是一个道理。

之前我们谈到的兼容性，是指在64位Windows上，兼容已经有的32位应用程序。现在考虑另一种兼容性。

如果你写了一个很牛的32位的应用程序，现在，你想把它变成64位的应用程序，以更充分地利用64位处理器所带来的新的处理能力。你肯定觉得，这不就是让64位编译器编译一遍就完了的事儿么？可能你发现，这并不是骨感的现实。你突然发现，你的程序里，为了某些你已经想不起来的原因，把System32这个文件夹，写死在了你的程序里。而这个System32中的32，让你很不安。你尝试着运行了你的程序，却发现一切正常。为什么呢？因为这是Windows系统的另一个兼容性方面的努力：让一个已有的32位应用程序，不加修改或者尽可能少地加以修改，便可以被编译成64位应用程序并在64位Windows上运行。其实，把System32这样的路径，写死在程序里，并不是一个个案。所以，为了保证这些应用程序可以顺利地过渡到64位，Windows最后还是决定让64位的系统文件放在System32的文件夹下。而让32位的系统文件，搬到了SysWow64中去。

你肯定会想，那让32位搬到SysWow64中去以后，那些写死在32位应用程序中的System32怎么办？答：Windows会给他们转向到SysWow64中去。那让64位中的System32转向到System64不也是一样么？真的一样么？不一样么？真的一样么？不一样么？真的不一样。

作为64位Windows操作系统，当然是希望能充分发挥64位处理器的潜力，让应用程序更有效率地运行。如果在运行64位应用程序时，总要检查是否需要转向，势必影响程序运行效率。所以，不能给64位应用程序做没有必要的转向，如果说必须要转，那就只能转32位应用程序了。是的，没有办法，在64位操作系统中，32位应用程序要做一些小的牺牲。

此外，为了保证32位应用程序不与64位应用程序相冲突，除了System32文件夹外，注册表也需要为32位和64位提供两套，也需要让32位的应用程序在必要时重定向。

结论

所以SysWow64文件夹，是64位Windows，用来存放32位Windows系统文件的地方。

后记

兼容性是一个重要的事情。当然，也是一个很有意思的事情。如果你在Windows 7中运行"winver"，你就会发现，Windows 7原来是Windows 6.1。为什么呢？事情是这样的，Windows XP是Windows 5.2，Windows Vista开始变成了6.0，结果，很多应用程序只是检查操作系统版本号的头一位，发现不是5，于是就提示用户说：“我们不支持Windows XP以前的系统”。这也是从Windows Vista的不成功中，学习到的一课。也许，以后永远都没有Windows 7.0也未可知啊。

原文作者：James Pratt

SmartScreen团队刚刚告知了我，我们已经到达了一个令人惊喜的里程碑：IE8已经阻拦了10亿次恶意软件下载！

社会工程学攻击和恶意软件一样，是互联网上一个正不断增长的威胁，也是人们上网时最常见的风险之一。作为SmartScreen筛选器（英文链接）的一部分，我们在IE8中加入了恶意软件防护，并且在过去的一年中，已经在Windows体验blog（英文链接）中谈论（英文链接）过若干次（英文链接）了。

关于这10亿次阻拦，我们提供了如下简要的事实：

• NSS实验室在2009年8月（英文链接）和2010年3月（英文链接）的两份报告中，对IE8，Chrome，Firefox和其他浏览器进行了比较并认可IE8的SmartScreen筛选器在阻止社会工作学的恶意软件攻击方面，处于领先地位。
• 我们的恶意软件阻拦率不断提高也源于我们不断地改进SmartScreen的后台服务。 比如在2009年8月，我们已经阻止了7千万次恶意软件下载（英文链接）——或者说每月阻止1千8百万次。在那时，根据Net Application的统计，大约15%的互联网用户使用IE8。在过去的两个月中，我们已经阻止了1亿次恶意软件下载。上个月，根据Net Application的统计，大约有26%的互联网用户使用IE8。和2009年8月相比，IE8的用户增长了1.7倍但我们每月阻止的恶意软件下载已经变成了之前的5倍。

10亿将恶意软件拦截是一个惊人的里程碑。它同时也证明着两件事：第一，社会工程学攻击，比如恶意软件，仍然是互联网用户的真正威胁。第二，为保证你的在线安全（英文链接），你的浏览器需要不断地改进并加强其服务。正是因为我们在2009年3月发布IE8之后仍不断地在后台服务方面进行投入，才使用SmartScreen筛选器能在阻止恶意软件方面做得越来越好。正是这样的投入，使得我们保持在社会工程学恶意软件图表（根据NSS实验室）的最上方。这项投入，已经保护了用户的在线安全。

如果你还没有升级到IE8，现在你就可以通过登录www.microsoft.com/ie来升级。如何你已经升级到了IE8，你可以检查SmartScreen筛选器是否已经打开。方法是：选择“安全”菜单，单击“SmartScreen筛选器”。如果菜单显示的是”关闭SmartScreen筛选器“，那说明SmartScreen筛选器已经打开。

原文作者：James Pratt，高级产品经理

原文来自：Internet Explorer Business and Marketing Team

（译者注：我正尝试以更有文采的方式翻译此后的技术文章，如有与原文冲突之出，以原文为准。本译文不代表IE官方观点。特此声明，永远有效。)

      当我们开始深入地接触HTML 5时，我们便感觉到其必将开拓一系列新的应用。而这些应用也必将以不同于今天既有的方式，对浏览器及硬件提出更高的要求。我们很快便认识到，正确实现HTML 5——我们最开始的初衷——更多的是关于如何设计支持HTML 5新应用的浏览器子系统，而不只是一组新的功能罢了。所以从一开始，我们给IE9规划的目标便是：通过Windows，基于先进的硬件系统，打造专业级别的，现代的，对HTML 5的支持。

      在今天（译者注：美国西部时间2010-3-16，下同）的MIX大会（英文网站）上，我们展示了那些开发人员已经了解并广泛使用的标准网页模式，如何在Windows上的IE9中利用计算机硬件更出色地运行。这一篇博客将提供我们今天所展示的内容的概况，其包括：性能、标准、硬件加速的HTML 5图像及面向开发人员的IE9平台预览版就绪信息。

      首先，我们展示了IE9的新脚本引擎——内部称之为“轮”（英文Chakra，见百度百科Chakra和七轮）。与此同时，我们也展示了在一项JavaScript性能基准测试中所取得的进展。通过把脚本引擎在基准测试中的差距区别缩小至一眨眼的工夫，我们借此诠释了我们是如何让真实的网络运行得更迅速。Chakra会以和IE并行的方式，在后台使用独立的CPU内核编译JavaScript脚本。

      我们致力于使基于标准的HTML，脚本和格式化标记（formatting markup）可以跨浏览器工作。我们分享了可以说明我们使上述目标得以实现的数据和框架，并展示了对若干标准更好的支持，这包括：HTML5， DOM和CSS3。我们展示了IE9最新的Acid3得分：55。随着我们不断地追求行业标准被制定时的目标——使开发者真正使用的标记（markup）在各浏览器中工作，我们的Acid3得分必将不断提高。我们已经向标准组织提交了测试用例，这是我们承诺参考标准流程的一部分。我们已经将这些测试用例公开，任何人都可以用来在任何浏览器上尝试。

      我们通过若干实例，向大家展示了具有丰富图像的交互性的网页可以获得的，来自浏览器的性能上的巨大提升——当这个浏览器通过操作系统充分利用PC硬件能力时。同样的HTML，脚本和CSS标记可以跨浏览器工作，且在IE9上自然而然地更快速地运行——因为IE9使用了硬件加速。IE9还是第一个提供SVG硬件加速的浏览器。

      最后，我们宣布第一个面向开发人员的IE平台预览版已经就绪，并保证我们将每8个星期左右，提供一次更新。我们希望开发社区可以更早地亲身体验我们在IE这个平台上所进行的工作。与以前的IE发布相比，平台预览版及其反馈标志着IE发布工作的一个主要变化。

性能

      IE9有一个新的JavaScript引擎，“轮”。这里有一张图，展示了IE9在一项特定的JavaScript性能基准测试，Webkit Sunspider，中的表现：

      你可以注意到，在这项基准测试中，IE9比IE8和其他一些浏览器更快。值得指出的是，IE9预览版和在其右边的浏览器的差别很有意思：我们需要大约70秒才能识别出这300毫秒的区别。

      随着我们使IE9的脚本引擎在真实的网站中执行得更快，IE也将会在这一特定基准测试中表现得更好。到目前为止，我们几乎没有针对Webkit Sunspider进行任何的优化。和大多数的基准一样，测试结果可能随机器的不同而得出不同的结果。

      我们在浏览真实网站时所体验的性能，相比起JavaScript，更多地取决于浏览器的其它子系统。比如，一些网站会花更多的时间布局其页面或渲染，而不是运行脚本。在这个博客贴（英文IE博客，未翻译）里的第一张图表用数据表明了这一点。今天的PC拥有特定的硬件来加速图像性能。IE9使用广泛应用的硬件来加速网页中的所有文字和图像，从而使网页显示得更快。

      为了进一步提高JavaScript的性能，“轮”做了一些和其他脚本很不同的事。“轮”使用一个单独的后台线程来编译JavaScript。如果有一个单独的CPU内核可用，Windows将使用它并行地执行此线程。后台编译将使得IE可以在生成更快的代码的同时，让用户不中断地浏览和使用网页。因为是在后台单独运行，这样的工作流程，可以充分利用今天的多内核机器——所以，拥有Core2Due，QuadCore，i7或者Phenom II的用户已然可以拥有使网页显示得更快的能力。

      对于开发人员来讲，无需更改其网站的任何内容，便可得到现代PC硬件所带来的性能提高。用户则拥有更少的等待，更多的交互——就像一个本地程序一样。这样的设计使得已经在众多真实网站中应用的网络开发模式，获得更好的性能。而这些的关键就在于把最好的技术，带入到开发者所使用的最重要的语言，JavaScript，当中去。

标准

      标准和互操作性的目的是使相同的HTML，脚本和格式化标记在不同的浏览器当中一样地工作。消除为不同浏览器写不同代码的需要可以使每一个人受益，也会带给开发人员更多的机会从事创新工作。

      许多标准仍在不断完善。他们要么还只是草案，要么被不同的浏览器以不同的方式部分地实现。开发人员正面对一个艰难的选择：他们需要更加努力地工作，写更多而且不同的HTML，脚本和标记，只是为了在不同的测量员中得到相似，而并不总相同的结果。

      我们希望相同的标记真的能在不同的浏览器中有同样的结果。在IE9中，我们继续完善我们的平台，正如我们在IE8中为CSS 2.1所做的一样。IE8提供了一个高质量的CSS 2.1的实现，坚持标准又兼顾其他浏览器在标准不明确之处的行为。开发人员可以期待业界为此有更多的努力以使HTML5的应用更容易开发。

      我们在这方面的努力是从数据开始的。开发人员真正使用的DOM（Document Object Model，文档对象模型，译者注）和JavaScript API是IE9标准支持方面的基准。为了得到这些数据，我们开发了一个工具，用以检验7000多个最常见网站的API使用情况。这里有一个分布图表，表明了每一个API被多少网站所使用。我们会在以后的博客中讨论这些数据的更多的细节。

       我们致力于完成每一项出现在上述数据中的业界标准。在IE9中，你也会看到我们支持了一些并没有出现在上述数据中的标准——那是因为我们需要提供一个完整HTML 5应用所必须的一切。

       在这里需要提及的主要技术包括HTML 5， CSS 3， DOM和SVG。IE9 测试驱动网站（英文网站）上面有更详尽的内容和样本。目前为止，我们期待开发人员关于以下实现的反馈：HTML 5的解析规则，Selection API，XHTML支持和在线SVG。至于CSS 3， 我们期待以下方面的反馈：Selectors， Namespaces，Colors，Values，Backgrounds和Borders，以及Fonts。关于DOM，我们期待以下方面的反馈：Core，Events，Style和Range。

       有些人使用Acid 3检测标准的支持程度。Acid 3测试包括了一系列不同技术的100个细节。有一些还处于“建设中”。而有些模式，比如SMIL动画，和HTML 5的部分内容，如CSS 3动画，相矛盾。这些是还需要进一步完善的地方。这里是今天的IE9平台预览版执行现在的Acid3测试的截屏：

      在标准以及某些开发人员真正使用的部分标准方面，随着IE向着“同一个标记”的行业目标不断接近，Acid 3得分也必将自然而然地得到提升。我们致力于网络标准的一个重要组成部分，便是开发行业标准用的系统的测试用例。目前为止，微软已经提交为HTML 5， CSS 3， DOM和SVG向W3C提交了100多项测试。你可以从这里（英文页面）尝试部分已经提交给W3C的测试。

      作为标准化流程的一部分，微软和标准化组织共同努力，创建全面的测试。我们将我们的测试用例提交给适合的讨论组，然后作为讨论组的一部分，和其它浏览器提供商一起合作，创建合理的、准确的、全面的测试用例系统。今天，仍然存在太多的情况，使得开发人员不得不去使用不同的HTML，脚本和格式化标记，却仍得不到一致的结果。来自标准组织的全面的测试用例系统将会帮助开发人员和网络行业本身。

GPU驱动的HTML 5

       HTML 5应用需要强大而快速的脚本和不同浏览器之间“同样的标记，同样的结果”。优秀的HTLM 5应用将基于这样的基础并走得更远：给用户提供游戏般的交互和电影般的丰富图像。

       现在的标准化的网页和众多的浏览器，在这方面所能做的还非常有限。这是因为他们只能使用PC硬件和操作系统提供的所有功能的一小部分。HTML 5应用必将需要的更多。

       为满足对这些应用的期待，IE9使用了Windows系统中先进的图像API和PC的硬件，来加速所有在屏幕上显示的文字和图像。这里有一个简单的示例（英文页面）：一个小巧的页面，显示一组运动的图片，并使之追寻鼠标指针。

       请注意，运行同样HTML，脚本和标记，IE9提供更快速的响应及每秒钟更多的桢数。今天的许多网站，会花费很多的时间在屏幕上绘制各种实体，正如上文所提到的那样。

       IE9是第一个提供完全由硬件加速的SVG支持的浏览器。IE9的开发人员工具，同样支持SVG。我们很兴奋地想看到开发人员在这样一个高效且内部一致的平台上，在现代的硬件（英文页面）上所进行的创造。我们会在将来的博客中深入讨论SVG。

IE预览

       今天，我们宣布第一个面向开发人员的IE平台预览版已经就绪，并保证我们将每8个星期左右，提供一次更新。与以前的IE发布相比，平台预览版及其反馈标志着IE发布工作的一个主要变化。

       有了平台预览版，开发人员可以更早的接触到我们在IE平台上所开展的工作。平台预览，直接提供给开发人员一个更好的论坛用来分享和讨论。更早期和更经常的平台预览版的发布，加上我们与标准组织的合作，我们对行业标准测试的开发，以及这样一个开放的社区讨论，这一切都反映了我们对网站发展的承诺。

      在MIX大会上，我们展示了对HTML 5 video的支持——这将在后续的平台预览中呈现。此外，我们还展示了HTML 5 video（使用特定的H.265 720p高清编码标准）如何通过操作系统，利用先进PC硬件进行视频解码以拥有出众的性能。

      如果你是一名开发人员或者对技术抱有热情，请下载平台预览版。这也是对如何使开发人员已知且广泛使用的网站标准利用PC硬件在Windows上更好地运行的第一次预览。

      上周，Channel 9访问了团队中的一些工程师。访问视频可以从以下地方找到（以下皆为英文内容）：

介绍IE9平台预览
GPU驱动的HTML 5
IE9性能：从JavaScript到COM到DOM到HTML 5
SVG：网络矢量图像的过去，现在和未来

谢谢，

原作者：

Dean Hachamovitch
General Manager, Internet Explorer

我只希望读者能觉得我的翻译有用。至于有益，甚至有趣，却是不敢奢望。如果读者见到译得不妥之处，还望不惜赐教。

如果读者希望我翻译哪篇IE的博客，也请告之。我尽力而为。

（译者注：由于时间关系，没有办法将图解完全翻译——因为我太希望开始翻译关于IE9的内容。如有关于IE博客翻译或相关技术文章翻译的请求、建议及意见，欢迎留言。如留有联系方式，我会在必要时联系留言者，谢谢！）

本文将讨论IE8如何确定用以渲染网站的文档模式，如怪异模式（又称IE5模式）和标准模式（更多资料，英文：https://en.wikipedia.org/wiki/Quirks_mode）。该内容对于开发人员和客户来说，是很重要的。

与此相关的，是我们最近更新的兼容性视图列表。此列表内容自从去年3月IE8发布以来，已经减少了1000多个网站。从最初的3100多，减少到了现在的2000多一点。在与网站开发人员及标准制定人员的共同努力下，我们很高兴地看到需要出现在兼容性视图（CV）列表中的网站不断地在减少。

数据驱动的设计

在讨论设计细节之前，我想和大家分享一些我们用于设计兼容性体验的数据。

让我们来看一下世界范围内的上千个高流量网站，如qq.com和netlog.com，以及那些最初列入兼容性视图列表中（英文资料：兼容性视图列表）的网站的doctype（wikipedia英文资料，百度百科，CSDN社区）和X-UA-Compatible meta标签和头部：

• 26%的网站指定使用怪异模式，如果amazon.com，tworld.co.kr和unibanco.com.br。
• 41%的网站使用了Transitional文档类型，即准标准模式（mozilla英文资料）。
• 14%的网站已经添加了X-UA-Compatible meta标签或HTTP响应头，从而使用IE7标准模式进行渲染。

以上的数据是可以理解的：许多高流量网站需要在尽可能多的浏览器中渲染，这就是为什么他们会使用怪异模式。许多网站有专门针对IE7的页面而且许多网站创作工具，如Aptana Studio（英文网站）和Expression Web，则默认指定使用Transitional文档类型：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

如果考虑一下网络的规模，那么将有几十亿的网页，分别指定使用怪异模式，IE7，准标准模式，或最新的标准模式。IE需要支持所有这些网站以确保世界范围内的用户拥有最好的体验。

有这些数据在手，我们设计IE8时考虑到了以下一些原则：

1. 默认情况下，使用最标准的方式渲染网页。
   如此前（IEblog英文，未翻译）的帖子（IEBlog英文，未翻译）所明确的，我们致力于互操作性，这便意味着默认情况下，使用最标准的方式渲染网页。
2. 用户只是期待网页在IE中正常工作。
   一小部分用户将需要改进那些在IE7标准模式中工作得最好的网站，以便使其可以工作在IE8的最标准的默认模式中。至于其他所有人，IE8提供了兼容性视图设置（IEBlog英文，未翻译）。
   
   在这里，最好的用户体验是一切自动地如网站设计者希望的那样工作。这就是为什么我们提供了兼容性视图列表（MSDN英文资料）。与此同样重要的是，用户可以通过兼容性视图按钮，修复那些尚未加入列表中网站。
3. 网站开发者完全掌控他们的内容如何被渲染。
   X-UA-Compatible meta标签和头部会覆盖IE和用户的设置。他们也使网站开发者可以细粒度地调控如何在IE中渲染每一个网页。
   
   比如，有些网站拥有一些专门为怪异模式写的网页，而另一些则为IE7标准模式。当IE收到的X-UA-Compatible头的值为EmulateIE7时，便会相应地以怪异模式或IE7标准模式进行渲染。
4. 给网站开发者以工具和时间，帮助他们转换到IE8标准模式。
   IE8引入了X-UA-Compatible meta标签和头部，这便给网站开发者提供了时间以转换到IE8标准模式。正如上文提到的，许多网站已经使用了这些机制来指定他们的内容必须使用IE7标准模式。

IE8如何确定文档模式的图解

给定了以上的原则，这里有四条规则明确了IE如何处理文档类型（doctype)，X-UA-Compatible meta标签和头部，开发人员工具，以及兼容性视图设置。这些标准自上而下出现在下面的图解中。

1. 开发人员工具的设置会覆盖一个标签（tab）中所显示的页面的全部文档模式。
2. X-UA-Compatible meta标签及此后的头部，覆盖兼容性视图设置和文档类型（doctype），除非X-UA-Compatible的值是EmulateIE7或EmulateIE8。
3. 用户的兼容性视图设置（IEBlog英文，未翻译）会覆盖微软兼容性视图列表（MSDN英文资料）。
4. 如果没有上述规则中的任何一种可以适用，则有文档类型（doctype）将决定网页使用以下哪一种模式进行渲染：IE8标准模式，IE8准标准模式，或怪异模式。

兼容性和互操作性是很复杂的。为了降低开发人员和用户使用的复杂度，我们希望看到更多的网站淘汰旧式的浏览器模式。我们也尊重网站开发人员对模式的选择。我们很高兴和网站所有者及标准组织成员继续（IEBlog英文，未翻译）提高（IEBlog英文，未翻译）IE的（IEBlog英文，未翻译）互操作性标准的实现。

非常感谢Jesse Mohrland对图解的检验。

原文作者：

Marc Sibey

Program Manager