为什么在 Windows 上将可执行文件符号链接到 C:\Windows\System32 不是一种常见做法？

Question

在 linux 上，在某些应用程序的安装过程中，很常见的是，它会创建一个指向它的可执行文件的符号链接，/usr/bin因此它们将位于系统PATH变量中。

另一方面，在 Windows 上，大多数应用程序会PATH在安装过程中将其自己的安装路径连接到环境变量，这会导致一些不属于此问题范围的问题。

我看到该文件夹C:\Windows\System32与 的作用有些相似/usr/bin，因为两者都是PATH两个系统中标准变量的一部分，那么为什么将可执行文件符号链接到 不是一种常见做法C:\Windows\System32？

Answer 1

因为PATH环境变量比符号链接功能早了二十年。您在 Linux 中看到的等效符号链接是在 2006 年随 Windows Vista 引入的。该PATH变量自 1986 年以来一直存在。

要从 20 年前的方法转向新方法，开发人员需要一个充分的理由来克服在 中创建符号链接的缺点System32：

• 这样做需要管理权限。
• 必须为每个 .exe 文件创建一个符号链接。
• 安装程序和卸载程序必须创建和销毁它们。如果开发人员更改了其 .exe 文件的名称，他必须编写一个例程来检查旧的符号链接并更新它们。
• 牢记上述所有内容，如果两个应用程序具有类似命名的 .exe 文件，那么除了“DLL 地狱”之外，我们还将拥有“符号链接地狱”。一个地狱还不够吗？
• 结果总是每台机器（不是每用户或每进程）。

同时：

• PATH无论如何，没有多少应用程序使用该变量。大多数应用程序都是 GUI 应用程序，将它们的快捷方式安装到“开始”菜单中，并且是它们的主要执行途径。
• 该PATH变量可以在每台机器、每用户甚至每进程的基础上进行定制。事实上，像 Visual Studio 这样的一些应用程序已经PATH为该实例定制了带有定制的每个进程变量的命令提示符。