Comment

Comment by SyzygyRhythm

Here was the explanation for the window-growing bug. It did the window adjustment math wrong, and it was able to fix it by replacing the call with NOPs.

  Bug 2 — window grows on every fullscreen→windowed transition

  mstsc.exe implements container-handled fullscreen (mstscax.dll calls it through a vtable thunk at RVA 0x1a3e0). In LeaveFullScreen (RVA 0x161a0):

  SetWindowPlacement(hwnd, &savedPlacement)   // restores the pre-fullscreen WINDOW rect
  GetWindowRect(hwnd, &rc)                    // rc = that window rect (frame included)
  SetWindowLong(GWL_STYLE, style | WS_CAPTION|WS_THICKFRAME|WS_MAXIMIZEBOX)
  AdjustWindowRectEx(&rc, style, FALSE, exStyle)   // <-- adds the frame a SECOND time
  SetWindowPos(hwnd, ..., rc.width, rc.height, SWP_NOMOVE|SWP_FRAMECHANGED)

  EnterFullScreen (0x15a8c) saves a raw GetWindowPlacement, and the clamp just above compares rcNormalPosition against [this+0xb0/0xb4], which 0x104b0 computes as window sizes — so the saved rect is unambiguously a window rect. Running AdjustWindowRectEx on it inflates by one non-client frame per cycle: +2×SM_CXSIZEFRAME wide (~16px) and +SM_CYCAPTION+2×frame tall (~39px). That's your "slightly wider, mostly taller."

  Patch: mstsc.exe RVA 0x16385 (file offset 0x15785), e8 16 2d 00 00 → 5× 0x90. The restored size is now exactly the saved one. The call's return value was already discarded, so NOPping it has no other effect.

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton