adam@metavax.UUCP (- Mr. Engineering) (02/09/89)
Does anyone know if Windows locks the data segment while a DialogBox is active? I have a feeling that DialogBox (the function) does nothing special about locking the data segment while it calls PeekMessage or whatever it calls...
roper@june.cs.washington.edu (Michael Roper) (02/10/89)
adam@metavax.UUCP writes: > Does anyone know if Windows locks the data segment while > a DialogBox is active? I have a feeling that DialogBox > (the function) does nothing special about locking the data > segment while it calls PeekMessage or whatever it calls... Windows locks your data segment when you get the CPU. As far as I know, the only way it can move unexpectedly during this period is if you do a LocalAlloc() or LocalRealloc(). However, this will result in a move only if the heap must be extended and then only if it can't be extended without moving the segment. Mike Roper
brent@well.UUCP (Brent Southard) (02/13/89)
In article <3816@metavax.UUCP> adam@metavax.UUCP (Adam Hoffman -- Mr. Engineering) writes: >I have a feeling that DialogBox (the function) does nothing >special about locking the data segment while it calls PeekMessage or >whatever it calls... You are absolutely correct. Your data segment may very well move during calls to MessageBox, DialogBox, or other functions that directly or indirectly call PeekMessage et all, thus losing the context. You must be very careful not to hold far pointers to local data across such function calls. brent -- Brent Southard, ImageTech Corp. | Everybody's trying to be a friend of mine, Usenet: ...well!brent | Even a dog can shake hands. - W. Zevon CIS: 76657,415 | We fell into love, love's a very deep hole. GEnie: b.southard | - Loudon Wainwright III
beckman@dev386.UUCP (Zacharias Beckman) (02/14/89)
In article <3816@metavax.UUCP>, adam@metavax.UUCP (- Mr. Engineering) writes: > Does anyone know if Windows locks the data segment while a DialogBox > is active? You can use the 'heapwalk' routine under windows/286 to see what is locked at any given point (it doesn't work too well under windows/386 because of the complex addressing). Run your program, get the dialog box on screen, and select the 'walk heap' option from the 'heapwalk' program; this will show you precisely what data/tasks/code/tdb's are owned by your application, what the lock levels are, etc. As for a direct answer to your question: "I'm not sure". Zacharias J. Beckman ... gatech!mdt!pgthor!dev386!beckman ... uunet!mcrware!pgthor!dev386!beckman (319) 354-5116 (319) 351-1993 The answer is 42.
billc@mirror.UUCP (Bill Callahan) (02/15/89)
In article <10693@well.UUCP> brent@well.UUCP (Brent Southard) writes: >In article <3816@metavax.UUCP> adam@metavax.UUCP (Adam Hoffman -- Mr. Engineering) writes: >>I have a feeling that DialogBox (the function) does nothing >>special about locking the data segment while it calls PeekMessage or >>whatever it calls... > >You are absolutely correct. Your data segment may very well move during >calls to MessageBox, DialogBox, or other functions that directly or >indirectly call PeekMessage et all, thus losing the context. You must be >very careful not to hold far pointers to local data across such function >calls. Just as helpful hint, in such situations, you have several alternatives when you do need to pass a pointer and have it be good: 1. Allocate and lock the piece of memory using GlobalAlloc and GlobalLock. 2. Use memory in your data segment (such as static or global buffers) and lock your data segment before the call, remembering to unlock it afterwords. 3. If your stack resides in a fixed or locked data segment, long pointers to automatic storage are (obviously, but also suprisingly) good. This one can be very handy. --------------------------------------------------------------------------- Bill Callahan billc@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc Mirror Systems 2067 Massachusetts Ave. 617\661-0777 x149 Cambridge, MA 02140
dennis@se-sd.sandiego.ncr.com (Dennis Foster) (02/16/89)
In article <433@dev386.UUCP> beckman@dev386.UUCP (Zacharias Beckman) writes: > ... stuff deleted ... >You can use the 'heapwalk' routine under windows/286 to see what is locked >at any given point (it doesn't work too well under windows/386 because of the >complex addressing). Run your program, get the dialog box on screen, and > ... stuff deleted ... You can much more information out of heapwalk in windows/386 if you execute windows/386 to not provide expanded memory. You do this by including a /n on the execution of windows. E.g., WIN386/N From this point, heapwalk shows about all there is to see!