CompuServe Thread

#DLL Memory Access

3 messages in this thread
#51303From: Ted BarbusinskiAug 9, 1993 2:21 PM
Under WIN16 (Windows 3.x) it's legal for two applications to dynamically link to a common DLL and, effectively, share data through that DLL's data segment by calling DLL API's that accessed that data. Our question is … Is this capability legal under WIN32 or WIN32s ? Let's assume, for example, that App 1 calls a DDL function that allocates some global memory (for a FIFO). App 2 then calls another function in that same DLL that loads data into that FIFO. Would this constitute a protection violation under WIN32 or WIN32s ? It seems to us that, since the global memory allocated for the FIFO "belongs" to App 1 it would be illegal for App 2 to use the same DLL to write to that FIFO. Is this true ? If this is a protection violation then is it true that DLLs can no longer be used to share data between applications ? Is DDE, now, the only portable method for data sharing between applications ? There are 2 Replies.
#51330From: Chris DonerAug 9, 1993 4:59 PM
Ted: DLLs can be used to share data, but your reasoning is sound all the same. The memory situation has changed, and what worked before doesn't work the same way now. By default, a DLL's data is *not* shared among processes. You can, however, change the storage attributes of your data and arrange for certain variables, or even certain dynamic allocations, to be shared among processes. To share variables, you need the data_seg() pragma to assign names to certain sections of your data. Then you need the SECTIONS statement to assign attributes (such as SHARED) to the individually named data sections. For dynamic allocations rather than variables, the solution for shared data is to make the DLL create a shared section object, also called a memory-mapped file, of the necessary size and write the data there. All instances of the DLL can read and write to the same "file". I hope that helps? Brian
#51359From: Chris DonerAug 9, 1993 7:48 PM
Ted: I just realized (rather belatedly) that we are conversing in the Win32s section, which means that in all likelihood you are working with Win32s, not with straight Win32. Unfortunately, Win32s DLL rules differ significantly from Win32 DLL rules, and I am not an expert on the differences. I believe, however, that in Win32s memory is by default PRIVATE, as in Win16, rather than SHARED, as in Win32, although a Win32s program still uses the new DllEntryPoint rather than the old LibEntry or LibMain or whatever. If you are writing for Win32s, others can help you better than I. Brian