[PATCH] ntdll/exception: Change return type to CONTEXT* of RtlLocateLegacyContext.
Paul Gofman
pgofman at codeweavers.com
Wed Sep 2 08:56:10 CDT 2020
On 9/2/20 16:40, Biswapriyo Nath wrote:
> I have done some tests with that function in Windows 10.
>
> 1. Call RtlGetExtendedContextLength, allocate a buffer with the
> returned length.
> 2. Pass that buffer as CONTEXT_EX to RtlInitializeExtendedContext
> which also returns CONTEXT in the first parameter.
Not necessarily, the actual context data location maybe ahead of the
first parameter buffer to provide alignment (there is a test for that in
dlls/ntdll/exception.c:test_extended_context()).
> 3. Use that CONTEXT_EX buffer to RtlLocateLegacyContext. Now check the
> returned CONTEXT structure pointer with the 2nd step one.
>
Yes, sure, and there is also the test for that. But I am not sure how
all that can give any clue how RtlLocateLegacyContext is defined
somewhere. The patch that you introduce should not result in binary
difference in the compiled code. It is not possible to test what pointer
type the (undocumented) function returns, only to look that up if the
function prototype is publicly available.
> Also there is a hint in the function name "RtlLocateLegacyContext"
> itself. CONTEXT_EX holds the offsets of "Legacy" context (in wdm.h).
> And by doing the pointer arithmetic "context_ex +
> context_ex->Legacy.Offset", RtlLocateLegacyContext should return a
> CONTEXT pointer.
You can't guess declared pointer type from test, only test the values.
That information is simply not there in the machine code and thus not
testable.
>
> I agreed with your logic and it's true. But if one wants to get the
> WoW-ed CONTEXT, he/she already has to set the appropriate CONTEXT
> pointer structure type as return value.It depends on the flag in
> RtlGetExtendedContextLength function.
>
>
Or that program willing to use this sort of function is a debugger and
simply got that structure from somewhere. The debugger might be x64,
while the debugged program might be x86 and that context has nothing to
do with 'CONTEXT' defined in the headers for debugger.
I think if there is an intention to use this context management API it
is strictly preferable to use kernel32 functions (like InitContext,
LocateXStateFeature etc.) instead of these undocumented ntdll functions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200902/c3f058e9/attachment-0001.htm>
More information about the wine-devel
mailing list