有{間}客栈

之前写过几篇文章介绍Windows 7中Ribbon界面的开发，随着Windows 7的发布，Ribbon界面成为一种趋势。这周，CodeProject就Ribbon界面做了一个调查，看看程序们对Ribbon界面是爱是恨》

The Windows 7 Ribbon. Love it or Loathe it?

Survey period: 9 Nov 2009 to 16 Nov 2009

Do you like the Windows 7 (formerly Office 2007) Ribbon or do you loathe it?

Option Votes %  
I love it 208 19.85 
I like it 324 30.92 
I'm ambivalent or don't have an opinion 254 24.24 
I don't like it 149 14.22 
I can't stand it 113 10.78 
Total 1048   100%

从结果来看，半数参与调查的人对Ribbon界面抱着欢迎的态度，其中有约20%甚至是Love的程度。只有约10&的人比较讨厌Ribbon界面，看来是程序员中比较守旧的一部分。

v从结果上分析，微软在Windows 7中推出的二代Ribbon界面还是比较成功的，能够被多数人说认同和接受，Ribbon逐渐成为一种趋势，不再是一个空洞的口号。想当初，我写下Ribbon界面会成为趋势的时候，还在担心自己会成为历史的笑话呢。这些有些放心了。

实际上，我个人也是比较接受Ribbon界面的，虽然开发起来更麻烦。

“帅哥，你有没有年薪100万?”

　　“Of cause，当然，sure!”

　　“不好意思，我只跟年薪100万以下的人聊天。”

　　以上只是一个笑话，这位妹妹嫌富爱穷很是让人肃然起敬。在软件世界，也有很多应用程序有着嫌富爱穷，喜旧厌新的“美德”。他们只能在旧的操作系统上运行，面对新的操作系统，它们死活不愿意正常运行，不是默默无语地退出就是给个“不支持操作系统”的提示。妹妹们嫌富爱穷可以，应用程序们喜旧厌新就不好了。

　　操作系统版本检查带来的兼容性问题

　 　无论是普通用户还是应用程序开发人员，在他们将应用程序运行到新的操作系统时，他们遇到的最普遍的应用程序兼容性问题是，应用程序检查操作系统版本失败 所带来的应用程序对新操作系统的不支持。操作系统版本检查本来是为了确保应用程序所需要的某些操作系统特性确实存在，有了这些操作系统特性，应用程序才可 以正常运行。当操作系统版本检查被滥用的时候，很多兼容性问题由此而产生。用户可能会遇到应用程序在加载的时候，悄无声息地退出而没有任何的信息提示。或 者是，用户可能会看到一个类似“此应用程序必须在Windows XP或者是其后的操作系统上运行”的错误提示对话框。但是，事实上这台计算机的操作系统是Windows 7，当然是在Windows XP之后了。错误或者说是低劣的版本检查，会给用户带来极大的不便。

　　通常，应用程序因为操作系统版本检查而失败有两个原因：

　 　• 在版本检查的代码中有Bug。在主版本号增加，次版本号减小的情况下，例如，将版本号从5.1变化到6.0，或者是某个期望的补丁(service pack)没有安装，甚至你在运行一个更新的操作系统(例如，从Windows XP SP3升级到Windows Vista SP1)，这些情况都会导致版本检查会失败。

　　• 应用程序开发人员特意设计的版本检查行为，阻止应用程序在未经过足够测试的新操作系统上运行。但是，我们建议你不要阻止应用程序在更新的操作系统上运行。 除非最终用户许可协议禁止应用程序在更新的操作系统上使用，否则应用程序不应在操作系统版本号增加的情况下无法运行。如果应用程序无法运行，则必须向用户 发送消息，并向日志写入一条消息，然后正常退出。

　　当一个应用程序在“不兼容”的Windows版本上运行的时候，它可能会显示一个错误 消息，也可能悄无声息地退出或者是无法正常工作。通常，如果我们解决了版本检查的问题，它就可以正常工作。当遇到这种问题，最终用户或者是IT管理员可以 简单地使用Windows 7的XP兼容模式，或者是微软所提供的应用程序兼容性工具集(Application Compatibility Toolkit (ACT))，对应用程序进行操作系统版本“欺骗”，让应用程序认为他还是运行在较旧的Windows版本上，从而解决版本检查的问题，让应用程序在 Windows 7上正常运行。这里需要注意的是，兼容模式仅仅适用于使用非托管代码进行的操作系统版本检查，对于托管代码中利用 Environment.OSVersion或者是通过P/Invoke使用GetVersionEx进行的操作系统版本检查并不适用。

　　图1 Windows 7的兼容模式

