CompuServe Messages

John, << From "Win32 SDK: Shared memory": "Memory allocated by a DLL is in the address space of the process that invoked the DLL and is not accessible to other processes using the same DLL." >> Yes, this is true on Windows NT, but not on Win32s. The memory is shared on Win32s. << From "Win32 SDK: Shared memory": Under Win32, GlobalAlloc(GMEM_FIXED) simply returns a pointer. No need to GlobalLock. For that matter, malloc() can be used under Win32 and is simply translated to GlobalAlloc(GMEM_FIXED). >> Under Win32s, GlobalAlloc() thunks down to the Windows GlobalAlloc(), so all is as it was on Windows. Under Windows NT and Win32s, malloc() maps most closely to HeapAlloc(). << I have a DLL that allocates an in-memory data structure that includes 32-bit pointers to itself, like a linked list. I'd like to pass this tree of information back to the calling application, which in turn will pass it to another DLL for further processing. Will this scheme work under both WinNT and Win32s? >> Yes. << I'd also like to confirm the safest, most portable method for passing the top-most structure of this data from DLL to DLL. It's a struct about 512 bytes in size. If the application allocates this, or if it's a global variable for the application, can the DLLs see it if all that's passed to the DLL is a pointer to it? >> Yes. Try these things out with a very small test case and let me know if you have trouble. Julie Read action !reply Enter reply. (/EXIT when done) 1: In the time since I first posted my message, anI have 2: tried small test cases under both Win32s and WinNT. 3: So far, so good, no problems. I also figured out t 4: hat WinNT malloc() must be doing some kind of sub-a 5: llocation into larger GlobalAlloc()-style a 6: lolocations, because I was able to do more than 64K orf s 7: mall 10-byte allocations. WinNT is still limited to 8: 64K GlobalAllocs()s, as I understand it. 9: 10: I've /post Message # 67426 posted