Der globale Hook treibt mich zum Wahnsinn

[idefix2]

Hallo,

nachdem mein globaler Hook sich hartnäckig weigert, sich zu benehmen, habe ich schrittweise das Problem isoliert, jetzt stehe ich aber absolut an:

Es ist offensichtlich so, dass Windows, wenn eine DLL installiert ist, in der ein globaler Hook aktiv ist, für jedes Programm, das ein Tastaturereignis geschickt bekommt, ein neuen separaten Datenbereich anlegt!!!

Das heisst, der Hook ist zwar global installiert, aber die Instanz der Hook DLL hat keinen Zugriff auf die Variablenwerte, die bei der Hookbehandlung eines anderen Programms gesetzt werden, und umgekehrt.

Um das zu überprüfen, habe ich eine Hookroutine geschrieben, die die Ziffer 1 generiert, wenn ein F gedrückt wird und die vorige taste auch F war. Die Hookroutine merkt sich also in einer globalen Variablen der DLL die Taste, die zuletzt gedrückt wurde. Wenn ich jetzt in irgend ein Fenster mehrere F hintereinander eingeben, wird ab dem zweiten F zu jedem F zusätzlich eine 1 angezeigt. Wechsle ich mit dem Eingabefocus in irgend ein anderes Programm, dann ist meine Hookroutine zwar dort auch aktiv, sie weiss aber nichts von der Eingabe in die anderen Fenster, und sie produziert zu einem F nur die Taste 1, wenn in das aktuelle Programm unmittelbar vorher F eingegeben worden ist, egal ob in der Zwischenzeit in einem anderen Programm irgend eine Tastatureingabe gemacht worden ist.


P.S.: In allen Hook-Tutotials und Anleitungen, wie auch in der Windows API-Dokumentation findet man die Vorgangsweise, den bei der Erstellung des Hooks zurückgegeben HookHandle in einer Variablen zu speichern und beim Aufruf von CallNextHookEx als ersten Parameter zu übergeben. Wenn man das in einem globalen Hook so macht, ist das aber reine Makulatur, weil die globale Variable HookHandle hat bei jedem Aufruf der Callbackprozedur von einem anderen Programm aus den Wert 0. Ich habe das sicherheitshalber eben noch überprüft. Offenbar fängt aber CallNextHookEx mit dem Parameter ohnehin nichts an, sodass es egal ist, sonst könnten alle diese globalen Hooks überhaupt nicht funktionieren.

[Neutral General]

Hallo,

Dieses Verhalten ist normal und auch naja.. gut so.
Du könntest das ganze mit Pipes oder MMFs lösen denke ich.
Ist zwar etwas umständlicher, aber ich sehe keine andere Möglichkeit.

Gruß
Neutral General

[idefix2]

Was ist daran bitte "gut so"? oder auch nur "naja.. gut so"?

Dass eine DLL, wenn sie von verschiedenen programmen geladen wird, separate Datenbereiche hat, ist natürlich in Ordnunng. Aber hier ist das ja nicht der Fall. Die DLL wird nur einmal geladen, und soll in der globalen Messagequeue hängen. Dass ein neuer Datenbereich angelegt wird, sobald eine Message an ein anderes Programm geht, ist in meinen Augen absoluter Schwachsinn. Früher sind Leute für geringere Blödheiten geköpft oder gevierteilt worden :x

Mit "Sicherheitsfeature" ist das nicht zu rechtfertigen - wie Du richtig geschrieben hast, lässt sich tiemlich sicher, aber mit ziemlichem Aufwand, mittels eines MMF ein Workaround programmieren, sodass das für jemand, der Übles im Sinn hat, kein wirkliches Hindernis ist. Dafür macht es jedem, der aus irgend einem Grund ohne jede schlechte Absicht einen globalen Hook schreiben will, das Leben schwer, und frisst möglicherweise zur Laufzeit völig unnötig Ressourcen - ich weiss nicht, mit wieviel Overhead der Zugriff auf ein MMF statt auf eine lokaler Variable verbunden ist.

[Neutral General]

Hi,

Mit meinen Mapped Streams (TIPCStream) lässt sich das ganze ohne großen Aufwand realisieren.

Gruß
Neutral General

[Tryer]

Zitat:

Zitat von idefix2

globalen Messagequeue

Zitat:

Zitat von idefix2

absoluter Schwachsinn

Genau. Warum sollte das System eine ewig lange globale Liste aller Nachrichten führen, wenn es die doch sofort an den richtigen Prozess verteilen kann. Das hat halt den Nebeneffekt das sich ein entsprechender Hook auch in jeden Prozess einklinken muss, und aufgrund der Trennung der Prozessräume ist das dann halt jedesmal eine neue Instanz. Was dann für den Hook "global" sein soll, das muss halt auch prozessübergreifen sein. Die Lösung wurde bereits genannt.

Grüsse, Dirk

[idefix2]

Zitat:

Warum sollte das System eine ewig lange globale Liste aller Nachrichten führen,

Richtig, warum sollte es. Das wäre ja auch nicht nötig. Es genügt ja, dass jede Nachricht beim Erstellen an die Kette der globalen Hooks gesendet wird. Ob die entsprechende Hookroutine im Prozessraum des Zielprozesses oder im Prozessraum des Programms liegt, das die DLL ursprünglich geladen hat, wäre vom Aufwand her für das Windows-System ziemlich egal sein. Für ersteres gibt es aber m.M.n. keine vernünftigen Argumente, es macht nur jegliche Programmierung unnötig kompliziert, und sorgt auch für absolut unnötigen Overhead zur Laufzeit.

[idefix2]

@ Neutral General -
danke, schau ich mir an.

[Mithrandir]

Bitte nutze in Zukunft den Edit-Button, wenn du noch etwas ergänzen möchtest. Doppelpostings sehen wir hier ungern. ;)

[Delphi-Laie]

Hallo idefix2!

Ich stand vor dem gleichen Problem und mußte diesbezüglich auch Lehrgeld bezahlen, schaust Du bitte hier!

Das Problem löste ich so, daß die DLL - bzw. alle ihre Kopien im Speicher - sich beim jeweiligen Hookereignis die nötigen Daten aus Dateien (!) holen. Das ist zwar nicht so elegant wie die Interprozeßkommunikation, hat aber den Vorteil, daß die Datenmenge beliebig groß sein kann, während sie bei der Interprozeßkommunikation ja zum Zeitpunkt des Programmierens bzw. Compilierens festgelegt sein muß. Auch stellte ich fest, daß die Festplatte damit keinesfalls strapaziert oder gar malträtiert wird (die LED leuchtet nicht auf), sondern daß die Dateien (wegen häufigen Zugriffes?) im Datenträgercache zu liegen scheinen und von dort aus angefordert werden. Wenn jemand die Festplatten schikaniert, dann ist es Windows mit seinem ewigen exzessiven Temporär-, Auslagerungs- und hiberfile-Gerödel selbst.

Heute würde ich es vielleicht dennoch mit Interprozeßkommunikation lösen, weil es einfach eleganter und gehobener ist. Mein damaliges Programm umzustricken, habe ich aber beim besten Willen keinen Antrieb mehr.

[wicht]

Zitat:

...hat aber den Vorteil, daß die Datenmenge beliebig groß sein kann, während sie bei der Interprozeßkommunikation ja zum Zeitpunkt des Programmierens bzw. Compilierens festgelegt sein muß.

IPC geht mit beliebig großen Daten. Gut, vielleicht nicht beliebig groß, aber die Größe der Daten muss nicht während des Programmierens festgelegt werden. Das geht ganz dynamisch während der Ausführungszeit.