Per batch herausfinden, ob das zu installierende programm x64 oder x86 lauffähig ist
Guten Abend,
kennt jemand einen ein- oder zweizeiler, mit welchem ich eine installationsdatei in form einer exe prüfen kann, ob diese bei windows 7 bsp in das program files oder in das program files (x86) hineinschreiben wird, sprich welche architektur das setup unterstützt?
freundliche grüße chris
zusatz: oder kennt jemand eine andere lösung? ich schreibe eine bat, welche in abhängigkeit der prozessorarchitektur UND die Architektur des Setups die richtige EXE installiert.
sprich wenn OS=64 und die installierbare EXE=64, dann installiere die X64 variante. oder wenn OS=64 und die installierbare EXE=86, dann installiere die X86 variante.
kennt jemand einen ein- oder zweizeiler, mit welchem ich eine installationsdatei in form einer exe prüfen kann, ob diese bei windows 7 bsp in das program files oder in das program files (x86) hineinschreiben wird, sprich welche architektur das setup unterstützt?
freundliche grüße chris
zusatz: oder kennt jemand eine andere lösung? ich schreibe eine bat, welche in abhängigkeit der prozessorarchitektur UND die Architektur des Setups die richtige EXE installiert.
sprich wenn OS=64 und die installierbare EXE=64, dann installiere die X64 variante. oder wenn OS=64 und die installierbare EXE=86, dann installiere die X86 variante.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 213994
Url: https://administrator.de/forum/per-batch-herausfinden-ob-das-zu-installierende-programm-x64-oder-x86-lauffaehig-ist-213994.html
Ausgedruckt am: 07.04.2025 um 21:04 Uhr
10 Kommentare
Neuester Kommentar
Hallo Chris,
ich kann deine Frage nicht so richtig nachvollziehen. Du wirst doch vorher wissen, ob dein Installer ein 64 Bit oder ein 32 Bit Programm ist, oder?
Es ist nicht so, dass man nicht auch den Dateiheader untersuchen könnte (per FC /B gegen eine vorher mit FSUTIL erzeugte temporäre Datei aus Nullzeichen), aber mit einem Ein- oder Zweizeiler hat das dann nichts mehr zu tun (es sei denn, es gibt irgendein 3rd Party Tool, Google wird's dir sagen ...).
Die Prozessorarchitektur hat übrigens auch nicht zwingend etwas mit dem Betriebssystem zu tun.
Grüße
rubberman
ich kann deine Frage nicht so richtig nachvollziehen. Du wirst doch vorher wissen, ob dein Installer ein 64 Bit oder ein 32 Bit Programm ist, oder?
Es ist nicht so, dass man nicht auch den Dateiheader untersuchen könnte (per FC /B gegen eine vorher mit FSUTIL erzeugte temporäre Datei aus Nullzeichen), aber mit einem Ein- oder Zweizeiler hat das dann nichts mehr zu tun (es sei denn, es gibt irgendein 3rd Party Tool, Google wird's dir sagen ...).
Die Prozessorarchitektur hat übrigens auch nicht zwingend etwas mit dem Betriebssystem zu tun.
Grüße
rubberman

Hi,
Wenn die Exe für x86 gedacht ist, ist die Architektur, mit der das (Windows-) OS installiert ist, völlig schnurz, dann kanst du sowieso keine andere EXE installieren.
Oder hast du dich nur etwas wirr ausgedrückt?
Gruß
Zitat von @ChrisDynamite:
oder wenn OS=64 und die installierbare EXE=86, dann installiere die X86 variante.
oder wenn OS=64 und die installierbare EXE=86, dann installiere die X86 variante.
Wenn die Exe für x86 gedacht ist, ist die Architektur, mit der das (Windows-) OS installiert ist, völlig schnurz, dann kanst du sowieso keine andere EXE installieren.
Oder hast du dich nur etwas wirr ausgedrückt?
Gruß
Hallo Chris,
ich habe keine Ahnung was so schwierig sein soll, 32 Bit Programme in ein Poolverzeichnis zu packen und 64 Bit Programme in ein anderes.
Ich habe gestern Abend mal noch fix eine Subroutine zusammengebaut, damit du eine Vorstellung bekommst, wie das was du vorhast aussieht
Funktion:
- Pfad wird an die Routine übergeben
- Hex Dump des Dateiheaders erstellen
- Suche nach der "Magic Number" Ermittle die Ziel-CPU
- Rückgabewert (Errorlevel) 0 bei Fehler, sonst 32 bzw. 64
Bei Fragen, bitte fragen
Antwort kommt aber erst heute Abend ...
Grüße
rubberman
EDIT: @112778 's Anregungen aufgegriffen und "Magic" gegen "Machine" ausgetauscht.
ich habe keine Ahnung was so schwierig sein soll, 32 Bit Programme in ein Poolverzeichnis zu packen und 64 Bit Programme in ein anderes.
Ich habe gestern Abend mal noch fix eine Subroutine zusammengebaut, damit du eine Vorstellung bekommst, wie das was du vorhast aussieht
Funktion:
- Pfad wird an die Routine übergeben
- Hex Dump des Dateiheaders erstellen
-
- Rückgabewert (Errorlevel) 0 bei Fehler, sonst 32 bzw. 64
@echo off &setlocal
call :get3264exe "%SystemRoot%\explorer.exe"
echo Windows Explorer: %errorlevel% Bit
pause
goto :eof
:::::::::::::::::::
:get3264exe ExePath
setlocal DisableDelayedExpansion
REM Eingehender Parameter (*.exe Dateipfad)
set "infile=%~1"
if not exist "%infile%" (endlocal &exit /b 0)
if /i "%infile:~-4%" neq ".exe" (endlocal &exit /b 0)
set "tmpf=%temp%\#.tmp~"
set "dump=%temp%\##.tmp~"
REM 1024 mal A in temporäre Datei schreiben.
>"%tmpf%" (for /l %%i in (1 1 1024) do <nul set /p "=A")
REM HexDump der ersten 1024 Byte des Executables erstellen
setlocal EnableDelayedExpansion
set /a x=1
>"!dump!" (
for /f "skip=1 tokens=1,2 delims=: " %%i in ('fc /b "!infile!" "!tmpf!"^|findstr /vbic:"FC:"') do (
set /a y=0x%%i
for /l %%k in (!x! 1 !y!) do echo 41
echo %%j
set /a x=y+2
)
)
endlocal
REM Temporäre Datei löschen.
del "%tmpf%"
REM Position der PE Signatur ermitteln.
<"%dump%" (
for /l %%i in (1 1 60) do set /p "="
set /p "PosPE1="
set /p "PosPE2="
)
set /a "PosPE=0x%PosPE2%%PosPE1%"
if %PosPE% gtr 1000 (
REM Kein Executable.
endlocal &exit /b 0
)
REM PE Signatur und Machine ermitteln
<"%dump%" (
for /l %%i in (1 1 %PosPE%) do set /p "="
set /p "PE1="
set /p "PE2="
set /p "PE3="
set /p "PE4="
set /p "Machine1="
set /p "Machine2="
)
REM HexDump löschen.
del "%dump%"
REM Prüfungen
set "Bit="
if "%PE1%%PE2%%PE3%%PE4%"=="50450000" (
if "%Machine2%%Machine1%"=="8664" (
set "Bit=64"
) else (
set "Bit=32"
)
) else (
REM PE Signatur nicht gefunden.
endlocal &exit /b 0
)
REM Alles OK
endlocal &exit /b %Bit%
Bei Fragen, bitte fragen
Grüße
rubberman
EDIT: @112778 's Anregungen aufgegriffen und "Magic" gegen "Machine" ausgetauscht.

Hi,
@ rubberman
%Magic% kommt 4 Byte hinter der 32-Bit-langen PE-Kennung und muss
0x014c (also 50 45 00 00 4c 01) für 32-Bit und
0x8664 (also 50 45 00 00 64 86) für 64-Bit lauten.
Ein 16-Bit-Programm (trunk_16.exe aus Win7-64 z. B.) hat hinter der 2-Byte PE-Kennung keine 2 Nullen, sondern irgendwas Anderes.
@ ChrisDynamite
Du könntest dumpbin.exe (benötigt Link.exe) aus Microsoft Visual C ++ - Paketen nutzen mit dem Parameter /HEADERS
damit kannst du die Informationen ohne Umweg direkt aus der Exe/dll holen.
Wenn du ein kleines Programm haben möchtest, das ich in Delphi gestrickt habe (44k), melde dich per PN. ;)
Der Header vom VLC-2.1.0-pre1-64-Bit-Setup ist übrigens falsch und somit zum Testen unbrauchbar.
Gruß
@ rubberman
%Magic% kommt 4 Byte hinter der 32-Bit-langen PE-Kennung und muss
0x014c (also 50 45 00 00 4c 01) für 32-Bit und
0x8664 (also 50 45 00 00 64 86) für 64-Bit lauten.
Ein 16-Bit-Programm (trunk_16.exe aus Win7-64 z. B.) hat hinter der 2-Byte PE-Kennung keine 2 Nullen, sondern irgendwas Anderes.
@ ChrisDynamite
Du könntest dumpbin.exe (benötigt Link.exe) aus Microsoft Visual C ++ - Paketen nutzen mit dem Parameter /HEADERS
damit kannst du die Informationen ohne Umweg direkt aus der Exe/dll holen.
Wenn du ein kleines Programm haben möchtest, das ich in Delphi gestrickt habe (44k), melde dich per PN. ;)
Der Header vom VLC-2.1.0-pre1-64-Bit-Setup ist übrigens falsch und somit zum Testen unbrauchbar.
Gruß
@112778
msdn.microsoft.com/en-us/library/ms809762.aspx
... kann also für 32 Bit Programme auch was ganz Anderes als 0x014C sein 
"Magic" steht im IMAGE_OPTIONAL_HEADER
Und ...
msdn.microsoft.com/en-us/magazine/cc301805.aspx
Von 16-Bit-Anwendungen war zum Glück nie die Rede
Grüße
rubberman
%Magic% kommt 4 Byte hinter der 32-Bit-langen PE-Kennung und muss
0x014c (also 50 45 00 00 4c 01) für 32-Bit und
0x8664 (also 50 45 00 00 64 86) für 64-Bit lauten
Nope. Was du meinst ist "Machine" aus dem IMAGE_FILE_HEADER und gibt die Ziel-CPU an.0x014c (also 50 45 00 00 4c 01) für 32-Bit und
0x8664 (also 50 45 00 00 64 86) für 64-Bit lauten
msdn.microsoft.com/en-us/library/ms809762.aspx
0x14d Intel i860
0x14c Intel I386 (same ID used for 486 and 586)
0x162 MIPS R3000
0x166 MIPS R4000
0x183 DEC Alpha AXP
"Magic" steht im IMAGE_OPTIONAL_HEADER
IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b.
Und ...
msdn.microsoft.com/en-us/magazine/cc301805.aspx
The only correct, Microsoft-approved way of differentiating between the two formats [32 und 64-Bit-Anwendungen] is via the value of the Magic field in the IMAGE_OPTIONAL_HEADER
Von 16-Bit-Anwendungen war zum Glück nie die Rede
Grüße
rubberman

