It'll be interesting to see what happens next and whether Microsoft will put effort into closing this loophole. If so I think it reinforces the idea that this hardware check is an attempt to force upgrades to Windows 10, not just a "we're choosing not to support this platform" decision.
Actual technical content on github, which is linked from the article, but perhaps should be the main link?
The article does at least do some digging vis-a-vis the history of Zeffy's work and how it came to reach the state that it's in currently, so some credit is due to computerworld.
It's both actually, MS is currently supporting approximately 7 OS flavors of windows as best I can tell, 5 of which are Windows 10 alone (7 SP1, 8.1, 10 RS1, 10 RS2, 10 CBB, 10 LTSB, 10 RS3). That's a lot of OS's to deal with and be ensuring that 'It just works'. If anything I would say this is a commentary on AMD and Intel's ability to make compatible processors than just on MS' ability to support. Unfortunately new processors have Errata and can be buggy pieces of garbage as Ryzen just showed with a bug in its FMA3 implementation that would cause a GP fault. MS has to test and handle these issues for every single supported CPU. To do this they have massive labs of machines with common CPU/Mobo combos that they deploy and run tests on with every single patch and build. Not surprisingly this isn't cheap and if you have to support effectively 7 different OSes you're going to make some cost decisions. I suspect this really was a decision to focus lab hardware and development time on the latest OS versions that can more easily share the errata patches than anything nefarious.
If I was running ubuntu on the release date of windows 7, it would have run out of service in 2013. Windows 7 still gets updates, you just can't install it on a new machine.
No version of Linux released in 2009 is still (a) supported, or (b) supports Kaby Lake.
Windows 7 was end of life'd in January of 2015. I don't think this is some kind of evil business decision Microsoft made. Switching to Linux isn't a magical way to ensure your OS version will be supported for the rest of eternity. Linux is great for many things, but give the Microsoft/Windows is evil thing a rest.
Let's put something into perspective. Linux is 25 years old. If Linux hasn't supplanted Windows on the desktop by now, then there is no indication it ever will.
And don't get me wrong, I think Linux is a fine OS and use it daily (lately more often than Windows). But "replace Windows" is not a static target, and the organizations in charge of promoting Linux as a desktop OS have nothing now or in the works that can compete with the corporate Juggernaut of Microsoft.
Selling software is hard, especially on Linux. We tell people FOSS means free as in freedom, but the vast majority of even people who parrot that line thinks it means free as in beer. As a software vendor, you'd be killing yourself to ignore 90% of the market.
But there's no COM on Linux. How can I magically port my software across if I do not have access to all the wonders of COM, eg. MS XML and have to rewrite my software from scratch?
At least with Microsoft you have support for APIs for a long long time; eg. MFC is old but it is still supported.
With Linux you are on your own.
So "get your software on Linux" is easy to say but in the real world it isn't so easy.
> Operating systems are hard, drop Windows and sell your software on Linux. We all know it's inevitable in the long run.
Soo... how do I run Linux on a new Dell XPS or a Surface Book without updating kernel to newest 4.x branch? Because last I check Linux forced me to update to new version (including userspace since new kernels weren't compatible with old userspace) to run on new hardware as well.
Nonsense. It's perfectly plain that the message passing micro kernel architecture and superior userland design of HURD will lead to it's inevitable supremacy.
I don't think anyone believed it was anything but a business decision so this is not really shocking.
Operating systems are hard, drop Windows and sell your software on Linux. We all know it's inevitable in the long run.
I doubt it, this isn't exactly revolutionary. All he did was modify a dll to return a 1 for the "is_os_supported" function instead of what it used to it.
The question is: why would you want put yourself through that level of hell? I don't mean working for Microsoft, that would be pretty amazing! What I mean is, why would anyone want to become a specialist in Windows Update and winsxs technologies?
Seriously, it's kludge after kludge. Windows 7 uses the WSUS protocol (which is a hairball set of web services) to figure out which updates it needs to apply - of which it does through recursively querying what base packages are on the system and goes some way to explain the incredibly slow updates people see... but it gets its latest package list and after Microsoft realised they had so many security patches they were releasing they discovered their CAB file format needed to be rearchitected as it could hold enough files... hence WSUSCAN2.CAB now must be downloaded along with something like a third or fourth attempt at getting the windows agent written correctly.
But it gets worse, because somehow it must check what it has downloaded in a gigantic (over 1GB) opaque ESE edb file, which it synchronised with the sift are distribution cache in the Windows directory. Here it looks up the Componebt Based Services registry, along with a CONPONENTS hive that only the Windows Update service loads and you generally can't see when you open Regedit. Except that there is a set of keys in the HKLM\Software\Microsoft\CurrentControlSet\Conponebt Based Services - consisting of an ApplicabilityCache, a list of packages, a package index, a set of package detection keys, and a set of componebt detection keys.
Once you begin to decipher a current and applicable state, you must work out how it relates to the package index list in the registry, which in turn somehow related to the packages keys, which have their own interesting binary keys that Microsoft set...
So once you've worked that out then you need to decipher the manifest files in the Windows Sude by Side system. These are signed with CAT files, abdysuslly have Microsoft Update files that go along with actually payload files. Somehow these relate to a set of session XML files, which are meant to help you troubleshoot when things go wrong and package states go awry. Except the XML format isntvfocumebted except in a few tantalising blogs which aren't in any way complete and some of which seem to becMicrosidt developers reverse engineering the file format themselves...
WinSxS itself holds every files ever installed by Windows Uodate in the %systemroot%\winsxs folder, which is a bunch of folders with NTFS hardkinks back to the C:\Windows\system32 files. Microsoft originally wanted to see the state of an installation so they made the decision that when the kinks to newer files were updated they would keep The of files around so they could know the system state and presumably try to allow rolling forwards and backwards o a snapshot of time - they reasoned this was ok because they released the dism.exe took to remove of hitfixee and updates from previous service packs. Unfortunately that switch never got used because the DISM got released in Windows 7 SP1 and sonebody in Mucrosodt decided to go with rolling updates, and no more service packs. Consequently there are often 8 or 9 GBof unneeded and unused files in most Windows 7 systems (depending on the age and how frequently updated the system has been maintained)... and evidently someone st Microsofy realised this because about 4 or 5 months ago they released an update for, or all things, the Windows Disk Cleanup Woizard to remove these old packages. You must run it, then reboot and depending on the amount if packages it removes has been known to have edb ysers stuck in "100% of updates have been installed" for 15 to 45 minutes whilst it cranks through the cleanup process. Of course most end users think there PC has crashed and Windows is "stuck" so they reboot it half way through, to varying results.
There are three different tools to check corruption - the sfc utility, the dism utility and a variety of Windows diagnostics that old you can download and that are a bunch of Powershell of VBscriot scripts that attempt to slowly fix the plethora of issues that can prevent Microsoft Update from working.
No, kernel reversing engineering is fun, but poking around Windows Update is not. I wouldn't recommend getting hired to untangle it...
When Mark Russinovich did something like this, he got a job offer from Microsoft. Maybe Zeffy has a future on the Windows team?