DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinden?

[Delphi-Laie]

Zitat:

Zitat von implementation

Das ist keine Macke, sondern das liegt einfach daran, dass tlhelp32 für 32 Bit geschrieben ist.
Wenn du eine 64-Bit-Version davon gefunden hast, und es immer noch nicht läuft, dann solltest du dich wundern.
Aber 32 und 64 Bit sind nunmal unterschiedlich. Da kannste nix machen.

Die tlhelp32-Unit tut im Quelltext nicht viel mehr, als neben den nötigen Konstanten-, Typ- und Variablendeklarationen einige - die entsprechenden - Funktionen der kernel32.dll zu importieren. Was soll denn an einem DLL-Funktionsimport 32- oder 64-bittig sein? Wenn das 64-Bit-Lazarus die Unit fehlerfrei compiliert, dann liegt das Compilat ja wohl hoffentlich in einer 64-Bit-Version vor? Und falls nicht, wäre es auch nicht schlimm, schließlich funktioniert ja immerhin die 32-Bit-Version.

Es klappte ja nicht einmal (in meinem Programm, nicht Luckies), nur die relevanten Funktionen aus der tlhelp32-Unit zu extrahieren und unter Verzicht auf diese Unit in der uses-Anweisung nur die Funktionsimporte direkt in die MainForm-Unit zu kopieren. Es compiliert, aber die Funktionalität in der Exe ist bestenfalls lausig.

Immerhin funktionieren die 32-Bit-Compilate von Luckies Programm (Delphi und Lazarus) ja auch unter Windows 64 Bit! Nur diese eine Funktion "GetExeStringFromProcID" will in der 64-Bit-Version anscheinend nicht, aber wo hat die 32- oder 64-Bit-Spezifika?? Sie ruft CreateToolHelpSnapShot und - wohl vergeblich - Process32First und Proces32Next auf. Diese Aufrufe haben jedoch keine Bitbreitenspezifik?!

Zitat:

Zitat von implementation

Bist du dir sicher, dass die Daten nicht heil bei der DLL ankommen? Vielleicht liegt auch in der der Fehler. Oder ist es gar eine 32-Bit-DLL?

Die Daten, die die DLL aus Dateien zieht, kommen heil bei dieser an, das merke ich ja am Programmverhalten. Die DLL ist 64 Bit und funktioniert auch teilweise - wenigstens der Modulschnappschuß und die 64-Bit-Hooks. Also, 64 Bit werden tatsächlich erzeugt.

Letztlich kann sich jeder anhand meines Anhangs weiter oben selbst davon überzeugen, daß irgendetwas mit dem 64-Bit-Compilat nicht stimmt.


Zur Zeit probiere, eher fummele ich an der Funktion "GetWindowModuleFileName", denn die wäre vielleicht eine brauchbare Alternative gewesen, aber an der klappt ja überhaupt nichts.

[Delphi-Laie]

Allmählich habe ich den Eindruck, daß der Fehler überall sonst gesucht wird, nur nicht bei Lazarus.

Nunja....sicher ist man selbst in den allermeisten Fällen wirklich der Schuldige, aber immer?

Daß es an der tlhelp32-Unit nicht liegen kann, versuche ich mit jetzt einem weiteren Argument zu untermauern. Im Gegensatz zum Prozeßschnappschuß funktioniert mit meinem Lazarus 64 Bit der Modulschnappschuß, mit dem sich ebenfalls der Exe-Dateiname ermitteln läßt. Nach meiner Beobachtung ist es immer der erste Eintrag des Modulschnappschusses (also Modul32First), der den Exe-Dateinamen liefert, der Rest sind DLL-Dateinamen.

So habe ich auf die Schnelle in Luckies schon oben strapaziertem WinInfo-Programm den Modulschnappschuß implementiert, den tlhelp32 analog zur Verfügung stellt. Mit diesem Schnappschuß funktioniert die Ermittlung und folglich Ausgabe des Exe-Dateinamens sowohl in der 32- als auch in der 64-Bit-Version!

Anbei die beiden vollständig funktionstüchtigen Compilate mit den Quelltexten.

Reicht das als Beweis, daß die tlhelp32-Unit unschuldig ist?