在上文中，我们介绍了操作系统服务的Session 0隔离，通过Session 0隔离，Windows 7实现了各个Session之间的独立和更加安全的互访，使得操作系统的安全性有了较大的提高。从操作系统服务的Session 0隔离尝到了甜头后，雷德蒙的程序员们仿佛爱上了隔离这一招式。现在他们又将隔离引入了同一个Session之中的各个进程之间，带来全新的用户界面特权隔离。

　　用户界面特权隔离

　 　在早期的Windows操作系统中，在同一用户下运行的所有进程有着相同的安全等级，拥有相同的权限。例如，一个进程可以自由地发送一个Windows 消息到另外一个进程的窗口。从Windows Vista开始，当然也包括Windows 7，对于某些Windows消息，这一方式再也行不通了。进程(或者其他的对象)开始拥有一个新的属性——特权等级(Privilege Level)。一个特权等级较低的进程不再可以向一个特权等级较高的进程发送消息，虽然他们在相同的用户权限下运行。这就是所谓的用户界面特权隔离 (User Interface Privilege Isolation ，UIPI)。

　　UIPI的引入，最大的目的是防止恶意代码 发送消息给那些拥有较高权限的窗口以对其进行攻击，从而获取较高的权限等等。这就像一个国家，原本人人平等，大家之间可以互相交流问候，但是后来坏人多 了，为了防止坏人以下犯上，获得不该有的权利，就人为地给每个人划分等级，等级低的不可以跟等级高的说话交流。在人类社会，这是一种令人讨厌的等级制度， 但是在计算机系统中，这却是一种维护系统安全的合适方式。

　　UIPI的运行机制

　　在Windows 7中，当UAC(User Account Control)启用的时候，UIPI的运行可以得到最明显的体现。在UAC中，当一个管理员用户登录系统后，操作系统会创建两个令牌对象(Token Object)：第一个是管理员令牌，拥有大多数特权(类似于Windows Vista之前的System中的用户)，而第二个是一个经过过滤后的简化版本，只拥有普通用户的权限。

　　默认情况下，以普通用户权限启 动的进程拥有普通特权等级(UIPI的等级划分为低等级(low)，普通(normal)，高等级(high)，系统(system))。相同的，以管理 员权限运行的进程，例如，用户右键单击选择“以管理员身份运行”或者是通过添加“runas”参数调用ShellExecute运行的进程，这样的进程就 相应地拥有一个较高(high)的特权等级。

