🚀 go-pugleaf

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.