by smitop on 1/23/24, 11:21 PM with 99 comments
by adrian_b on 1/24/24, 1:01 PM
This technique had already been used in many Microsoft programs for CP/M, i.e. for Intel 8080 or Zilog Z80 CPUs.
There were two reasons for the use of such jumps in the middle of instructions. One was to obfuscate the program for disassemblers, which were desynchronized with the instruction stream by such jumps. The other reason is that each such jump usually saved one byte of instruction code in comparison with conventional conditional program structures.
When the program size was still measured in kilobytes, saving even only one hundred bytes by this method was important.
The instruction into the middle of which a jump was performed was usually an instruction that loaded a 16-bit register with an immediate value that happened to be the encoding for some other instruction.
The value loaded into the register was not used. Therefore, when the instruction was entered through its start address, no operation was done, but when it was entered through a jump, some extra instruction was executed.
A typical use case would be at the beginning of a loop, which was entered after initializing a control variable, while whenever the loop was repeated later an extra instruction was executed (corresponding to the immediate value of the register load), to update the control variable. This saved one byte upon the standard loop implementation that uses an unconditional jump for entering the body of the loop in its middle, after the loop initialization.
by mst on 1/24/24, 5:52 PM
> There’s at least one such utility out there that properly enough validates if their patches would work, or blocklist specific Windows builds known to break from it completely. I wish the other very-obvious-from-your-article software would do so too.
and I can't help but agree.
If you're going to reach into the guts of another process and start flipping bits, it's only Correct to take responsibility for doing so carefully enough you don't blow the entire thing up.
(I have written code that replaced/wrapped other people's function pointers for various reasons (occasionally even -good- ones) and considered any problem caused by an upgrade of the code hosting my cuckoo chick to be my bug - and while it was occasionally bloody annoying, I did this to myself ;)
by bombcar on 1/24/24, 1:47 PM
by Ciantic on 1/24/24, 11:24 AM
I've also made an explorer.exe in-memory patch to disable flashing taskbar buttons in Windows 10, it injected itself to WndProc and set the specific message to zero. In Windows 11 it's now a setting, so I don't need that anymore.
Now I'm investigating an explorer.exe patch for Windows 11 to speed up wallpaper animations. Which cannot be configured at the moment, there is only one setting to turn off all animations but no setting to speed up the wallpaper fade in animation.
by EdSharkey on 1/24/24, 5:54 PM
Why is this allowed? This sounds like a small hell.
I left Windows the moment we shifted from "developers, developers, developers, developers" to "advertisers, advertisers, advertisers, advertisers" and never looked back.
Ubuntu is very pleasant to work with, nowadays.
by omoikane on 1/24/24, 7:19 PM
See also: https://www.hyrumslaw.com/
by mbork_pl on 1/24/24, 11:10 AM
by saurik on 1/24/24, 11:18 AM
Just look through the comments on this article to see people pointing out how Microsoft keeps removing options for how people can do this in less risky ways, or even ideas for how Microsoft can improve the safety of these extensions (which aren't all exactly right but I will note that if Microsoft embraced these more and provided an official loader--not one that limited the access but merely coordinated the installation--this is easily solved with the same kind of "safe mode" I designed for shell extensions on jailbroken iOS devices).
To quote one of the comments:
> Not just this article, but far too often when articles such as this are written, about widely used 3rd party tweaks, and the commenting strongly supports the tweak in question, but MS charges forward that “all these enthusiasts are wrong, we will continue our way” is telling of how far out of touch the Win dev team is away from its user base.
by jackewiehose on 1/24/24, 12:27 PM
Watching that I was just thinking NO NO NO - it worked fine for the last 25 years and there can be absolutely no reason why they had to destroy the taskbar now.
He deserves every headache he gets with these support requests.
Or to quote this comment of the linked article:
> There wouldn’t be as much of a need if the windows shell team was smarter [...] In fact I actively encourage, support, and celebrate efforts like this. Make their life hell and delay them. If they spend more time on investigating issues like this, they’ll have less time to f*k something else up.
by TravHatesMe on 1/24/24, 11:17 AM