From: baruch@gallifrey.NoSubdomain.NoDomain (Robert Baruch)
Subject: Re: NT, 3.1, and Global Memory
Organization: NYNEX Science & Technology, Inc.
Date: Fri, 4 Sep 92 14:12:13 GMT

In article <KEVIN.92Sep4095239@runningbear.edscom.demon.co.uk>, kevin@edscom.demon.co.uk (Kevin Broadey) writes:
|> >>>>> Regarding Re: NT, 3.1, and Global Memory; johnhall@microsoft.com
|> >>>>> (John Hall) adds:
|> 
|> In article baruch@nynexst.com (Robert Baruch) writes:
|> 
|> | After reading countless paragraphs on how Windows supports only 
|> | a few means of data transfer between applications, I have come to
|> | the conclusion that if I didn't want to use DDE, I could use a DLL,
|> | and GlobalAlloc memory which could then be shared between
|> | all the applications using that DLL.
|> | 
|> | My questions are:
|> | 
|> | (1)  If I GlobalAlloc in the DLL, and get a handle using one application,
|> |      then another application accesses this handle, will I get the data from
|> |      the first application UNDER WINDOWS NT?  I know that it works
|> |     under Windows 3.1.
|> 
|>     John> No.  This won't work.
|> 
|>     John> However, I have just posted a dll which handles shared memory
|>     John> under Windows NT.  Operations are ShrAlloc(), ShrLock(),
|>     John> ShrUnlock(), ShrFree(), ShrName() to assign a name to a handle
|>     John> and ShrGet() to get a handle based upon a name.
|> 
|>     John> I even make heroic efforts to force all addresses to be identical
|>     John> across processes.
|> 
|>     John> This is available on Compuserve WIN32 porting from OS/2.
|> 
|>     John> Included in this kit is source code for the dll, test code,
|>     John> and some discussions on implementation decisions.  
|> 
|>     John> I'll ask Alistair to place it on ftp.
|> 
|> There's something strange going on here.
|> 
|> I've got 2 Windows 3.1 applications that I'm porting to NT.
|> 
|> App1 does GlobalAlloc, GlobalLock, fills in the memory, GlobalUnlock,
|> PostMessage the handle to app2.
|> 
|> App2 does GlobalLock, reads the memory, GlobalUnlock, GlobalFree.
|> 
|> Everything is fine and dandy.
|> 
|> Admittedly this isn't done in a DLL, but since DLLs (by default) run as
|> if they were part of the app (accessing the app's data space, for
|> instance) this shouldn't make any difference.
|> 
|> So what's going on?

Apparently passing data using global allocations works experimentally under 3.1, and
possibly NT.  However, Microsoft keeps saying that you shouldn't use this, 
because applications are not guaranteed to have the same addressing space
in future versions of NT.  I guess they want to leave that avenue open to them, and
they can't do that if they support global alloc data passing.

There were two reasons I allocated my global data in a DLL:

(1)  The rationalization: The DLL contains functions which create data pipes, and so
     I wanted to manage all the data in the DLL, just passing handles to the applications.
    The DLL actually creates circular buffers, with messages on the buffer being globally
    allocated data.

(2)  The real reason:  I read that you could allocate data in a DLL if you wanted to
      pass it between allocations.  I think they actually meant local alloc, but I used
      global alloc because I didn't want to be limited to less than 64K of data.

I'm not sure if that answers your questions.  I took two interpretations of your
question and answered them.

--Rob
Newsgroups: comp.os.ms-windows.programmer.win32