When passing a value to a function that takes both a WPARAM and a LPARAM parameter, does it matter on which of them I pass it? Someone told me that if I use Windows x64 I should use WPARAM; is this true?
When sending messages, WPARAM and LPARAM parameters have specific interpretations depending on the message. You need to pass those parameters in the way that the message that you are sending expects them to be passed. If you are defining your own message (perhaps via an offset from WM_USER, WM_APP, or RegisterWindowMessage), then you obviously have a bit more latitude.
In the days of 16-bit Windows, a WPARAM was a 16-bit word, while LPARAM was a 32-bit long. These distinctions went away in Win32; they both became 32-bit values.
According to this, LPARAM is defined as LONG_PTR, which in 64-bit Windows is a signed, 64-bit value. WPARAM is defined as UINT_PTR, which in 64-bit Windows is an unsigned, 64-bit value. If you are defining your own message, you might want to assign its parameters accordingly.
╔════════════════╦══════════════════╦═══════════════╗
║ ║ WPARAM ║ LPARAM ║
║ ╟──────────────────╫───────────────╢
║ OS ║ handles, numbers ║ pointers ║
╠════════════════╬══════════════════╬═══════════════╣
║ 16-bit Windows ║ 16-bit unsigned ║ 32-bit signed ║
║ 32-bit Windows ║ 32-bit unsigned ║ 32-bit signed ║
║ 64-bit Windows ║ 64-bit unsigned ║ 64-bit signed ║
╚════════════════╩══════════════════╩═══════════════╝
The history of its definition has changed over the years.
WINDOWS.H (Windows 2.03 SDK, c. 1988)
/* Message structure */
typedef struct tagMSG {
HWND hwnd;
WORD message;
WORD wParam;
LONG lParam;
DWORD time;
POINT pt;
} MSG;
WinDefs.h (c. 1999)
/* Types use for passing & returning polymorphic values */
typedef UINT WPARAM;
typedef LONG LPARAM;
typedef LONG LRESULT;
WinDef.h (c. 2005)
/* Types use for passing & returning polymorphic values */
typedef UINT_PTR WPARAM;
typedef LONG_PTR LPARAM;
typedef LONG_PTR LRESULT;
Bonus Reading
What do the letters W and L stand for in WPARAM and LPARAM? archive (W is for unsigned 16-bit WORD, and L is for signed 32-bit LONG)
What happens to WPARAM, LPARAM, and LRESULT when they travel between 32-bit and 64-bit windows? archive (the unsigned is zero-extended, the signed is sign-extended)
It's message-specific. You can use this list of system-defined message categories as reference. Select a group, then a message from the group to see what the message specifies you should pass as WPARAM/LPARAM.
Raymond Chen explains why we have two params.
Yes, the order matters. WPARAM sent/posted in one side winds up WPARAM on the other end; likewise for LPARAM.
If you have your own custom messages you can use WPARAM and LPARAM for anything you want. (There may be some common conventions though.)
Yes, it does. I once passed them in swapped order and the function I call fails. Nevertheless, you should consult MSDN when in doubt. I never program in Win64 though, so I don't whether there are differences between Win32 and Win64 regarding WPARAM/LPARAM behavior.
Related
Not to long ago, someone told me that long are not 64 bits on 64 bit machines and I should always use int. This did not make sense to me. I have seen docs (such as the one on Apple's official site) say that long are indeed 64 bits when compiling for a 64-bit CPU. I looked up what it was on 64-bit Windows and found
Windows: long and int remain 32-bit in length, and special new data types
are defined for 64-bit integers.
(from http://www.intel.com/cd/ids/developer/asmo-na/eng/197664.htm?page=2)
What should I use? Should I define something like uw, sw ((un)signed width) as a long if not on Windows, and otherwise do a check on the target CPU bitsize?
In the Unix world, there were a few possible arrangements for the sizes of integers and pointers for 64-bit platforms. The two mostly widely used were ILP64 (actually, only a very few examples of this; Cray was one such) and LP64 (for almost everything else). The acronynms come from 'int, long, pointers are 64-bit' and 'long, pointers are 64-bit'.
Type ILP64 LP64 LLP64
char 8 8 8
short 16 16 16
int 64 32 32
long 64 64 32
long long 64 64 64
pointer 64 64 64
The ILP64 system was abandoned in favour of LP64 (that is, almost all later entrants used LP64, based on the recommendations of the Aspen group; only systems with a long heritage of 64-bit operation use a different scheme). All modern 64-bit Unix systems use LP64. MacOS X and Linux are both modern 64-bit systems.
Microsoft uses a different scheme for transitioning to 64-bit: LLP64 ('long long, pointers are 64-bit'). This has the merit of meaning that 32-bit software can be recompiled without change. It has the demerit of being different from what everyone else does, and also requires code to be revised to exploit 64-bit capacities. There always was revision necessary; it was just a different set of revisions from the ones needed on Unix platforms.
If you design your software around platform-neutral integer type names, probably using the C99 <inttypes.h> header, which, when the types are available on the platform, provides, in signed (listed) and unsigned (not listed; prefix with 'u'):
int8_t - 8-bit integers
int16_t - 16-bit integers
int32_t - 32-bit integers
int64_t - 64-bit integers
uintptr_t - unsigned integers big enough to hold pointers
intmax_t - biggest size of integer on the platform (might be larger than int64_t)
You can then code your application using these types where it matters, and being very careful with system types (which might be different). There is an intptr_t type - a signed integer type for holding pointers; you should plan on not using it, or only using it as the result of a subtraction of two uintptr_t values (ptrdiff_t).
But, as the question points out (in disbelief), there are different systems for the sizes of the integer data types on 64-bit machines. Get used to it; the world isn't going to change.
It is not clear if the question is about the Microsoft C++ compiler or the Windows API. However, there is no [c++] tag so I assume it is about the Windows API. Some of the answers have suffered from link rot so I am providing yet another link that can rot.
For information about Windows API types like INT, LONG etc. there is a page on MSDN:
Windows Data Types
The information is also available in various Windows header files like WinDef.h. I have listed a few relevant types here:
Type | S/U | x86 | x64
----------------------------+-----+--------+-------
BYTE, BOOLEAN | U | 8 bit | 8 bit
----------------------------+-----+--------+-------
SHORT | S | 16 bit | 16 bit
USHORT, WORD | U | 16 bit | 16 bit
----------------------------+-----+--------+-------
INT, LONG | S | 32 bit | 32 bit
UINT, ULONG, DWORD | U | 32 bit | 32 bit
----------------------------+-----+--------+-------
INT_PTR, LONG_PTR, LPARAM | S | 32 bit | 64 bit
UINT_PTR, ULONG_PTR, WPARAM | U | 32 bit | 64 bit
----------------------------+-----+--------+-------
LONGLONG | S | 64 bit | 64 bit
ULONGLONG, QWORD | U | 64 bit | 64 bit
The column "S/U" denotes signed/unsigned.
This article on MSDN references a number of type aliases (available on Windows) that are a bit more explicit with respect to their width:
http://msdn.microsoft.com/en-us/library/aa505945.aspx
For instance, although you can use ULONGLONG to reference a 64-bit unsigned integral value, you can also use UINT64. (The same goes for ULONG and UINT32.) Perhaps these will be a bit clearer?
Microsoft has also defined UINT_PTR and INT_PTR for integers that are the same size as a pointer.
Here is a list of Microsoft specific types - it's part of their driver reference, but I believe it's valid for general programming as well.
The easiest way to get to know it for your compiler/platform:
#include <iostream>
int main() {
std::cout << sizeof(long)*8 << std::endl;
}
Themultiplication by 8 is to get bits from bytes.
When you need a particular size, it is often easiest to use one of the predefined types of a library. If that is undesirable, you can do what often happens with autoconf software and have the configuration system determine the right type for the needed size.
For the history of how the choices were made for UNIX & Windows
(the idfferent choices were plausible, Microsoft wasn't being dumb, given its code base.):
The Long Road to 64 Bits - Double Double, Toil and Trouble, in
https://queue.acm.org/detail.cfm?id=1165766 2006 Queue
or
https://dl.acm.org/doi/pdf/10.1145/1435417.1435431 2009 CACM
Note: I helped design the 64/32-bit MIPS R4000, made the suggestion that led to <inttypes.h> and wrote the section of C99 explaining motivation for long long.
The size of long on Windows platforms is 32 bits (4 bytes).
You can check this using sizeof(long), which returns the size in bytes.
If you need to use integers of certain length, you probably should use some platform independent headers to help you. Boost is a good place to look at.
I have seen how to convert a GUID into a CString but what about a DWORD.
Possible?
A UUID/GUID is 128 bits. A DWORD is only 32 bits. If by "convert" you mean "convert without losing data", then the answer is no.
I have found the following function from MSDN which converts an unsigned long from network byte to unsigned long in host byte order i.e. in little-endian defined as:
u_long WSAAPI ntohl(
_In_ u_long netlong
);
The MSDN document says that it can convert a 32 bits number. But since in C++ as I have read that long and int are not the same i.e. long is not guaranteed to be 32 bits or the same size of an integer INT_MAX.
So, I wonder if there is a a similar function which takes a 32 bits values such as unsigned int instead of unsigned long?
The documentation specifically says that ntohl's netlong parameter is a 32-bit value:
netlong [in]
A 32-bit number in TCP/IP network byte order.
I have read that long and int are not the same i.e. long is not
guaranteed to be 32 bits or the same size of an integer INT_MAX.
You're right -- in Standard C++ a long is not guaranteed to be any particular size, except that it must be at least 32 bits.
However since we're talking about the endian conversion functions, we're talking about platform-specifics here. We need to drill down now in to what a long is under Windows. And under Windows, a long is 32-bits:
LONG
A 32-bit signed integer. The range is –2147483648 through 2147483647
decimal. This type is declared in WinNT.h as follows:
typedef long LONG;
ntohl() and htonl() always operate on 32-bit values on all platforms. That is part of the BSD standard. On platforms where (u_)long is larger than 32-bits, a different 32-bit data type will be used instead. For instance, some platforms, including Linux and FreeBSD, use uint32_t to avoid any issues with the size of (u_)long.
When passing a value to a function that takes both a WPARAM and a LPARAM parameter, does it matter on which of them I pass it? Someone told me that if I use Windows x64 I should use WPARAM; is this true?
When sending messages, WPARAM and LPARAM parameters have specific interpretations depending on the message. You need to pass those parameters in the way that the message that you are sending expects them to be passed. If you are defining your own message (perhaps via an offset from WM_USER, WM_APP, or RegisterWindowMessage), then you obviously have a bit more latitude.
In the days of 16-bit Windows, a WPARAM was a 16-bit word, while LPARAM was a 32-bit long. These distinctions went away in Win32; they both became 32-bit values.
According to this, LPARAM is defined as LONG_PTR, which in 64-bit Windows is a signed, 64-bit value. WPARAM is defined as UINT_PTR, which in 64-bit Windows is an unsigned, 64-bit value. If you are defining your own message, you might want to assign its parameters accordingly.
╔════════════════╦══════════════════╦═══════════════╗
║ ║ WPARAM ║ LPARAM ║
║ ╟──────────────────╫───────────────╢
║ OS ║ handles, numbers ║ pointers ║
╠════════════════╬══════════════════╬═══════════════╣
║ 16-bit Windows ║ 16-bit unsigned ║ 32-bit signed ║
║ 32-bit Windows ║ 32-bit unsigned ║ 32-bit signed ║
║ 64-bit Windows ║ 64-bit unsigned ║ 64-bit signed ║
╚════════════════╩══════════════════╩═══════════════╝
The history of its definition has changed over the years.
WINDOWS.H (Windows 2.03 SDK, c. 1988)
/* Message structure */
typedef struct tagMSG {
HWND hwnd;
WORD message;
WORD wParam;
LONG lParam;
DWORD time;
POINT pt;
} MSG;
WinDefs.h (c. 1999)
/* Types use for passing & returning polymorphic values */
typedef UINT WPARAM;
typedef LONG LPARAM;
typedef LONG LRESULT;
WinDef.h (c. 2005)
/* Types use for passing & returning polymorphic values */
typedef UINT_PTR WPARAM;
typedef LONG_PTR LPARAM;
typedef LONG_PTR LRESULT;
Bonus Reading
What do the letters W and L stand for in WPARAM and LPARAM? archive (W is for unsigned 16-bit WORD, and L is for signed 32-bit LONG)
What happens to WPARAM, LPARAM, and LRESULT when they travel between 32-bit and 64-bit windows? archive (the unsigned is zero-extended, the signed is sign-extended)
It's message-specific. You can use this list of system-defined message categories as reference. Select a group, then a message from the group to see what the message specifies you should pass as WPARAM/LPARAM.
Raymond Chen explains why we have two params.
Yes, the order matters. WPARAM sent/posted in one side winds up WPARAM on the other end; likewise for LPARAM.
If you have your own custom messages you can use WPARAM and LPARAM for anything you want. (There may be some common conventions though.)
Yes, it does. I once passed them in swapped order and the function I call fails. Nevertheless, you should consult MSDN when in doubt. I never program in Win64 though, so I don't whether there are differences between Win32 and Win64 regarding WPARAM/LPARAM behavior.
Not to long ago, someone told me that long are not 64 bits on 64 bit machines and I should always use int. This did not make sense to me. I have seen docs (such as the one on Apple's official site) say that long are indeed 64 bits when compiling for a 64-bit CPU. I looked up what it was on 64-bit Windows and found
Windows: long and int remain 32-bit in length, and special new data types
are defined for 64-bit integers.
(from http://www.intel.com/cd/ids/developer/asmo-na/eng/197664.htm?page=2)
What should I use? Should I define something like uw, sw ((un)signed width) as a long if not on Windows, and otherwise do a check on the target CPU bitsize?
In the Unix world, there were a few possible arrangements for the sizes of integers and pointers for 64-bit platforms. The two mostly widely used were ILP64 (actually, only a very few examples of this; Cray was one such) and LP64 (for almost everything else). The acronynms come from 'int, long, pointers are 64-bit' and 'long, pointers are 64-bit'.
Type ILP64 LP64 LLP64
char 8 8 8
short 16 16 16
int 64 32 32
long 64 64 32
long long 64 64 64
pointer 64 64 64
The ILP64 system was abandoned in favour of LP64 (that is, almost all later entrants used LP64, based on the recommendations of the Aspen group; only systems with a long heritage of 64-bit operation use a different scheme). All modern 64-bit Unix systems use LP64. MacOS X and Linux are both modern 64-bit systems.
Microsoft uses a different scheme for transitioning to 64-bit: LLP64 ('long long, pointers are 64-bit'). This has the merit of meaning that 32-bit software can be recompiled without change. It has the demerit of being different from what everyone else does, and also requires code to be revised to exploit 64-bit capacities. There always was revision necessary; it was just a different set of revisions from the ones needed on Unix platforms.
If you design your software around platform-neutral integer type names, probably using the C99 <inttypes.h> header, which, when the types are available on the platform, provides, in signed (listed) and unsigned (not listed; prefix with 'u'):
int8_t - 8-bit integers
int16_t - 16-bit integers
int32_t - 32-bit integers
int64_t - 64-bit integers
uintptr_t - unsigned integers big enough to hold pointers
intmax_t - biggest size of integer on the platform (might be larger than int64_t)
You can then code your application using these types where it matters, and being very careful with system types (which might be different). There is an intptr_t type - a signed integer type for holding pointers; you should plan on not using it, or only using it as the result of a subtraction of two uintptr_t values (ptrdiff_t).
But, as the question points out (in disbelief), there are different systems for the sizes of the integer data types on 64-bit machines. Get used to it; the world isn't going to change.
It is not clear if the question is about the Microsoft C++ compiler or the Windows API. However, there is no [c++] tag so I assume it is about the Windows API. Some of the answers have suffered from link rot so I am providing yet another link that can rot.
For information about Windows API types like INT, LONG etc. there is a page on MSDN:
Windows Data Types
The information is also available in various Windows header files like WinDef.h. I have listed a few relevant types here:
Type | S/U | x86 | x64
----------------------------+-----+--------+-------
BYTE, BOOLEAN | U | 8 bit | 8 bit
----------------------------+-----+--------+-------
SHORT | S | 16 bit | 16 bit
USHORT, WORD | U | 16 bit | 16 bit
----------------------------+-----+--------+-------
INT, LONG | S | 32 bit | 32 bit
UINT, ULONG, DWORD | U | 32 bit | 32 bit
----------------------------+-----+--------+-------
INT_PTR, LONG_PTR, LPARAM | S | 32 bit | 64 bit
UINT_PTR, ULONG_PTR, WPARAM | U | 32 bit | 64 bit
----------------------------+-----+--------+-------
LONGLONG | S | 64 bit | 64 bit
ULONGLONG, QWORD | U | 64 bit | 64 bit
The column "S/U" denotes signed/unsigned.
This article on MSDN references a number of type aliases (available on Windows) that are a bit more explicit with respect to their width:
http://msdn.microsoft.com/en-us/library/aa505945.aspx
For instance, although you can use ULONGLONG to reference a 64-bit unsigned integral value, you can also use UINT64. (The same goes for ULONG and UINT32.) Perhaps these will be a bit clearer?
Microsoft has also defined UINT_PTR and INT_PTR for integers that are the same size as a pointer.
Here is a list of Microsoft specific types - it's part of their driver reference, but I believe it's valid for general programming as well.
The easiest way to get to know it for your compiler/platform:
#include <iostream>
int main() {
std::cout << sizeof(long)*8 << std::endl;
}
Themultiplication by 8 is to get bits from bytes.
When you need a particular size, it is often easiest to use one of the predefined types of a library. If that is undesirable, you can do what often happens with autoconf software and have the configuration system determine the right type for the needed size.
For the history of how the choices were made for UNIX & Windows
(the idfferent choices were plausible, Microsoft wasn't being dumb, given its code base.):
The Long Road to 64 Bits - Double Double, Toil and Trouble, in
https://queue.acm.org/detail.cfm?id=1165766 2006 Queue
or
https://dl.acm.org/doi/pdf/10.1145/1435417.1435431 2009 CACM
Note: I helped design the 64/32-bit MIPS R4000, made the suggestion that led to <inttypes.h> and wrote the section of C99 explaining motivation for long long.
The size of long on Windows platforms is 32 bits (4 bytes).
You can check this using sizeof(long), which returns the size in bytes.
If you need to use integers of certain length, you probably should use some platform independent headers to help you. Boost is a good place to look at.