dove.exe non trova le librerie OpenSSL quando viene utilizzata la variabile% ProgramFiles% nella variabile di ambiente PATH

Ho installato entrambe le versioni a 32 e 64 bit delle librerie OpenSSL su Vista x64. È stata installata la versione a 32 bit e installata c:\Program Files (x86)\OpenSSLla versione a 64 bit c:\Program Files\OpenSSL. Quindi ho aggiunto la voce %ProgramFiles%\OpenSSLalla PATHvariabile d'ambiente. %ProgramFiles%\OpenSSLviene espanso c:\Program Files (x86)\OpenSSLper i programmi a 32 bit e ampliato c:\Program Files\OpenSSLper i programmi a 64 bit. L'idea è che i programmi a 32 bit utilizzino la versione a 32 bit delle librerie OpenSSL e che i programmi a 64 bit utilizzino la versione a 64 bit. Volevo verificare se funziona eseguendo cmd.exe a 32 bit e rilasciando where ssleay32.dlle quindi eseguendo cmd.exe a 64 bit e rilasciando lo stesso. Tuttavia in entrambi i casi viene visualizzato l'errore INFO: Could not find files for the given pattern(s).
Cosa c'è che non va?

Questo è un seguito alla variabile d'ambiente PATH differente per Windows a 32 e 64 bit - è possibile?

— Piotr Dobrogost
fonte

Cosa succede quando cerchi openssl.exe, anziché una dll? Inoltre, hai provato un altro metodo, come l'esecuzione di openssl.exe in cmd per vedere se è quello giusto? (È possibile utilizzare Process Monitor per vedere quale versione di openssl.exe è in esecuzione). Può darsi che "dove" non funzioni molto bene nel tuo ambiente.

— harrymc,

where openssl.exetrova quello nella cartella OpenVPN che è dopo quello OpenSSL nel PERCORSO.

— Piotr Dobrogost,

Penso che tu abbia dimostrato molto profondamente che% ProgramFiles% non funziona come previsto nel PERCORSO. Forse cmd -k funzionerà con il parametro "set path =% path%;% ProgramFiles% \ OpenSSL", o qualche altra combinazione.

— harrymc,

Risposte:

Inserire i .DLL a 32 bit nella directory \ Windows \ SysWOW64 e le DLL a 64 bit nella directory \ Windows \ system32.

MODIFICARE:

Forse questo aiuta:

Questa è solo un'ipotesi intelligente, ma dopo alcune indagini credo di aver trovato il problema:

Se la definizione di una variabile di ambiente var1 contiene un'altra variabile di ambiente var2 e il nome di var1 è alfabeticamente inferiore al nome di var2 (ovvero strcmp (var1, var2) <0), allora var2 non verrà espanso. Ciò sembra essere dovuto al fatto che quando Windows imposta per la prima volta le variabili di ambiente, queste vengono create in ordine alfabetico, quindi var2 non esiste fino a quando non è già stata creata var1 (e quindi l'espansione non può essere eseguita).

Credo che questa sia una limitazione in Windows. In realtà una sorta di controllo della dipendenza tra le variabili dovrebbe essere eseguita in modo che vengano create nell'ordine corretto. Fortunatamente, esiste una soluzione alternativa.

1) Abilita "espansione variabile ritardata" nel registro (vedi http://batcheero.blogspot.com/2007/06/how-to-enabledelayedexpansion.html )

2) Cambia i segni '%' intorno a var2 in '!', Ad es. "% Var2%" diventa "! Var2!"

Ho eseguito alcuni test limitati su Windows 7 e questo sembra risolvere il problema.

È da qui: http://social.answers.microsoft.com/Forums/en-US/vistainstall/thread/48b23109-9fbc-47c5-a5d1-465773f94704

— Darokthar
fonte

Perché dovrei? La mia configurazione attuale dovrebbe funzionare. Mi piacerebbe sapere perché non lo è.

— Piotr Dobrogost,

Non funziona, ecco perché dovresti provarlo. Capisco che dovrebbe funzionare. Sto solo cercando di aiutare. E windows sta cercando i percorsi sopra elencati per .DLLs. Se funziona in questo modo, non mi importa perché l'altra configurazione non funziona. Forse è un bug o funziona come previsto. Non lo sappiamo ... Ovviamente nessun altro lo sa o è disposto a rispondere. Provalo o lascialo così com'è ...

— Darokthar,

Se funziona in questo modo, non mi importa perché l'altra configurazione non funziona. Mi interessa :)

— Piotr Dobrogost,

@Piotr Dobrogost Non mi interessa la generosità. Se me lo dai o no, non mi importa. Ma ho appena trovato le cose che ho modificato nel post ...

— Darokthar,

L'impostazione dell'espansione ritardata delle variabili nel registro rende l'output dei echo %path%percorsi di visualizzazione con% ProgramFiles% espanso correttamente. Tuttavia, dove.exe non gestisce ancora tali percorsi.

— Piotr Dobrogost,

Sembra che Harry abbia ragione

Penso che tu abbia dimostrato molto profondamente che% ProgramFiles% non funziona come previsto nel PERCORSO.

La cosa strana è che non riesco a trovare alcuna informazione su questo problema usando Google ...

La soluzione che ho cercato è ispirata all'idea nella risposta di Darokthar;
Ho collegato simbolicamente
c:\windows\system32\OpenSSL-bina c:\Program Files\OpenSSL\bin
e
c:\windows\SysWOW64\OpenSSL-binper c:\Program Files (x86)\OpenSSL\bin
e ha aggiunto c:\windows\system32\OpenSSL-binal PATH.

— Piotr Dobrogost
fonte

Radice del prob: l'assurdità "alfabetica" di Windows (cioè envvar1non si espande all'interno di un'altra envvar2se envvar2"viene prima" in ordine alfabetico).

La mia soluzione alternativa: dimentica di utilizzare %ProgramFiles%completamente, anche con l'espansione variabile ritardata. Invece crea un altro envvar, chiamato _ProgFileso simile: il carattere di sottolineatura principale significherà che tutti gli altri envvar che lo seguono in ordine alfabetico lo useranno come correttamente espanso ...

Quindi il tuo PERCORSO leggerà ... ;%_ProgFiles%\OpenSSL;...o qualcosa del genere.

— roditore mike
fonte