一个经常让我困惑的问题是,为什么 Windows 团队决定复制 Program Files 文件夹以支持 32 位和 64 位平台?从长远来看,这不会给每个人带来更多的工作和混乱吗?
让他们复制树的关键因素是什么,而其他一些系统保留一个“程序文件”目录(有点像 MAC 的通用二进制格式http://en.wikipedia.org/wiki/Universal_binary)?
我敢肯定有一个很好的理由让他们创建这个“程序文件(x86)”文件夹,如果有人在房间里,请分享:)
一个经常让我困惑的问题是,为什么 Windows 团队决定复制 Program Files 文件夹以支持 32 位和 64 位平台?从长远来看,这不会给每个人带来更多的工作和混乱吗?
让他们复制树的关键因素是什么,而其他一些系统保留一个“程序文件”目录(有点像 MAC 的通用二进制格式http://en.wikipedia.org/wiki/Universal_binary)?
我敢肯定有一个很好的理由让他们创建这个“程序文件(x86)”文件夹,如果有人在房间里,请分享:)
c:\program files 文件夹包含很多 DLL,尤其是在 Common Files 子目录中。c:\program files (x86)\common files 文件夹包含这些 DLL 的 32 位版本。其中许多 DLL 已经存在了很长时间,将近 20 年,许多遗留程序都依赖于它们。
不虚拟化文件夹会大大增加 DLL Hell 的几率。这也是环境具有引用 Common Files 文件夹的三个变量的原因,CommonProgramFiles、CommonProgramFiles(x86) 和 CommonProgramW6432。
Appcompat 在微软是相当神圣的,尽管它正在消失。Windows 8 是一个相当彻底的背离,这个问题在 Windows Store 应用程序中不存在。