Tastaturhook mit Delphi XE2

[kuba]

Hallo,

ich möchte einen Tastaturhook in mein Programm einbauen. Soweit funktioniert es schon, aber leider nicht wenn ich mein Programm mit Delphi XE2 als 64-Bit Version kompiliere.

Im Anhang habe ich das Testprogramm gepostet.

Hat jemand eine Idee, warum es mit 64-Bit nicht funktionieren will ?

Im Ereignisprotokoll steht folgender Fehler:
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\PAVSHOOK64.DLL

KUBA

[Delphi-Laie]

Eine Antwort kann ich Dir leider nicht geben, jedoch Deine schlechte Erfahrung bestätigen: Weder mit Delphi noch mit Lazarus schaffte ich es (mit den jeweiligen 64-Bit-Compilaten), unter Windows (7 mit 64 Bit) globale Hooks zu installieren.

Letzlich ist das wohl so komplex und für die Ersteller der Compiler so nebensächlich (nicht mehr sekundär, sondern schon tertiär), daß man sich damit noch nicht ernsthaft beschäftigt hat. Oder es liegt am Windows selbst.

[kuba]

Das angehängte Programm funktioniert einwandfrei unter Win32 (2K,XP,Vista,7), lässt sich auch mit 64-Bit kompilieren.

C:\WINDOWS\SYSTEM32\PAVSHOOK64.DLL kommt von Panda Antivirus. Bisher konnte ich jedoch noch keinen Zusammenhang herstellen.

Neulich fand ich heraus dass bei 64-Bit Systemen zwingend "OpenKeyReadOnly" verwendet werden muss wenn man HKEY_LOCAL_MACHINE Registry lesen will, bei 32 Bit geht auch einfach "OpenKey".

Es kann nicht so schwierig sein, irgendwo hängt der hook sich auf weil irgendwo eine Kleinigkeit falsch läuft.

Leider finde ich es mit dem Debugger nicht heraus (weil ich zu blöd bin).

KUBA

[Luckie]

Zitat:

Zitat von kuba (Beitrag 1148970)

Neulich fand ich heraus dass bei 64-Bit Systemen zwingend "OpenKeyReadOnly" verwendet werden muss wenn man HKEY_LOCAL_MACHINE Registry lesen will, bei 32 Bit geht auch einfach "OpenKey".

Das ist falsch. Auch unter 32-Bit kann man als nicht Administrator diesen Schlüssel nur lesend öffnen. Die Zugriffsberechtigungen haben nicht mit 32- oder 64 Bit zu tun. Wobei unter 64-Bit mit einem 32-Bit Programm noch die Redirection von dem 32-Bit Programm dazu kommt.

[jaenicke]

Ich habe nur kurz reingeschaut, ich probiere es noch aus. Du hast ein Problem in CreateMMF. Deshalb wird der Hook gar nicht erst versucht zu setzen

Delphi-Quellcode:

  Result := CreateFileMapping($FFFFFFFF, nil, PAGE_READWRITE, 0, Size, PChar(Name));
//

Der erste Parameter ist falsch. Korrekt:

Delphi-Quellcode:

  Result := CreateFileMapping($FFFFFFFFFFFFFFFF, nil, PAGE_READWRITE, 0, Size, PChar(Name));
//

// EDIT:
Dann funktioniert das Programm auch mit 64-Bit kompiliert vollkommen korrekt. ;-)

[Daniel]

Meine Herren - Finger weg von den "magic numbers", also den festen Zahlenwerten im Code. Was da erwartet wird, ist ein THandle, welches unter XE2 als NativeUInt deklariert ist und damit gemäß der Ziel-Architektur wächst oder schrumpft.

Wenn man an dieser Stelle einfach die Konstante "INVALID_HANDLE_VALUE" einsetzt, hat man einen Code, der sich für beide Architekturen übersetzen lässt, weil sich der Compiler um den korrekten Wert kümmert.

[jaenicke]

Zitat:

Zitat von Daniel (Beitrag 1148978)

Wenn man an dieser Stelle einfach die Konstante "INVALID_HANDLE_VALUE" einsetzt, hat man einen Code, der sich für beide Architekturen übersetzen lässt, weil sich der Compiler um den korrekten Wert kümmert.

Schön wäre es, probiere es bitte erst einmal aus... Es hat einen Grund warum ich das so geschrieben habe... Mit INVALID_HANDLE_VALUE geht es nicht (das ist als THandle(-1) deklariert).

[kuba]

Zitat:

Zitat von jaenicke (Beitrag 1148973)

Ich habe nur kurz reingeschaut, ich probiere es noch aus. Du hast ein Problem in CreateMMF. Deshalb wird der Hook gar nicht erst versucht zu setzen

Delphi-Quellcode:

  Result := CreateFileMapping($FFFFFFFF, nil, PAGE_READWRITE, 0, Size, PChar(Name));
//

Der erste Parameter ist falsch. Korrekt:

Delphi-Quellcode:

  Result := CreateFileMapping($FFFFFFFFFFFFFFFF, nil, PAGE_READWRITE, 0, Size, PChar(Name));
