Ergebnis der Suchanfrage

• Forum: Win32/Win64 API (native code)

  AW: Alternative für MapAndLoad

   
    by Bernhard Geyer, 1. Dez 2020
  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.
• Forum: Win32/Win64 API (native code)

  AW: Alternative für MapAndLoad

   
    by Bernhard Geyer, 1. Dez 2020
  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 ...
• Forum: Win32/Win64 API (native code)

  AW: Alternative für MapAndLoad

   
    by Bernhard Geyer, 1. Dez 2020
  Also ein Brutalversion wie hier vorgeschlagen:
  https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-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
• Forum: Win32/Win64 API (native code)

  AW: Alternative für MapAndLoad

   
    by Bernhard Geyer, 1. Dez 2020
  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.
• Forum: Win32/Win64 API (native code)

  Alternative für MapAndLoad

   
    by Bernhard Geyer, 1. Dez 2020
  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...