[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