Grüße

Delphi-Laie

[Delphi-Laie]

Ist zwar schon ein wenig her, aber trotzdem.... allen, die mir in dieser Diskussion halfen, danke ich noch einmal herzlich!

Inzwischen bin ich mir sicher, daß es ein Fehler in Lazarus ist; der ausführliche Fehlerbericht findet sich hier.

Ich beobachte es immer wieder: Wenn man irgendwo einen Fehler ausgrub, sei es in Windows, sei es in Delphi oder in Lazarus, und den in den Foren berichtet, kommt allerdings reflexartig immer ein Abstreiten desselben bzw. ein Schieben desselben auf einen selbst - warum bloß?!

[JamesTKirk]

Hi!

Ich weiß nicht, ob du es mitbekommen hast (oder wirst :mrgreen: ), aber ich habe dir in deinem Bugreport geantwortet und ein Anwendung angehängt, die du vielleicht mal testen könntest (näheres in dem dortigen Post).

Leider habe ich es nicht geschafft ein 64-Bit Windows zu installieren, da die Installation in QEMU die ganze Zeit meinte nen BSOD bringen zu müssen... leider hab ich auch nur Windows 7 x64 und Windows Server 2008 R2 x84 zur Verfügung und kein Windows XP x64 oder Windows Server 2003 x64 (die gibt's bei uns an der Uni einfach nicht zum runterladen :( ).

Gruß,
Sven

[Delphi-Laie]

Tausend Dank, alles weitere dort (auch mein wichtigster Teilerfolg!!)!

[Delphi-Laie]

Hallo JamesTKirk/Sven,

mein Bugreport wurde etwas überraschend geschlossen, allerdings artete es dort zugegebenermaßen auch immer mehr zur Diskussion aus.

Mir sind noch zwei Dinge klargeworden:

1. Die Modulenumeration funktioniert bei den Systemprozessen (Ring 0 / Kernelmodus) deshalb nicht, weil das (anforderbare) Privileg dazu fehlt.
2. explorer.exe und cmd.exe sind 64-Bit-Prozesse, während andere, die über ihre Module bereitwillig auskunfteten, 32-Bit-Prozesse waren. Es war wohl unter der Würde der 64-Bit-Prozesse, einem anfragenden 32-Bit-Prozeß Auskunft über die Module zu geben (salopp formuliert).

Wenn nun Lazarus noch standardmäßig mit der die tlhelp64-Unit oder mit einer angepaßten jwatl32help (jwatl64help?!) aufgebohrt würde, wäre es optimal, und solche Bugreports wie meiner wären dann überflüssig.

Dir nochmals herzlichen Dank! Leider kann ich Dmitry an dieser Stelle kaum danken....

Delphi-Laie

[JamesTKirk]

Hi!

Zitat:

Zitat von Delphi-Laie

mein Bugreport wurde etwas überraschend geschlossen, allerdings artete es dort zugegebenermaßen auch immer mehr zur Diskussion aus.

1. wurde er nicht "geschlossen", sondern auf "resolved" gesetzt (schließen musst du ihn noch). Du könntest ihn wieder öffnen, aber das bringt aus meiner Sicht nichts, da das Problem ja nun nicht mehr im FPC Code liegt
2. das Thema ist aus Sicht des Bugreports erledigt (denn es funktioniert ja jetzt prinzipiell, wenn ich dass deiner Antwort dort richtig entnommen habe) und jede weitere Diskussion sollte nicht im Bugtracker stattfinden

Zitat:

Zitat von Delphi-Laie

1. Die Modulenumeration funktioniert bei den Systemprozessen (Ring 0 / Kernelmodus) deshalb nicht, weil das (anforderbare) Privileg dazu fehlt.

Jupp, das kann dir unter Windows leicht mal passieren und ist der Normalfall, wenn man nicht als Administrator unterwegs ist (wie es im Konzept von NT ja eigentlich gedacht war... *seufz*).

Zitat:

Zitat von Delphi-Laie

2. explorer.exe und cmd.exe sind 64-Bit-Prozesse, während andere, die über ihre Module bereitwillig auskunfteten, 32-Bit-Prozesse waren. Es war wohl unter der Würde der 64-Bit-Prozesse, einem anfragenden 32-Bit-Prozeß Auskunft über die Module zu geben (salopp formuliert).

Ich würde nicht behaupten, dass dies "unter der Würde" der Prozesse ist, sondern vielmehr eine Designentscheidung von Microsoft (schließlich geben dir nicht die Prozesse Auskunft über sich, sondern das Betriebssystem gibt dir die Auskunft und dieses hat die volle Kontrolle über die Informationen). Es ist wahrscheinlich zu riskant einem 32-Bit Prozess auf diese Weise Zugang zu den 64-Bit Modulen zu gewähren (schließlich kann ein 32-Bit Prozess nicht mit 64-Bit virtuellem Speicher umgehen, etc).

Zitat:

Zitat von Delphi-Laie

Wenn nun Lazarus noch standardmäßig mit der die tlhelp64-Unit oder mit einer angepaßten jwatl32help (jwatl64help?!) aufgebohrt würde, wäre es optimal, und solche Bugreports wie meiner wären dann überflüssig.

1. jwatlhelp32 ist Teil von Free Pascal (genauer: FCL), nicht Lazarus. Es gibt also keinen Grund Lazarus "aufzubohren".
2. Der Bug wurde gefixt und wird eventuell Teil des nächsten Releases werden (eventuell werde ich bitten den Fix in FPC 2.4.1 zu mergen), es besteht also gar kein Bedarf eine tlhelp64 einzuführen. Zudem heißt der C-Header auch in Win64 noch tlhelp32.h :mrgreen:
3. Du hast einen Fehler in Free Pascal Code entdeckt und damit ist es nur gut und recht, wenn du diesen berichtest, selbst wenn ein ähnlicher Report bereits vorhanden und in der Entwicklerversion bereits gefixt wurde. Ganz nach dem Prinzip "doppelt hält besser". Und selbst wenn man Lazarus oder Free Pascal mit einer hypothetischen tlhelp64 ausstatten würde, so könnte auch diese noch Bugs enthalten, die berichtet werden wollen.

Wenn du noch weiter Probleme mit der tlhelp32 frag also bitte hier weiter (oder in einem neuen Thread, je nachdem was den Mods lieber ist :zwinker: ).

Gruß,
Sven

[Delphi-Laie]

Howdy!

Zitat:

Zitat von JamesTKirk

Zitat:

Zitat von Delphi-Laie

mein Bugreport wurde etwas überraschend geschlossen, allerdings artete es dort zugegebenermaßen auch immer mehr zur Diskussion aus.

1. wurde er nicht "geschlossen", sondern auf "resolved" gesetzt (schließen musst du ihn noch). Du könntest ihn wieder öffnen, aber das bringt aus meiner Sicht nichts, da das Problem ja nun nicht mehr im FPC Code liegt

??
Nach dem Einloggen konnte ich weder editieren noch etwas neues verfassen. Damit hat sich das für mich erledigt. Ob ich das schließe oder nicht, wird wohl für niemanden mehr irgendeine Bedeutung haben.

Zitat:

Zitat von JamesTKirk

Zitat:

Zitat von Delphi-Laie

1. Die Modulenumeration funktioniert bei den Systemprozessen (Ring 0 / Kernelmodus) deshalb nicht, weil das (anforderbare) Privileg dazu fehlt.

Jupp, das kann dir unter Windows leicht mal passieren und ist der Normalfall, wenn man nicht als Administrator unterwegs ist (wie es im Konzept von NT ja eigentlich gedacht war... *seufz*).

Administrator bin ich auf eigenen Computern grundsätzlich. Es fehlte das zusätzlich zu ordernde Privileg. Da ich nunmehr weiß, wie man sich das holt, werden alle Programme, für die es nützlich ist, damit ausgestattet werden.

Zitat:

Zitat von JamesTKirk

Zitat:

Zitat von Delphi-Laie

Wenn nun Lazarus noch standardmäßig mit der die tlhelp64-Unit oder mit einer angepaßten jwatl32help (jwatl64help?!) aufgebohrt würde, wäre es optimal, und solche Bugreports wie meiner wären dann überflüssig.

1. jwatlhelp32 ist Teil von Free Pascal (genauer: FCL), nicht Lazarus. Es gibt also keinen Grund Lazarus "aufzubohren".

Einverstanden. Ich zähle den Unterbau mit dazu (auch der Bugtrucker heißt ja Lazarus), auch wenn er genaugenommen (s)eine eigene Bezeichnung hat.

Zitat:

Zitat von JamesTKirk

(eventuell werde ich bitten den Fix in FPC 2.4.1 zu mergen)

Du bist also in das Lazarus-/FP(C)-Projekt stärker als Otto Normalsterblicher (wie meine Wenigkeit einer ist) involviert?

Dank & Gruß

Delphi-Laie

[BUG]

[OT]

Was ist ein Bugtrucker? Ein Bug, der LKW fährt? Oder meinst du den Bugtracker?
Weil du dieses Wort ja in insgesamt 3 Beiträgen (in unterschiedlichen Themen) erwähnst :warn:

[JamesTKirk]

Hi!

Zitat:

Zitat von Delphi-Laie

??
Nach dem Einloggen konnte ich weder editieren noch etwas neues verfassen. Damit hat sich das für mich erledigt. Ob ich das schließe oder nicht, wird wohl für niemanden mehr irgendeine Bedeutung haben.

Am unteren Ende deines Bugreports (vor den Kommentaren) müssten sich jetzt (wenn du eingeloggt bist) drei Buttons und eine Combobox befinden. Ein Button heißt "Change status to:" und ein anderer "Reopen issue". Mit dem ersten kannst du den Bugreport endgültig schließen (und dabei einen abschließenden Kommentar abgeben) und mit dem zweiten kannst du den Eintrag wieder neu öffnen (ist dann nützlich, wenn man mit der Lösung nicht einverstanden ist :mrgreen: ).

Zitat:

Zitat von Delphi-Laie

Administrator bin ich auf eigenen Computern grundsätzlich. Es fehlte das zusätzlich zu ordernde Privileg. Da ich nunmehr weiß, wie man sich das holt, werden alle Programme, für die es nützlich ist, damit ausgestattet werden.

Ich ziehe das "principle of least privilege" vor (und unter Windows 7 funktioniert das mittlerweile sogar anständig :mrgreen:), aber das muss ja jeder selbst wissen, was er bevorzugt. ;)

