Windows hooks have a few changes but will basically operate as they do today under win3. First, these are the existing hook calls:
FARPROC SetWindowsHook(int, FARPROC);
BOOLUnhookWindowsHook(int, FARPROC);
DWORD DefHookProc(int, WORD, DWORD, FARPROC FAR *);
Under win3, these calls will set callback procs that the system calls in any context. For example, if app B sets an `input' hook to point to a .dll routine, when app A calls GetMessage this hook will be called in app A's context.
Under win3 a .dll doesn't `attach' to processes – it's just visible. Under Win32, attaching is required. This means if app A needs to call a hook in a .dll not visible to it, the hook code must `attach' that .dll to that process (call LoadModule on that module in app A's context). Two points come up:
1.The hook code needs a module handle to do this, which is not part of the current function.
2.Most hooks are set for local processing, meaning when app B sets a hook, usually app B is only interested in app B calling that hook. As a result, the existing hook calls will set hooks that are sensitive to only the process that set them. This means these sort of hooks don't need to be put in .dlls but can be put in private code.
Two new functions are being introduced which allow finer control over hooking. They are SetWindowsHookEx, UnhookWindowsHookEx, and CallNextHookProc . They allow control over which input queue needs to be hooked. The Win3 functions are macroed on top of these calls, but only allow the calling thread is allowed to hook itself (a difference from Win3). To hook globally or hook other independent input queues, SetWindowsHookEx must be used. See the programmers reference for more details.