Well, as I am new to this board I think I'll start posting two really important things to know about behaviour of Windows 2k/xp, which are not documented anywhere (also not in MSDN) and thus, took me a few weeks to locate the problem(s).
:alright: case #1:
When using GetThreadContext() to retrieve the current state of processor registers of another Thread/Process, you have to push the address of a CONTEXT-Structure as second argument.
You MUST place your CONTEXT-structure-variable at a memory address which is divisible by 4 (also called dword-alignment)! Otherwise, GetThreadContext will mysteriously fail on 2k/xp-systems!
In MASM, you can achieve this by writing
align dword
before you define the variable and
align byte
after it, if you don't want dword align anymore (wastes space).
:alright: case #2:
On Windows 2k/xp systems, you cannot use the function CreateToolhelp32Snapshot() on processes which have been created in suspended state! You won't get a valid Snapshot-handle.
If you know more phenomenons of this kind, don't hesitate to tell us. Could save days/weeks of research!
aweX <-
:alright: case #1:
When using GetThreadContext() to retrieve the current state of processor registers of another Thread/Process, you have to push the address of a CONTEXT-Structure as second argument.
You MUST place your CONTEXT-structure-variable at a memory address which is divisible by 4 (also called dword-alignment)! Otherwise, GetThreadContext will mysteriously fail on 2k/xp-systems!
In MASM, you can achieve this by writing
align dword
before you define the variable and
align byte
after it, if you don't want dword align anymore (wastes space).
:alright: case #2:
On Windows 2k/xp systems, you cannot use the function CreateToolhelp32Snapshot() on processes which have been created in suspended state! You won't get a valid Snapshot-handle.
If you know more phenomenons of this kind, don't hesitate to tell us. Could save days/weeks of research!
aweX <-
About case 1, I've already reported this silly undocumented behaviour of NT based OS's, specifically my report had as example QueryPerformance*(), but the rule is general.
Always align to at least DWORD anything of your own you pass to the API functions.
Always align to at least DWORD anything of your own you pass to the API functions.
Did you get any replies to your report so far?
What would they be useful for?
That they actually read your report...
that they're adding it into MSDN ...
etc
etc
that they're adding it into MSDN ...
etc
etc
dword alignment doesn't waste much space, and you ought to align
all dword-or-larger sized data items to at least dword boundaries
(read the intel docs if you need to know why). No, I don't think
the PlatformSDK mentions dword alignment anywhere, but that's because
it's written mainly for C programmers, and I don't think there's any
modern compiler that has alignment less than 4 bytes.
all dword-or-larger sized data items to at least dword boundaries
(read the intel docs if you need to know why). No, I don't think
the PlatformSDK mentions dword alignment anywhere, but that's because
it's written mainly for C programmers, and I don't think there's any
modern compiler that has alignment less than 4 bytes.
Here's another one for you:
Nope, it doesn't. ;) Only tested it on 98 though.
#edit#
Just tested it on XP, the size of nDebugStringLength is correct there. Seems to be a feature of 98 then ;)
typedef struct _OUTPUT_DEBUG_STRING_INFO {
LPSTR lpDebugStringData;
WORD fUnicode;
WORD nDebugStringLength;
} OUTPUT_DEBUG_STRING_INFO, *LPOUTPUT_DEBUG_STRING_INFO;
Members
[...]
nDebugStringLength
Specifies the length, in characters, of the debugging string.
The length [b]includes[/b] the string's terminating null character.Nope, it doesn't. ;) Only tested it on 98 though.
#edit#
Just tested it on XP, the size of nDebugStringLength is correct there. Seems to be a feature of 98 then ;)