Articles of win64

LVITEM为Windows 64位

很长一段时间,我尝试使用带有LVIF_TEXT掩码的LVM_GETITEMW消息来获取ListView的文本。 我的程序工作在32位但不是在64位体系结构。 我发现问题是在LVITEM结构。 不久,我的问题是哪个结构是适当的64位,为什么。 我用作LVITEMW结构的结构体具有以下字段: ('mask', c_uint32), ('iItem', c_int32), ('iSubItem', c_int32), ('state', c_uint32), ('stateMask', c_uint32), ('pszText', c_uint32), ('cchTextMax', c_int32), ('iImage', c_int32), ('lParam', c_uint64), ('iIndent', c_int32), ('iGroupId', c_int32), ('cColumns', c_uint32), ('puColumns', c_uint32), ('piColFmt', c_int32), ('iGroup', c_int32) (用python 2.7 ctypes编写,但这只是一种书写forms – 语言真的不相关)。 这些字段与文档一样 。 经过大量的search,我发现这个论坛正是我所需要的 – 64位解决scheme! 所以在64位的结构应该有更多的“空间”,应该看起来像这样(指针现在是64位,也是状态stateMask是64位,这有点不同于论坛的build议,但也起作用): ('mask', c_uint32), ('iItem', c_int32), ('iSubItem', c_int32), ('state', c_uint32), ('stateMask', […]

如何使用ifdef检测Windows DWORD_PTRtypes是否受支持?

Windows API中有一些新的整数types可以支持Win64。 他们并不总是得到支持; 例如它们不在MSVC6中 。 如何编写#if条件来检测这些types是否被<windows.h>支持? (我的代码需要在许多不同版本的Microsoft Visual C ++中编译,包括MSVC6,所以我需要提供我自己的这些types的定义,用#if在较新的编译器中禁用它们)。 (对于search者,types的完整列表是:DWORD_PTR,INT_PTR,LONG_PTR,UINT_PTR,ULONG_PTR)

如何检索system32或SysWOW64的正确path?

我有一个可以在32位或64位Windows上运行的32位进程。 所以,自然,如果进程试图访问文件c:\windows\system32\file.ext ,它将被redirect到c:\windows\SysWOW64\file.ext 。 到目前为止这么好 – 我不想禁用redirect。 我的问题是,我的进程并没有实际访问该文件 – 而只是采取其path,并将其写入文本文件 ,我希望该文本文件读取64位系统上的SysWOW64和32位系统上的system32 ,位系统。 我怎样才能做到这一点?

如何编译OpenSSL for x64?

按照INSTALL.W64中的说明,我有两个问题: 代码仍然写入“out32”文件夹。 我需要能够链接到我的工作站上的库的32位和64位版本,所以我不希望64位版本打开32位库。 输出仍然是32位! 这意味着我尝试从x64应用程序链接到库时会出现“无法parsing的外部符号”错误。

64位Windows API:C / C ++“DWORD”的大小是多less?

我只安装了32位Windows,所以我无法自己validation。 如果我理解正确,那么在Microsoft API的各个地方使用的DWORD是参考原来的16位字,而与当前的硬件架构无​​关? 因此,即使当我最终编译并链接我的应用程序以在64位Windows中运行时,似乎是32位的DWORD也将保持32位? 或者将DWORD变成128位宽?

GWL_USERDATA用于存储对象指针的替代方法是什么?

在我工作的Windows应用程序中,我们有一个直接位于Win32上方的定制框架(不要问)。 当我们创build一个窗口的时候,我们通常的做法是通过SetWindowLong(hwnd, GWL_USERDATA, this)把this放在窗口的用户数据区域,这使得我们可以有一个类似MFC的callback或紧密集成的WndProc 。 问题是,这不能在Win64上工作,因为LONG只有32位宽。 这个问题的更好的解决scheme是什么,适用于32位和64位系统?