了解 MAKEINTRESOURCEW 定义
查看 Windows SDK,我发现了 MAKEINTRESOURCEW 的 #define 指令:
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
有人能给我解释一下这到底意味着什么吗?例如,MAKEINTRESOURCEW(0) 的值是多少? (1)? (-1)?
Looking at the Windows SDK, I found this #define directive for MAKEINTRESOURCEW:
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
Can someone explain to me what the heck that means? For example, what would be the value of MAKEINTRESOURCEW(0)? (1)? (-1)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这是一个宏,它将参数 i 转换为一个单词,然后将该结果转换为指向 unsigned long 的指针,然后再次转换为指向宽字符字符串的 long 指针。
That's a macro that casts an argument i to a word, then casts that result to a pointer to an unsigned long, then again to a long pointer to a wide-character string.
就像其他用户所说 - 它只是将整数转换为“指向字符串的指针”。
原因如下:在 Windows 3.0 的远古时代,人们试图尽可能简约。
假设可执行文件中的资源可以具有字符串标识符或整数。因此,当您尝试访问此类资源时 - 您指定上述内容之一,并且该函数会自动区分您的含义(通过检查提供的“指针”是否看起来像有效的指针)。
由于该函数无法接收“可变参数类型” - 他们决定让它接收 LPCTSTR (或类似的),而传递的实际参数可能是整数。
Windows API 的另一个例子:指向窗口过程的指针。每个窗口都有一个窗口过程(通过带有
GWL_WNDPROC
标志的GetWindowLong
访问。然而有时它只是一个整数,指定窗口的“类型”。
然后有一个 CallWindowProc 知道如何区分这些情况。
Like other users said - it just casts an integer into a "pointer to a string".
The reason for this is the following: At the ancient times of Windows 3.0 people tried to be minimalistic as much as possible.
It was assumed that resources in the executable can have either string identifier or integer. Hence when you try to access such a resource - you specify one of the above, and the function distinguish what you meant automatically (by checking if the provided "pointer" looks like a valid pointer).
Since the function could not receive a "variable argument type" - they decided to make it receive LPCTSTR (or similar), whereas the actual parameter passed may be integer.
Another example from Windows API: A pointer to the window procedure. Every window has a window procedure (accessed via
GetWindowLong
withGWL_WNDPROC
flag.However sometimes it's just an integer which specifies what "kind" of a window is that.
Then there's a
CallWindowProc
which knows to distinguish those cases.该宏的结果将是指向长字符串的指针,其值等于给定参数。您可以通过读取预编译器输出来查看它(请参阅 /P C++ 编译器选项)。当在 Win32 和 x64 配置中需要 LP[w]WSTR 指针时,需要进行所有转换来编译此宏结果。
某些 Windows API(例如 LoadIcon)需要字符串指针作为参数。这些函数可能会测试指针值,如果它小于某个最大值,它们会将其解释为资源索引,而不是字符串(丑陋的 C 风格接口的问题)。因此,该宏允许通过适当的转换将 WORD 作为字符串传递,而不更改其值。
The result of this macro will be pointer to long string with value equal to given parameter. You can see it by reading precompiler output (see /P C++ compiler options). All casting is required to compile this macro result, when LP[w]WSTR pointer is required, both in Win32 and x64 configurations.
Some Windows API, like LoadIcon, expect string pointer as their parameter. Possibly, these functions test the pointer value, and if it is less than some maximum, they interpret it as resource index, and not as string (problems of ugly C-style interface). So, this macro allows to pass WORD as string, without changing its value, with appropriate casting.
在大多数情况下,它保持值不变,但将其从 int 转换为指针,因此对于期望看到指针的函数来说是可以接受的。中间转换将输入 int 扩大到与指针相同的大小,同时确保它不被符号扩展。如果您关心的话,
ULONG_PTR
并不是您可能猜想的“ULONG POINTER”,而是一个与指针大小相同的 unsigned long。早在 64 位编程成为关注点之前,定义是这样的:现在,他们使用 ULONG_PTR,对于 32 位目标来说是 32 位无符号长整型,对于 64 位目标是 64 位无符号长整型。
For the most part, it leaves the value unchanged, but converts it from an int to a pointer so it's acceptable to functions that expect to see a pointer. The intermediate casts widen the input int to the same size as a pointer, while ensuring against it's being sign extended. In case you care,
ULONG_PTR
is not a "ULONG POINTER" like you might guess -- rather, it's an unsigned long the same size as a pointer. Back before 64-bit programming became a concern, the definition was something like:Nowadays, they use ULONG_PTR, which is a 32-bit unsigned long for a 32-bit target, and a 64-bit unsigned long for a 64-bit target.