**5/9**
Oh, right, this is the bug where the game hooks a bunch of stuff. So do we expect that this change is a no-op in the absence of hooking?
Effectively yes. After looking into it some more, I'm not so convinced that we want to do this, though. It looks like we can't depend on `GetClientRect` giving a proper origin (which BTW I think is supposed to always be at (0,0)? At least MSDN is very explicit about it), while `ClientToScreen` just returns `FALSE` for the video child window. Maybe using `presenter->native_size` and / or `info->szAspectRatio` is more proper? I'll probably try something along those lines.
**6/9**
It doesn't look like RE2 calls that function, not sure if there are other ways to get there? I don't see `IVMRAspectRatioControl` being queried either. Hacking the vmr7 tests it seems to confirm that the default is to stretch (I guess you already knew this), but the game on Windows has the letterboxing. I'd be curious about the window dimensions on Windows, but I suspect that peeking into that is a step too far.
This is more of a problem though. I don't think we want to be changing the default AR mode. Is there a different path that we could be using to get the image onto the screen, one that might also be hooked by the native ddraw? \[and that might also sidestep the GetClientRect() issue...\]
I think I figured it out. The game window is 320x240 fullscreen while the video is 320x160. VMR is set up in windowed mode. The game calls `VideoWindow_SetWindowPosition(..., 0, 10, 320, 160)`, which would center the video vertically when accounting for the caption bar that the parent (ddraw, fullscreen) window is supposed to have. But we tweak the window styles when entering fullscreen and the game doesn't expect or check for that, so the child window ends up higher than it should be. I don't think there is much we can do upstream for this one until we figure out some way to stop messing with window styles in wined3d. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9520#note_124405