Nachrichten vollkommen abfangen

[Mephistopheles]

Zitat:

Zitat von c113plpbr

Zitat:

Zitat von Mephistopheles

Ist das repräsentativ? Bei mir war bereits das Gegenteil der Fall.

Dann hast du wohl etwas falsch gemacht ...

Oh. Danke für den Tip, das wußte ich nicht.
Es ist so schwer den falschen Weg zu meiden;
Eine gesunde Einstellung für einen Entwickler ... wenn mein Programm beim Benutzer abstürzt "hat der Benutzer wohl was falsch gemacht".
Mag sein, daß es damals noch nicht funktionierte (es ist schon einige Zeit her). Aber dennoch sollte ein solches Paket immer stabilstmöglich laufen.

Zitat:

Zitat von c113plpbr

Zitat:

Zitat von Mephistopheles

Das kommt immer auf die Menge von Fenstern an. Prinzipiell magst du recht haben. Aber an welcher Prozessorleistung (CPU + GPU) hast du denn die 2 FPS gemessen? Ich denke mal an meinem K6-II 450 (16 MB Grafikkarte) war es nicht, oder? Und ja - auch wenn Entwicklerrechner oft sehr leistungsfähig sind - die meisten Rechner kommen nicht an einen Pentium HT ran.

(es war ja nur ein beispiel) Siehe mein Nachtrag.

Ich brauche ca. 30 Minuten von mir bis zur Arbeit. Jetzt die Quizfrage: welches Fahrzeug benutze ich (oder überhaupt eines?), mit welcher Durchschnittsgeschwindigkeit bewege ich mich fort und welche Entfernung lege ich dabei zurück?
Wie du vielleicht siehst, ist dein Beispielvergleich sinnlos ohne die Rahmendaten.
Genauso sinnlos wie vermeintliche Optimierungen von diversen Assemblerprogrammierern.

Zitat:

Zitat von c113plpbr

[edit]
Man, warum musst du alles, was ich sage so kritisieren, als ob ich überhaupt keine ahnung hätte?
bisher hab ich von dir nur behauptungen gehört, keine beweise. Beweise hab ich ja schon (im gegensatz zu dir) versucht aufzubringen ...

Ich bin der Geist der stets verneint!
Und das mit Recht: denn alles, was entsteht,
ist werth, daß es zu Grunde geht.
Da du Kritik offenbar nicht als konstruktiv (du könntest ja die Rahmendaten nennen) auffassen kannst, verbleibe ich mit besten Grüssen.

Zitat:

Zitat von c113plpbr

Und selbst wenn 1000 aufrufe pro sekunde kämen (was relativ unwarscheinlich ist), wäre api hooking nicht viel langsamer als windowseigene methoden.
Aber ich habe nie behauptet, dass dies die "ultimative lösung" ist, es war nur ein vorschlag. Und welchen weg OrallY hinterher geht, bleibt doch wohl noch ihm überlassen.
[/edit]

Tut es. Habe auch nichts anderes behauptet.
Das mit der Geschwindigkeit hängt aber nach wie vor von den Rahmenbedingungen ab. Aber wie ich sehe renne ich damit gegen massive Wände. Nichtsdestotrotz ist Hooking, sei es nun SSDT-Hooking oder eben API-Hooking im Usermode eine potentiell riskante Sache. Ein PC ist ein sehr universelles Gerät mit reichhaltiger Softwareauswahl. Wie willst du garantieren, daß deine Software mit allen sauber interagiert *). Und vor allem, warum willst du nicht die windowseigenen und damit offiziell unterstützten (und potentiell sichereren) Methoden (Message-Hooks WH_* z.B.) Methoden einem API-Hook vorziehen?
Ja, ein API-Hook mag irrelevant sein. Woher nimmst du aber die Annahme, daß dein Programm das einzige wäre, welches eine bestimmte API hookt?

*) Wenn ein Programm - sagen wir MS Word - abstürzt, nachdem dein Programm installiert wurde; und wenn dies passiert, weil bei Word getrickst wurde (dein Programm sei also nicht schuld für mein Besipiel) - glaubst du im Ernst, daß man Word deshalb runterwerfen und die Schuld geben würde?

[c113plpbr]

Zitat:

Zitat von Mephistopheles

Eine gesunde Einstellung für einen Entwickler ... wenn mein Programm beim Benutzer abstürzt "hat der Benutzer wohl was falsch gemacht".

Du drehst mir die Worte im Mund um. So war das nicht gemeint.
Denn wenn du das Programm geschrieben hast, war es wohl nicht des Benutzers Schuld.

