While I was at it, I figured since the Android app has a bunch of bloat like nagscreens, telemetry, social media integration, I might look into that as well. So I stripped the Android app down to the bare essentials to be what it is: just a video editor.
It is really crazy how good LLM are when you give it access to some tools such as ghidra headless, frida, etc.
It's not really more complex once you're practiced at it, just tedious.
The latter implies that you've understood where and how it happens as well as noticed any other areas that may be impacted by fixing the bug or by not fixing it. AI just fixes it without thinking about anything else - which is great, but it explains why serious people (and Microsoft) aren't doing just that. We've spent decades worrying about quality, reliability and performance. Using AI is saying all of that was poppycock and it's faster to rebuild than to understand and fix. It's a different school of thought, and hopefully one that bursts down in flame in a few months.
They don't fix this stuff, because it's a priority-3 ticket sitting in the middle of the queue that has hundreds of similar tickets on it, and none of them are being done, because the team has moved on and is either developing new stuff, or addressing priority-1 bugs that are blocking the other teams that are developing the new stuff (possibly backend stuff, but still stuff that will bring money).
Fixing a bug for everyone is very different from fixing the bug just for yourself
That's quite remarkable. How detailed was your prompting to specify the incorrect and desired behavior?
I have a challenging task. There is a copy of the Windows Remote Desktop executable in this dir. I'd like to see if you can fix two bugs in it (without source code). First, occasionally texture filtering will be disabled until the program is restarted. What happens is that if the window isn't full size, it looks grainy (aliased) instead of smooth, and text is difficult to read. The second bug is when switching from full screen to a window. Each time you do this, the non-fullscreen window gets slightly wider and taller (mostly taller), which causes the aspect ratio to go wrong over time (not to mention getting too big). Can you try to fix one or both of these bugs by patching the binary? You'll also have to strip the signing since it will no longer be correct.
vmconnect.exe (Hyper-V enhanced session) not going fullscreen after login when the window is fullscreen and you have to minimize and maximize to get fullscreen? Have your agent debug the issue and come up with an elaborate hook system that leaves the Microsoft files untouched.
Codex/Chatgpt electron app coming with annoying or missing features (Mini, Invite friends, no mcp hotreload, windows updates failing, ...)? Just point codex at codex and have it build an mcp Ouroboros to improve itself and enable dynamic js userscripts.
Deskflow clipboard sharing between devices missing file sharing, just have sessions on Mac, Linux and Windows collude to cook up a solution.
Yet writing proper documentation and reports that are human digestible still seems a bit out of reach, why would humans need to read anyway...
I'm pretty familiar with reverse engineering and for most of my career I doubt I went more than a month without patching some memory into 0x90. The explanations are perfectly reasonable and are close to what I expected. It's just that it would have taken me a week to find where to patch without the source!
The insertion of NOPs is a great way to remove a function call that might have crashed the program. If you didn’t need anything that function did, you’ve solved your problem but not fixed the bug.
Also I don't think it's an honest take. You took this stance because the change was done by AI. If a person patched MS app he uses that had a bug that bothered him for a decade you would be more appreciative.
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.