Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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
You forgot the HIWORD(lParam) and LOWORD(lParam) macros... ;) – Ernelli Mar 3 '11 at 7:33

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

share|improve this answer

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

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
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

Your Answer


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