In der JCL (TJclPeImage) wird beim Laden die WinAPI MapAndLoad verwendet.
Unglücklicherweise verwendet diese AnsiStrings statt Unicodestrings.
Kombiniert damit das nich überalle 8.3-Dateinamen mehr existieren schlägt damit die Prüfung ob eine Exe-Datei 64-Bit ist fehlt (LoadedImage.FileHeader^.FileHeader.Machine aus dem TJclPeImage).

Was wäre die alternative festzustellen ob eine Exe 64 Bit ist? Ich würde das eigentlich benötigen ohne das ich dise Exe Starte?

Zitat von Bernhard Geyer:

Was wäre die alternative festzustellen ob eine Exe 64 Bit ist?

Im Prinzip das Gleiche, was diese Funktion macht. In den PE-Header der EXE schauen, ob die Bits für 64-Bit gesetzt sind.

https://docs.microsoft.com/en-us/win...ebug/pe-format
z.B. IMAGE_FILE_MACHINE_AMD64 und IMAGE_FILE_MACHINE_IA64

Also bei mir funktioniert folgende Funktion seit vielen Jahren einwandfrei, auch unter Win64 und für 64-bit Executables:

markieren

Delphi-Quellcode:

function GetExecutableArchitecture(const AFileName: string): Word;
var
  LI: TLoadedImage;
begin
  if NOT MapAndLoad(PAnsiChar(AnsiString(AFileName)), nil, @LI, False, True) then
      RaiseLastOsError;
  Result := LI.FileHeader.FileHeader.Machine;
  UnMapAndLoad(@LI);
end;

Ich gebe zu, dass es auch etwas problematisch sein dürfte mit Unicode-Zeichen im Pfad, aber bislang hab ich keine andere Möglichkeit gefunden (aber in den vergangenen paar Jahren auch nicht mehr danach gesucht).

Grüße
Dalai

Zitat von Dalai:

Also bei mir funktioniert folgende Funktion seit vielen Jahren einwandfrei, auch unter Win64:[DELPHI]

Na dann lass es mal auf eine Exe im Verzeichnis E:\עברית laufen unter Deutschen Windows laufen.
Und auch ein GetShortPathName funktioniert nicht, wenn für E:\ diese Logik der kurzen Dateinnamen nicht aktiv ist.

Oder die Datei nach TEMP kopieren und dort MappenUndLaden

Zitat von himitsu:

Zitat von Bernhard Geyer:

Was wäre die alternative festzustellen ob eine Exe 64 Bit ist?

Im Prinzip das Gleiche, was diese Funktion macht. In den PE-Header der EXE schauen, ob die Bits für 64-Bit gesetzt sind.

https://docs.microsoft.com/en-us/win...ebug/pe-format
z.B. IMAGE_FILE_MACHINE_AMD64 und IMAGE_FILE_MACHINE_IA64

Also ein Brutalversion wie hier vorgeschlagen:
https://superuser.com/questions/3584...bit-on-windows
Also
1, Suche "PE" in der Datei
2, Überspringe die beiden Null-Zeichen (\0\0)
3, Wenn jetzt d† kommt ($64 $86) kommt dann hat man AMD64

Zitat von himitsu:

Oder die Datei nach TEMP kopieren und dort MappenUndLaden

Ist leider eine 320 MB-Exe (das 32-Bit "könnte noch vorkommen) Gegenstück ist aktuell 270 MB.
Hatte ich mir auch schon überlegt. Wenn dann noch Netzwerk oder VPN dazu kommt hat man gleich ein SAP erschaffen ...

Hey, die sind das Nonplusultra .... jeder will so sein wie die.


Pssst, wenn MapAndLoad bissl Fehlertollerant ist,
dann reicht es ja das erste KB/MB zu kopieren.

Du brauchst ja nur die zwei/drei Header am Anfang.



Das sind zwei Records.
Im Ersten ab Adresse 0 steht drin, wo der Andere anfängt und dort drin findeste dann das interessante Byte/Feld.
An Position X steht der Offset zum Zweiten, dort noch bissl was drauf rechnen (im zweiten Record) und djeses Byte dann auslesen.

Zitat von himitsu:

Pssst, wenn MapAndLoad bissl Fehlertollerant ist,
dann reicht es ja das erste KB/MB zu kopieren.

Du brauchst ja nur die zwei/drei Header am Anfang

Mach jetzt meinen selbstlesen. 1 kB + "Suche PE" und dann 2 Byte weiter die 2 Byte einlesen.
Ich denke damit kann ich die nächsten 3-5 Jahre überbrücken, bis 32-Bit auch für uns komplett gestorben ist.

Zitat von Bernhard Geyer:

Na dann lass es mal auf eine Exe im Verzeichnis E:\עברית laufen unter Deutschen Windows laufen.

Deswegen sagte ich ja

Zitat von Dalai:

Ich gebe zu, dass es auch etwas problematisch sein dürfte mit Unicode-Zeichen im Pfad

Zitat:

Und auch ein GetShortPathName funktioniert nicht, wenn für E:\ diese Logik der kurzen Dateinnamen nicht aktiv ist.

In welcher Verbindung steht das mit der Frage, welche Architektur ein Executable hat?

Grüße
Dalai