@ rubberman
Wenn du meinst ....
Deshalb liefert dein Script ja auch keine brauchbaren bzw. falsche Ergebnisse.
Meine Abfrage mit allen Exe-Dateien unter Windows7-64 hat jedenfalls alle korrekt erkannt.
Microsoft hat asuch einen Artikel veröffentlicht, in dem ausschließlich auf 014C für 32-Bit-Programme verwiesen wird. Den such ich jetzt aber nicht extra nochmal.
Nur die Ziel-CPU ist interessant: Intel x86/x64 und die entsprechenden von AMD. Was interessieren für Windows-OS-Nutzer andere CPUs (vielleicht außer IA64) mit denen Windows-Programme garantiert nicht laufen......
Gruß
Wenn du meinst ....
Deshalb liefert dein Script ja auch keine brauchbaren bzw. falsche Ergebnisse.
Meine Abfrage mit allen Exe-Dateien unter Windows7-64 hat jedenfalls alle korrekt erkannt.
Microsoft hat asuch einen Artikel veröffentlicht, in dem ausschließlich auf 014C für 32-Bit-Programme verwiesen wird. Den such ich jetzt aber nicht extra nochmal.
Nur die Ziel-CPU ist interessant: Intel x86/x64 und die entsprechenden von AMD. Was interessieren für Windows-OS-Nutzer andere CPUs (vielleicht außer IA64) mit denen Windows-Programme garantiert nicht laufen......
Gruß
Deshalb liefert dein Script ja auch keine brauchbaren bzw. falsche Ergebnisse.
Hmm, kann ich nicht bestätigen. Habe ausgiebig auf Win7 x86 und x64 getestet. Bislang ohne Negativergebnis.Nur die Ziel-CPU ist interessant: Intel x86/x64 und die entsprechenden von AMD. Was interessieren für Windows-OS-Nutzer andere CPUs (vielleicht außer IA64) mit denen Windows-Programme garantiert nicht laufen......
Da hast du schon Recht. Letztlich kann man auch einfach auf 0x8664 testen. Ist es was Anderes, dann ist es eine 32-Bit-Anwendung. Egal, ich hab nichts anderes gefunden als den Verweis auf "Magic" im oben verlinkten Beitrag. Der ist allerdings nicht mehr so ganz up to date (2002). Schon möglich, dass M$ inzwischen eine andere Lesart als Maß der Dinge annimmt Grüße
rubberman

