Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Given a standard windows procedure function:

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Where do the names wParam and lParam come from and what the history behind them?

share|improve this question

migrated from superuser.com Mar 3 '11 at 6:28

This question came from our site for computer enthusiasts and power users.

    
Once upon a time there was a programmer. He may have been wise or he may have been just a average programmer, but he decided to call it this way. After month of use these function parameter names became sort of a standard. But you may call them whatever you want if you feel you know of a better name. –  user17124 Mar 3 '11 at 6:27
2  
You forgot the HIWORD(lParam) and LOWORD(lParam) macros... ;) –  Ernelli Mar 3 '11 at 7:33
add comment

3 Answers

Back in the dark ages of Windows 3.0 these names were already well established. I never had an SDK for Windows earlier than 3.0, but I suspect they originate with Windows 1.0. All of these were essentially 16-bit extended DOS applications. Being 16-bit programs running in an environment where a good machine had all 640K of RAM installed, there was a lot of pressure on memory footprint for applications. So, the generic Window Message was kept as small as practical. It still needed room for a command code, and more than one parameter. Sometimes the parameter would need to be a fully-qualified (aka FAR) pointer that included both a 16-bit segment number along with a 16-bit offset. So there was need for a parameter big enough to hold the largest possible pointer.

The result of that was that the messages contained the 16-bit message code (wCommand or sometimes uMsg as you have it), a generic 16-bit parameter (wParam) and a generic 32-bit parameter (lParam).

As Windows got more powerful and dependent on advanced processors such as the 80286 and 80386, and eventually grew to have 32-bit modes of operation, those names became just bits of history.

Development for Windows 3.0 was not all that pleasant. We didn't have any IDE that was hosted in Windows, or even a compiler that could run while Windows was running. All code was edited in DOS, compiled in DOS, and Windows launched for testing. If you were lucky, you could debug under Windows, but since the system depended on cooperative tasking, and bugs were likely to seize control of the only thread, even that wasn't all that easy to do reliably.

share|improve this answer
add comment

Under Win16, the types of these parameters were WORD and LONG.

share|improve this answer
add comment

The w and l prefix derive from the Microsoft coding guidelines which had Hungarian notation in them for a long time. The names are very generic probably due to the fact the parameters have very different meanings for various calls of the same function. Each wparam and lparam has a different meaning for each message resulting in a very generic name.

share|improve this answer
2  
And this also shows the fallacy of the Hungarian notation, as the prefixes couldn't be changed when the types had to be. :-( –  Bo Persson Mar 3 '11 at 19:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.