in richedit.h NMHDR is defined as follows:
typedef struct _nmhdr
{
HWND hwndFrom;
UINT idFrom;
UINT code;
} NMHDR;
in winuser.h, it is defined as :
typedef struct tagNMHDR
{
HWND hwndFrom;
UINT_PTR idFrom;
UINT code; // NM_ code
} NMHDR;
note that IdFrom went from being a UINT in richedit.h to a UINT_PTR in winuser.h
when compiling for 32bit that won't make a difference but, when compiling for 64bit, the winuser.h idFrom is going to be 4 bytes larger than the richedit.h idFrom.
I suspect that I must be missing something because a difference in size of 4 bytes between the two structures would have broken a fair amount of code out there but, I don't see how that conflict is resolved.
I would appreciate an explanation of how these two seemingly incompatible definitions can coexist. Thank you for your help.
Related
I've installed vscode extension (ms-vscode.cpptools) from Microsoft to enable intellisense. But, when i typed MessageBox, the parameters have no labels.
It should be
MessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType)
My Question: Why MingW distribute the header files without labels?
It should be
MessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType)
That is not so.
The tooltip is showing you the declaration of the function, as declared
in MingGW's header winuser.h. That declaration specifies the function's
prototype, consisting of:
The return type of the function, then
The name of the function, then
The types of the parameters in the parameter-list, within brackets, in the right order.
as the tooltip does:
int MessageBoxW (HWND, LPCSTR, LPCSTR, UINT)
What you call "labels" are parameter-names. They are optional, and redundant,
in a function declaration, since the compiler does not need them to understand
how the declared function will be called, and what it returns. MessageBoxW
is to be called with arguments that are a HWND, a LPCSTR, another LPCSTR,
and a UINT, in that order; and it returns and int.
The compiler requires parameters to be named in a function definition:
add.c
// definition
int add(int x, int y)
{
return x + y;
}
main.c
#include <stdio.h>
extern int add(int,int); // Declaration
int main()
{
printf("%d\n",add(3,4));
return 0;
}
Compile with maximum strictness, link and run:
$ gcc -Wall -Wextra -pedantic -o prog main.c add.c
$ ./prog
7
See also Function Declaration in C
Parameter-names are useful to human readers in a function-declaration when the declaration
is accompanied by documentation of the function, since the documentation
can then refer to the parameter-names to explain the function's behaviour:
/*
Return the sum of `x` and `y`
*/
int add(int x, int y);
But they are unnecessary to the compiler.
Like the MinGW windows headers, Micorosoft's own headers do not contain comments
to document the APIs, but they do contain parameter-names, and also SAL Annotations
of the parameter names. E.g. in Microsoft's WinUser.h (SDK 2017) the declaration of MessageBoxW is:
int
WINAPI
MessageBoxW(
_In_opt_ HWND hWnd,
_In_opt_ LPCWSTR lpText,
_In_opt_ LPCWSTR lpCaption,
_In_ UINT uType);
The SAL annotations, (_In_opt_, _In_ and similar) are a non-standard Microsoft
language extension that supports static analysis of the correctness of code
implementing or invoking the APIs and they are used for that purpose by Microsoft's
compilers.
Such SAL-based static analysis needs names for the annotated parameters in order to provide
meaningful diagnostics; hence the parameters have names in the annotated declarations
in Microsoft's headers.
GCC, including MinGW ports, does not support SAL; so parameter names remain
redundant in function declarations.
I used the 'ntQuerySystemInformation' to get all the handle information like:
NtQuerySystemInformation(SystemHandleInformation, pHandleInfor, ulSize,NULL);//SystemHandleInformation = 16
struct of pHandleInfor is:
typedef struct _SYSTEM_HANDLE_INFORMATION
{
ULONG ProcessId;
UCHAR ObjectTypeNumber;
UCHAR Flags;
USHORT Handle;
PVOID Object;
ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;
It works well in xp 32bit, but in Win7 64bit can only get the right pid that less than 65535. The type of processId in this struct is ULONG, I think it can get more than 65535. What's wrong with it? Is there any other API instead?
There are two enum values for NtQuerySystemInformation to get handle info:
CNST_SYSTEM_HANDLE_INFORMATION = 16
CNST_SYSTEM_EXTENDED_HANDLE_INFORMATION = 64
And correspondingly two structs: SYSTEM_HANDLE_INFORMATION and SYSTEM_HANDLE_INFORMATION_EX.
The definitions for these structs are:
struct SYSTEM_HANDLE_INFORMATION
{
short UniqueProcessId;
short CreatorBackTraceIndex;
char ObjectTypeIndex;
char HandleAttributes; // 0x01 = PROTECT_FROM_CLOSE, 0x02 = INHERIT
short HandleValue;
size_t Object;
int GrantedAccess;
}
struct SYSTEM_HANDLE_INFORMATION_EX
{
size_t Object;
size_t UniqueProcessId;
size_t HandleValue;
int GrantedAccess;
short CreatorBackTraceIndex;
short ObjectTypeIndex;
int HandleAttributes;
int Reserved;
}
As You can see, the first struct really can only contain 16-bit process id-s...
See for example ProcessExplorer project's source file ntexapi.h for more information.
Note also that the field widths for SYSTEM_HANDLE_INFORMATION_EX in my struct definitions might be different from theirs (that is, in my definition some field widths vary depending on the bitness), but I think I tested the code both under 32-bit and 64-bit and found it to be correct.
Please recheck if necessary and let us know if You have additional info.
From Raymond Chen's article Processes, commit, RAM, threads, and how high can you go?:
I later learned that the Windows NT folks do try to keep the numerical values of process ID from getting too big. Earlier this century, the kernel team experimented with letting the numbers get really huge, in order to reduce the rate at which process IDs get reused, but they had to go back to small numbers, not for any technical reasons, but because people complained that the large process IDs looked ugly in Task Manager. (One customer even asked if something was wrong with his computer.)
I want more detailed information about cbClsExtra and cbWndExtra WNDCLASSEX members that are used in RegisterClassEx winapi.
MSDN says that this members can be used to set size of extra bytes that will be allocated for class and for each window instance accordingly.
MSDN says
The system initializes the bytes to zero.
1) Does this mean that bytes are initialized with zero value or system allocates zero (none) bytes by default?
2) The most important question is how to use this extra bytes (provide examples please with winapi used) and how they are used most common?
Thanks in advance.
Does this mean that bytes are initialized with zero value or system allocates zero (none) bytes by default?
initialization is always done on variables, so it means to sets the allocated extra memory to 0.
The most important question is how to use this extra bytes (provide
examples please with winapi used) and how they are used most common?
The only way to do this is via the GetClassLongPtr and GetWindowLongPtr functions, these functions are simple enough to not need examples (call Get* to get the value, and Set* set set the value, passing either the class ATOM or window HWND).
I guess this is a really old question and the person already went on with life, but I think it deserves a proper answer as I was struggling with it and the answer wasn't much help. Yes it stated how to set the extra memory and the ONLY functions to use; but much much more detail was NECESSARY.
You see, experience persons thinks things are obvious and common sense, but I beg to differ. Win32 API is not a very intuitive API. Once you learn it you get to understand certain patterns, but later discover that some parts of the API is very different from some. Example, Setting font for your window, is different from setting font in an Edit control; which is surprisingly very very different for Rich Edit Control.
Thus I always refer to MSDN documentation and when I cant get the information there; ask Stack Overflow.
///______MY SOLUTION _________
Here is how you use cbWndExtra, which is extra bytes you can allocate to each Window Instance of that class. I know not about cbClassExtra.
Note I use cbWndExtra as an alternative to GWL_USERDATA. With the latter I would create and new pointer to my special structure and set it to GWL_USERDATA. This struct has all state I need to manage the window object.
However I have been trying out cbWndExtra to avoid creating memory on the heap. For simple primitive variables.
Step 1. Create windowProc.def file. This contains enumerations and functions for accessing the window bytes in a type safe way.
#include <windows.h>
#define LINE_NUM_VIEW_WIDTH 0
#define CODE_EDITOR_EDITOR 0
#define CODE_EDITOR_LINE_VIEW (CODE_EDITOR_EDITOR + sizeof(HWND))
#define CODE_EDITOR_HEIGHT (CODE_EDITOR_LINE_VIEW + sizeof(HWND))
#define CODE_EDITOR_RESIZABLE (CODE_EDITOR_HEIGHT + sizeof(LONG))
#define LINE_NUMBER_VIEW_WND_EXTRA_BYTES sizeof(LONG)
#define CODE_EDITOR_WND_EXTRA_BYTES (CODE_EDITOR_RESIZABLE + sizeof(LONG))
#define getLineNumberViewWidth( hwnd) GetWindowLong(hwnd,LINE_NUM_VIEW_WIDTH)
#define setLineNumberViewWidth( hwnd, n) SetWindowLong(hwnd,LINE_NUM_VIEW_WIDTH,n)
#define getTextEditor( hwnd) ((HWND)GetWindowLongPtr(hwnd,CODE_EDITOR_EDITOR))
#define getLineNumberView( hwnd) ((HWND)GetWindowLongPtr(hwnd,CODE_EDITOR_LINE_VIEW))
#define setCodeEditorHeight(hwnd,n) SetWindowLong(hwnd,CODE_EDITOR_HEIGHT,n)
#define getCodeEditorHeight(hwnd) GetWindowLong(hwnd,CODE_EDITOR_HEIGHT)
#define isCodeEditorResizable(hwnd) GetWindowLong(hwnd,CODE_EDITOR_RESIZABLE)
#define setCodeEditorResizable(hwnd, yes) SetWindowLong(hwnd,CODE_EDITOR_RESIZABLE,yes)
Note the trick with GetWindowLong, GetWindowLongPtr. Use GetWindowLong for Long, int, bool, and the likes. Use GetWindowLongPtr for pointers. Also notice the Long in the name. the function returns sizeof(LONG) and stores sizeof(Long). And msdn states valid range is 0 to cbWndExtra - sizeof(Long). Thus even though you can allocate 1 byte of cbWndExtra, DONT! Allocate multiples of LONG. And also remember that GetWindowLongPtr stores and retrieves sizeof(LONG_PTR). valid range 0 - cbWndExtra - sizeof(LONG_PTR). LONG_PTR and LONG are different size on 64 bit windows.
It is really simple. GetWindowLong will always try retrieve Long. Thus if you allocate 12 bytes and try to retrieve index 10; that is a mistake as only 2 bytes can be retrieved. Maybe windows gives you a bly, but as far as I am concernes that is undefined behaviour. And I stay clear of undefined behaviour.
Note there is GetWindowWord as well. Never used it. There is no GetWindowByte, Short, Bool or any mechanism getting and setting 1 byte or 2 byte. Thus allocate one Long block for all your bools.
Step 2. create windowProc.cpp
#include <stdio.h>
#include "windowProc.def"
LRESULT CALLBACK windowProc(HWND hwnd,UINT msg,WPARAM wparam,LPARAM lparam)
{
switch(msg)
{
case WM_CREATE:
setCodeEditorHeight(hwnd,100); // from windowProc.def
printf("%i",getCodeEditorHeight(hwnd)); // from windowProc.def
return 0;
default: return DefWindowProc(hwnd, msg, wparam, lparam);
}
}
ATOM registerMainWindow()
{
WNDCLASSEX wincl = {0};
wincl.cbSize = sizeof(WNDCLASSEX);
wincl.hInstance = (HINSTANCE)0x400000;
wincl.lpszClassName = "JavWindowProc";
wincl.lpfnWndProc = windowProc;
wincl.hCursor = LoadCursor(NULL,IDC_IBEAM);
wincl.hbrBackground = (HBRUSH)(COLOR_BACKGROUND+1);
wincl.cbWndExtra = CODE_EDITOR_WND_EXTRA_BYTES; // Safely set the size with our enumeration from windowProc.def
return (LPCSTR)RegisterClassEx(&wincl);
}
HWND createMainWindow(const char *title,int width,int height)
{
static auto className = registerMainWindow();
return CreateWindowExA(
0, // Extended possibilites for variation
className,
title,
WS_CHILD,
0,0,width,height,
HWND_DESKTOP,
0,
(HINSTANCE)0x400000,
NULL // No Window Creation data// The alternative to cbWndExtra
);
}
Steps 3 Obviously create your main function with your message loop.
Hope this was a help to somebody.
I am running out of ideas here. I have a piece of code adapted from http://thetechnofreak.com/technofreak/keylogger-visual-c/ to convert keycodes to unicode chars. It works fine in all situations except when you try to run the 32-bit version from 64-bit Windows. For some reason pKbd->pVkToWcharTable keeps returning NULL. I have tried __ptr64 as well as explicitly specifying SysWOW64 and System32 for the kbd dll path. I have found several items across the internet referring to this exact or very similar problem but I cannot seem to get any of the solutions to work (See: KbdLayerDescriptor returns NULL at 64bit architecture) The following is my test code that was compiled with mingw-32 on Windows XP (gcc -std=c99 Wow64Test.c) and then executed on Windows 7 64-bit. On Windows XP I am getting a valid pointer, however on Windows 7 I am getting NULL.
***Update: So it looks like the problems I am having are due to mingw not implementing __ptr64 correctly as the sizeof operation gives 4 bytes instead of the 8 bytes given by visual studio. So the real solution would be figuring out a way to make the size of KBD_LONG_POINTER dynamic or at least 64-bits but I am not sure if thats possible. Any ideas?
#include <windows.h>
#include <stdio.h>
#define KBD_LONG_POINTER __ptr64
//#define KBD_LONG_POINTER
typedef struct {
BYTE Vk;
BYTE ModBits;
} VK_TO_BIT, *KBD_LONG_POINTER PVK_TO_BIT;
typedef struct {
PVK_TO_BIT pVkToBit;
WORD wMaxModBits;
BYTE ModNumber[];
} MODIFIERS, *KBD_LONG_POINTER PMODIFIERS;
typedef struct _VK_TO_WCHARS1 {
BYTE VirtualKey;
BYTE Attributes;
WCHAR wch[1];
} VK_TO_WCHARS1, *KBD_LONG_POINTER PVK_TO_WCHARS1;
typedef struct _VK_TO_WCHAR_TABLE {
PVK_TO_WCHARS1 pVkToWchars;
BYTE nModifications;
BYTE cbSize;
} VK_TO_WCHAR_TABLE, *KBD_LONG_POINTER PVK_TO_WCHAR_TABLE;
typedef struct {
DWORD dwBoth;
WCHAR wchComposed;
USHORT uFlags;
} DEADKEY, *KBD_LONG_POINTER PDEADKEY;
typedef struct {
BYTE vsc;
WCHAR *KBD_LONG_POINTER pwsz;
} VSC_LPWSTR, *KBD_LONG_POINTER PVSC_LPWSTR;
typedef struct _VSC_VK {
BYTE Vsc;
USHORT Vk;
} VSC_VK, *KBD_LONG_POINTER PVSC_VK;
typedef struct _LIGATURE1 {
BYTE VirtualKey;
WORD ModificationNumber;
WCHAR wch[1];
} LIGATURE1, *KBD_LONG_POINTER PLIGATURE1;
typedef struct tagKbdLayer {
PMODIFIERS pCharModifiers;
PVK_TO_WCHAR_TABLE pVkToWcharTable;
PDEADKEY pDeadKey;
PVSC_LPWSTR pKeyNames;
PVSC_LPWSTR pKeyNamesExt;
WCHAR *KBD_LONG_POINTER *KBD_LONG_POINTER pKeyNamesDead;
USHORT *KBD_LONG_POINTER pusVSCtoVK;
BYTE bMaxVSCtoVK;
PVSC_VK pVSCtoVK_E0;
PVSC_VK pVSCtoVK_E1;
DWORD fLocaleFlags;
BYTE nLgMax;
BYTE cbLgEntry;
PLIGATURE1 pLigature;
DWORD dwType;
DWORD dwSubType;
} KBDTABLES, *KBD_LONG_POINTER PKBDTABLES;
typedef PKBDTABLES(CALLBACK *KbdLayerDescriptor) (VOID);
int main() {
PKBDTABLES pKbd;
HINSTANCE kbdLibrary = NULL;
//"C:\\WINDOWS\\SysWOW64\\KBDUS.DLL"
//"C:\\WINDOWS\\System32\\KBDUS.DLL"
kbdLibrary = LoadLibrary("C:\\WINDOWS\\SysWOW64\\KBDUS.DLL");
KbdLayerDescriptor pKbdLayerDescriptor = (KbdLayerDescriptor) GetProcAddress(kbdLibrary, "KbdLayerDescriptor");
if(pKbdLayerDescriptor != NULL) {
pKbd = pKbdLayerDescriptor();
printf("Is Null? %d 0x%X\n", sizeof(pKbd->pVkToWcharTable), pKbd->pVkToWcharTable);
}
FreeLibrary(kbdLibrary);
kbdLibrary = NULL;
}
It might be late for you, but here is a solution for anyone having the same problem. This demo and incomplete explanation helps, but only works in Visual Studio:
http://www.codeproject.com/Articles/439275/Loading-keyboard-layout-KbdLayerDescriptor-in-32-6
The pointers in the structures in kbd.h all have the KBD_LONG_POINTER macro, which is defined as *__ptr64* on 64 bit operating systems. In Visual Studio, this makes the pointers take up 8 bytes instead of the usual 4 of 32 bit programs. Unfortunately in MinGW, *__ptr64* is defined to not do anything.
As written in the linked explanation, the KbdLayerDescriptor function returns pointers differently on 32 bit and 64 bit Windows. The size of pointers seem to depend on the operating system and not on the running program. Actually, the pointers are still 4 bytes on a 64 bit operating system for a 32 bit program, but in VS, the __ptr64 keyword lies that they are not.
For example some structures look like this in kbd.h:
typedef struct {
BYTE Vk;
BYTE ModBits;
} VK_TO_BIT, *KBD_LONG_POINTER PVK_TO_BIT;
typedef struct {
PVK_TO_BIT pVkToBit;
WORD wMaxModBits;
BYTE ModNumber[];
} MODIFIERS, *KBD_LONG_POINTER PMODIFIERS;
This can't work neither in MinGW nor in VS for 32 bit programs on 64 bit Windows. Because the pVkToBit member in MODIFIERS is only 4 bytes without __ptr64. The solution is to forget about KBD_LONG_POINTER (you could even remove them all) and define structures similar to the above. i.e. :
struct VK_TO_BIT64
{
BYTE Vk;
BYTE ModBits;
};
struct MODIFIERS64
{
VK_TO_BIT64 *pVkToBit;
int _align1;
WORD wMaxModBits;
BYTE ModNumber[];
};
(You could use VK_TO_BIT and not define your own VK_TO_BIT64, as they are the same, but having separate definitions help understanding what's going on.)
The member pVkToBit still takes up 4 bytes, but KbdLayerDescriptor pads pointers to 8 bytes on a 64 bit OS, so we have to insert some padding (int _align1).
You have to do the same thing for the other structures in kbd.h. For example this will replace KBDTABLES:
struct WCHARARRAY64
{
WCHAR *str;
int _align1;
};
struct KBDTABLES64
{
MODIFIERS64 *pCharModifiers;
int _align1;
VK_TO_WCHAR_TABLE64 *pVkToWcharTable;
int _align2;
DEADKEY64 *pDeadKey;
int _align3;
VSC_LPWSTR64 *pKeyNames;
int _align4;
VSC_LPWSTR64 *pKeyNamesExt;
int _align5;
WCHARARRAY64 *pKeyNamesDead;
int _align6;
USHORT *pusVSCtoVK;
int _align7;
BYTE bMaxVSCtoVK;
int _align8;
VSC_VK64 *pVSCtoVK_E0;
int _align9;
VSC_VK64 *pVSCtoVK_E1;
int _align10;
DWORD fLocaleFlags;
byte nLgMax;
byte cbLgEntry;
LIGATURE64_1 *pLigature;
int _align11;
DWORD dwType;
DWORD dwSubType;
};
(Notice that the _align8 member does not come after a pointer.)
To use this all, you have to check whether you are running on 64 bit windows with this: http://msdn.microsoft.com/en-us/library/ms684139%28v=vs.85%29.aspx
If not, use the original structures from kbd.h, because the pointers behave correctly. They take up 4 bytes. In case the program is running on a 64 bit OS, use the structures you created. You can achieve it with this:
typedef __int64 (CALLBACK *LayerDescriptor64)(); // Result should be cast to KBDTABLES64.
typedef PKBDTABLES (CALLBACK *LayerDescriptor)(); // This is used on 32 bit OS.
static PKBDTABLES kbdtables = NULL;
static KBDTABLES64 *kbdtables64 = NULL;
And in some initialization function:
if (WindowsIs64Bit()) // Your function that checks the OS version.
{
LayerDescriptor64 KbdLayerDescriptor = (LayerDescriptor64)GetProcAddress(kbdLibrary, "KbdLayerDescriptor");
if (KbdLayerDescriptor != NULL)
kbdtables64 = (KBDTABLES64*)KbdLayerDescriptor();
else
kbdtables64 = NULL;
}
else
{
LayerDescriptor KbdLayerDescriptor = (LayerDescriptor)GetProcAddress(kbdLibrary, "KbdLayerDescriptor");
if (KbdLayerDescriptor != NULL)
kbdtables = KbdLayerDescriptor();
else
kbdtables = NULL;
}
This solution does not use __ptr64 at all, and works both in VS and MinGW. The things you have to watch out for are:
The structures should be aligned on 8 byte boundaries. (This is the default in current VS or MinGW, at least for C++.)
Don't define KBD_LONG_POINTER to __ptr64, or remove it from everywhere. Although you are better off not changing kbd.h.
Understand how alignment for structure members work. (I have compiled this as C++ and not C. I'm not sure whether alignment rules would be any different for C.)
Use the correct variable (either kbdtables or kbdtables64) depending on the OS.
This solution is obviously not needed when compiling a 64 bit program.
Good day, folks!
I have a structure with 100+ parameters needed by my kernel. I create a buffer object for the data, do the write, and set a pointer to that data as a kernel argument. (The kernel arg is __global, but I've tried other types for it.)
So far so good! I can see the structure's elements from my kernel function just fine!
However, I want a dozen helper functions to have access to these parameters. I have tried, but I haven't found a way to do this. If I try to copy the (__global) vh into another global pointer, or a __local pointer, or a __private pointer, it fails. If I try to copy the structure data itself into a __global, or __local, or __private copy of the structure, it fails. I've tried byte-wise copies, I've tried async_work_group_copy, I've tried casts, I tried passing the whole __global pointer in to the helper functions, I've tried other types for the kernel arg itself, I've tried everything I can think of. It seems that it might not be possible to get this data to these helper functions, but it must be possible, right?
Any answer will be welcome, even if it's "that can't be done", or "you're an idiot". I've asked this question on another forum and had nobody has said even that much, though perhaps I didn't word my question properly. But ... I can't be the only person in the world with helper functions in their kernel code, right? How the heck do you get data to them that was passed in to the kernel function?
Thanks folks....
David
Thanks....
Here is an example which demonstrates the functionality you want, hope it helps!
Structure definitions:
typedef struct agent {
uint energy;
uint action;
uint type;
uint next;
} AGENT __attribute__ ((aligned (16)));
typedef struct sim_params {
uint size_x;
uint size_y;
uint size_xy;
uint max_agents;
uint null_agent_pointer;
uint grass_restart;
uint lines_per_thread;
} SIM_PARAMS;
typedef struct cell {
uint grass;
uint agent_pointer;
} CELL;
Helper function:
/*
* Helper function
*/
void removeAgentFromCell(__global AGENT * agents,
__global CELL * matrix,
uint cellIndex,
uint agentIndex,
uint previousAgentIndex,
SIM_PARAMS sim_params)
{
...
}
Main kernel:
/*
* The kernel
*/
__kernel void step1(__global AGENT * agents,
__global CELL * matrix,
__global ulong * seeds,
const uint turn,
const SIM_PARAMS sim_params)
{
uint index;
uint agentIndex;
uint previousAgentIndex;
...
// Call helper function
removeAgentFromCell(agents, matrix, index, agentIndex, previousAgentIndex, sim_params);
...
}
Tried and tested and working in AMD APP SDK (on both CPU and GPU) and Nvidia CUDA Toolkit. So I guess it will work in OSX.