有{間}客栈

甲型H1N1流行，人人谈隔离而色变。好在我们今天谈的不是H1N1的隔离，而是系统服务的Session 0的隔离。

　　隔离，是为了更好的保护。但是，众所周知的，隔离也会给我们的生活带来一些不便。在Windows 7中，操作系统服务的Session 0隔离，阻断了系统服务和用户桌面进程之间进行交互和通信的桥梁。通过Session 0隔离，虽然可以让操作系统更加安全，但是也给系统服务带来了不少兼容性的问题。

        系统服务在Windows 7上遇到的问题

　　操作系统服务是Windows操作系统中一套完整的机制。服务不同于普通用户程序之处在于，你可以配置服务，让它们从系统启动时开始运行直到系统关闭，而整个过程无需用户参与。操作系统服务负责所有无需用户参与的后台活动，从远程过程调用(PRC)到网络位置识别服务等等。

　 　虽然操作系统服务在执行过程中无需用户参与，但是，有些服务可能需要向用户显示一些用户界面以反馈消息或者是跟用户应用程序进行通信。这种服务在 Windows 7中将遇到一些兼容性问题。比如，在Windows 7中，当你的服务尝试向用户显示一个消息对话框时，你将只会看到在任务栏上的一个图标，而无法正常地看到服务想要显示的对话框。确切地讲，你的服务可能会 遇到下面这些千奇百怪的问题：

　　• 虽然服务在运行，但是没干任何它应该干的事情

　　• 虽然服务在运行，但是其他进程却无法与之通信

　　• 当你的服务试图通过Windows消息与用户应用程序进行通信时，消息却无法到达应用程序

　　• 当你的服务试图与桌面进行交互时，仅仅在任务栏上显示一个闪动的图标，无法进行正常的用户交互

　　以上这些问题，实际上都是因为Windows 7的系统服务Session 0隔离而引起的。这些问题大致可以分为两类：

　　• 服务无法正确显示用户界面或者仅仅显示一个提示界面

　 　当一个服务想在桌面显示任何用户界面的时候(即使它被容许跟桌面进行交互)，一个缓冲层会用“Interactive Service Detection”对话框提示用户，询问是否需要显示来自服务的用户交互界面。虽然用户可以选择继续查看来自服务的用户界面消息，但是，工作流的被中 断，使这成为一个严重的应用程序兼容性问题。例如，下面的代码视图在服务中显示一个对话框：

　　如果我们在服务属性中，配置服务不可以与桌面进行交互，我们将看不到任何对话框，即使我们在服务中配置它可以与琢磨进行交互，它也会被“Interactive Service Detection”对话框打断，使得工作流被中断。

　　图1  设置系统服务属性

　　图2  系统服务显示消息对话框

　　• 服务和应用程序所共享的对象变得不可见或者是不可访问

　 　当服务创建的对象被一个普通应用程序(以普通用户权限运行)访问的时候，在全局名字空间中将无法找到这个对象(这是因为它是Session 0所私有的)。另外，即使对象是可见的，为了与之通信，其他进程的安全性也要做相应的改变。这将会影响到其他进程，比如普通用户权限运行的应用程序与服务 之间的交互。

阅读全文：VS与Win7共舞：系统服务的Session 0隔离

呵呵，记得当时年纪小。。。

Anyhow, happy birthday to myself, fighting!

强烈抗议，IT168的编辑一点幽默感都没有，把我的文章修改的味同嚼蜡。

“快说，你是不是安装程序?”操作系统问。

　　“我不是啊，长官。我虽然长得像，但是我真的不是安装程序啊!”，一个应用程序扮出一副可怜相，胆胆怯怯的回答道。

　　“不是?那为什么你的程序名中含有Install?”，操作系统以怀疑的眼光盯着他，“所有程序名中含有Install的应用程序都是安装程序，都必须在执行的时候都向用户请求管理员权限!”

　　“是是是，长官!”应用程序心中暗喜，操作系统主动给我机会让我请求管理员权限，我求之不得呢，用户早就厌烦UAC了，肯定直接点击“YES”了事啊，有了管理员权限，我就可以为所欲为啦，偷偷修改个首页先，哈哈哈哈~~~

　　UAC又惹祸了

