where.exe does not find OpenSSL libs when %ProgramFiles% variable is used in the PATH environment variable

I installed both 32bit and 64bit version of OpenSSL libs on Vista x64. The 32bit version was installed in c:\Program Files (x86)\OpenSSL and the 64bit version was installed in c:\Program Files\OpenSSL. Then I added the entry %ProgramFiles%\OpenSSL to the PATH environment variable. %ProgramFiles%\OpenSSL is expanded to c:\Program Files (x86)\OpenSSL for 32bit programs and it's expanded to c:\Program Files\OpenSSL for 64bit programs. The idea is to have 32bit programs use 32bit version of OpenSSL libs and 64bit programs use 64bit version. I wanted to check if this works by running 32bit cmd.exe and issuing where ssleay32.dll and then by running 64bit cmd.exe and issuing the same. However in both cases I get the error INFO: Could not find files for the given pattern(s).
What's wrong?

This is a follow up to Different PATH environment variable for 32bit and 64bit Windows - is it possible?

Piotr Dobrogost

Posted 2011-02-20T20:03:14.983

Reputation: 4 413

What happens when you search for openssl.exe, rather than a dll? Also, have you tried another method, such as executing openssl.exe in cmd to see if it is the right one ? (You may use Process Monitor to see which openssl.exe version is executing). It may be that "where" does not work very well under your environment.

– harrymc – 2011-02-23T06:50:39.497

where openssl.exe finds the one in OpenVPN folder which is after OpenSSL one in the PATH. – Piotr Dobrogost – 2011-02-23T20:06:36.110

I think you have proven very soundly that %ProgramFiles% does not work as expected in the PATH. Maybe cmd -k will work with the parameter of "set path=%path%;%ProgramFiles%\OpenSSL", or some other combination.

– harrymc – 2011-02-23T20:51:38.390

Answers

Put the 32bit .DLLs into the \Windows\SysWOW64 directory and the 64bit DLLs into the \Windows\system32 directory.

EDIT:

Maybe this helps:

This is just an intelligent guess, but following some investigation I believe I've found the problem:

If the definition of an environment variable var1 contains another environment variable var2 and the name of var1 is alphabetically less than the name of var2 (i.e. strcmp(var1, var2) < 0), then var2 won't get expanded. This seems to be because when Windows first sets up the environment variables, they are created in alphabetical order, so var2 does not exist until after var1 has already been created (and so the expansion can't be done).

I believe this is a limitation in Windows. Really some sort of dependency check between the variables should be carried out so that they are created in the correct order. Fortunately, there is a workaround.

1) Enable 'delayed variable expansion' in the registry (see http://batcheero.blogspot.com/2007/06/how-to-enabledelayedexpansion.html)

2) Change the '%' signs around var2 to '!', e.g. "%var2%" becomes "!var2!"

I've done some limited testing on Windows 7 and this appears to fix the problem.

It's from here: http://social.answers.microsoft.com/Forums/en-US/vistainstall/thread/48b23109-9fbc-47c5-a5d1-465773f94704

Darokthar

Posted 2011-02-20T20:03:14.983

Reputation: 1 361

Why should I? My current setup should work. I'd like to know why it doesn't. – Piotr Dobrogost – 2011-02-23T20:07:57.043

It doesn't work, thats why you should give it a try. I understand that it should work. I'm just trying to help. And windows is searching the above paths for .DLLs. If it works that way i wouldn't care why the other configuration isn't working. Maybe it's a bug or working as intended. We don't know... Obviously no one else does know or is willing to answer. Try it or leave it the way it is... – Darokthar – 2011-02-23T21:11:18.413

If it works that way i wouldn't care why the other configuration isn't working. I care :) – Piotr Dobrogost – 2011-02-23T22:00:55.220

@Piotr Dobrogost I don't care about the bounty. If you give it to me or not doesn't matter to me. But i just found the stuff i edited into the post... – Darokthar – 2011-02-23T23:07:44.010

Setting delayed variable expansion in the registry makes output of echo %path% display paths with %ProgramFiles% being properly expanded. However, where.exe still doesn't handle such paths. – Piotr Dobrogost – 2011-02-24T21:08:30.613

It seems harrymc is right saying

I think you have proven very soundly that %ProgramFiles% does not work as expected in the PATH.

The odd thing is I can't find any information on this problem using google...

The solution I went for is inspired by idea in Darokthar's answer;
I symlinked
c:\windows\system32\OpenSSL-bin to c:\Program Files\OpenSSL\bin
and
c:\windows\SysWOW64\OpenSSL-bin to c:\Program Files (x86)\OpenSSL\bin
and added c:\windows\system32\OpenSSL-bin to PATH.

Piotr Dobrogost

Posted 2011-02-20T20:03:14.983

Reputation: 4 413

Root of the prob: the "alphabetic" nonsense in Windows (i.e. envvar1 is not expanded within another envvar2 if envvar2 "comes first" alphabetically).

My workaround: forget about using %ProgramFiles% completely, even with delayed variable expansion. Instead create another envvar, called _ProgFiles or similar: the leading underscore will mean that all other envvars following it alphabetically will use it as properly expanded ...

So your PATH will read ... ;%_ProgFiles%\OpenSSL;... or something like this.

mike rodent

Posted 2011-02-20T20:03:14.983

Reputation: 11