Global Hooks

[Memger]

Hi Leute!
hab da mal eine etwas knifflige frage!
und zwar geht es mal wieder um das berühmte thema "systemweite hooks".
ist ja alles schön und gut, funktioniert ja ach ganz toll, usw. aber wie sieht das unter der haube aus???
aus welchem grund MUSS ein systemweiter hook (abgesehen von den low-level hooks, die ja auch in einer exe gesetzt werden können und trotzdem systemweit sind) in eine Dll ausgelagert werden? was ist hier der technische hintergrund??
würde mich mal interessieren....

gruß
Memger

[Robert Marquardt]

Ist doch ganz einfach.<br>
Eine DLL kann in den Adressraum aller Programme eingeblendet werden.<br>
Das ist genau was mit einer Hook-DLL passiert. Sie wird allen laufenden Applikationen zugeschlagen.<br>
Mit einem Programm ist das nicht moeglich und daher ist der programmlokale Hook auch nicht wirklich global

[Memger]

Hi Robert!
ok klar...die frage war dumm gestellt....was ich meinte war, warum die lowlevel hooks NICHT in eine dll ausgelagert werden müssen???!

gruß
MeMge

[Nico Bendlin]

Dann sage einfach, welchen Du meinst!<br>
Was bitte ist ein LowLevel-Hook?<br>

Gruß Nic

[Memger]

Hi!
immer schön freundlich bleiben ;-)
also..ein low-level hook läßt sich nur unter NT/2000 einrichten. soweit ich das verstanden habe, wird diese hook-funktion schon aufgerufen BEVOR der jeweilige thread überhaupt die betreffende message in seine message-que gepostet bekommt (während ein "normaler" systemweiter hook aufgerufen wird, kurz bevor der jeweilige thread die nachricht verarbeiten will, oder per peekmessage(...no_remove) sie sich "anschaut"). meine frage dazu war dann, warum diese low-level hook funktion auch in einer "normalen anwendung" installiert seind darf?

gruß
memge

[Robert Marquardt]

Das liegt dann daran das Microsoft immer mal wieder alles anders macht.<br>
Windows NT/2000 ist ein voellig anderes Betriebssystem als Win9x. Nur die Win32-Schnittstelle ist gleich.<br>
Inzwischen hat Microsoft angefangen auch in Win9x Callback-Benachrichtigungen abseits der Message Queues einzurichten. Namentlich Multimediatimer und z. B. Notifications. Mutexe (aka WaitForSingleObject etc) sind auch solche abseitigen Wege.<br>
Das ist zwar prinzipiell alles das Gleiche und koennte alles ueber Messages behandelt werden, aber der Implementationsansatz von Windowsprogrammen ist einfach so Scheisse das Microsoft immer mal wieder solche Nebenwege impementiert

[Memger]

Hi Robert!
irgendwie verstehe ich dich nicht ganz....
was soll das heißen, "abseitige wege"??? funktionen zur thread/prozesssynchronisation waren schon IMMER in win95 implementiert, also inwiefern "abseitige wege"?? dass nt und 95 "under the hood" teilweise ganz anders arbeiten ist mir schon klar....aber irgendwie beantwortet das meine frage nicht...es sei denn du hast die antwort geschickt versteckt ;-)
...klar könnte man threads über messages synchronisieren...aber mit welcher performance bitte?????
und was soll der letzte satz von wegen scheiß implementationsansatz von windowsprogrammen bedeuten? wenn du schon so scharf kritisierst, dann solltest du es vielleicht auch begründen ;-)
aber so ganz losgeworden bin ich meine frage eigentlich immernoch nicht...

gruß
Memge

[Robert Marquardt]

Abseitige Wege: Die Benachrichtigung beim Auftreten eines asynchronen Ereignisses ist gewoehnlich eine Message. Warum also hat Microsoft weitere Benachrichtigungswege eingerichtet? Eine Notification ist doch eigentlich nichts anderes als das Bestellen einer Benachrichtigung.

Scheiss Implementationsansatz: Ein Programm musss doch tatsaechlich die Messagepumpe selbst bedienen. Damit kann aber nicht mehr sichergestellt werden das ein Programm auf unbekannte Messages reagiert. Jetzt schleppt jedes Windowsprogramm einen Wasserkopf zum Messageempfang mit sich herum. Das sollte besser im System enthalten sein. Dort koennte man dann auch Notifications und andere spezielle Messages effizient behandeln

[Memger]

