While in this case the jump into the middle of an instruction was not intentional, several decades ago many Microsoft programs for MS-DOS, like their BASIC interpreter, contained frequent intentional jumps into the middle of instructions.<p>This technique had already been used in many Microsoft programs for CP/M, i.e. for Intel 8080 or Zilog Z80 CPUs.<p>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.<p>When the program size was still measured in kilobytes, saving even only one hundred bytes by this method was important.<p>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.<p>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.<p>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.
One of the comments says:<p>> 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.<p>and I can't help but agree.<p>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.<p>(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 ;)
Kind of sad. Even from this blog, he admits that the Microsoft of old would test software and see if it worked; the Microsoft of now obviously knows of the existence of these shell enhancements, but clearly doesn’t test patches against them at all.
I know it must be frustrating from Microsoft's standpoint, but those are needed because they keep changing things. Start All Back is one very popular explorer.exe patch that makes the Windows 11 taskbar function a lot like Windows 10. For one thing, it allows you to move the taskbar again.<p>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.<p>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.
So these patchers are monkey patching a system executable needed to have a bootable/usable system?<p>Why is this allowed? This sounds like a small hell.<p>I left Windows the moment we shifted from "developers, developers, developers, developers" to "advertisers, advertisers, advertisers, advertisers" and never looked back.<p>Ubuntu is very pleasant to work with, nowadays.
I wonder if there is a special name for this patching pattern, where not only does a piece of code depend on undocumented behavior, it's depending on the exact binary bytes.<p>See also: <a href="https://www.hyrumslaw.com/" rel="nofollow">https://www.hyrumslaw.com/</a>
Frankly, it is really annoying when developers working at one of the large closed-source platform oligopolists blame their users for trying to work around the deficiencies (or even outright hostile "business model" optimizations) in their software by whatever scant means are left to them: maybe if Microsoft didn't keep removing good functionality and stopped forcing bad "features" on everyone, fewer people would see a need to install and use these extensions that are being scapegoated here for the lack of satisfaction in Windows updates.<p>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).<p>To quote one of the comments:<p>> 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.
There is an interview with Raymond Chen where he is trying to defend the
reason why they crippled the taskbar with Windows 11 [1].<p>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.<p>He deserves every headache he gets with these support requests.<p>Or to quote this comment of the linked article:<p>> 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.<p>[1]: <a href="https://www.youtube.com/watch?v=HDicLHBvQQM" rel="nofollow">https://www.youtube.com/watch?v=HDicLHBvQQM</a>
Maybe large swaths of users wouldn't download enhancement suites if you actually listened to them? It took like 3 years to support the basic feature to "never group tabs" in the Taskbar -- that's been supported by previous versions of windows for decades. That's why I downloaded patches.