SendMessage() with shared memory?

I'm writing an app which communicates with other running apps, navigating through their controls. For example, suppose I have the hwnd of a ComboBox in some app. I might do:

SendMessage(hwnd, CB_GETLBTEXT, idx, (LPARAM)namebuf)

to get the text associated with the idx'th combo box entry.

The problem I'm having is that Win95/98 will often crash. I'm assuming the reason is that the memory buffer I'm passing (namebuf) is only valid for my app -- when the other app tries to access it, it's an invalid memory access.

Does this sound right? If so, is there a way to get a memory address which would be valid for both apps -- in effect, a shared memory address?

How did you declare namebuf? Maybe you're not declaring it correctly.

O-Deka-K

Sounds like you need to use GlobalAlloc. It allocates memory outside of your process ( think - sending data to the clipboard ).

GlobalAlloc() is only provided for backwards-compatibility with 16-bit apps. There's no such thing as a "local heap" in Win32, so there's no longer any use for GlobalAlloc(), LocalAlloc(), near, or far (well, unless you're making a 16-bit app in VC++ 1.x).

New Win32 apps should use VirtualAlloc() instead. The docs say it's faster than the old two. You may want to use new instead of VirtualAlloc() though, depending on the situation.

O-Deka-K

"...there's no longer any use for GlobalAlloc()..."
One exception (from MSDN):
However, the global functions are still used with DDE and the clipboard functions.
Yes, you can pass global handle to another process and it could then do a GlobalLock() on it to get to that memory.
Unfortunately, in the case of WM_GETTEXT message, the recipient is NOT going to do a GlobalLock, he will just attempt to write to the specified memory address.
If you are lucky, this will cause immediate GPF. If that other process happen to have memory allocated at the provided address, he will write all over himself, and might fail randomly for no apparent reason...
VirtualAlloc(), however new it is, only allocates memory in your own process address space, which is not helping us here.
You could use VirtualAllocEx() to allocate memory in another process address space, and then read it with ReadProcessMemory().


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I do not do it for the rating. Oh, wait... Sure, I do!

Thanks -- that sounds promising...

Excellent! Top rating! Give that man a cookie!

Sounds like you understand the exact problem, and your solution sounds like it will work. I'll give it a try.

Many thanks!

Er, ummm, well......



func()
{
char namebuf[100];

...
SendMessage(hwnd, CB_GETTEXT, 0, namebuf);
}





(he sheepishly admits...)

Unfortunately, looking into it a bit, I see that VirtualAllocEx() only works under NT (4.0+) -- not Win95/98.

Could it be that there is no solution for Win95/98? There _must_ be some dastardly sort of trick which could be used...

My copy of VC 5 SDK samples has 395 occurrence of GlobalAlloc, some of which are comments and some probably are for DDE and the clipboard functions, but probably many of them are uses that the documentation implies are not valid. So as much as the documentation seems to indicate that it is a mistake to use GlobalAlloc, it is probably more useful than the documentation indicates.

My VC 5 MFC source uses GlobalAlloc 21 times and 7 of those use GMEM_SHARE.

http://support.microsoft.com/support.../q119/7/65.asp is current for VC 6 and uses GlobalAlloc.

According to the documentation, the only way to get shared memory is by using file sharing. If you read my other reply, though, you will see that the SDK samples and even MFC itself uses GlobalAlloc. So try using something such as:hGlob = GlobalAlloc(GPTR | GMEM_SHARE, (DWORD)nLen);
if (hGlob)
lpStr = (LPSTR)GlobalLock(hGlob);

I do not know if it will work but it might.

As I understand it, GlobalLock() is giving you a memory address in your process's virtual address space. The other app would have to likewise do a GlobalLock() on the handle in order to get a pointer to the same memory (and the pointer would be different).

I think.

I think we are getting into some undocumented features of 32-bit Windows. You are correct that that is how it works according to the documentation. In a 16-bit environment it was easy to do what you want to do, and I think that 32-bit Windows still supports some of those features but does not say so in the documentation. The only reason why I suspect that some features are still supported is because the SDK samples and the MFC source code seem to be using features that are not documented. I think that Windows designates a range of memory addresses that is shared by all processes and hopefully requesting a shared area of memory allocates memory in that range and if so then the memory would be addressable to all proceses.

I cannot find the documentation page I saw a couple of weeks ago but I did see a nice diagram showing designated address ranges in Windows.

Earlier, while reading docs, I saw that 1GB of address space is shared among processes (Win95/98):



Windows 95 and Windows 98: The 4 MB partition in low memory (0x00000000 to 0x00000FFF) is used for compatibility with MS-DOS and 16-bit Windows, the next approximately 2G partition (0x00400000 to 0x7FFFFFFF) is available to the process for private use, the next 1 GB partition (0x80000000 to 0xBFFFFFFF) is shared by all Win32 processes, and the 1 GB partition in high memory (0xC0000000 to 0xFFFFFFF) is used by the system.






Perhaps you're right that GlobalAlloc() gives you memory in that space, and that it isn't necessary for the other process to GlobalLock() it. Worth a try -- thanks for the suggestion!

Okay, I guess I was wrong. I was just going by the documentation though, and you know how great MS docs are. ;-P

e.g.
GlobalAlloc
...
"This function is provided only for compatibility with 16-bit versions of Windows."
...
GMEM_DDESHARE, GMEM_SHARE
"This flag is provided primarily for compatibility with 16-bit Windows. However, this flag may be used by some applications to enhance the performance of DDE operations and therefore can be specified if the memory is to be used for DDE. ."

I highlighted the inconsistent parts. Notice that there are two periods at the end too (editing mistake?). Looks like you guys are right.

O-Deka-K

I think that the documentation is intentionaly misleading, but I am guessing about a lot of this. If the documentation is misleading, then I think it is unusual for the Windows documentation to be so misleading. The documentation often is intentionaly incomplete but it is seldom intentionally misleading. I think that the reason it is misleading is that Microsoft does not want to guarantee that GlobalAlloc will always work the way it works, but they should say that. It is quite common for the Windows documentation to say such things.

So now I am so curious about whether it will work that I am tempted to try it myself.

win32.hlp> under dinamic link library its a posible solution, it could be usefull this code:

// File: DLLSHMEM.C.
// The DLL entry-point function sets up shared memory using
// a named file-mapping object.

#include <windows.h>
#include <memory.h>

#define SHMEMSIZE 4096

static LPVOID lpvMem = NULL; // pointer to shared memory

BOOL DllEntryPoint(HINSTANCE hinstDLL, // DLL module handle
DWORD fdwReason, // reason called
LPVOID lpvReserved) // reserved
{
HANDLE hMapObject = NULL; // handle to file mapping

BOOL fInit, fIgnore;

switch (fdwReason)
{
// The DLL is loading due to process
// initialization or a call to LoadLibrary.

case DLL_PROCESS_ATTACH:

// Create a named file mapping object.

hMapObject = CreateFileMapping(
(HANDLE) 0xFFFFFFFF, // use paging file
NULL, // no security attributes
PAGE_READWRITE, // read/write access

0, // size: high 32-bits
SHMEMSIZE, // size: low 32-bits
"dllmemfilemap"); // name of map object
if (hMapObject == NULL)
return FALSE;

// The first process to attach initializes memory.

fInit = (GetLastError() != ERROR_ALREADY_EXISTS);

// Get a pointer to the file-mapped shared memory.

lpvMem = MapViewOfFile(

hMapObject, // object to map view of
FILE_MAP_WRITE, // read/write access
0, // high offset: map from
0, // low offset: beginning
0); // default: map entire file
if (lpvMem == NULL)
return FALSE;

// Initialize memory if this is the first process.

if (fInit)
memset(lpvMem, '\0', SHMEMSIZE);


break;

// The attached process creates a new thread.

case DLL_THREAD_ATTACH:
break;

// The thread of the attached process terminates.

case DLL_THREAD_DETACH:
break;

// The DLL is unloading from a process due to
// process termination or a call to FreeLibrary.

case DLL_PROCESS_DETACH:

// Unmap shared memory from the process's address space.


fIgnore = UnmapViewOfFile(lpvMem);

// Close the process's handle to the file-mapping object.

fIgnore = CloseHandle(hMapObject);

break;

default:
break;
}

return TRUE;
UNREFERENCED_PARAMETER(hinstDLL);
UNREFERENCED_PARAMETER(lpvReserved);
}

// SetSharedMem sets the contents of shared memory.

VOID SetSharedMem(LPTSTR lpszBuf)
{
LPTSTR lpszTmp;


// Get the address of the shared memory block.

lpszTmp = (LPTSTR) lpvMem;

// Copy the null-terminated string into shared memory.

while (*lpszBuf)
*lpszTmp++ = *lpszBuf++;
*lpszTmp = '\0';
}

// GetSharedMem gets the contents of shared memory.

VOID GetSharedMem(LPTSTR lpszBuf, DWORD cchSize)
{
LPTSTR lpszTmp;

// Get the address of the shared memory block.

lpszTmp = (LPTSTR) lpvMem;

// Copy from shared memory into the caller's buffer.


while (*lpszTmp && --cchSize)
*lpszBuf++ = *lpszTmp++;
*lpszBuf = '\0';
}


Note that the shared memory can be mapped to a different address in each process. For this reason, each process has its own instance of the lpvMem parameter, which is declared as a global variable so that it is available to all DLL functions. The example assumes that the DLL global data is not shared, so each process that loads the DLL has its own instance of lpvMem.
In this example, the shared memory is released when the last handle of the file-mapping object is closed. To create persistent shared memory, a DLL can create a detached process (see CreateProcess) when the DLL is first loaded. If this detached process uses the DLL and does not terminate, it has a handle of the file-mapping object that prevents the shared memory from being released.

Welcome to the Codeguru forums, mauricioprado00. I am sure you will make many more contributions that will help very many.

Note that this thread is very old; more than 8 years old. So your contribution might help others in the future looking for relevant answers but just be aware that the person asking the question has probably either gotten a solution or given up trying.