　 　随着Windows Vista引入UAC(User Access Control)机制，默认情况下，应用程序都运行在普通用户权限下。虽然微软出于良好的愿望而在Vista中引入UAC机制， 但是在Vista操作系统中，只要系统稍作改变，它就会频繁弹出对话框来寻求用户的许可，因此它成为了Vista中最受痛恨的一个功能。 虽然如此，Windows 7还是继承了这一机制并根据用户的反馈做了相应的改进。为了降低计算机系统的风险，UAC机制将执行应用程序的用户权限降低了，这就为那些在UAC机制出 现之前所设计的应用程序的执行带来了兼容性的麻烦。这些旧有应用程序通常都假设以管理员权限运行，在Windows 7上，因为UAC的存在，这一假设不成立了，最终导致应用程序无法正常运行。一些应用程序确实是需要管理员权限才可以正常运行的，尤其是安装程序，他们需 要向一些需要特殊权限的区域，比如“Program Files”或者是注册表的HKEY_LOCAL_MACHINE写入内容，这种情况它们会遇到访问拒绝的错误，或者是数据被UAC Virtualization重定向到其他位置而无法正确执行。

　　为了解决这个问题，“聪明”的雷德蒙程序员们想出了一个办法：安装程序 检测。从Windows Vista开始，当然也包括Windows 7，操作系统将采用一些启发式算法来判断应用程序是不是一个安装程序，也就是在执行的时候这个程序是否需要请求管理员权限，如果操作系统判断应用程序是一 个安装程序，就会让它在执行的时候向用户请求获取管理员权限以便让应用程序正确的执行。

　　操作系统是如何检测的?

　 　所有在Windows Vista之前开发的没有manifest(包括外部的和内部的)的32位应用程序都会进行这种启发式的安装程序检测。操作系统会假设这些应用程序是旧有 的，他们都需要进行安装程序检测以确定这些应用程序是否管理员权限才能正常运行。面对这样的应用程序，操作系统的启发式安装检测通常会通过以下这些途径来 判断一个32位应用程序是不是安装程序：

　　• 文件名包含关键字：”install”, “setup”和”update”等等。

　 　• 在版本资源的以下字段内包含关键字：厂商(Vendor)、公司名(CompanyName)、产品名(ProductName)、文件说明(File Description)、初始文件名(Original Filename)、内部文件名(Internal Name)、导出名(Export Name)。

　　• 在可执行文件的manifest内包含关键字。

　　• 在链接到可执行文件的特定StringTable中包含关键字。

　　• 在链接到可执行文件的资源文件数据包含关键属性。

　　• 可执行文件包含特定的字节序列。

　　如果找到了，操作系统会认为它需要管理员权限才可以正常运行。一个UAC保护盾的图标会覆盖在应用程序图标上，这就表示应用程序在启动的时候会请求管理员权限以便它可以正确执行。

　　图1 安装程序检测

阅读全文：Win7共舞：UAC惹祸 如何进行安装程序检测？

巴适惨了，好吃得话都说不沉头达(非重庆人，听不懂)

上两周逛超市，买了块咖喱，昨天星期天，在家没事，于是决定把它做了！

按照之前从网上Google来的裁判，到菜市场买了一颗土豆，两根胡萝卜，一颗洋葱。回家按照晚上的做法说的，依样画葫芦开始烹饪我的咖喱饭了。

先是在电饭锅里面把饭做了。然后在等饭熟的时候，开始做咖喱。首先土豆削皮切成丁，胡萝卜削皮，切成丁，洋葱削皮，呵呵不用切成丁，切成丝。然后锅里放油，翻炒片刻，等土豆快熟的时候，加水加咖喱块。等水开的时候，不停的搅拌，很快就有咖喱的样子出来了。然后就是小火熬煮了，小火，小火，看着锅里咖喱翻滚，听着肚子饥肠辘辘，这真是一个考验人意志的好办法啊。等大约45分钟，咖喱已经入味啦，这时候米饭也已经好了。本来应该用盘子的，可惜我没有盘子，只好用碗将就了，成一碗饭，然后浇上金黄的咖喱，喔，还没有开始吃，首先是咖喱的香味，口水都出来了。

看起来已经是秀色可餐了。米饭雪白，咖喱金黄，胡萝卜绯红，在加上土豆丁和米饭粒粗细搭配，这不是一道美食，而是一副美景了。开始品尝，入口是满口的新香，首先是米饭的清香，然后有一点点辣，接着是咖喱中各种香料的味道，好像还有点点胡萝卜的味道。恩，正点啊！脑子已经完全被美味占领，没空再想了。。。