Hi Robert!
zu "abseitige wege":
meiner meinung nach ist benachrichtigung nicht gleich benachrichtigung, denn wartet mein thread z.B. per waitforsingleobject auf einen asynchronen rückruf, dann ist dieser weg sicherlich wesentlich performanter als das gleiche über eine mesageque. denn das einfache "resumen" eines threads ist in jedem fall schneller als das senden einer nachricht, das auswerten und erst dann das fortsetzten des threads!!!!
unabhängig davon kann mit diesen "weiteren benachrichtigungswegen" beispielsweise auf mehrere objekte gewartet werden, während gleichzeitig auf benutzereingaben reagiert werden kann (msgwaitformultipleobjects)!! in diesem fall also vermutlich eine fkt. um dem entwickler das leben zu erleichtern...

des weiteren bin ich mit deinen ausführungen zu "scheiß implementationsansatz" nicht ganz einverstanden ;-)
...wie soll denn bitteschön mehr flexibilität beim auswerten von messages bereitsgestellt werden, wenn das jeweilige programm diese auswertung nicht selber vornimmt????? so kann doch jedes programm nach belieben filtern, oder??
abgesehen davon verstehe ich nicht wo das problem bei der reaktion auf "unbekannte" nachrichten liegt..??

gruß
Memge

[Robert Marquardt]

Bei der Messageauswertung ist das Problem, das es tatsaechlich einem Programm erlaubt ist die Message nicht einmal dem Defaulthandler vorzulegen. Es ist dem Defaulthandler ja unbenommen die Message zu ignorieren, aber damit kann das System einem Programm keine unbekannte Message schicken und dann eine Reaktion darauf implementieren wenn es vonm System-Defaulthandler behandelt wird.
Abgesehen davon sind die meisten Programme mit einer Default-Messagepumpenfunktion zufrieden und muessen trotzdem eine eifgene Pumpe implementieren. Eigentluch sollte das Betriebssystem solche Standardfunktionalitaet bereitstellen. Dafuer ist es schliesslich da. So wird nur Platz auf Platte und im speicher verschwendet

[Nico Bendlin]

Das man die Nachrichten vor dem DefaultHandler filtern kann ist doch gut (wird eh' selten gebraucht, aber wenn, warum nicht!).<p>
Und Dein Problem mit "unbekannten" Nachrichten kann ich überhaupt nicht nachvollziehen. Eine Reaktion auf eine "unbekannte" Nachricht zu erwarten ist doch etwas viel verlangt (was soll passieren?).<p>
Und es gibt Mittel und Wege, um eigene Nachrichten-IDs systemweit zu registrieren, sodaß man gefahrlos mit einer "privaten" Nachricht broadcasten kann, da diese nur von denen verarbeitet wird, die sie kennen...

Gruß Nic

[Hagen Reddmann]

das Message Prinzip entspricht auch dem Object orientierten design. Wenn ich in einer großen Menschenmenge unterhalte, hören nur die zu die sich angesprochen fühlen, mich verstehen und mir auch antworten können. Also ich find's absolut logisch. Besser als die Ansätze beim Linux, worauf nämlich Roberts bemerkungen hinauslaufen (glaube ich
Das es mehrere Wege gibt finde ich auch richtig und logisch, wir menschen sprechen und denken nicht immer die gleiche Sprache, und da die maschinen vom Menschen "abstammen" ist es nur allzu verständlich das auch diese verschiedene Sprechweisen unterstützen !
Auch sollte man mal die Entwickler solcher Systeme verstehen. Da kommen viele wichtige Leute, der eine wills so der andere so, der eine glaubt sein System ist das beste der andere glaubt von sich das gleiche. Schlussendlich können wir nur nach 10 Jahren Praxiserfahrung entscheiden welches System sich am meisten verbreitet hat. Und wies momentan aussieht laufen die meisten Anwendersystem unter MS Systemen.

Gruß Hage

[Memger]

robert: dass ein programm eine message nicht einmal dem default-handler vorlegen muss, ist doch gerade eine "coole" sache, denk z.B. man customdraw eigenschaften in delphi.....und mal ehrlich was ist denn das für'n quatsch von wegen platz auf platte und im speicher vrschwenden???? wer's darauf anlegt, sollte wohl nicht in delphi programmieren.....sondern nur noch generische programme schreiben, ohne vcl, mfc oder sonst was.....

gru memge

[Assarbad]

low-level hooks sind NICHT hooks die anders arbeiten als die andern hooktypen, NUR sie ermöglichen das abfangen auch jener nachrichten die die HL-hooks nicht erst bekommen (systemtasten etc pp)

fast alle hooktypen können sowohl lokal als auch global installiert und entsprechend genutzt werden ... der unterschied ist einzig wie weit der hook wirkt (lokal / global).

steht aber alles im PSDK bzw Win32.HLP

Ass