Introduction to software engineering entropy

Software engineering entropy vs software entropyWhen I started thinking about this topic, I planned to name this blog “Some new thoughts on software engineering entropy”. After doing some searches and studies, I realized that there is actually no such thing called “software engineering entropy”.  All the studies are carried out focusing on “software entropy”, which,…

1

一个很有哲学意味的接口设计

工程和哲学,通常很难联系到一起。现实生活中,也确实如此。但如果能在忙碌的工程中,拿出一些时间,也可以在繁杂的代码中,看到一丝哲学的火花。   作为曾经流行的技术,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本身,则颇有道可道,非常道的意味。   这就是一个程序员,在养家之余,还很享受的阅读代码的一小段思考。

2

戏说计算机与哲学

转一篇2005年写的东西     其实计算机并不只是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。我不信上帝,但我勇于面对这个现实。

0

用Surface写博客

好久没有更新我的技术博客了。2012年12月12日,领到了公司承诺的Surface RT。初次尝试感觉不错。决定尽力更新技术博客。正在思考新的内容,会尽快赶上。

0

什么是SysWow64

Wow!什么是Wow64 今天有个同事,被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也未可知啊。

8

IE8 SmartScreen筛选器的一个重要的里程碑

原文链接(Windows团队blog):http://windowsteamblog.com/ie/b/ie/archive/2010/07/23/internet-explorer-8-smartscreen-174-filter-reaches-important-milestone.aspx 原文作者: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

0

硬件加速的HTML 5:第一个IE9平台预览版就绪(面向开发人员)

(本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/03/16/html5-hardware-accelerated-first-ie9-platform-preview-available-for-developers.aspx) (译者注:我正尝试以更有文采的方式翻译此后的技术文章,如有与原文冲突之出,以原文为准。本译文不代表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应用所必须的一切。       …

1

技术文档翻译并不轻松啊

本以为三天可以完成的关于IE9的第一篇博客,竟然用了近一个月的时间。而且,对于遣词造句,也没有能做到我当初想像中的那样精致。不过也感觉到了一些翻译的乐趣。那就是用不同的语言,表达相同的情感——即使文字上相差很多,却微妙地表达了同样的内容,语气和情感。 我只希望读者能觉得我的翻译有用。至于有益,甚至有趣,却是不敢奢望。如果读者见到译得不妥之处,还望不惜赐教。 如果读者希望我翻译哪篇IE的博客,也请告之。我尽力而为。

1

IE8 如何确定文档模式

(本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx) (译者注:由于时间关系,没有办法将图解完全翻译——因为我太希望开始翻译关于IE9的内容。如有关于IE博客翻译或相关技术文章翻译的请求、建议及意见,欢迎留言。如留有联系方式,我会在必要时联系留言者,谢谢!) 本文将讨论IE8如何确定用以渲染网站的文档模式,如怪异模式(又称IE5模式)和标准模式(更多资料,英文:http://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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 如果考虑一下网络的规模,那么将有几十亿的网页,分别指定使用怪异模式,IE7,准标准模式,或最新的标准模式。IE需要支持所有这些网站以确保世界范围内的用户拥有最好的体验。 有这些数据在手,我们设计IE8时考虑到了以下一些原则: 默认情况下,使用最标准的方式渲染网页。 如此前(IEblog英文,未翻译)的帖子(IEBlog英文,未翻译)所明确的,我们致力于互操作性,这便意味着默认情况下,使用最标准的方式渲染网页。 用户只是期待网页在IE中正常工作。 一小部分用户将需要改进那些在IE7标准模式中工作得最好的网站,以便使其可以工作在IE8的最标准的默认模式中。至于其他所有人,IE8提供了兼容性视图设置(IEBlog英文,未翻译)。 在这里,最好的用户体验是一切自动地如网站设计者希望的那样工作。这就是为什么我们提供了兼容性视图列表(MSDN英文资料)。与此同样重要的是,用户可以通过兼容性视图按钮,修复那些尚未加入列表中网站。 网站开发者完全掌控他们的内容如何被渲染。 X-UA-Compatible meta标签和头部会覆盖IE和用户的设置。他们也使网站开发者可以细粒度地调控如何在IE中渲染每一个网页。 比如,有些网站拥有一些专门为怪异模式写的网页,而另一些则为IE7标准模式。当IE收到的X-UA-Compatible头的值为EmulateIE7时,便会相应地以怪异模式或IE7标准模式进行渲染。 给网站开发者以工具和时间,帮助他们转换到IE8标准模式。 IE8引入了X-UA-Compatible meta标签和头部,这便给网站开发者提供了时间以转换到IE8标准模式。正如上文提到的,许多网站已经使用了这些机制来指定他们的内容必须使用IE7标准模式。 IE8如何确定文档模式的图解 给定了以上的原则,这里有四条规则明确了IE如何处理文档类型(doctype),X-UA-Compatible meta标签和头部,开发人员工具,以及兼容性视图设置。这些标准自上而下出现在下面的图解中。 开发人员工具的设置会覆盖一个标签(tab)中所显示的页面的全部文档模式。 X-UA-Compatible meta标签及此后的头部,覆盖兼容性视图设置和文档类型(doctype),除非X-UA-Compatible的值是EmulateIE7或EmulateIE8。 用户的兼容性视图设置(IEBlog英文,未翻译)会覆盖微软兼容性视图列表(MSDN英文资料)。 如果没有上述规则中的任何一种可以适用,则有文档类型(doctype)将决定网页使用以下哪一种模式进行渲染:IE8标准模式,IE8准标准模式,或怪异模式。 兼容性和互操作性是很复杂的。为了降低开发人员和用户使用的复杂度,我们希望看到更多的网站淘汰旧式的浏览器模式。我们也尊重网站开发人员对模式的选择。我们很高兴和网站所有者及标准组织成员继续(IEBlog英文,未翻译)提高(IEBlog英文,未翻译)IE的(IEBlog英文,未翻译)互操作性标准的实现。 非常感谢Jesse Mohrland对图解的检验。 原文作者: Marc Sibey Program Manager

0

Adobe Flash现已支持InPrivate浏览

本文系IE博客之翻译。原文请见:http://blogs.msdn.com/ie/archive/2010/02/11/adobe-flash-now-supports-inprivate-browsing.aspx Adobe Flash现已支持InPrivate浏览     作为一款浏览器,IE也是一个支持各种各样加载项(add-on)的平台(这里有一些很不错的实例)。IE使用者通常在涉及性能,稳定性或隐私性的时候,并不将加载项和IE本身区分开。大家都只是使用IE并希望其正常工作。这就是为什么那些最棒的加载项可以和IE很好的集成并让用户只是“浏览”。     最近,Adobe宣布他们最新的Flash已经支持InPrivate浏览。现在,Flash版本10.1将会响应我们在IE8中加入的接口。当你浏览一个包含Flash的网站时,Flash可以保存“Flash Cookies”。“Flash Cookies”是一些由Flash创建的,网站可以用来保存数据的文件。现在,就如同IE的浏览历史和cookie一样,这些Flash文件也会在InPrivate浏览窗口关闭时被删除。     我们非常高兴看到Flash集成了InPrivate浏览功能,而且很高兴地看到他们也同样支持Firefox和Chrome中的隐私浏览。好样的,Flash团队! 原文作者: Andy Zeigler Program Manager   相关内容: InPrivate浏览: Internet Explorer 8 隐私浏览 加载项:加载项资源库

0