　　这将导致系统会运行两种不同类型，不同特权等级的进程(当然，从技术上讲这两个进程都是在同一用户下)。我们可以使用Windows Sysinternals工具集中的进程浏览器(Process Explorer)查看各个进程的特权等级。 (http://www.microsoft.com/technet/sysinternals)

　　图1 进程浏览器

　　下图展示了以不同特权等级运行的同一个应用程序，进程浏览器显示了它们拥有不同的特权等级：

　　图2  不同特权等级的同一应用程序

　　所以，当你发现你的进程之间Windows消息通信发生问题时，不妨使用进程浏览器查看一下两个进程之间是否有合适的特权等级。

阅读全文：VS与Win7 共舞：用户界面特权隔离

【IT168 专稿】“小陈，再把你的项目策划书给我发一份!你昨天发给我的我找不到了!我记得保存在C:\Users\Win7 \Documents\Office 2010\项目策划书\陈良乔\草稿\这个目录下了啊，怎么找不到了?难道是在D盘的D:\文档\W7项目\项目文档\策划书\陈良乔\草稿\下?”

　　“喂喂喂，QQ客服吗?我找不到QQ接收的文件了啊，刚刚好友发给我的文件在哪里啊?”

　　“老婆，我们去年去重庆旅游时照的照片在哪里啊?我怎么找不到了?”

　　——计算机里面的文件越来越多，我们置身于茫茫的文件海洋，该怎么办?

　　为什么要引入库(Library)的概念

　　在以往的Windows操作系统中，我们总是以树状结构的方式来组织和管理我们计算机上的各种文件和文件夹。我们往往根据文件的内容或者类型将他们分别保存在不同的目录下，从而一层一层嵌套形成树状结构。但是随着硬盘容 量越来越大，计算机上的文件数量越来越多，同时由于树状结构的先天缺陷，这种组织文件的方式开始变得无法满足我们日常的需要了。单一的一种树状结构的分类 方式，无法满足文件之间复杂的联系。比如，当你在准备一份计划书的时候，你将文档保存在文档相关的目录下，同时，你将文档中的各种插图保存在图片相关的目 录下，在这种情况下，当你要查看修改文档中的某张图片时，你需要在文档目录图片目录之间跳转切换，为我们的工作带来很多不便。又比如，你是一位高清电影爱 好者，收藏了很多电影，这些电影分别按照树状结构分类存放在你的硬盘上的各个分区，如果现在你想找到某部电影，就需要在各个分区，各个目录之间查找，费时 费力。

　　为了帮助用户更加有效的对硬盘上的无数文件进行更加有效的管理，微软在Windows 7中提供了新的文件管理方式：库(Library)。作为访问用户数据的首要入口，库在Windows 7里是用户指定的特定内容集合，和文件夹管理方式是相互独立的，分散在硬盘上不同物理位置的数据可以逻辑地集合在一起，查看和使用都更方便。引入了库的概 念后，我们就可以将这两个相关的文件夹组织到同一个库下，比如我可以将我的所有视频整理到视频库中，这样我们在查找电影时就方便多了，只需要在视频库中进行查找，就可以很快地找到相关的内容了，虽然这些文件保存在不同的硬盘位置，不同的文件夹下。

　　
图1 Windows 7中的库

　 　本质上，库的概念的引入，不是来解决文件的分类问题的，这个问题在文件夹时代已经解决了，库解决的是分类方式不唯一的问题。还是上面视频库的例子，一部 电影，我们可以按照风格分类，也可以按照演员分类，还可以按照产地分类，如果是文件夹的方式，这部电影我到底该放在哪个文件夹下呢?库的诞生，才能使分类 真正做到严格。对于计算机中的各种资源，往往是有很多种分类方式，同时各种资源之间又有复杂的关联关系，在特定的应用环境中，采用特定的分类方式才能获得 最好的工作效率。而库可以对分类方式进行完全的自定义，一个库基本上就代表了一种分类方式，可以满足人们对文件进行复杂分类的需求。

阅读全文：VS与Windows 7共舞：库(Library)

【IT168专稿】在之前关于Visual Studio 2010的新特性介绍文章中，我们已经喊出了“全体程序员注意：Ribbon全面来袭!”的口号。在这里，我们不再去强调Ribbon界面的易用和高效， 也不去强调和证明它将成为未来应用程序界面的一种趋势。为了让我们的应用程序“Ready for Windows 7”，我们有必要根据实际的情况需要，为我们的应用程序添加Ribbon界面。

　　在前面的文章中，我们介绍了如何为MFC应用程序添加 Ribbon界面，但是这种方法只适用于基于MFC的Windows应用程序。如果我们的应用程序是标准的Windows应用程序该怎么办呢?为了推广 Ribbon界面，为了讨好程序员们，让程序员可以轻松地为各种应用程序创建Ribbon界面，微软真是不遗余力，不断地推出新的Ribbon界面接口。 为了可以让所有基于C++的普通Windows应用程序都可以添加Ribbon界面，微软在Windows 7 SDK中，又推出了基于COM的接口——Scenic Ribbon API。

　　利用Scenic Ribbon API，我们可以更加灵活方便地为各种Windows应用程序添加Ribbon界面，改善应用程序的用户体验。在接下来的文章中，我们就介绍一下如何利用这种新的方式为普通Windows应用程序添加Ribbon界面。

　 　我们都知道，Ribbon界面是随着Office 2007一同发布的。在过去的几年中，微软不断地吸取用户对Ribbon界面的反馈，不断地对其进行改进，到了Windows 7，微软正式加入了命名为Scenic Ribbon的第二代Ribbon界面，即取代第一代Ribbon的升级版本。随着Scenic Ribbon成为Windows 7的一部分以及微软所提供的Scenic Ribbon API，这意味着今后第三方程序开发者能在自己开发的应用程序中免费用上这种界面形式。Scenic Ribbon作为第二代Ribbon界面，所适用的是所有的Windows应用程序，和前代有所不同是理所当然的。例如，由于最初Ribbon界面是 Office专用，因此使用Ribbon界面的Office 2007程序窗口左上角都有一个比较显眼的Office图标按钮。当应用到其他程序之后，这个图标显然不能继续存在，因此在Scenic Ribbon中，这个位置就被相应应用程序自身的图标所取代。另外，为了满足各种应用程序的需要，Scenic Ribbon还添加了部分Ribbon控件，使得Ribbon界面的控件更加丰富，能够应对各种应用程序对Ribbon界面控件的需要。值得一提的 是，Office作为Ribbon界面的开山鼻祖，到了Office的下一个版本Office 2010，也全面使用了Scenic Ribbon以替代第一代Ribbon界面。

　　
 图1 Office 2010全面使用Scenic Ribbon界面

阅读全文：

VS 2010与Windows7共舞：又见Ribbon