Inna zmienna środowiskowa PATH dla 32-bitowego i 64-bitowego systemu Windows - czy jest to możliwe?

14

Czy możliwe jest posiadanie całości lub części PATHzmiennej środowiskowej specyficznej dla typu obrazu uruchomionego procesu (32bit / 64bit)? Kiedy uruchamiam jakąś aplikację z poziomu 64-bitowego cmd.exe, chciałbym, aby wybrała 64-bitową wersję biblioteki OpenSSL, natomiast gdy uruchamiam jakąś aplikację z 32-bitowego cmd.exe, chciałbym, aby wybrała 32-bitową wersję biblioteki OpenSSL.

ŚLEDŹ
gdzie.exe nie znajduje bibliotek OpenSSL, gdy zmienna% ProgramFiles% jest używana w zmiennej środowiskowej PATH

Piotr Dobrogost
źródło

Odpowiedzi:

9

Upewnij %ProgramFiles%się %ProgramFiles(x86)%ENV zmienną przełączanie do pracy dla Ciebie:

Foldery miejsce z x32 i x64 wersje biblioteki OpenSSL na odpowiednie %programfiles%i %ProgramFiles(x86)%katalogów oraz w PATHzmiennej środowiskowej, należy odniesienie do tych folderów za pomocą %programfiles%zmiennej.

W ten sposób, jeśli pracujesz w środowisku x32-bit, twój PATHwpis %programfiles%/OpenSSL/zostanie automatycznie rozwiązany %ProgramFiles(x86)%/OpenSSL/na dysku.

romka
źródło
1
Mam problem z uruchomieniem go. echo %programfiles%pokazuje inną ścieżkę w zależności od typu cmd.exe, z którego jest uruchamiany, ale where ssleay32.dllw obu typach cmd.exe (32-bitowy i 64-bitowy) nie można znaleźć tej biblioteki DLL i wyświetla INFO: Could not find files for the given pattern(s).jakieś pomysły?
Piotr Dobrogost
Może to pomóc: Chociaż może to pomóc: stackoverflow.com/questions/906310/…
Darokthar
1
jeśli jedna z bibliotek DLL jest wersją 32-bitową, na komputerze 64-bitowym powinna przejść do folderu C: \ windows \ syswow64
romka
To mi nie działa. Gdy dołączę% ProgramFiles% do definicji zmiennej PATH, to wcale się nie rozwija, więc mój exe nie znajduje swoich bibliotek DLL.
Carlos A. Ibarra
7

Odpowiedź (zaznaczona poprawnie) romka jest prosta i elegancka, ale niestety nie działa (przynajmniej na Windows 7 i Windows 8 64 bity, nie pchałem dalej testu).

Problem wynika z faktu, że zmienna systemowa PATH% nie zawsze rozwija inną zmienną env: działa na przykład z% SYSTEMDRIVE%, ale niestety nie dla% PROGRAMFILES%. Wikipedia sugeruje, że takie zachowanie pochodzi z poziomu pośredniego (% SYSTEMDRIVE% nie odnosi się do trzeciej zmiennej env).

Jedynym rozwiązaniem, jakie znalazłem, jest użycie magicznej File System Redirector i katalogów System32 / SysWoW64, zgodnie z sugestiami w komentarzach.

Aby uniknąć bezpośredniego wdrażania bibliotek DLL w katalogu Windows, co zwykle jest trudne w utrzymaniu, można zamiast tego wdrożyć łącze miękkie do katalogu niestandardowego (działa w systemie Windows Vista i nowszych wersjach systemu Windows):

Nawiasem mówiąc, przepraszam, że nie komentuję bezpośrednio odpowiednich postów: obecnie brak wystarczającej reputacji na moim koncie, aby to zrobić.

Baptiste Chardon
źródło
5

Tak, jest to absolutnie możliwe. Po prostu napisz trzy pliki .bat. Pierwszy powinien wyglądać tak:

@echo off
if "%1" == "" goto x86
if not "%2" == "" goto usage

if /i %1 == x86 goto x86
if /i %1 == ia64 goto ia64
goto usage

:x86
if not exist "%~dp0bin\x86.bat" goto missing
call "%~dp0bin\x86.bat"
goto :eof

:ia64
if not exist "%~dp0bin\ia64.bat" goto missing
call "%~dp0bin\ia64.bat"
goto :eof

:usage
echo Error in script usage. The correct usage is:
echo %0 [option]
echo where [option] is: x86 ^| ia64
echo:
echo For example:
echo %0 x86
goto :eof

:missing
echo The specified configuration type is missing. The tools for the
echo configuration might not be installed.
goto :eof

Drugi i trzeci plik .bat są w zasadzie takie same, z tą różnicą, że różnią się nazwą. Pierwszy nazywa się x86.bat, a drugi ia64.bat i są one umieszczane w folderze o nazwie bin, który znajduje się nad pierwszym plikiem nietoperza. Będziesz miał to:

