How to share HGLOBAL with another application?

Question

I\'m trying to understand something about HGLOBALs, because I just found out that what I thought is simply wrong.

In app A I GlobalAlloc() data

Answer 1

Read the documentation. With the introduction of 32-bit processing, GlobalAlloc() does not actually allocate global memory anymore.

To share a memory block with another process, you could allocate the block with GlobalAlloc() and put it on the clipboard, then have the other process retreive it. Or you can allocate a block of shared memory using CreateFileMapping() and MapViewOfFile() instead.

Answer 2

Each process "thinks" that it owns the full memory space available on the computer. No process can "see" the memory space of another process. As such, normally, nothing a process stores can be seen by another process.

Because it can be necessary to pass information between processess, certain mechanisms exists to provide this functionality.

One approach is message passing; one process issues a message to another, for example over a pipe, or a socket, or by a Windows message.

Another is shared memory, where a given block of memory is made available to two or more processes, such that whatever one process writes can be seen by the others.

Answer 3

Don't be confused with GMEM_SHARE flag. It does not work the way you possibly supposed. From MSDN:

The following values are obsolete, but are provided for compatibility with 16-bit Windows. They are ignored.

GMEM_SHARE

GMEM_SHARE flag explained by Raymond Chen:

In 16-bit Windows, the GMEM_SHARE flag controlled whether the memory should outlive the process that allocated it.

To share memory with another process/application you instead should take a look at File Mappings: Memory-mapped files and how they work.

Answer 4

(This is just a very long comment as others have already explained that Win32 takes different approach to memory sharing.)

I would say that you are reading into books (or tutorials) on Windows programming which are quite old and obsolete as Win16 is virtually dead for quite some time.

16-bit Windows (3.x) didn't have the concept of memory isolation (or virtual /flat/ address space) that 32-bit (and later) Windows versions provide. Memory there used to be divided into local (to the process) and global sections, both living in the same global address space. Descriptors like HGLOBAL were used to allow memory blocks to be moved around in physical memory and still accessed correctly despite their new location in the address space (after proper fixation with LocalLock()/GlobalLock()). Win32 uses pointers instead since physical memory pages can be moved without affecting their location in the virtual address space. It still provides all of the Global* and Local* API functions for compatibility reasons but they should not be used anymore and usual heap management should be used instead (e.g. malloc() in C or the new operator in C++). Also several different kind of pointers existed on Win16 in order to reflect on the several different addressing modes available on x86 - near (same segment), far (segment:offset) and huge (normalised segment:offset). You can still see things like FARPTR in legacy Win16 code that got ported to Win32 but they are defined to be empty strings as in flat mode only near pointers are used.