When was the WM_COPYDATA message introduced, and was it ported downlevel?


Gabe wondered when the WM_COPY­DATA message was introduced.

The WM_COPY­DATA message was introduced by Win32. It did not exist in 16-bit Windows.

But it was there all along.

The The WM_COPY­DATA message was carefully designed so that it worked in 16-bit Windows automatically. In other words, you retained your source code compatibility between 16-bit and 32-bit Windows without having to do a single thing. Phew, one fewer breaking change between 16-bit and 32-bit Windows.

As Neil noted, there's nothing stopping you from sending message 0x004A in 16-bit Windows with a window handle in the wParam and a pointer to a COPY­DATA­STRUCT in the lParam. Since all 16-bit applications ran in the same address space, the null marshaller successfully marshals the data between the two processes.

In a sense, support for the WM_COPY­DATA message was ported downlevel even before the message existed!

Comments (9)
  1. Bert Huijben says:

    No time machine necessary this time :)

  2. Smithers says:

    They ported a feature from Win32 to Win16 even before it was invented? To think, all this time you've been lying to us that Microsoft research haven't finished their time machine yet.

    Although, I suppose with a time machine, it doesn't really matter when it gets finished, does it?

  3. Antonio 'Grijan' says:

    Well, that time machine has to be really buggy… 21 years after the firs alpha was created, it has yet to be released! On the other hand, as Smithers points, the fact that we haven't received any visits from the future may prove that we won't be able to make it work in the future :-( .

  4. John Doe says:

    Or rather, we're stuck in the main universe time branch.  A time machine creates a branch at the target time, so some versions of us will see visitors from other times.

  5. Crescens2k says:

    Of course, you could wonder if that may be a good thing. You never know, a universe where there are no compatibility issues in any software because someone came from the future to fix things could have ended up so awesome that the universe imploded due to division by zero.

  6. Myria says:

    @Antonio:

    "What do we want?"

    "Time travel!"

    "When do we want it?"

    "It's irrelevant!"

  7. smf says:

    Time travel is all around us, we just have no control over the speed or direction of the travel.

    Some time travel myths don't allow time travel before the time machine was created, making when you want it quite relevant.

  8. Joshua says:

    I believe the following are now known to be true:

    If you send a nonexistent message it will be delivered as is.

    If you send a nonexistent message that Windows later uses (let the reader understand) your code will break. Therefore don't send unallocated messages in the system range (0 .. WM_USER – 1).

    If you send a message that was already allocated in a future version of Windows to a program that knows what to do with it your code will work if the null marshaller does the right thing (which is almost always equal to the message will be delivered as is).

    [More accurately, "If you send a nonexistent message on 16-bit Windows, it will be delivered as is." The rules are stricter on 32-bit and 64-bit Windows. That's because 16-bit Windows didn't require marshaling for any messages! -Raymond]
  9. Joshua says:

    Hmm what did I miss? A message not in the table of messages doesn't get marshaled so WPARAM and LPARAM don't change when sent across processes (ignoring widening/narrowing when crossing bitness). Perhaps sending messages from future Windows versions is forbidden in 32 bit or 64 bit Windows. Perhaps something else.

    [16-bit Windows does not marshal anything, so WPARAM and LPARAM never change when sent across processes. 32-bit Windows does marshaling and rejects invalid messages since it doesn't know how to marshal them. This trick, therefore, works only with 16-bit Windows. -Raymond]

Comments are closed.