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: Date: Thu, 20 Jun 1991 19:50:53 GMT In article 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.