Zitat:

Zitat von Delphi-Laie

Zitat:

Zitat von JamesTKirk

Zitat:

Zitat von Delphi-Laie

Wenn nun Lazarus noch standardmäßig mit der die tlhelp64-Unit oder mit einer angepaßten jwatl32help (jwatl64help?!) aufgebohrt würde, wäre es optimal, und solche Bugreports wie meiner wären dann überflüssig.

1. jwatlhelp32 ist Teil von Free Pascal (genauer: FCL), nicht Lazarus. Es gibt also keinen Grund Lazarus "aufzubohren".

Einverstanden. Ich zähle den Unterbau mit dazu (auch der Bugtrucker heißt ja Lazarus), auch wenn er genaugenommen (s)eine eigene Bezeichnung hat.

Das liegt wohl daran, dass du dir nur die Bugs für Lazarus anzeigen lässt. Geht man oben auf "All Projects" oder "FPC", so heißt er "freepascal bugtracker", aber das nur am Rande. :D

Zitat:

Zitat von Delphi-Laie

Zitat:

Zitat von JamesTKirk

(eventuell werde ich bitten den Fix in FPC 2.4.1 zu mergen)

Du bist also in das Lazarus-/FP(C)-Projekt stärker als Otto Normalsterblicher (wie meine Wenigkeit einer ist) involviert?

