☰

当 PATH 环境变量中使用 %ProgramFiles% 变量时，where.exe 找不到 OpenSSL 库

tag-icon • tag-icon windows 64-bit 32-bit path environment-variables
当 PATH 环境变量中使用 %ProgramFiles% 变量时，where.exe 找不到 OpenSSL 库

我在 Vista x64 上安装了 32 位和 64 位版本的 OpenSSL 库。32 位版本安装在c:\Program Files (x86)\OpenSSL，64 位版本安装在c:\Program Files\OpenSSL。然后我将条目添加%ProgramFiles%\OpenSSL到PATH环境变量中。对于 32 位程序，%ProgramFiles%\OpenSSL扩展为c:\Program Files (x86)\OpenSSL，对于 64 位程序，扩展为c:\Program Files\OpenSSL。这个想法是让 32 位程序使用 32 位版本的 OpenSSL 库，而 64 位程序使用 64 位版本。我想通过运行 32 位 cmd.exe 并发出where ssleay32.dll，然后运行 ​​64 位 cmd.exe 并发出相同的命令来检查这是否有效。但是在这两种情况下，我都收到错误，出了INFO: Could not find files for the given pattern(s).
什么问题？

这是 32 位和 64 位 Windows 的 PATH 环境变量不同 - 可能吗？

答案1

将 32 位 .DLL 放入 \Windows\SysWOW64 目录，将 64 位 DLL 放入 \Windows\system32 目录。

编辑：

也许这有帮助：

这只是一个聪明的猜测，但经过一些调查，我相信我已经找到了问题所在：

如果环境变量 var1 的定义包含另一个环境变量 var2，并且 var1 的名称按字母顺序小于 var2 的名称（即 strcmp(var1, var2) < 0），则 var2 将不会扩展。这似乎是因为当 Windows 首次设置环境变量时，它们是按字母顺序创建的，因此 var2 直到 var1 创建后才存在（因此无法进行扩展）。

我认为这是 Windows 的一个限制。实际上应该对变量之间进行某种依赖性检查，以便按正确的顺序创建它们。幸运的是，有一个解决方法。

1) 在注册表中启用“延迟变量扩展”（参见 http://batcheero.blogspot.com/2007/06/how-to-enabledelayedexpansion.html）

2) 将 var2 两侧的 '%' 符号改为 '!'，例如将“%var2%”改为“!var2!”

我在 Windows 7 上做了一些有限的测试，这似乎解决了这个问题。

它来自这里：http://social.answers.microsoft.com/Forums/en-US/vistainstall/thread/48b23109-9fbc-47c5-a5d1-465773f94704

答案2

看来 harrymc 说得对

我认为您已经非常充分地证明了 %ProgramFiles% 在 PATH 中无法按预期工作。

奇怪的是我无法使用谷歌找到有关此问题的任何信息......

我寻求的解决方案受到 Darokthar 的答案中的想法的启发；
我将其符号链接
c:\windows\system32\OpenSSL-bin到c:\Program Files\OpenSSL\bin
并
c:\windows\SysWOW64\OpenSSL-bin添加c:\Program Files (x86)\OpenSSL\bin
到c:\windows\system32\OpenSSL-binPATH。

答案3

问题的根源：Windows 中的“字母顺序”无意义（即，如果按字母顺序“排在第一位”，envvar1则不会在另一个字母顺序中展开）。envvar2envvar2

我的解决方法：完全忘记使用%ProgramFiles%，即使变量扩展延迟。而是创建另一个环境变量，称为_ProgFiles或类似：前导下划线将意味着按字母顺序跟在其后面的所有其他环境变量都将使用它作为正确扩展...

因此你的 PATH 将会读取... ;%_ProgFiles%\OpenSSL;...或类似这样的内容。

相关内容