Need full control over SendMessageA's LPARAM - page 2

Probably both. I don't know what happens if a 64-bit application (on 64-bit Windows) sends a message to a 32-bit application. Presumably truncation of the integers at 32 bits, though I'm not sure. Alternatively, it's possible that 32-bit apps and 64-bits apps simply can't exchange messages. I've never tried this.

I think it's a truncation. This works because of the lo hi rule ; Lo dword before Hi dword, Lo word before Hi word, Lo bytes before Hi bytes. With this rule, sending small values abiding old rules should still work, even if sent from a x64 app.

I'm not familiar with Pascal, but you simply cannot use GlobalAlloc() as a way of passing memory between separate 32-bit applications. (It may continue to work between 16-bit applications if you have an old compiler, but that's not going to help you in communicating from MT4.) See http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx. You should theoretically be able to use WM_COPYDATA, though file access is going to be a lot simpler.

Hmm, perhaps that's why, I remember it was working about 13 years ago when the 16 bit compilers were working. I don't understand why GlobalAlloc wasn't then deprecated in the 32-bit environment. Since what it allocates is thread specific and undistributable, why bothering with handlers when you have straight pointers?

Depends which of the many meanings of "deprecated" you're referring to. Microsoft generally take the approach that API functions don't cease to exist unless they absolutely have to. There were plenty of 16 bit apps which used GlobalAlloc() across the board, not just for sharing memory with other applications. Therefore, in order to allow these to continue to work when recompiled for 32-bit, the GlobalAlloc() function simply became identical to LocalAlloc(). As http://msdn.microsoft.com/en-us/library/aa366596(VS.85).aspx says, "the global and local families of functions are equivalent".

...And, being pedantic, it's process-specific, not thread-specific.

I see. I have the same Win32 Programmer's Reference that I had at that time, it specifies there is no longer that distinction between local and global heap, but it fails to say that memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes.

As I see, it was a decision thingy. They simply decided to remove the sharing facility that GlobalAlloc offered int the 16-bit model, although memory sharing in Win32 wouldn't have been so bad. After all I remember protected mode apps had General Protection Faults even when accesssing some of their own pointers.

This new WM_COPYDATA mechanism seems similar to the old style, but there must be something that makes it so special:

case WM_COPYDATA:
   pMyCDS = (PCOPYDATASTRUCT) lParam;   

now that lparam is a pointer, like any other pointer, and PCOPYDATASTRUCT is in another application, it should blow up with a GPF for refferring data in another app, but probably there is something that the compiler sets but it's not present in the code and makes the magic of sharing.

But you're right, if needed, will use the file technique.

I would imagine that the "magic" consists of the operating system processing the WM_COPYDATA between send and receipt by the two apps, transferring the memory between address spaces, and adjusting the pointer which the receiving app sees. I can't see how it could be something done by the compiler. That would again imply that it was possible for processes to have unmanaged access to each other's address spaces. This is why Windows 3.x kept falling over.