PATH\first.bat
PATH\bin\x86.bat
PATH\bin\ia64.bat

Zawartość drugiego i trzeciego pliku .bat powinna wyglądać następująco:

@set PATH=THE PATH YOU WANT

Możesz utworzyć link do pierwszego pliku .bat, który będzie miał następujące ustawienia:

Cel:% comspec% / k "PATH \ first.bat" OPCJA | Gdzie OPCJA to x86 lub ia64

Zacznij za: ŚCIEŻKA | Gdzie ŚCIEŻKA jest ŚCIEŻKĄ do pierwszego. Nietoperza

Skrypt jest uproszczonym skryptem używanym przez Microsoft do uruchomienia odpowiedniego wiersza poleceń dla środowiska Visual Studio. Możesz po prostu rozszerzyć ten skrypt na N środowisk. Dodając więcej plików .bat dla różnych środowisk i edytując plik first.bat z większą liczbą opcji i instrukcji goto. Mam nadzieję, że to samo wyjaśnia.

Mam nadzieję, że Microsoft nie pozwie mnie za użycie ich skryptu.

EDYTOWAĆ:

Ach, chyba źle cię zrozumiałem. Dla 32-bitowej linii cmd link powinien zostać utworzony jako:

Cel:% windir% \ SysWoW64 \ cmd.exe „PATH \ first.bat” x86

EDYCJA 2:

Wypróbuj coś takiego:

if "%ProgramFiles%" == "%ProgramFiles(x86)%" goto x64_PATH
if "%ProgramFiles%" == "%ProgramW6432%" goto x86_PATH

:x64_PATH
@set PATH=YOUR 64 bit PATH
SOME_PATH\your64BitApp.exe
goto :eof

:x86_PATH
@set PATH=YOUR 32bit PATH
SOME_PATH\your32BitApp.exe
goto :eof
Darokthar
źródło
1
Możesz to skorygować, dla jasności - są szanse, że nie używają 64-bitowej technologii Intel (ia64 - procesory Itanium), ale raczej technologię AMD64 bit, zwaną potocznie x64.
Multiverse IT,
Dziękuję za odpowiedź. Pomysł jest fajny. Jednak szukałem rozwiązania na poziomie systemu, takiego jak to, które służy do modyfikowania %ProgramFiles%zmiennej. (Cytat: Sam% ProgramFiles% zależy od tego, czy sam proces żądania zmiennej środowiskowej jest 32-bitowy czy 64-bitowy (jest to spowodowane przekierowaniem 64-bitowym Windows na Windows). En.wikipedia.org/wiki/ … )
Piotr Dobrogost
1

Chciałem tylko streścić odpowiedź, którą otrzymałem, podążając za linkami podanymi w odpowiedzi Baptiste Chardon. Korzystając z mklinknarzędzia wiersza polecenia, aby utworzyć symboliczne łącze do katalogu wewnątrz C:\Windows\system32 i na C:\Windows\SysWOW64zewnątrz, każdy o tej samej nazwie (choć różnych obiektach docelowych), możesz po prostu dodać je C:\Windows\system32do Pathzmiennej środowiskowej. Na przykład:

C:\> mklink /D C:\Windows\SysWOW64\my_XXbit_dlls C:\dlls\x86
symbolic link created for C:\Windows\SysWOW64\my_XXbit_dlls <<===>> C:\dlls\x86
C:\> mklink /D C:\Windows\System32\my_XXbit_dlls C:\dlls\x64
symbolic link created for C:\Windows\System32\my_XXbit_dlls <<===>> C:\dlls\x64
użytkownik74094
źródło
0

Miałem ten problem i odpowiedź jest następująca:

Ścieżka do zmiennej systemowej na komputerach 64-bitowych to c:\progra~2. Musisz mieć ścieżkę bez przestrzeni dla zmiennej środowiskowej, w przeciwnym razie system nie będzie czytał dalejC:\programs .

Na naszych 32-bitowych maszynach są zmienne środowiskowe programy firmy, c:\program filesa na 64-bitowych c:\progra~2. Następnie ustawiamy nasze skróty dla użytkowników na%companyprograms%\...

Możesz to zrobić za pomocą zasad grupy lub skryptu.

JRubinstein
źródło
-1

Jak wskazała romka w następnej odpowiedzi, prostą odpowiedzią jest katalog SysWOW64.

Na szczęście instalatorzy z produkcji Shining Light zajmują się tym . Po prostu uruchom instalatory 32-bitowe i 64-bitowe i wybierz, aby skopiować pliki .DLLs do katalogu Windows „System”, a odpowiedni katalog zostanie wybrany dla plików .DLLs (tj. 64-bitowe .DLLs przejdź do System32, a 32-bitowe .DLLs do SysWOW64.

Gdy to zrobię, moje 32-bitowe aplikacje znajdują 32-bitowe .DLLs, a moje 64-bitowe aplikacje znajdują 64-bitowe .DLLs.

etinthelab
źródło