Some time ago, I talked about how to return results back from the WM_ message. Which reminded me of a clever bit of history.
The WM_ message was introduced in 32-bit Windows. There was no need for it in 16-bit Windows because all 16-bit programs ran in the same address space. A far pointer in one process was good in any process. You could put it in the lParam of a window message and send it to any other window, same process or different process, doesn’t matter. But 32-bit programs ran in separate address spaces, so this trick didn’t work. Hence the need for WM_ to pass data not only between 32-bit programs, but also between 32-bit programs and 16-bit programs.
How did this message get retrofitted into 16-bit Windows so that Win32s could support it?
Easy: It was already implemented, unwittingly.
If the source and destination windows are both 16-bit windows, then the pointer to the COPYDATASTRUCT is already valid in both processes, as is the pointer inside the COPYDATASTRUCT. And the window handle in the wParam is also the same for both processes. Therefore, doing absolutely nothing with the wParam and lParam and simply allowing it to pass from a 16-bit program to another 16-bit program will still behave as expected.
And it so happens that Windows 3.1 already did that: Windows 3.1 always passed the wParam and lParam unmodified, even when the message sender and receiver are in different processes, because all programs shared the same address space.
It was just a sneaky trick to design the WM_ message in such a way that the null marshaler is the correct behavior when it is sent between 16-bit programs.
