kevin@msa3b.UUCP (Kevin P. Kleinfelter) (05/21/91)
I'd like to do a GlobalAlloc in a DLL, and have the memory owned by the DLL (not the application that calls the DLL). I don't mean I want to allocate the memory in LibMain; my application calls a DLL routine, and I want the DLL routine to GlobalAlloc. What SEEMS to happen is that the GlobalAlloc allocates memory that is "owned" by the application. I have another application that makes other calls to the DLL to update and retrieve data from this memory. Is there some kind of a call I can make in the DLL routines that switches Windows notion of the current instance to be the DLL's instance and not the calling applications instance? I need to share chunks of Read/Write memory. * DLL isn't gonna cut it (DLL sends a copy of the memory according to page 16-39 of "Guide to Programming" * static storage in the DLL isn't gonna cut it (I cannot tell at compile-time how much memory is needed, and the more applications that call my DLL, the more memory I'll need. * ClassExtra bytes aren't gonna cut it because I'm going to need to share dozens and maybe hundreds of 2K blocks of memory. I need it to be FAST because this memory will be accessed at least once for EVERY message my application receives. (Programming was easier back in the days when my program owned the whole machine!) -- Kevin Kleinfelter @ DBS, Inc (404) 239-2347 ...gatech!nanoVX!msa3b!kevin This is only a test. If this were an actual .signature line, you would be directed where to tune for official news and information.
bonneau@hyper.hyper.com (Paul Bonneau) (05/22/91)
In article <1652@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >I'd like to do a GlobalAlloc in a DLL, and have the memory owned by the >DLL (not the application that calls the DLL). I don't mean I want to >allocate the memory in LibMain; my application calls a DLL routine, and >I want the DLL routine to GlobalAlloc. > >What SEEMS to happen is that the GlobalAlloc allocates memory that is >"owned" by the application. I have another application that makes other >calls to the DLL to update and retrieve data from this memory. > From the "Guide To Programming", page 20-34 "When a DLL allocates a global object, the application that called the DLL owns that object". I don't know of any API to allow a DLL to "own" global handles, but it obviously can be done, since GDI (which is nothing more than a DLL itself) does so when you create brushes, icons, etc. If the amount of memory you need is small, you might consider using a LocalHeap in the DLL (in this case you must explicitly create the heap with LocalInit()). When you pass a reference to this memory to the caller, locking the local object, and casting to a far pointer will provide the address of the data. You can then use LocalHandle() to extract the handle from the locked address for those APIs of the DLL that accept the reference to the memory back from the app. cheers - Paul Bonneau.
jerrys@bunker.isc-br.com (Jerry Shea) (05/23/91)
In article <1991May21.224503.21936@hyper.hyper.com> bonneau@hyper.UUCP (Paul Bonneau,,) writes: >In article <1652@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >>I'd like to do a GlobalAlloc in a DLL, and have the memory owned by the >>DLL (not the application that calls the DLL). I don't mean I want to >>allocate the memory in LibMain; my application calls a DLL routine, and >>I want the DLL routine to GlobalAlloc. >> >From the "Guide To Programming", page 20-34 "When a DLL >allocates a global object, the application that called the >DLL owns that object". If you allocate the memory with the GMEM_DDESHARE flag set, it will be owned by the code segment that allocates it rather than by the task. This is one way of letting a DLL own the memory. I've tried this and it seems to work fine. I'm not sure if there are any other consequences of allocating memory this way though. Hope this helps, Jerry -- Jerry Shea | INET: jerrys@bunker.shel.isc-br.com ISC-Bunker Ramo, An Olivetti Company | UUCP: uunet!bunker!jerrys 2 Enterprise Drive | BIX: jshea Shelton, CT 06484 USA | Phone: (203) 337-1646