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?

  • 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
    Commented Mar 3, 2011 at 6:27
  • 2
    You forgot the HIWORD(lParam) and LOWORD(lParam) macros... ;)
    – Ernelli
    Commented Mar 3, 2011 at 7:33

3 Answers 3


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


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.


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.

  • 3
    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
    Commented Mar 3, 2011 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.