Ich bin auf jeden Fall kein Stammentwickler von einem der beiden Projekte, falls du das meinst. Allerdings habe ich schon einige Patches abgeliefert, die eingebunden wurden und berichte auch fleißig Bugs und Feature Requests, die mir so auf- und einfallen. Zudem bin ich bei den Hauptmailinglisten eingetragen und scheue auch nicht da mal zu antworten oder ein eigenes Thema zu starten.
Das mit dem Mergen war nur ein Angebot von mir an dich, dass ich an die FPC-Community weiterleiten würde, da ich weiß, wo man so eine Bitte anbringt.

Gruß,
Sven

[Delphi-Laie]

Zitat:

Zitat von JamesTKirk

Das mit dem Mergen war nur ein Angebot von mir an dich, dass ich an die FPC-Community weiterleiten würde, da ich weiß, wo man so eine Bitte anbringt.

Ja, tue es doch - bitte! Auch ich bin natürlich an weiterer Perfektionierung dieses freien und plattformübergreifenden Pascal-Compilers interessiert. Müßte ich keine Extra-Unit mehr meinen Quelltexten hinzufügen.

Danke nochmals für alles!

[Nintendo]

Für den Fall das die Dll partout nicht geladen wird, habe ich die Idee, die Dll mit eigenen Routinen in den Ram zu laden, dann halt alle Relozierung selber zu erledigen und dann meinetwegen mit Assembler Call Befehlen die Funktionen der Dll aufzurufen.

