【IT168 专稿】回想当年微软高调发布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的作用范围内。