Zitat:

Zitat von Mephistopheles

Mag sein, daß es damals noch nicht funktionierte (es ist schon einige Zeit her). Aber dennoch sollte ein solches Paket immer stabilstmöglich laufen.

Willst du damit sagen, dass alles was du programmierst, auf anhieb perfekt funktioniert? Irren ist nun mal Menschlich, und jeder macht Fehler. Aber Fehler kann man ausbessern, und so sollte man jedem die Chance geben, seine Fehler auszubessern, bevor man über ihn, oder sein Werk richtet.
Vielleicht läuft es ja nun stabil, zumindest bin ich der Meinung.

Zitat:

Zitat von Mephistopheles

Ich brauche ca. 30 Minuten von mir bis zur Arbeit. Jetzt die Quizfrage: welches Fahrzeug benutze ich (oder überhaupt eines?), mit welcher Durchschnittsgeschwindigkeit bewege ich mich fort und welche Entfernung lege ich dabei zurück?
Wie du vielleicht siehst, ist dein Beispielvergleich sinnlos ohne die Rahmendaten.
Genauso sinnlos wie vermeintliche Optimierungen von diversen Assemblerprogrammierern.

Damit du es dir auch ausrechnen kannst: 6 Zyklen muss deine CPU (bei einer leeren funktion) mehr schuften. (laut Detours)
Natürlich ist hier nichts anderes miteinberechnet, was getan werden müsste, dass die ganze Aktion auch sinnvoll ist.
Ich will damit eigentlich nur sagen: auch ein Windows-Hook verbrät (mind.) soviel, wie ein API Hook. Daher sind API-Hook und Windows-Hook von der Performance her gleich einzustufen.

Zitat:

Zitat von Mephistopheles

Da du Kritik offenbar nicht als konstruktiv (du könntest ja die Rahmendaten nennen) auffassen kannst, verbleibe ich mit besten Grüssen.