Hier habe ich dazu einen anderen Thread eröffnet, der sich mit dem Problem unter Voraussetzung verschiedener Wortbreiten mit der Problematik beschäftigt:

http://www.delphipraxis.net/177781-l...ml#post1238082

Die Exporttabelle mit den anzusprechenden Funktionen wird, wie ich bisher verstanden habe durch eine Struktur mit Namen

IMAGE_EXPORT_DIRECTORY

repräsentiert. Ich kann aber die Adrees dieser Tabelle in den im Netz verfügbaren Dokus nirgends finden.

Delphi-Quellcode:

Delphi-Quellcode:
  PIMAGE_DOS_HEADER = ^IMAGE_DOS_HEADER;
  IMAGE_DOS_HEADER = record // DOS .EXE header
    e_magic : WORD; // Magic number { MZ for exe }
    e_cblp : WORD; // Bytes on last page of file
    e_cp : WORD; // Pages in file
    e_crlc : WORD; // Relocations
    e_cparhdr : WORD; // Size of header in paragraphs
    e_minalloc : WORD; // Minimum extra paragraphs needed
    e_maxalloc : WORD; // Maximum extra paragraphs needed
    e_ss : WORD; // Initial (relative) SS value
    e_sp : WORD; // Initial SP value
    e_csum : WORD; // Checksum
    e_ip : WORD; // Initial IP value
    e_cs : WORD; // Initial (relative) CS value
    e_lfarlc : WORD; // File address of relocation table
    e_ovno : WORD; // Overlay number
    e_res : array[0..3] of WORD; // Reserved words
    e_oemid : WORD; // OEM identifier (for e_oeminfo)
    e_oeminfo : WORD; // OEM information; e_oemid specific
    e_res2 : array[0..9] of WORD; // Reserved words
    e_lfanew : Longint; // File address of new exe header
  end;
 
  PIMAGE_FILE_HEADER = ^IMAGE_FILE_HEADER;
   IMAGE_FILE_HEADER = record
    Machine : WORD;
    NumberOfSections : WORD;
    TimeDateStamp : DWORD;
    PointerToSymbolTable : DWORD;
    NumberOfSymbols : DWORD;
    SizeOfOptionalHeader : WORD;
    Characteristics : WORD;
  end;

  TLocation = record
   case DWORD of
    0: (PhysicalAddress: DWORD);
    1: (VirtualSize: DWORD);
  end;

  IMAGE_SECTION_HEADER = record
    Name : array[0..IMAGE_SIZEOF_SHORT_NAME-1] of BYTE;
    Misc : TLocation;
    VirtualAddress : DWORD;
    SizeOfRawData : DWORD;
    PointerToRawData : DWORD;
    PointerToRelocations: DWORD;
    PointerToLinenumbers: DWORD;
    NumberOfRelocations : WORD;
    NumberOfLinenumbers : WORD;
    Characteristics : DWORD;
  end;

  PIMAGE_DATA_DIRECTORY = ^IMAGE_DATA_DIRECTORY;
   IMAGE_DATA_DIRECTORY = record
    VirtualAddress: DWORD;
    Size: DWORD;
  end;

  PIMAGE_BASE_RELOCATION = ^IMAGE_BASE_RELOCATION;
   IMAGE_BASE_RELOCATION = record
    VirtualAddress: DWORD;
    SizeOfBlock: DWORD;
  end;

  PIMAGE_OPTIONAL_HEADER32 = ^IMAGE_OPTIONAL_HEADER32;
   IMAGE_OPTIONAL_HEADER32 = record
    //
    // Standard fields.
    //

    Magic : WORD;
    MajorLinkerVersion : BYTE;
    MinorLinkerVersion : BYTE;
    SizeOfCode : DWORD;
    SizeOfInitializedData : DWORD;
    SizeOfUninitializedData : DWORD;
    AddressOfEntryPoint : DWORD;
    BaseOfCode : DWORD;
    BaseOfData : DWORD;

    //
    // NT additional fields.
    //

    ImageBase : DWORD;
    SectionAlignment : DWORD;
    FileAlignment : DWORD;
    MajorOperatingSystemVersion : WORD;
    MinorOperatingSystemVersion : WORD;
    MajorImageVersion : WORD;
    MinorImageVersion : WORD;
    MajorSubsystemVersion : WORD;
    MinorSubsystemVersion : WORD;
    Win32VersionValue : DWORD;
    SizeOfImage : DWORD;
    SizeOfHeaders : DWORD;
    CheckSum : DWORD;
    Subsystem : WORD;
    DllCharacteristics : WORD;
    SizeOfStackReserve : DWORD;
    SizeOfStackCommit : DWORD;
    SizeOfHeapReserve : DWORD;
    SizeOfHeapCommit : DWORD;
    LoaderFlags : DWORD;
    NumberOfRvaAndSizes : DWORD;
    DataDirectory : array[0..IMAGE_NUMBEROF_DIRECTORY_ENTRIES-1] of IMAGE_DATA_DIRECTORY;
  end;

  PIMAGE_NT_HEADERS32 = ^IMAGE_NT_HEADERS32;
   IMAGE_NT_HEADERS32 = record
    Signature : DWORD;
    FileHeader : IMAGE_FILE_HEADER;
    OptionalHeader : IMAGE_OPTIONAL_HEADER32;
  end;
  
  TThunkCharacterisics = record
  case DWORD of
   0: (Characteristics : DWORD); { 0 for terminating null import descriptor        }
   1: (OriginalFirstThunk: DWORD); { RVA to original unbound IAT (PIMAGE_THUNK_DATA) }
  end;

  PIMAGE_IMPORT_DESCRIPTOR = ^IMAGE_IMPORT_DESCRIPTOR;
   IMAGE_IMPORT_DESCRIPTOR = record
    Thunk : TThunkCharacterisics;
    TimeDateStamp : DWORD; { 0 if not bound,                                }
                                            { -1 if bound, and real date\time stamp          }
                                            {     in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND) }
                                            { O.W. date/time stamp of DLL bound to (Old BIND)      }

    ForwarderChain : DWORD; { -1 if no forwarders                           }
    Name : DWORD;
    FirstThunk : DWORD; { RVA to IAT (if bound this IAT has actual addresses)  }
  end;
  
  TCode = record
  case LongWord of
   0 : (Offset,Segment: Word);
   1 : (LinearAddr: LongWord);
  end;
  
  PIMAGE_EXPORT_DIRECTORY = ^IMAGE_EXPORT_DIRECTORY;
   IMAGE_EXPORT_DIRECTORY = record
    Characteristics : DWORD;
    TimeDateStamp : DWORD;
    MajorVersion : WORD;
    MinorVersion : WORD;
    Name : DWORD;
    Base : DWORD;
    NumberOfFunctions : DWORD;
    NumberOfNames : PDWORD;
    AddressOfFunctions : PDWORD; { RVA from base of image }
    AddressOfNames : PDWORD; { RVA from base of image }
    AddressOfNameOrdinals : PDWORD; { RVA from base of image }
  end;

Ist vieleicht hier schon in einem Datenfeld die Adresse der Exporttabelle verborgen?

Die Struktur der .EXE Datei ist nur bis hierher dokumnentiert. Danach kommen die Section Header. Wo aber ist die Exporttabelle -> IMAGE_EXPORT_DIRECTORY?