Newsgroups: comp.windows.ms.programmer
Path: utzoo!utgpu!watserv1!watmath!hyper.hyper.com!bonneau
From: bonneau@hyper.hyper.com (Paul Bonneau)
Subject: Re: Hacking The Dialog Class
Message-ID: <1991Jun20.195053.8190@hyper.hyper.com>
Reply-To: bonneau@hyper.UUCP (Paul Bonneau,,)
Organization: HyperCube Inc.
References: <c5HP41w163w@burklabs>
Date: Thu, 20 Jun 1991 19:50:53 GMT

In article <c5HP41w163w@burklabs> ronb@burklabs (Ron Burk       ) writes:
>For obscure reasons, I have written a program that replaces the window
>function defined in window class "#32770" (a window class defined by
>USER.EXE).  In effect, this puts my own callback function in the chain
>for many Windows dialog boxes.  To accomplish this, I defined and
>exported a window callback function, created a dummy window of class
>"#32770", did a SetClassLong to poke in the address of my callback
>function (using MakeProcInstance, of course), then deleted the dummy
>window.  This is fine and dandy and everything works as expected
>except for one small fact:  when my callback function gets invoked,
>the data segment is set correctly, but the stack segment seems to
>belong to the application who put up the window (SS != DS).  I made
>my application work simply by not depending on SS == DS, but
>what gives?  How could my callback function get called with
>my data segment and someone else's stack?  It's not a DLL, just
>a simple program.

What you have done is to superclass a system global dialog
class.  So whether or not you are a DLL, every app that
creates an instance of this class will be calling *your*
WindowProc to handle messages for the window.  So when a
window of some other app needs servicing, your WndProc gets
called without a context switch ever occuring (context
switches occur when GetMessage() or PeekMessage() is called).
Thus you have the stack of the caller, since your app is not
the active one.

cheers - Paul Bonneau.
