onde.exe não encontra libs OpenSSL quando a variável% ProgramFiles% é usada na variável de ambiente PATH

Question

Instalei a versão de 32 bits e 64 bits das bibliotecas OpenSSL no Vista x64. A versão de 32 bits foi instalada em c:\Program Files (x86)\OpenSSL e a versão de 64 bits foi instalada em c:\Program Files\OpenSSL . Em seguida, adicionei a entrada %ProgramFiles%\OpenSSL à variável de ambiente PATH . %ProgramFiles%\OpenSSL é expandido para c:\Program Files (x86)\OpenSSL para programas de 32 bits e é expandido para c:\Program Files\OpenSSL para programas de 64 bits. A idéia é que os programas de 32 bits usem a versão de 32 bits das bibliotecas OpenSSL e os programas de 64 bits usem a versão de 64 bits. Eu queria verificar se isso funciona executando 32bit cmd.exe e emitindo where ssleay32.dll e, em seguida, executando 64 bits cmd.exe e emitindo o mesmo. No entanto, em ambos os casos, recebo o erro INFO: Could not find files for the given pattern(s).
O que há de errado?

Este é um acompanhamento para Diferente variável de ambiente PATH para Windows de 32 e 64 bits - é possível?

    

Answer 1

Coloque as DLLs de 32 bits no diretório \ Windows \ SysWOW64 e as DLLs de 64 bits no diretório \ Windows \ system32.

EDITAR:

Talvez isso ajude:

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.

É daqui: link

    

Answer 2

Parece que harrymc está certo em dizer

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

O mais estranho é que não consigo encontrar nenhuma informação sobre este problema usando o google ...

A solução que escolhi é inspirada na ideia da resposta de Darokthar; Eu criei um link simbólico para c:\windows\system32\OpenSSL-bin to c:\Program Files\OpenSSL\bin
e c:\windows\SysWOW64\OpenSSL-bin to c:\Program Files (x86)\OpenSSL\bin
e adicionou c:\windows\system32\OpenSSL-bin ao PATH.

    

Answer 3

Raiz do prob: o disparate "alfabético" no Windows (por exemplo, envvar1 não é expandido dentro de outro envvar2 if envvar2 "vem primeiro" em ordem alfabética).

Minha solução alternativa: esqueça de usar %ProgramFiles% completamente, mesmo com a expansão de variável atrasada. Em vez disso, crie outro envvar, chamado _ProgFiles ou similar: o sublinhado à esquerda significará que todos os outros envovars que o seguem em ordem alfabética o usarão como expandido adequadamente ...

Assim, o seu PATH lerá ... ;%_ProgFiles%\OpenSSL;... ou algo assim.