//

// EDIT:
Dann funktioniert das Programm auch mit 64-Bit kompiliert vollkommen korrekt. ;-)

Super !! Vielen Dank, funktioniert einwandfrei :thumb:

KUBA

[Daniel]

Zitat:

Zitat von jaenicke (Beitrag 1148990)

[...] probiere es bitte erst einmal aus... Es hat einen Grund warum ich das so geschrieben habe... Mit INVALID_HANDLE_VALUE geht es nicht (das ist als THandle(-1) deklariert).

Ich bin schlauer, als ich aussehe :stupid: Denn ich habe es probiert. Folgender Code gibt mir für 32-bit und 64-bit den jeweils korrekten Wert aus:

Delphi-Quellcode:

program Project731;
{$APPTYPE CONSOLE}
{$R *.res}
uses
  System.SysUtils;
begin
  try
    WriteLn( IntToHex(INVALID_HANDLE_VALUE, 16) );
    ReadLn;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Ich kann derzeit allerdings nicht sagen, welche Einflüsse hier noch mit hineinspielen und warum das bei Dir nicht klappt.

[DeddyH]

Zitat:

Delphi-Quellcode:

program Project731;

Ich dachte immer, ich sei der Einzige, der bei Mini-Testprogrammen so schlampert :lol:

[jaenicke]

Zitat:

Zitat von Daniel (Beitrag 1148995)

Ich kann derzeit allerdings nicht sagen, welche Einflüsse hier noch mit hineinspielen und warum das bei Dir nicht klappt.

Das klappt ja auch bei mir. Aber sobald ich den Wert der Funktion übergebe klappt es dort nicht.

[Daniel]

Zitat:

Zitat von jaenicke (Beitrag 1149062)

Das klappt ja auch bei mir. Aber sobald ich den Wert der Funktion übergebe klappt es dort nicht.

:shock: das ist ja mal spannend.

[jaenicke]

Ich hatte nicht die Zeit genauer im Assemblercode zu schauen was nun eigentlich passiert. Ich vermute da geht was mit Signed/Unsigned durcheinander. Ich schaue mal, wenn ich zu Hause bin. ;-)

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1149073)

Ich hatte nicht die Zeit genauer im Assemblercode zu schauen was nun eigentlich passiert. Ich vermute da geht was mit Signed/Unsigned durcheinander. Ich schaue mal, wenn ich zu Hause bin. ;-)

Wenn man u.U. Problem mit Signed/Unsigned vermutet könnte man auch die rangechecks im Commpiler aktivieren. Dann wird 'ne Exception geschmissen wenn hier ein entsprechendes Signed/Unsinged-Missmatch auftritt.

[Daniel]

Das hat mir ja nun keine Ruhe gelassen. Wie sieht denn das nicht funktionierende Minimalbeispiel aus? Folgender Code geht, aber ich befürchte fast, dass wir auf die eine oder andere Weise aneinander vorbei reden.

Delphi-Quellcode:

program Project745;
{$APPTYPE CONSOLE}
{$R *.res}
uses
  WinAPI.Windows,
  System.SysUtils;

var maphandle : THandle;

begin
  //maphandle:= CreateFileMapping($FFFFFFFFFFFFFFFF, nil, PAGE_READWRITE, 0, mapsize, PChar('daniel'));
  maphandle:= CreateFileMapping(INVALID_HANDLE_VALUE, nil, PAGE_READWRITE, 0, 8192, PChar('daniel'));
  if (maphandle <> 0) then
  begin
    /// hat wohl geklappt
    WriteLn( 'aufruf erfolgreich' );
    CloseHandle( maphandle );
  end
  else
  begin
    /// hat ... so gut wie ... geklappt
    WriteLn( 'aufruf fehlgeschlagen: "' + SysErrorMessage(GetLastError) + '"' );
  end;

  ReadLn;
end.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1148996)

Zitat:

Delphi-Quellcode:

program Project731;

Ich dachte immer, ich sei der Einzige, der bei Mini-Testprogrammen so schlampert :lol:

Zitat:

Zitat von Daniel (Beitrag 1149101)

Delphi-Quellcode:

program Project745;

Also in 9h hat unser Admin 14 neue Mini-Projekte erzeugt
Das macht also 1,56 Mini-Projekte pro Stunde

wenn er ohne Pause geschuftet hat :mrgreen:

[jaenicke]

Zitat:

Zitat von Daniel (Beitrag 1149101)

Das hat mir ja nun keine Ruhe gelassen. Wie sieht denn das nicht funktionierende Minimalbeispiel aus? Folgender Code geht, aber ich befürchte fast, dass wir auf die eine oder andere Weise aneinander vorbei reden.

Nein, tun wir nicht. Genau dabei kam dann als Ergebnis 0 und GetLastError lieferte Code 6 (ungültiges Handle). Jetzt habe ich aus der History genau den im Test benutzten Code reaktiviert und es geht... :?
Der einzige Unterschied ist, dass ich Windows neu gestartet habe seitdem. Was dann dort passiert war weiß ich nicht, aber mit der Konstante hatte es dann nichts zu tun.