中国数学外国人做视频网站,wordpress中collapse,成都网站设计策划免费,北京到广州火车时刻表查询从前#xff0c;Windows 是 16 位的。每条message信息都可以携带两段数据#xff0c;分别称为 WPARAM 和 LPARAM。在消息参数传递中对指针类型使用强制类型转换#xff0c;这是一种常见用法。第一个参数是一个 16 位值#xff08;word#xff09;#xff0c;… 从前Windows 是 16 位的。每条message信息都可以携带两段数据分别称为 WPARAM 和 LPARAM。在消息参数传递中对指针类型使用强制类型转换这是一种常见用法。第一个参数是一个 16 位值word因此称为 W第二个参数是一个 32 位值long因此称为 L。 W 参数用于传递句柄和整数。L 参数用于传递指针。 当 Windows 转换为 32 位时WPARAM 参数也变为 32 位值。一个字的大小变成了32bit。(在 64 位 Windows 中两个参数都是 64 位值。 了解这些术语的起源很有帮助。如果查看一下窗口消息的设计就会发现如果消息使用指针指针通常会在 LPARAM 中传递而如果消息使用句柄或整数则会在 WPARAM 中传递。(如果一条信息两个都包含则整数放在 WPARAM 中指针放在 LPARAM 中。 学会了这一点记忆窗口消息的参数就容易多了。相反如果一条消息违反了这一规则那么你的大脑就会说 不这不对。 Once upon a time, Windows was 16-bit. Each message could carry with it two pieces of data, called WPARAM and LPARAM. It is the common practice of passing casted pointers as message parameters. The first one was a 16-bit value (“word”), so it was called W. The second one was a 32-bit value (“long”), so it was called L. You used the W parameter to pass things like handles and integers. You used the L parameter to pass pointers. When Windows was converted to 32-bit, the WPARAM parameter grew to a 32-bit value as well. The word changes to 32-bit. (And in 64-bit Windows, both parameters are 64-bit values!) It is helpful to understand the origin of the terms. If you look at the design of window messages, you will see that if the message takes a pointer, the pointer is usually passed in the LPARAM, whereas if the message takes a handle or an integer, then it is passed in the WPARAM. (And if a message takes both, the integer goes in the WPARAM and the pointer goes in the LPARAM.) Once you learn this, it makes remembering the parameters for window messages a little easier. Conversely, if a message breaks this rule, then it sort of makes your brain say, “No, that’s not right.” LPARAM 是 LONG_PTR 的类型定义在 win32 中是 long有符号 32 位在 x86_64 中是 __int64 有符号 64 位。 WPARAM 是 UINT_PTR 的类型定义在 win32 中是无符号 int32 位无符号在 x86_64 中是__int6464 位无符号。 LPARAM is a typedef for LONG_PTR which is a long (signed 32-bit) on win32 and __int64 (signed 64-bit) on x86_64. WPARAM is a typedef for UINT_PTR which is an unsigned int (unsigned 32-bit) on win32 and unsigned __int64 (unsigned 64-bit) on x86_64. 分割线 Windows的SDK里代码经常有WPARAM和LPARAM这两个参数作为一个消息结构体的两个成员传递信息。WPARAM通常用来表示句柄或数值LPARAM通常用来表示一个指针。在平时编写代码时也会使用这两个参数来传递数据这时就要注意区分两个类型。 LPARAM因为是会被用作指针的类型所以使用时赋值要使用指针类型或者类型的长度不能小于指针的类型。而WPARAM作为普通数值使用可以使用当前平台的一个字或者是固定的长度类型。 今天遇到的问题就和这两个类型相关。示例代码如下使用的是unsigned int类型传递的参数名借用了WPARAM和LPARAM。 #include stdio.h void func(unsigned int LPARAM, unsigned int WPARAM) { unsigned int * value; printf(Input LPARAM: 0x%lX \n, LPARAM); value (unsigned int *) LPARAM; *value 100; printf(WPARAM is %d\n, WPARAM); } int main() { unsigned int foo, bar; printf(foo addr: 0x%lX \n, foo); func(foo, bar); return 0; } 这段代码在ARM 32平台上执行是没问题的但执行在ARM 64和x86-64的Ubuntu虚拟机平台上就崩了。 我PC的处理器 Intel(R) Core(TM) i5-8400H CPU 2.50GHz 2.50 GHz 64-bit operating system, x64-based processor Windows 64系统上面安装的64 bit的Ubuntu虚拟机。 编译并之执行上面代码 $ gcc -o x86 test.c $ ./x86 foo addr: 0x7FFE0163AD10 Input LPARAM: 0x163AD10 Segmentation fault (core dumped) 因为在64 位系统上unsigned int类型大多还是4字节long int才是8字节而指针类型是8字节这样一转换就直接挂了。 所以使用LPARAM和WPARAM参数的较好的方式如下 #include stdint.h #include stdio.h void func(intptr_t LPARAM, uint32_t WPARAM) { int * value; printf(Input LPARAM: 0x%lX \n, LPARAM); value (int *) LPARAM; *value 100; printf(Input WPARAM is %d \n, WPARAM); } int main() { unsigned int foo, bar; bar 1000; printf(foo addr size %ld %ld, value 0x%lX\n, sizeof(foo), sizeof(unsigned long) , (unsigned long)foo); func((intptr_t)foo, bar); printf(foo is %d, bar is %d. \n, foo, bar); return 0; } 输出 $ gcc -o x86 test.c $ ./x86 foo addr size 8 8, value 0x7FFE82FD8750 Input LPARAM: 0x7FFE82FD8750 Input WPARAM is 1000 foo is 100, bar is 1000. LPARAM类型使用intptr_t类型在stdint.h中定义32位系统就是4字节64位系统就是8字节适配系统大小自动调节。 WPARAM类型使用uint32_t类型在stdint.h中定义使用固定大小正常应该能满足需求并且32位、64位系统的int 类型大多同样是4字节。 参考 1Microsoft What do the letters W and L stand for in WPARAM and LPARAM? - The Old New Thing 2Stackoverflow c# - What are the definitions for LPARAM and WPARAM? - Stack Overflow