喔。。喔。。我爱咖喱。。。

某人没吃上，只能怪她没口福了。哈哈

回想当年微软高调发布Windows Vista的时候，突出的兼容性问题成为其在推广时遇到的最大阻力，让Windows Vista“出师未捷身先死”，从而成为继Windows Me之后微软最失败的操作系统。 有鉴于此，微软在进行Windows 7的开发的时候，将应用程序兼容性放在了前所未有的高度，提前两年就开始为Windows 7进行各种兼容性测试，同时在Windows 7上提供了Windows XP虚拟模式，最大程度地保证应用程序可以平滑地过渡到Windows 7，从这些我们都可以看出微软的良苦用心。

　　但是，操作系统的改变，必然会带来一些应用程序兼容性的问题，保持应用程序的良好兼容新，不 仅仅是微软自家的事情，作为应用程序的开发者，我们也有不可推卸的责任。你的应用程序是否能够与Windows 7良好兼容?这是摆在每个程序员面前的一个问题。下面我们就以一系列文章，来介绍一下Windows 7有了什么新的变化?这些变化会带来那些应用程序兼容性问题?如何让应用程序与Windows 7保持兼容?

　　很多程序员在设计和实现应 用程序的时候，为了图方便和省事，都有向应用程序所在的目录“Program Files”，Windows目录或者操作系统根目录(尤其是C:\)写入数据文件的习惯。另外，这些人也习惯于用注册表HKLM/Software下的 键值来保存一些数据，比如应用程序的配置参数等等。应用程序一直都工作的很好，直到万恶的UAC的出现。在Windows 7中，这些人会发现他们所要创建的文件没有相应的位置被创建，注册表键值没有被修改。他们问“到底怎么回事?我的应用程序运行正常并没有报错，但是所创建 的文件怎么就不见了呢?在其他操作系统上都工作的好好的啊?”

　　都是UAC Virtualization惹的祸

　　从Windows Vista开始，当然也包括Windows 7，因为UAC机制的引入，操作系统的标准普通用户被限制访问一些核心文件，文件夹和注册表键值。当我们开发的应用程序试图向这些地方写入数据的时候，会被重新定向到其他操作系统认为比较安全的位置。大多数时候，对于普通用户和应用程序开发人员来说这都是透明的，并没有给我们带来什么不便。但是在有些时候，事情并非如此。数据重新定向可能会导致一些奇怪的现象：

　　——在应用程序中，你写入数据到“Program Files”目录，虽然应用程序执行正确，没有错误值返回，但是在这个目录下你却找不到你刚刚写入的文件。

　　——你的应用程序修改了注册表键值，但是你在注册表相应的位置却看不到更新。

　　——当你关闭或者启用UAC后，你的应用程序找不到某些文件了，原来存在的文件凭空消失了。

　 　在Windows Vista之前，我们通常都是以管理员身份来运行应用程序的。这样，应用程序就可以自由地对操作系统相关的目录或者注册表键值进行读写。当我们以普通用户 身份运行这些应用程序时，就会出现这样或者那样无法访问的错误。Windows Vista为了减少这种错误，改善对于普通用户的应用程序的兼容性，同时又不失去其安全性，就利用UAC Virtualization(UAC 虚拟化访问)这种机制，将应用程序的写操作(包括文件和注册表操作)重新定向到了一个预先在用户的配置文件中定义的目录。UAC Virtualization分为文件Virtualization和注册表Virtualization。例如，当一个普通用户运行一个应用程序尝试写 入数据到 C:\Program Files\Contoso\Settings.ini时，这个写入操作将被重新定向到C:\Users\Username\AppData\Local \VirtualStore\Program Files\Contoso\settings.ini。这就是为什么我们在写入的时候没有任何错误，但是在相应的目录下找不到我们创建的文件。同样的， 对注册表HKLM\Software的写入操作也会被重新定向到HKCU\Software\Classes\VirtualStore。下图1展示了整 个UAC Virtualization的流程。

　　图1  UAC Virtualization的流程

　 　这里需要注意的是，UAC Virtualization仅作用于32位的应用程序对系统文件/目录、注册表的读写。64位程序、非交互式程序、模拟程序(Processes that impersonate)、内核调用者、Manifest中含有requestedExecutionLevel属性的可执行文件不包含在 Virtualization的作用范围内。

月的全文：与Win7共舞：UAC与数据重定向