[comp.windows.ms.programmer] GlobalAlloc by DLL

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