Die Rahmendaten von der Detours Zeitmessung kann ich dir leider nicht nennen, da ich sie nicht besitze, so leid es mir tut. (Nun, man könnte natürlich das Verhältnis der beiden Werte ausrechnen, und es auf einen durchschnittsrechner aus dem Jahre 1999 beziehen ('99 wurde dieses Dokument verfasst), und es dann auf das schlecht-, bzw. bestmögliche auslegen, doch es wird warscheinlich ein Wert bleiben, der vernachlässigbar klein ist. Und wenn nicht, werden Systemeigene Methoden trotzdem kaum schneller sein können.)
Zu meiner "Messung": Wie schon aus meiner Aussage hervorgeht, hab ich dies nicht gemessen, sondern geschätzt.

Zitat:

Zitat von Mephistopheles

Das mit der Geschwindigkeit hängt aber nach wie vor von den Rahmenbedingungen ab. Aber wie ich sehe renne ich damit gegen massive Wände. Nichtsdestotrotz ist Hooking, sei es nun SSDT-Hooking oder eben API-Hooking im Usermode eine potentiell riskante Sache. Ein PC ist ein sehr universelles Gerät mit reichhaltiger Softwareauswahl. Wie willst du garantieren, daß deine Software mit allen sauber interagiert *). Und vor allem, warum willst du nicht die windowseigenen und damit offiziell unterstützten (und potentiell sichereren) Methoden (Message-Hooks WH_* z.B.) Methoden einem API-Hook vorziehen?
Ja, ein API-Hook mag irrelevant sein. Woher nimmst du aber die Annahme, daß dein Programm das einzige wäre, welches eine bestimmte API hookt?

Wie gesagt, ich habe nie behauptet, dass es die beste Methode ist. Aber es sollte ein Vorschlag sein. Ob man diesen nun "ernst" nimmt, oder nicht, überlasse ich jedem selbst.

ciao, Philipp

[Christian Seehase]

Moin ihr Beiden,

ich möchte doch dringend darum bitten wieder zum Thema zu kommen, und die begonnene Diskussion ggf. in einem anderen Thread fortzuführen.
Danke.

Falls ihr wollt, kann dieser Thread auch geteilt werden, und als Basis für einen neuen dienen.
Dann bitte per PN melden.

[OrallY]

Danke für die rege Beteiligung :wink:.

Zitat:

Zitat von Mephistopheles

Mich würde erst einmal interessieren, was genau du erreichen möchtest, denn dies wäre hier wohl besser. Ich habe noch nicht einmal deinen aktuellen Lösungsansatz komplett deiner Beschreibung entnehmen können. Hingegen zu einer bestimmten Problemstellung kann man eventuell Alternativen finden.

Ein berechtigter Einwandt, dem ich hiermit nachgehen möchte:

• Programmfunktion:
  Der Benutzer soll im Endeffekt (genaue Funktion ist irrelevant) überall auf dem Bildschirm mit gedrückter rechter Maustaste zeichnen können. Die Anwendung selbst läuft im Hintergrund und soll den Dienst bereitstellen.
• Problem:
  Drückt man irgendwo auf dem Bildschirm die Maustaste, erzeugt das loslassen beispielsweise ein Kontextmenü. Dies jedoch will ich vermeiden. Dabei muss das Programm natürlich unterscheiden, wann es ein Kontextmenü zulassen soll (die Maus wurde zwischen Drücken und Loaslassen der Maustaste gar nicht oder kaum bewegt) und wann es genau dies verhindern soll (die Maus bewegt sich bei gedrückter Maustaste).
• Bisherige Lösung:
  Ein globaler LowLevel-Mousehook der anhand den oben genannten Parametern entscheidet, ob er die Mausnachricht durch den Aufruf von CallNextHookEx weiterleiten oder durch Nichtaufruf die Nachrichten blockieren soll.
  
  
  Delphi-Quellcode:

  library mousehook;
  
  uses
    Windows,
    Messages;
  
  const
    WM_MOUSEHOOK = WM_USER + $0400;
  
  type
    TFileMapStuff = record
      aHandle: Cardinal;
      BlockRMB: boolean;
    end;
  
  const
    BLOCKINGCOUNT = 10;
  
  var
    HookHandle        : HHook;
    FileMapObj        : THandle;
    FileMapView       : ^TFileMapStuff;
    ComRec            : TFileMapStuff;
    MouseEventCounter : integer;
    MouseDown         : boolean;
  
  function MouseHookProc(Code: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
  var
    mhs: ^TMouseHookStruct;
  begin
    if (wParam <> WM_RBUTTONDOWN) and
       (wParam <> WM_RBUTTONUP) and
      Result := CallNextHookEx(HookHandle, Code, wParam, lParam);
  
    if code = HC_ACTION then
    begin
      FileMapObj := OpenFileMapping(FILE_MAP_READ, False,'HookMapFile');
      try
        if FileMapObj <> 0 then
        begin
          FileMapView := MapViewOfFile(FileMapObj, FILE_MAP_READ, 0, 0, 0);
          ComRec := FileMapView^;
          UnmapViewOfFile(FileMapView);
          CloseHandle(FileMapObj);
        end;
      except
        Result := CallNextHookEx(HookHandle, Code, wParam, lParam);
        exit;
      end;
  
      if ((wParam = WM_RBUTTONUP) or (wParam = WM_RBUTTONDOWN)) and not ComRec.BlockRMB then
      begin
        Result := CallNextHookEx(HookHandle, Code, wParam, lParam);
        exit;
      end;
  
      PostMessage(ComRec.aHandle, WM_MOUSEHOOK, wParam, lParam);
  
      if (wParam <> WM_RBUTTONDOWN) and
         (wParam <> WM_RBUTTONUP) and
         (wParam <> WM_MOUSEMOVE) then
        exit;
  
      if wParam = WM_RBUTTONDOWN then
      begin
        MouseDown := true;
        MouseEventCounter := 0;
      end
      else if wParam = WM_RBUTTONUP then
      begin
        MouseDown := false;
  
        if MouseEventCounter < BLOCKINGCOUNT then //Wurde die Maus nicht/kaum bewegt Tastenklick simulieren
        begin
          mhs := Pointer(lParam);
          MouseEventCounter := BLOCKINGCOUNT;
          mouse_event(MOUSEEVENTF_RIGHTDOWN, mhs^.pt.X, mhs^.pt.Y, 0, 0);
          mouse_event(MOUSEEVENTF_RIGHTUP, mhs^.pt.X, mhs^.pt.Y, 0, 0);
          Result := CallNextHookEx(HookHandle, Code, wParam, lParam);
          exit;
        end
      end;
  
      if (wParam = WM_MOUSEMOVE) and (MouseDown) then
        if MouseEventCounter < BLOCKINGCOUNT then
          Inc(MouseEventCounter);
  
    end;
  end;
  
  procedure InstallHook; stdcall;
  begin
    HookHandle := SetWindowsHookEx(14, @MouseHookProc, hInstance , 0); //14 ist der LL-MouseHook
    MouseEventCounter := 0;
    MouseDown := false;
  end;
  
  procedure UninstallHook; stdcall;
  begin
    UnhookWindowsHookEx(HookHandle);
  end;
  
  exports
  InstallHook,
  UninstallHook;
  
  begin
  end.

  Wie schon gesagt, ich kann mir nicht vorstellen, dass es so sauber ist, CallNextHookEx einfach nicht aufzurufen, oder?
  
• Weiteres Problem:
  Mit diesem Lösungsansatz funktioniert zwar das Blockieren der Maustaste, jedoch tritt das im 1. Posting genannte Problem mit dem Highlighting auf. Aus diesem Grund möchte ich verhindern, dass ein Fenster die Nachrichten, die für das Highlighting verantwortlich sind, während des Zeichnens erhält.

greez

P.S.: Ich stelle gerade fest, dass für die Benutzung des MadCodeHooks anscheinend Adminprivilegien erforderlich sind. Liege ich da richtig? Wäre dies der Fall würde diese Möglichkeit für mich schon mal nicht in Frage kommen :|.

[Mephistopheles]

Zitat:

Zitat von c113plpbr

Du drehst mir die Worte im Mund um. So war das nicht gemeint.
Denn wenn du das Programm geschrieben hast, war es wohl nicht des Benutzers Schuld.

Aber wenn Madshi den nichtfunktionierenden Teil geschrieben hat, war es dennoch meine Schuld (s.o. dein Kommentar)?

Zitat:

Zitat von c113plpbr

Willst du damit sagen, dass alles was du programmierst, auf anhieb perfekt funktioniert? Irren ist nun mal Menschlich, und jeder macht Fehler. Aber Fehler kann man ausbessern, und so sollte man jedem die Chance geben, seine Fehler auszubessern, bevor man über ihn, oder sein Werk richtet.

Sollte man? Da bin ich nicht so sicher. In wievielen kommerziellen Projekten hast du schon mitgearbeitet?
Mit Worten läßt sich trefflich streiten,
Mit Worten ein System bereiten,
An Worte läßt sich trefflich glauben,
Von einem Wort läßt sich kein Iota rauben.

Zitat:

Zitat von c113plpbr

Ich will damit eigentlich nur sagen: auch ein Windows-Hook verbrät (mind.) soviel, wie ein API Hook. Daher sind API-Hook und Windows-Hook von der Performance her gleich einzustufen.

Nicht aber von Stabilität und Zuverlässigkeit. Kleiner Tip: Kernelmode-Programmierer behelfen sich seit langem mit SSDT-Patching. Es ist potentiell sehr gefährlich. Mit Windows XP und 2003 wurden einige neue Funktionen eingeführt, die statt Hooking einen Callback-Mechanismus einführen (nichts anderes also als Fensterhooks, nur ohne die Möglichkeit der "Interception"). Welchen Mechanismus bevorzugst du? Wie erklärst du einem Kunden, daß er einen nichtzertifizierten Treiber bekommt, obwohl ein zertifizierter unter Nutzung neuester Möglichkeiten möglich wäre?

Zitat:

Zitat von c113plpbr

Wie gesagt, ich habe nie behauptet, dass es die beste Methode ist. Aber es sollte ein Vorschlag sein. Ob man diesen nun "ernst" nimmt, oder nicht, überlasse ich jedem selbst.

Sieht nach einem Konsens aus.

Zitat:

Zitat von OrallY

Programmfunktion:
Der Benutzer soll im Endeffekt (genaue Funktion ist irrelevant) überall auf dem Bildschirm mit gedrückter rechter Maustaste zeichnen können. Die Anwendung selbst läuft im Hintergrund und soll den Dienst bereitstellen.

Sieht nach einem Job für SetCapture() aus.

Zitat:

Zitat von OrallY

Problem:
Drückt man irgendwo auf dem Bildschirm die Maustaste, erzeugt das loslassen beispielsweise ein Kontextmenü. Dies jedoch will ich vermeiden. Dabei muss das Programm natürlich unterscheiden, wann es ein Kontextmenü zulassen soll (die Maus wurde zwischen Drücken und Loaslassen der Maustaste gar nicht oder kaum bewegt) und wann es genau dies verhindern soll (die Maus bewegt sich bei gedrückter Maustaste).

Das mit dem Kontextmenü verstehe ich nicht, denn bei SetCapture() bekommt NUR dein Fenster Input.

Zitat:

Zitat von OrallY

Wie schon gesagt, ich kann mir nicht vorstellen, dass es so sauber ist, CallNextHookEx einfach nicht aufzurufen, oder?

Es ist prinzipiell schon "mal" okay, aber so generisch wie bei dir sieht ganz böse aus. Im Notfall hülfe nur noch Strg+Alt+Entf gegen deinen Hook, wenn der Amok läuft ;)

Zitat:

Zitat von OrallY

Weiteres Problem:
Mit diesem Lösungsansatz funktioniert zwar das Blockieren der Maustaste, jedoch tritt das im 1. Posting genannte Problem mit dem Highlighting auf. Aus diesem Grund möchte ich verhindern, dass ein Fenster die Nachrichten, die für das Highlighting verantwortlich sind, während des Zeichnens erhält.

Würde bei SetCapture() nicht auftreten. Lies dich mal schlau und implementiere deinen Ansatz. Bei weiteren Fragen postest du die einfach hier, bzw. postest hier einen Link zu einem neuen Thread (damit ich darauf aufmerksam werde).

Zitat:

Zitat von OrallY

P.S.: Ich stelle gerade fest, dass für die Benutzung des MadCodeHooks anscheinend Adminprivilegien erforderlich sind. Liege ich da richtig? Wäre dies der Fall würde diese Möglichkeit für mich schon mal nicht in Frage kommen :|.

Theoretisch sollten bei soetwas immer Debug-Privilegien reichen. Denn über Debug-Privilegien kannst du höchste Systemrechte erlangen.
Wenn es nur um das Hooken von Prozessen der gleichen Privilegienstufe (z.B. gleicher Benutzer) geht, sollte es aber möglich sein dies ohne spezielle Privilegien zu erreichen. Ich kenne seine aktuelle Implementierung nicht und habe keine Zeit mir das mit DeDe näher anzuschauen.

Es gab da mal eine OpenSource-Implementierung mit SetCapture(), die du eventuell als Anschauungsmaterial verwenden kannst. Zu finden war das (ist schon lange her) unter:
http://www.bendlins.de/nico/delphi/
Der Autor treibt sich meines Wissens auch hier im Forum herum, versuche ihn einfach zu kontaktieren. Ansonsten sind mir nur C/C++-Implementierungen bekannt.

Im Platform SDK gibt es ein Beispiel namens "Drawing Lines with the Mouse":
ms-help://MS.PSDK.1033/winui/winui/windowsuserinterface/userinput/mouseinput/usingmouseinput.htm
(Der Link gilt mit dem letzten aktuellen 2003er Platform SDK)

[OrallY]

Das Problem mit SetCapture ist, dass ich es ja erst setzen kann, wenn irgendwo die Nachricht WM_RBUTTONDOWN auftritt. Das hat wiederrum die Folge, dass ich genau diese Nachricht nicht mehr mit SetCapture "aufhalten" kann, da das MouseCapturing erst aktiv wird, nachdem WM_RBUTTONDOWN schon verschickt wurde. Der Effekt ist z.B. dass Fenster aktiviert werden oder der Cursor in einem Editor gesetzt.

[Mephistopheles]

Hast du schonmal versucht das SetCapture() aufzurufen, ohne ein sichtbares Fenster haben zu müssen? Das einzige Problem sollte doch sein, daß du irgendein spezielles Signal geben mußt, damit dein Fenster bescheid bekommt, daß es SetCapture() aufrufen muß. Ich hab's zugegebenermaßen so noch nicht getestet - da bisher immer ein Ausgangspunkt (/-fenster) für SetCapture() sichtbar existierte.

[OrallY]

Zitat:

Zitat von Mephistopheles

Das einzige Problem sollte doch sein, daß du irgendein spezielles Signal geben mußt, damit dein Fenster bescheid bekommt, daß es SetCapture() aufrufen muß.

Welches Signal jedoch und wann soll es ausgelöst werden? Der Auslöser zum MouseCapturing ist ja eine Mausnachricht ("Maustaste unten"), die ich mit einem Hook auffange. Jedoch schlüpft dann die Auslöser-Nachricht durch das Netz und erreicht eine Anwendung.

Meine Anwendung soll ja im Hintergrund laufen und erst aktiv werden, wenn der Benutzer z.b. die rechte Maustaste drückt um zu zeichnen.

[Mephistopheles]

Rechtsklick reicht meines Erachtens nach nicht aus. Es ist zu unspezifisch und gemeinhin das Signal ein Kontextmenü zu zeigen. Es müßte z.B. zur gleichen Zeit auch eine Taste gedrückt sein.

[OrallY]

Genau dies möchte ich aber nicht :wink:. Die Maus muss ausreichen.

In einem Posting zuvor erwähntest du, dass es möglich ist mittels Subclassing und DLL-Injection die Nachrichtenweitergabe an Anwendungen zu verhindern.
Könntest du das bitte genauer Erläutern?