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.
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.
Biology sometimes "jumps into the middle of instructions" when decoding DNA/RNA. The "instruction" length is always 3 nucleotides and the sequence usually has only one valid "entry point".
There are exceptions though. Some sequences do encode biologically useful information with sequences which not only overlap but do so with the starting points differing by a number not divisible by 3: https://en.wikipedia.org/wiki/Reading_frame#Multiple_reading...
You'd almost hope there was some younger more code-centric version of Douglas Hofstadter, figuring out how to write palindromic or multi-framed assembler that was semantically equivalent to, for example, his "Crab Canon".
Rather than "jumping into the middle of an instruction" (which to me implies some crazy trickery where both the original instruction and the middle of it do something useful, like the sibling comment about biology), a more straightforward way of looking at it is that the "jumped-into" instruction is actually a single-byte jump which skips over the one or two following bytes - and those shouldn't be considered to be part of the instruction at all.
The opcode will of course perform whatever function it was normally intended for, but it will have been chosen by the programmer to be something that doesn't affect the state of the program in a meaningful way. So it really is just a shorter form of jump, not something beyond the understanding of mere humans - you could always replace it with a regular jump and get the same semantics.
CPUs at the time didn't have branch prediction. The 8086 did prefetch code, but always linearly, and even an unconditional jump would flush that prefetch queue. So having an instruction like "CMP AX,xxxx" (where xxxx=any 16 bit immediate value) would be both shorter and faster than the "proper" jump instruction, while affecting only the flag register.
And on the 8080, there was no short (8 bit relative) jump instruction, so this kind of trick even saved two bytes instead of just one.
> Rather than "jumping into the middle of an instruction" (which to me implies some crazy trickery where both the original instruction and the middle of it do something useful, like the sibling comment about biology)
Doesn't "jumping into the middle of the instruction" just mean that decoding from the middle is another instruction, then when decoding from the start of it?
Almost any random bytes can be decoded as some instruction - most of them are not useful. The essence of this jump-forward-by-one-or-two-bytes trick is that it performs an operation which doesn't have an effect on the program, so it can be considered to be a single-byte jump opcode, and its "immediate operand" as a separate instruction which is simply skipped over.
You could define assembler macros named something like "SKIP1" and "SKIP2" that emit these opcode bytes (3Ch / 3Dh), and use them just like a jump, provided that you don't care about the flags.
My point was that this is easier to reason about than the more general case where (working) code jumps into the middle of an instruction that already does something else - that either takes extreme cleverness, or evolution over millions of years.
> 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 ;)
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.
A relevant quote about the lenghts they went to to assure stuff not getting broken:
"Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95."
A huge difference between 1995 and today is in 1995 "simcity.exe" might represent fewer than a half dozen artifacts because patches and updates were rare. An exception covering a handful of cases is maintainable and testable.
Today patches are near constant so a "simcity.exe" might represent hundreds of different versions of the code. It's much harder to maintain exceptions since the list of cases is much larger. Even if your test harness is embarrassingly parallel your results are only as accurate as the latest version available to test.
None of that is impossible but there's additional non-zero costs involved in maintaining compatibility exceptions. At some point they tip over to not being worth the investment.
"New version 1.7 of DOS32AWE released, the download link is in the first message. Finally Sim City 2000 is supposed to be working flawlessly. The bug is in the game which sometimes overwrites unallocated RAM . A spare buffer is dedicated now which handles such buggy behavior. Could be useful in other games too."
That's a lot of money and time to spend on supporting someone else's bug-riddled software. You can't test literally all software that exists before you release a security patch. Just imagine testing every single solitary Windows application that exists, or has every existed, just to see if one of them crashes due to intentionally doing the wrong thing. What are they supposed to do, fix the 3rd party software? Delay fixing the security hole?
Testing is the responsibility of the 3rd party (in addition to using supported methods). If the 3rd party was part of a preview release program, they could test changes before they are officially released.
That's a lot of money and time to spend on supporting someone else's bug-riddled software.
Consider that it's money and time that MS spent to get into their position today. They built their empire on "back-compat is king", and betraying that principle gives far less reason for their customers to continue using their software instead of moving to alternatives.
Microsoft cares about backwards compatibility and does a good job at it IMO, especially compared to their competitors. The thing that broke was not a public API, but an internal, undocumented, unexported function in Explorer. Microsoft did patch API abuse in the past for prominent software, but they can't be expected to do it forever and for all software.
> Microsoft cares about backwards compatibility and does a good job at it
Indeed. This is one of the few points that I give high marks to Microsoft for, and when it comes to Windows, is the only thing that makes me feel sympathy for Microsoft devs.
Pulling off the level of backward compatibility that Windows has maintained for so long is an incredible accomplishment.
I'm not sure if you're holding up the XP list as being better than the list today, but I bet even the list at that time did not include every random shell extension imaginable.
At the time, there weren’t that many “random shell extensions”. Many of the more common ones were almost certainly there if needed.
My point was you didn’t need to be a “prominent” developer for Microsoft to patch up your app at runtime. This was particularly important for XP, given that it was the big, strategic consumer swap to the NT kernel and had to go smoothly.
> That's a lot of money and time to spend on supporting someone else's bug-riddled software. You can't test literally all software that exists before you release a security patch.
Microsoft has been pushing telemetry for how long? I would think they would have a good idea of what to test so that p99 their software works for their customers.
But it depends on the severity of the security issue fixed. If it's a big deal, you push it and let telemetry dictate your future hotfixes. If it's not a big deal, you do your internal testing, then push it through external testing, and see what telemetry picks up (hey!)
> Just imagine testing every single solitary Windows application that exists, or has every existed, just to see if one of them crashes due to intentionally doing the wrong thing. What are they supposed to do, fix the 3rd party software? Delay fixing the security hole?
Microsoft made its business on "where do you want to go today?" Not "you're holding it wrong"
If windows and the 3rd party software worked before a windows update and doesn't after the windows update, that's Microsoft's problem because it reduces acceptance of updates. One way forward is to fingerprint the broken application and not do the update if it's active, another way is to prevent it from running after the update. Either of those allow unaffected users to get the update and get on with their life. Once the application is identified, Microsoft can work with them to update their software to do things right, and then figure out how to get users updated.
I've been a user of desktops where the OS developer clearly doesn't care about continuity for users, and Windows feels more and more like that. It's not pleasant, and if I can't be assured what works today will work tomorrow, that leads to delaying updates which is bad for business.
This can come up even with application software (which is my area). If it worked before and it's broken now, or if your application appears to be the only thing that is broken for the user, from most user perspectives, it doesn't matter that the problem may have been technically created by an OS bug, errant virus scanner, or whatever. As I tell colleagues, "It may not be our fault, but it's still our problem."
Correct. Customers are paying for a working solution. If what they get doesn't work, they couldn't care less (and shouldn't have to care) about who or what is to blame. They just want it to work.
> If windows and the 3rd party software worked before a windows update and doesn't after the windows update, that's Microsoft's problem because it reduces acceptance of updates.
This is the critical key to the whole thing. Currently, I basically apply updates as soon as they're available (with a bit of delay for major ones like new macOS version updates) but if I get burned a few times I'll go back to waiting carefully.
> the Microsoft of now obviously knows of the existence of these shell enhancements, but clearly doesn’t test patches against them at all
Microsoft taking into account this method of modding explorer in its testing would be like asking Apple's design team to take into account the one in a million iPhone user who sticks their phone up their butt. [0] I don't know what it says about Windows or its users that there must be more than one in a million people running this stuff, but still.
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.
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.
Oh geez these are annoying! I've spent hours trying to find a setting to disable the flashing taskbar on the Teams client on my corporate issued Win10 laptop. The best I've found is to keep the Teams client minimized in tray just to avoid this behavior.
It boggles my mind there's no way to disable this feature that is so distracting it almost makes working impossible whenever I forget to kill the Teams client window. And really goes to show why people need to resort to these hacks.
I've literally spent over 30 minutes on a support call with someone who had accidentally moved and resized their taskbar.
All I could get out of the user was "half the screen is grey".
I quickly figured out it was probably the taskbar, and I tried asking if it was the top or bottom half, or left or right. "Half" was the reply...
After a lot of attempts and little progress, I made a breakthrough by asking in which corner the clock was. "Bottom left", aha! And with that I managed to guide the user to dragging the taskbar back and resizing it properly.
Granted this was back in Windows 98 where the taskbar wasn't locked, so was rather easy to do, it was probably their first PC and they were non-native so language barrier.
Wallpapers can be animated? This is like learning my car can count butterflies. I wonder why such a feature exists but also now feel obligated to hook VLC into the wallpaper function so i can play movies underneath all my other work. Can wallpapers have sound?
Now, browsers have themes and wallpapers, so it's customisation all the way down.
This winter, Edge introduced interactive wallpapers. There were little buttons you could press to put a layer of frost on everything, or make snow fall. I couldn't make enough snow fall to obliterate the clickbait MSNBC headlines.
That is the same animation, but it is also triggered if you have chosen a different wallpaper per virtual desktop. It animates the background change when switching desktops, and the animation feels like it lasts around 500ms. I wouldn't mind a quick animation but the default is too slow.
> I know it must be frustrating from Microsoft's standpoint
no sympathy. Chen seems a little irritated (as he should be) at the situation, but he's still missing (or purposely not stating) the real point. the correct response is alluded to by a couple folks in the comments section. i'll be more explicit:
- if microsoft was paying attention, it would simply add the functionality these 3rd party hacky extensions were adding, obviating the need for that extension at all. Like adding a setting for the flashing taskbar buttons you mentioned.
- failing that, simply allow some of those "internal" functions as a public extension points
the fact that a market for such egregious hacks implies significant demand for something.
gad, explorer and windows UI is such a dumpster fire. you don't even need to do any kind of fancy market research, just look at what the most popular extensions are doing to patch over deficiencies and them fix them!
That is the weird part. My explorer.exe patch to disable flashing taskbar buttons was functioning with Microsoft Defender turned on for the whole lifetime of Windows 10 I used it. I didn't even need a UAC prompt to patch the memory. Nothing detects it, even though it goes and adds assembly instructions to three locations in the memory with WriteProcessMemory etc. It's not working by injecting DLL, it just modifies the running explorer.exe process memory so it will not modify files.
I guess the C version was flagged by defender eventually? Seems to happen at some point with unsigned programs that aren't super popular these days. Using VB6 seems to be a safe bet to end up in defender quarantine. I guess because it was still used for malware a decade ago.
DEP does nothing to prevent OpenProcess() and WriteProcessMemory() from working or prevent applications from loading a dll which reaches into the main process's image to patch it. DEP tries to prevent exploitation from taking place within a single process by ensuring say, a buffer overflow can't just call the value you loaded into your webpage, not running software tampering with the memory of other running software using APIs which allow for the purpose.
Even if the page is marked as non-writable, execute only, you can pause the process, change the permissions and resume it or do it at image load time without issue.
Windows applications using the old/standard win32 api don't have sandboxing between them at all and any application is free to tamper with any other to an almost limitless extent. It's incredibly powerful, in both good and bad ways.
Certain advanced firewall tools with IDS style features can hook these calls and notify you when an application is attempting to do something like this.
Most troubleshooting involves defeating virus checking and opening up the firewall. It's right up there with clearing your cookies and restarting the machine. It's in all the scripts. Totally routine. Nothing to worry about.
So these patchers are monkey patching a system executable needed to have a bootable/usable system?
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.
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.
Is it just me? His posts always begin with an interesting technical anecdote and then veer off into boring propaganda with sullies the reputability. It's an intellectual let-down.
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.
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.
A reply from the article author sort of communicates why they don’t work with the patcher:
> They don’t use the shell extension mechanism to get into the process. They sneak in by nefarious means. Patching is not supported. There is no “correct” way of doing it. Just different levels of bad.
I assume the “nefarious” ways are similar to rootkits in that they exploit vulnerabilities to gain system access they’re not intended to have.
It’s also only really the reason they don’t care that the patcher breaks. The reason I assume they don’t add or retain these features is maintenance and support cost.
No, the "nefarious" means they are simply using APIs like WriteProcessMemory/ VirtualProtectEx/CreateRemoteThreadEx to modify the memory of runing programs or use SetWindowsHookEx to install global hooks (which inject your dll into every process for the non low-level events)
Sure, but if you use/build a tool that modifies how Windows runs by trawling through and manipulating internal process memory that explicitly is not meant to be modified by anything else, that's on you.
It's like asking why Nintendo won't support the NES you desoldered the CPU from and replaced with a higher clock capable CMOS 6502 and new crystal
"Nintendo is such a bad company, I upgraded my NES and now it can't play anything"
Yeah. It's not fair to judge Microsoft for people abusing the API, but that's a different question from whether or not they should lock it out. That would be a big freedom reduction, and even though I'm sure it would make life slightly easier for for some parts of Microsoft, I'm pretty sure it wouldn't be for the best.
Going to the game console example, blaming Nintendo for the botched upgrade is dumb, but what if Nintendo puts security keys in every component to prevent repair? Yeah, it's fair and good that they foiled the 3 modders who bricked their devices and tried to claim warranty, but they also sent 3 million extra devices to the dump that otherwise could have been fixed by enterprising teenagers with soldering irons. It would be 100% fair to blame them for that.
In the open source world, I think the equivalent here would be to export an internal function in the desktop environment so you can call it with a third party extension. Open source might help you choose the function, but that's not a ton of help if the project owner rejects your pull request because it doesn't mesh with their worldview.
The “correct” way to do this would be to check that the surroundings of the code you’re injecting into are as expected, similar to how applying a diff patch file contains lines before/after to synchronize with the text being patched. When confronted with an incompatible change, the extension would just disable itself and not proceed with the patching. I’ve heard of MS Office extensions that function like that and work robustly.
One of the comments on the post mentions an Explorer extension that makes the effort as well.
IMO if you're doing something that far into "don a rubber glove and root around inside somebody else's rectum" territory then the responsibility rests with the author of the crazy, not the authors of the program being fettled.
(and I'd note that I have written code that was very definitely in that territory, held myself to that standard, and having planned to do so from the start didn't find it overly onerous ... I do have a certain sympathy for people who didn't, though)
Well yeah, I mean no one forces you to use Explorer for file management under Windows. I'm an old-time Norton Commander user, and when Windows came around I switched to Total Commander. There are open-source alternatives too, even cross-platform ones, like this one: https://doublecmd.sourceforge.io/.
That being said, no one forces you to use Windows either - except maybe your employer or the software you are using, but this is getting less and less of a problem fortunately (web apps, Proton etc.).
This isn't really about using Explorer for file management. It is about using Explorer as the shell. That's the default setup for everybody. Changing the default steel is difficult and some programs may not be compatible with whatever alternative shell you switch to.
Most people don't want to learn a whole new shell. They just want the Explorer shell to have the features that it has had since Windows 7. Features that Microsoft inexplicably chose to remove in Windows 11 and that they are only now belatedly adding back.
I disagree strongly. If you start mucking around in the memory of the system, and shit breaks, it's on you and not Microsoft. The amount of effort they put into compatibility is Herculean, and honestly is way above and beyond what is reasonable to expect. It's not their fault that they can't handle every single edge case of programmers going rogue and stomping all over the rest of the system.
When most of this code was written, sandboxes didn't exist. Existing security concepts were built around protecting users from hacking each other on a shared multi-user system. Of course a user is allowed to patch their own processes, how else are they going to debug them and why should we stop them from doing so?
You must do BJJ, to be able to twist yourself into such knots to blame Microsoft for a 3rd party vendor's unsupported buggy hacks. No mention of how the 3rd party vendor lies by omission to the users by not telling them that their software is very literally using unsupported, buggy means to accomplish its goals. Leaving the user to blame Microsoft for the crash, when if the user knew the truth, they may feel differently, and maybe not even use the 3rd party software. But it feels better to blame the big bad corporation, despite the fact that they have not lied, and are just trying to fix security issues.
There is an interview with Raymond Chen where he is trying to defend the
reason why they crippled the taskbar with Windows 11 [1].
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.
Unfortunately it's the designers that are screwing up the UI/UX of Windows, not the programmers. If you give more time to the designers then you're just going to get more of a clone of OSX rather than something useful.
The OSX dock has almost always supported vertical orientations, nearly as long as the Windows taskbar used to. If they are trying to clone OSX they are doing a miserable job at it in their choices of features to cut.
I don’t use windows often, but I was using it to check some hardware the other day and had to dig through nests of settings to get back to back to what was more or less the display settings screen from the Windows 9x/NT era, albeit with a less efficient layout and lots of superfluous white space.
Unfortunately, macOS has gone this direction as well and it’s settings have become inscrutable. Simple things like using drag and drop to reorder network interface priorities are luxuries of the past. It seems like those designing have never used them and never plan to.
Watching the clip, the improvements he's talking about are great and very welcomed. Is this a case of any change being considered bad because you're used to how things are?
Only supporting grouped taskbar icons is a big inconvenience when actually trying to do work. Instead of clicking directly on the taskbar item which corresponds to the window you want to access it requires that you hover over the icon, then try to pick out the window you want from a very small thumbnail of it. This just adds extra time and unnecessary thought into this process. It's also quite bizarre given that wide monitors are more normal these days with plenty of space to have a long taskbar with many items on it, but instead you only get some short icons in the centre.
This may have been fixed in recent versions where they finally added the ability to change the taskbar grouping in the settings, but I haven't felt the need to test it.
Also the new start menu is a pain in the ass as the quick launch area is just an alphabetic list of applications and/or documents with no ability to group them in any other way. In Windows 10 you can group related applications together and have quick access to "secondary" applications that you might want to use. (I pin "primary" applications to the taskbar and pretty much always have them running anyway). To get to all applications there's another click where as in Windows 10 you just start scrolling as they're just there (maybe that's an option I enabled but it works well).
Those are the two general gripes I have with the new taskbar and start menu in Windows 11. Maybe I'm used to my setup in Windows 10 but I didn't see anything wrong with the way things were from a design perspective. So the change seems kind of arbitrary just to make it look more like OSX rather than from any functional perspective.
One point that I think more technical folks should consider is if we are actively harming our desires to have a functional UI design by disabling telemetry. As that tells the people at Microsoft what features people actually use, and if they only get telemetry from non-power users then they're going to prioritise for them and remove "unused" features that us technical folks use all the time.
>This may have been fixed in recent versions where they finally added the ability to change the taskbar grouping in the settings, but I haven't felt the need to test it.
THANK YOU. I never heard about this, I had completely given up on using the taskbar for anything except the system tray.
I agree to the rest of your points -- I only use the start menu to search for stuff now. The pinned icons take up way too much space and even though I spent some time carefully curating them I never seem to want to use them.
You didn't mention the system tray, but I want to add that the redesign also made it worse than in Win10. The volume, battery, wifi, etc icons are joined into one button but actually if you right click they are three different buttons still. This is awful design, the fact that you have different options depending on where you right click is not communicated at all.
This isn't about "change", they just removed some essential
functionality that I use daily since 1995.
Besides from being used to it, it is also required for my work to have
wide, labeled, ungrouped application buttons instead of icons that are
oftentimes barely distinguishable.
I wouldn't say it worked "fine" for 25 years. It's still there all the time taking screen space. You can hide it but it will re-appear if you move your mouse to the now cleared screen real estate.
The reason I need taskbar hacks is that I want one feature they never added: hide the taskbar permanently until I explicitly ask to see it (for example by pressing a Windows Key). For me it doesn't matter much if the taskbar is horizontal, vertical or goes through the screen diagonally. Just let me hide it and keep it hidden. I am ok with full screen taskbar as long as it only appears when I ask it to. I see not adding this obvious feature as manifestation of "you will have it our way and you will like it" attitude of Windows UI team (or whoever is responsible for it).
It isn't 100% reliable but it's good enough for me. Now I hope to find something that prevents Windows 11 from dimming my screen when on battery after a few seconds of inactivity. Pretty please?
> I see not adding this obvious feature as manifestation of "you will have it our way and you will like it" a
Their corporate customers demand that your multi-use computer be turned into a nearly-dumb appliance with no configurability. It sucks for you, but you'll just have to suffer for the "greater good". Power users are not just an endangered species, but rather a dangerous enemy to be wiped out through any means necessary. They hate you, and you either need to be subjugated or forced to use an abacus.
You get a tool tip when hovering the mouse over the progress bar. But
now I see the chapters are also listed in the video description, which I
should have linked to in the first place:
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.
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.