Hmm, kann ich nicht bestätigen. Habe ausgiebig auf Win7 x86 und x64 getestet. Bislang ohne Negativergebnis.
Gleich die ersten beiden, die ich getestet habe, lieferten mir 32-Bit zurück, obwohl es 64bitter waren: Totalcommander tcmdx64.exe und df64.exe (Defraggler).Die Magic # ist dafür imo nicht gedacht.
Magic # definiert 10B = PE für die meisten Windows-Anwendungen. 20B = PE+ ist, soweit ich das verstanden habe, gedacht für Image-Limitierungen bis 2 GB. Die DOCX mit den neuesten Infos aus 2013 heißt pecoff_v83.docx
http://download.microsoft.com/download/9/C/5/9C5B2167-8017-4BAE-9FDE-D5 ...
Ob der Link funktioniert? *gg
Der geht jedenfalls: http://msdn.microsoft.com/library/windows/hardware/gg463125
Thnx, ich acker mich mal durch 
Auf den ersten Blick haben die aber immer noch alle möglichen Prozessoren im Repertoir
Naja, falls sich Chris noch mal melden sollte, fass ich das Script meinetwegen auch noch mal an (schon passiert) ... Ich halte es aber immer noch für sinnvoller die Programme vorher nach 32 und 64 Bit zu sortieren, statt im Nachgang den Fileheader zu untersuchen.
Grüße
rubberman
Auf den ersten Blick haben die aber immer noch alle möglichen Prozessoren im Repertoir
Naja, falls sich Chris noch mal melden sollte, fass ich das Script meinetwegen auch noch mal an (schon passiert) ... Ich halte es aber immer noch für sinnvoller die Programme vorher nach 32 und 64 Bit zu sortieren, statt im Nachgang den Fileheader zu untersuchen.
Grüße
rubberman