One way people abused hooks in 16-bit Windows

Date:	August 10, 2006 / year-entry #269
Tags:	history
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20060810-06/?p=30173
Comments:	11
Summary:	We saw last time how windows hooks were implemented in 16-bit Windows. Even though the HHOOK was an opaque data type that should have been treated like a handle, many programs "knew enough to be dangerous" and took advantage of the fact that the HHOOK was just a pointer to the previous hook procedure. The...

We saw last time how windows hooks were implemented in 16-bit Windows. Even though the HHOOK was an opaque data type that should have been treated like a handle, many programs "knew enough to be dangerous" and took advantage of the fact that the HHOOK was just a pointer to the previous hook procedure.

The most common way of abusing this knowledge was by unhooking from the windows hook chain the wrong way. Instead of calling the UnhookWindowsHook function to unhook a windows hook, they called SetWindowsHook again! Specifically, they removed their hook by simply reinstalling the previous hook at the head of the chain:

HHOOK g_hhkPrev;

// install the hook
g_hhkPrev = SetWindowsHook(WH_KEYBOARD, MyHookProc);
...

// crazy! uninstall the hook by setting the previous hook "back"
SetWindowsHook(WH_KEYBOARD, g_hhkPrev);

This code worked in spite of itself; it's as if two wrongs made a "sort of right". If nobody else messed with the hook chain in between the time the hook was installed and it was subsequently "uninstalled", then reinstalling the hook at the head of the chain did restore the chain variables in the same way they would have been restored if they had uninstalled the hook correctly.

But if somebody else installed their own WH_KEYBOARD hook in the meantime, then setting the previous hook "back" would have the effect of not only "uninstalling" the MyHookProc but also all other hooks that were installed in the meantime. (This is exactly the same problem you have if you aren't careful in how you remove subclassed window procedures.)

I still have no idea why they used this strange technique instead of doing the right thing, which is just swapping out one line of code for another:

UnhookWindowsHook(WH_KEYBOARD, MyHookProc);

Windows 3.1 introduced the SetWindowsHookEx/CallNextHookEx model, which doesn't use the external linked list technique but rather manages the hook chain internally. This protected the hook chain from programs that corrupted it by mismanaging the external hook chain, but it meant that when these crazy programs tried to unhook by hooking, they ended up corrupting the internal hook chain. Special code had to be written to detect these crazy people and turn their bad call into the correct one so that the hook chain wouldn't get corrupted.

Comments (11)

Caliban Darklock says:

August 10, 2006 at 11:45 am

And where else have we seen this (bad) practice?

Why, under DOS, when installing ISRs for background processing. Which just goes to show that people never, ever, EVER learn.
nksingh says:

August 10, 2006 at 12:58 pm

Well, it’s never ever the same people every time. It’s like Nietzsche’s Eternal Recurrence of inexperienced (too smart for their own good) programmers. Also, old programmers never die, they just move up the management hierarchy.
Joseph Bruno says:

August 10, 2006 at 1:11 pm

There was also the problem that there was a bug in the debug kernel of Windows 3.1 that made it crash if you used SetWindowsHookEx. The only cure was to go back to the deprecated SetWindowsHook.
Kevin says:

August 10, 2006 at 1:29 pm

This is all well and good, but how does one restore GDI objects? By calling SelectObject and passing the old value, of course. So is it so hard to understand why programmers get confused? I’m not blaming MS in particular here, but this is a common problem when there are inconsistencies across an API. In this case SetWindowsHook should not have returned something that was a valid parameter for a subsequent call (although given the rampant casting required under Win16 that wouldn’t have stopped some people from still trying!).

[Um, but there can be multiple hooks, but only one bitmap selected into a DC. Different models. You don’t “chain to the previous bitmap” in a DC. -Raymond]
Coderjoe says:

August 10, 2006 at 3:27 pm

Right, but inexperienced programmers in a rush could wind up with the mistaken impression that there is only one hook, or something, and treat it like the do GDI objects.
Shog9 says:

August 10, 2006 at 3:40 pm

Joe/Kevin:

You know, most of us have probably seen and/or made enough newbie mistakes to recognize the strange logic that goes into making them.

It doesn’t make them any less stupid.

Now, misunderstanding the difference between selecting a bitmap into a DC and selecting anything else…
Merit says:

August 10, 2006 at 6:10 pm

I think it has to do with the requirement that you save the old value in a global variable. Without stopping to think about it pretty hard thats a really strange requirement, so people might have assumed that you needed to keep it around in order to do the unhook.
Kevin says:

August 10, 2006 at 7:49 pm

[Um, but there can be multiple hooks, but only one bitmap selected into a DC. Different models. You don’t “chain to the previous bitmap” in a DC. -Raymond]
But will a programmer writing his first (and only one in that program) windows hook necessarily realize that? Would it not be better to design API calls, where possible, so that this kind of mistake is impossible or at least unlikely, even for programmers who might miss a detail in the docs? The tone of some of these comments is starting to remind me of cases of “blame the user”, which I believe Raymond’s written about in the past. In this case it’s “blame the user of this API for not understanding the model the author had in mind, when there’s an incorrect but superficially similar model in the same general space (ie Win16 development) that the user has probably been using all along”. Whose fault is that?

[You’d think a function called CallNextHook would be an extremely strong indication that there can be multiple hooks. Setting the current object into a container and installing a hook into a container are very different concepts. It actually surprises me that people think they’re related… -Raymond]
Norman Diamond says:

August 10, 2006 at 9:42 pm

I still have no idea why they used this

> strange technique instead of doing the right

> thing

Although I know (after taking too long to learn this) not to blame you for two possible reasons, nonetheless there are two pretty obvious possible reasons.

1. Not everyone was a Win16 programmer, no problem. Some people who weren’t Win16 programmers were learning to be Win16 programmers, no problem. Some people who weren’t Win16 programmers were doing Win16 programming in products to be released, without anyone else checking and fixing their work, oops.

2. Some people don’t always have time to experiment to see which 75% of MSDN is correct, so they skip MSDN and just do the experiments.

I also agree with Merit’s suggestion that the use of a global variable provides some pretty powerful intuition that the global variable was intended to be used that way, and then add the fact that it seemed to work sometimes…
Mihai says:

August 10, 2006 at 11:29 pm

I think it was inspired by DOS and TSR.

The only way to unhook an interrupt was to set the previous interrupt address.

The rigth way was to GetInterrupt (ah=35h), compare it to the saved interrupt address, and not uninstall yourself if different, only set a flag to disable processing in your own interrupt routine.

But I have seen enough applications that just restored the original interrupt handler, "killing" other TSR or even the system.

Fun times :-)
Ben Hutchings says:

August 11, 2006 at 4:34 pm

Well, they would have to had to know about UnhookWindowsHook, and that’s not an obvious counterpart to SetWindowsHook. The name SetWindowsHook doesn’t suggest that any counterpart exists (except maybe GetWindowsHook). (Further thought would lead to the realisation that this can’t work for out-of-order removal, but there are plenty of hook mechanisms that are broken in that way.) The lesson I would draw is that functions that attach and detach functions from hooks should be done using names that suggest an inverse function exists. For example, Attach/Detach, Install/Remove, Add/Remove, Register/Unregister, Subscribe/Unsubscribe.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index