<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx</link><description>A very different type of architecture.</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#693364</link><pubDate>Wed, 09 Aug 2006 18:26:14 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:693364</guid><dc:creator>Nawak</dc:creator><description>This is really clever!&lt;br&gt;But it also 'looks' fragile as it relies on user functions doing the right thing in order for the whole mechanic to work!&lt;br&gt;Since I am quite a nice guy (no, really ;) ), I am waiting for your tomorrow's post to see what evil deeds people managed to do with that!</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#693390</link><pubDate>Wed, 09 Aug 2006 18:49:22 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:693390</guid><dc:creator>Csaboka</dc:creator><description>&amp;gt; But it also 'looks' fragile as it relies on user functions doing the right thing in order for the whole mechanic to work!&lt;br&gt;&lt;br&gt;Well, if you look at it that way, the whole 16-bit Windows world was fragile since it relied on user programs playing nicely. Back in the 16-bit days, it would have been too expensive to protect against misbehaving user programs. If you wanted to bring the whole system down, all you needed to do is not yielding to the OS.&lt;br&gt;&lt;br&gt;This solution is ideal if you want to be memory efficient and you can assume user programs playing nicely together with you.</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#693392</link><pubDate>Wed, 09 Aug 2006 18:50:04 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:693392</guid><dc:creator>Caliban Darklock</dc:creator><description>How perceptive of you, Nawak. ;)&lt;br&gt;&lt;br&gt;I was rather frustrated by programming under 16-bit Windows, not because of Windows itself, but purely because other developers had chosen to implement strange custom solutions to problems that had established &amp;quot;correct&amp;quot; answers. It was reasonably common that someone would reverse-engineer the contents of a handle - which was deliberately undocumented and unsupported, because it could change at any time - and access it directly. &lt;br&gt;&lt;br&gt;In the HHOOK case, for example, someone might try to duplicate the above logic himself rather than use the standard Windows calls. If he happened to get something wrong, probably because he didn't really understand the process, the system would behave oddly and nobody would know why. I suspect that may form the basis of Raymond's next post.&lt;br&gt;</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#693717</link><pubDate>Thu, 10 Aug 2006 00:37:30 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:693717</guid><dc:creator>Tom</dc:creator><description>I love opaque data structures. &amp;nbsp;It's a relief not knowing how a class or data structure is implemented because otherwise you are tempted to program through the interface instead of to the interface (e.g. guess the implementation by the members of the class so you can 'optimize' how you call its methods). &amp;nbsp;&lt;br&gt;&lt;br&gt;I would have to say that if you are using a debugger to find undocumented members of structs/classes and relying on them being there: a) you're doing something wrong; and b) you get what you deserve.&lt;br&gt;&lt;br&gt;I understand that Microsoft makes lots of thunks for broken software (see &lt;a rel="nofollow" target="_new" href="http://blogs.msdn.com/oldnewthing/archive/2006/01/09/510781.aspx"&gt;http://blogs.msdn.com/oldnewthing/archive/2006/01/09/510781.aspx&lt;/a&gt; &amp;nbsp;for more information), and I can understand why. &amp;nbsp;But it sure would be nice to say &amp;quot;to heck with them&amp;quot; when somebody pokes around internal undocumented structures and expects things to work that way forever.&lt;br&gt;&lt;br&gt;In regards to hook dispatching, I can't imagine how expensive it is for more than one process to have a hook on a high-traffic message. &amp;nbsp;How does Win32 make this work without a ton of context switches?&lt;br&gt;</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#694312</link><pubDate>Thu, 10 Aug 2006 15:40:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:694312</guid><dc:creator>CN</dc:creator><description>Tom: The hook function must reside in a DLL. That DLL must/will be loaded in each target process. So, in addition to message processing, you add clutter the virtual address space and some loading time. (More so if the hook function is just one function in a heavy DLL that's then brought into every process.)</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#694325</link><pubDate>Thu, 10 Aug 2006 16:00:03 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:694325</guid><dc:creator>swapping</dc:creator><description>CN: 16-bit windows didn't have &amp;quot;virtual address space&amp;quot;, it had segmenting at best. Only the (4k) pages that is used is loaded into ram, usually not very much.</description></item><item><title>One way people abused hooks in 16-bit Windows</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#694363</link><pubDate>Thu, 10 Aug 2006 17:00:16 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:694363</guid><dc:creator>The Old New Thing</dc:creator><description>Unhooking by hooking again.</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#694440</link><pubDate>Thu, 10 Aug 2006 18:32:55 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:694440</guid><dc:creator>Chris Becke</dc:creator><description>It seems an app that passed a copy of the HHOOK it originally got would defeat the unhooking mechanism. e.g.&lt;br&gt;&lt;br&gt;DWORD CALLBACK MyHookProc(int nCode, WPARAM wParam, LPARAM lParam)&lt;br&gt;{&lt;br&gt; &amp;nbsp;...&lt;br&gt; &amp;nbsp;HHOOK hhkLocal = g_hhkPrev;&lt;br&gt; &amp;nbsp;return DefHookProc(nCode, wParam, lParam, &amp;amp;hhkLocal);&lt;br&gt;}&lt;br&gt;&lt;br&gt;Why do this? Who knows: Given the lack of a user parameter I can imagine a scenario where parts of the code use their own copies of an HHOOK.</description></item><item><title>re: How were window hooks implemented in 16-bit Windows?</title><link>http://blogs.msdn.com/oldnewthing/archive/2006/08/09/693280.aspx#695865</link><pubDate>Fri, 11 Aug 2006 22:49:32 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:695865</guid><dc:creator>ATZ Man</dc:creator><description>@swapping, @DN&lt;br&gt;&lt;br&gt;Win16 enhanced mode had demand-paged virtual memory. In any mode, all running Win16 applications were in one memory space (accessed by the app through segment registers, it is true). The hook DLL would not have to be mapped into each target process, because the DLL was already jumpable into through a far call from any running application.&lt;br&gt;</description></item></channel></rss>