I am finishing the port of a suite of Windows programs that were originally released under Windows 2.0 (they started development under Windows 1.0, I've found many comments dated 1986!). These programs allocate and deallocate memory all over the place. Way more than is necessary, but they were probably trying to fit into the small physical memory on PCs back then.

I'm campaigning to rewrite the whole suite into one integrated program, but I haven't convinced them it would be cheaper to start over yet.

Anyway, one thing that is causing a lot of problem is allocated memory shared between applications. One program will allocate the memory, possibly do something with it, then send a message that another application picks up, grabs the shared memory, does something with it, then the original program continues.

In a lot of places, the second program is hanging because the memory passed to it is locked when it gets it. In some cases the sending program does a GlobalUnlock before sending the message to the receiving program, but it still arrives locked.

I was able to get it to work by calling:

addr = MapViewOfFile(sharedHandle, FILE_MAP_ALL_ACCESS, 0, 0, viewSize)

Then looking at the second DWORD which is the flags and manually clearing the lock flag if it's set. I'm concerned I may be doing something that might destabilize the program though. It's kind of a kludge.

The programs use GlobalAlloc, GlobalLock, etc. as well as the LocalAlloc, etc. functions. From what I've read, these old function calls are now just wrappers to the current heap functions and there really isn't Global and Local memory anymore.

I'm also wondering if the lock flag is set upon allocation in the Win 32 alloc functions, but is not locked by default in the Win 16 functions? Something systematic is definitely going on that is different in Win 32 and Win 16. I'm just guessing this is it.