IE保护模式的文件虚拟重定向

　　然而奇怪的是，为什么紫光拼音只是在我这台计算机上有点“水土不服”，而在别的计算机上却能够过得好好的?

　　这就要说到IE保护模式的另外一个优势了：

　　如果IE保护模式只有这点“防守”的能耐，那么它还不足于成为IE 7+浏览器最重要的安全特性。事实上，IE保护模式既具备严厉的安全措施(防守)，同时又具备灵活的兼容性手段(进攻)，可以说是攻守兼备。

　　原来Windows Vista为了能够让绝大多数加载项都能在IE浏览器上正常运行，IE保护模式采用一种虚拟重定向技术。

　　原来IE保护模式在以下目录中，创建一个和[用户配置文件夹]完全一致的目录层次[拥有“Low”的完整性级别]：

　　%userprofile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized

　　例如D:\Users\Admin，对于IE保护模式来说，还有一套完全一致的虚拟镜像版本：

　　D:\Users\Admin\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\D\Users\Admin

　　这样，如果IE加载项需要修改[用户配置文件夹]下的文件，系统就会自动重定向到该文件的虚拟镜像版本，对于该加载项来说，它根本不知道自己被IE保护模式“欺骗”了。

　　在正常的Windows Vista系统上，当在IE保护模式下呼出紫光拼音输入法时，利用Filemon工具进行检测，会发现当紫光拼音想要修改D:\Users\Admin\AppData\Roaming\Unispim下的usrwl.dat文件时，实际上是修改D:\Users\Admin\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\D\Users\Admin\AppData\Roaming\Unispim目录下的usrwl.dat文件，如下图所示，所以紫光拼音可以正常工作。

　　提示

　　不少读者朋友提到某些第三方的Web应用程序也有安全模式的功能。确实现在不少开发商都注意到安全的重要性，但是IE保护模式的安全效果，无疑更占上风。以电驴eMule为例，其安全模式是在系统里新增一个名为eMule_Secure的普通用户，然后借助runas的方法以该普通用户身份运行eMule，以达到安全目的。这种方法的安全级别，和Windows Vista的UAC处于同一层次，比起IE保护模式，其安全性还是有所不如。更重要的是，UAC和IE保护模式，既安全、又方便、且兼容。

　　而Firefox的安全模式，则类似于IE 7的NoAddons，和IE保护模式完全是两个概念，其安全性也远非IE保护模式可比。

　　唯一遗憾的是，笔者的这台计算机，不知道出于什么原因，无论是Beta 2、5456，还是最新的5472.5版本，紫光拼音输入法无法正常触发IE的虚拟重定向功能，所以导致拒绝访问的错误。