Alternative für MapAndLoad

[Bernhard Geyer]

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?

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1478307)

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

[Dalai]

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

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

[Bernhard Geyer]

Zitat:

Zitat von Dalai (Beitrag 1478309)

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.

[himitsu]

Oder die Datei nach TEMP kopieren und dort MappenUndLaden :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1478308)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1478307)

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

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1478311)

Oder die Datei nach TEMP kopieren und dort MappenUndLaden :stupid:

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 ...

[himitsu]

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


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.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1478316)

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.

[Dalai]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1478310)

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

Deswegen sagte ich ja

Zitat:

Zitat von Dalai (Beitrag 1478309)

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

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1478339)

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

Die Funktion MapAndLoad wird nur verwendet, um die Platform (Bitigkeit) der Anwendung auszulesen. :zwinker:

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1478342)

Die Funktion MapAndLoad wird nur verwendet, um die Platform (Bitigkeit) der Anwendung auszulesen. :zwinker:

Ja eben. Deswegen sehe ich nicht, was GetShortPathName damit zu tun hat.

PS: Die durch MapAndLoad gefüllte Datenstruktur LOADED_IMAGE lässt noch mehr zu, als nur die Plattform auszulesen.

Grüße
Dalai

[himitsu]

Die MapAndLoad-API gibt es nur als ANSI. (obwohl es die scheinbar erst seit WinXP gibt und die WinNT-Linie eigentlisch schon ewig auf Unicode ist)

Heißt, dass Unicode-Dateinamen damit nicht möglich sind und man sie z.B. durch GetShortPathName in ANSI umwandeln müsste.

[Dalai]

Ah, jetzt verstehe ich den Zusammenhang. Ja, das ist nachvollziehbar. Vielleicht könnte man mit den Funktionen MapViewOfFile und ImageNtHeader etwas machen, um die Datenstruktur IMAGE_NT_HEADERS füllen zu lassen. Halte ich für besser, als manuell in der EXE rumzusuchen.

Übrigens gibt's MapAndLoad im Win2k auch schon.

Grüße
Dalai

[mael]

Ich würde die Funktion selbst schreiben, ohne MapAndLoad, sondern einfach mit einem TFileStream, da ist die Dateigröße auch egal und das funktioniert performant.

Ich kann meinen getesteten Code hier teilen, um die Bittigkeit einer EXE zu prüfen, falsch gewünscht.

Edit: LoadLibraryEx() mit LOAD_LIBRARY_AS_DATAFILE, ist sonst was man verwendet um Module (DLLs/EXE usw.) in den Speicher zu laden, und dann dort direkt mit Pointern weiter zu arbeiten. Windows verwendet hier automatisch Paging und wird nur die relevanten Teile laden. Aber wenn etwas mit virtuellen Addressen zu tun hat, muss man trotzdem umrechnen. Und die Offsets in den Dateiheadern muss man auch beachten. Feste Offsets/Konstanten sollte man nicht verwenden, um an die richtige Stelle zu springen.

[mael]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1478307)

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

Besser ist es die Offsets die in den Headern angegeben sind zu verwenden. Dann funktioniert das mit allen Images, egal von welchem Compiler oder wie die optimiert wurden (solange sie korrekt sind natürlich).
Der Code bleibt trotzdem knapp, etwa eine Bildschirmseite.