With mob's help I figured out how to get WH_JOURNALRECORD to work. However, I have a new problem: the mouse cursor is gone.
My program loads a DLL. The DLL debugs a game. The game has a mouse cursor, but when I ALT-TAB to Windows, the mouse cursor is gone, although windows still changes various things as the invisible mouse goes over them, so it is still responding.

I would do this with WH_KEYBOARD, but that would load the dll with the hookproc in the game's process, which would complicate things.

Do you guys know how to make that mouse cursor reappear??

;vb hook procedure code in my app

Public Function HookProc(ByVal nCode As Long, ByVal wParam As Long, ByRef lParam As EVENTMSG) As Long
If nCode = HC_ACTION Then
If RecordFlag = True Then
rc = HookProcedure(lParam)
End If
ElseIf nCode = HC_SYSMODALOFF Then
RecordFlag = True
ElseIf nCode = HC_SYSMODALON Then
RecordFlag = False
End If
If nCode < 0 Then
HookProc = CallNextHookEx(hHandle, nCode, wParam, lParam)
HookProc = 0
End If
End Function

;asm code in my dll

HookProcedure PROC USES edi lParam:DWORD
mov edi, lParam
.IF [edi].message == WM_KEYDOWN
mov eax, [edi].paramL
and eax, 0FFh
.IF eax == VK_SHIFT
invoke MyProcedure, ADDR NewValue
ASSUME edi:nothing
HookProcedure ENDP

There's a second problem that I observed.
I check for WM_KEYDOWN. The API reference says that the high parameter (wParam) hold the virtual key code. If i'm not mistaken, those are the VK_ constants. Also, the low parameter holds "key data".
Here are the various results I get with a few keys:

VK_SHIFT = 10h
EVENTMSG.paramH = 2Ah
EVENTMSG.paramL = 2A10h

VK_TAB = 09h
EVENTMSG.paramH = {something}h
EVENTMSG.paramL = {the same something}09h

It seems that the VK_ code goes in the low byte of the low parameter, while the second byte of the low parameter and the high parameter apparently hold the scan code.

I also tried some of the letters and numbers, and the VK_ code (same as ascii code in this case) is in the same spot.

I looked at the structures to make sure all the parameters are in the correct places and to make sure they are the proper sizes, and everything is fine.

Does anyone know what's up with these VK_ codes?
Posted on 2002-01-15 13:36:26 by Hel
hi hel... hm i don't see a "CallNextHookEx" in your code...
and btw according to the api-ref a recordhook-callback must
look like this:


int code, // hook code
WPARAM wParam, // undefined
LPARAM lParam // address of message being processed

that means in asm it should be like

RecordProc PROC nCode:DWORD, wParam:DWORD, lParam:DWORD

OR stopflag,0

;// RESPOND...
;// lParam Points to an EVENTMSG struc


MOV stopflag,0


MOV stopflag,1

_NOPE: OR _nCode,0

INVOKE CallNextHookEx,hhandle,nCode,wParam,lParam


RecordProc ENDP

hm i had always problems with keyboard input... i stopped
playing with hooks... so i never found a suitable solution...
a few weeks ago i coded a little keylogger that used
TranslateMessage but you can't use this since TMSG only
works for non-virtual-keycodes... There are a couple of
functions for that purpose... try MapVirtualKey or look around
in your api ref...
Posted on 2002-01-16 03:33:32 by mob
I do have a CallNexHookEx; it's in the VB code. I looked at your code and translated into VB word for word and the mouse cursor is gone.
Then, I realized that CallNextHookEx gets called only if Code < 0, which means that most of the time the other WH_JOURNALRECORD hooks wouldn't get called.

API Reference:

Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications.

Therefore, i changed the code a bit. In asm it would be




invoke CallNexHookEx
.IF Code < 0
xor eax, eax
Posted on 2002-01-16 07:33:22 by Hel
hm api-ref sais...

If code is less than zero, the hook procedure must pass the message to the CallNextHookEx function without further processing and should return the value returned by CallNextHookEx.

If not, the return value is ignored.
Posted on 2002-01-16 08:32:59 by mob