November 3rd, 2004

Why do I sometimes see redundant casts before casting to LPARAM?

If you read through old code, you will often find casts that seem redundant.

SendMessage(hwndListBox, LB_ADDSTRING, 0, (LPARAM)(LPSTR)”string”);

Why was “string” cast to LPSTR? It’s already an LPSTR!

These are leftovers from 16-bit Windows. Recall that in 16-bit Windows, pointers were near by default. Consequently, “string” was a near pointer to a string. If the code had been written as

SendMessage(hwndListBox, LB_ADDSTRING, 0, (LPARAM)”string”);

then it would have taken the near pointer and cast it to a long. Since a near pointer is a 16-bit value, the pointer would have been zero-extended to the 32-bit size of a long.

However, all pointers in window messages must be far pointers because the window procedure for the window might very well be implemented in a different module from the sender. Recall that near pointers are interpreted relative to the default selector, and the default selector for each module is different. Sending a near pointer to another module will result in the pointer being interpreted relative to the recipient’s default selector, which is not the same as the sender’s default selector.

The intermediate cast to LPSTR converts the near pointer to a far pointer, LP being the Hungarian prefix for far pointers (also known as “long pointers”). Casting a near pointer to a far pointer inserts the previously-implied default selector, so that the cast to LPARAM captures the full 16:16 far pointer.

Aren’t you glad you don’t have to worry about this any more?

Topics
History

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

0 comments

Discussion are closed.