win32

The culprit for Firefox 89+ font issue has been found: something in ntoskrnl that has yet to be identified (although it should be not be difficult, as it was a bug fixed between Windows 7 RC and RTM). A few other extended kernel users helped identify the source of the bug by running Firefox 89 on Windows 7 builds 7100 to 7600. 7100 to 7264 (the RC) have this issue as well, then RTM runs it fine. We are blessed by the stability of Windows 7 beta builds as they have helped us identify various issues (6519 as lacking the "drift" issue) without letting the builds' inherent idiosyncrasies and shortcomings get in the way. Imagine if we had to work with Whistler or Longhorn builds? VMware Workstation 16 will take longer due to a lack of functions for the VMX driver, although later versions of 11 and 12 should run with the GetVersionEx spoofer.

Yes, and fcwin2k (for specific applications). However, they don't manipulate the GetVersionEx* functions and just manipulate some registry values instead. This was good enough at the time, but isn't 100% effective like my method. And the registry value that win2k used to grab version numbers has been deprecated as of Vista.

Work continues on the Vista extended kernel. With the next release, you will be able to spoof version numbers on-demand, for either a specific application or the entire system. The values will be set in osver.ini in the Windows folder. Because I had difficulty accessing high-performance, Vista-compatible hardware for the past few months, I was initially forced to test it on NT4.

Yes. Just install the same required updates.

I have yet to find a way, as 2019's x64 installer crashes early on (for now). And implementation of 32 bit functions for the x86 installers is forthcoming. There were no formal bundled updates until November, as things were just added in at will. So it will be impossible to do so for that period. Too busy for November to May. But now that the structure of the project is evolving, there should be one for the next release, likely in August or September.

It does, as the Eclipse 2020-12 IDE does call win7 functions through its JRE. I believe it's using JRE 14 or 15. Worked perfect.

The Extended Kernel project is still active, but the amount of time I have to work on it has dropped to new lows for various reasons. In fact, I was investigating the Firefox 89 font rendering breakage, and was planning on upgrading win32k to fix it (and upgrading win32k will help with gdi32 and DX components; plus, something in win32k bugchecks me when I close Waterfox G3 sometimes). But I am only near real Vista hardware for 2 out of every 14 days through late August. One side note: I have finally found something that surpasses Vista in performance on my HP Z600 workstation, while being from its lineage. 21996.1's averaged benchmarked results (in Cinebench R11.5) are slightly better than 2008 with 2019-04 updates and extended kernel, and perceived performance is identical or even better than Vista, which in turn is better than 7/1809. So some efforts may be redirected to that from Vista.

I believe that VMware's drivers (like vmx86.sys) are missing functions at the moment, and some Windows 8 functions will be needed as well. There is also a version block that prevents VMs from launching starting with 11.0.23 and 12.0.1 that will also have to be defeated. I hope to accomplish this in a few months. It will be very ironic to have VMware 16 working on Vista hosts, considering that its guest additions don't support it!

Some applications started demanding the SHA-2 rollup update KB4474419, which is obviously already installed, so that will become the minimum soon. Though there are currently two sets of ntoskrnl/winload; one works with April 2017 updates (soon to be discontinued), and the other only works with the (SHA-2) March 2019 update. They will not work with anything else.

Yes. I tried debugging it, but I'm not sure if it's connected to directwrite, mediafoundation, or the non-presence of kernelbase.dll (which isn't needed by Vista, and is simply part of kernel32 broken out into a new file). Very hard with multi-process applications.

Yes it would, though if you have the SHA-2 update, I would assume that it would have cached a 6003.20xxx HAL (which would be acceptable as I haven't released a HAL mod) instead of a 6002.18005 one.

There are only two acceptable update levels, and two separate filesets for each; April 2017 (which is the standard for the update distribution), or March 2019 (which needs different variants of ntoskrnl and winload (exe/efi) that are not currently incorporated into the installer, though they will be with the next version); the latter is the SHA-2 update point. This was done to placate some applications that reportedly requested the presence of the SHA-2 update.

They shouldn't have messed with the boot options, though they may have overwritten ci.dll and especially ntoskrnl.exe, which is now quite important.

What is your update level? The addition of a custom ntoskrnl has/will make the flexibility of updating considerably lower than in the past, which means you will only be able to use the updates that correspond to the ntoskrnl/winload that I've made. So right now it's just April 2017 or March 2019, and soon it will be just March 2019.

I recently started a separate site with more details on the extended kernel. You can find it by searching "eclipse" and the TLD for Christmas Island. But yes, I am trying more invasive methods of version spoofing, which have worked for the .NET Core 5.0 installer, but make Steam think it's offline, while Office has yet to be tested.

That would be odd, as those updates are perfectly applicable to Vista. The only problem I could see is that the updates may be the wrong architecture (ia64 or x86). My installs use media with slipstreams built by DISM++, which means that I don't get an update list on new installs made with them, which means I have no particular idea.

To get the best extended kernel experience, install from vistakernsetup_02262021.7z. It's a 7-zip archive that contains the extended kernel installer and the newest files. Widevine DRM components are not working for unspecified reasons. They worked back in July, though I think that it may have something to do with the extensions not recognizing locales. ntoskrnl changes the NT version in the registry back at every boot. I patched it once, but it did nothing to prevent version blocking, so I left it alone.

Yes. EnumDisplayDevicesW seems faintly familiar, but it returns completely different info so it's likely not a suitable replacement. And more proof of crummy MS documentation. It lies to users about the function being in Vista! https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-displayconfiggetdeviceinfo

Did you try running it in DX9 or DX11 mode?

Unsure. I had this happen before on an older install, but never found the cause. What version of Chromium is it? You may want to launch it with the parameter --no-sandbox.

New patched versions of winload.exe/efi were introduced to bypass code integrity checks. The installer also automatically sets bcdedit /set {current} nointegritychecks yes for them to work. To bypass all protections on ntdll.dll and win32k.sys, ci.dll was patched. ntext is now deprecated and the RtlQueryPerformanceCounter function is now in ntdll, so Firefox executables no longer need to be modified.

The MEGA folder has a new winload.exe, winload.efi and ntoskrnl.exe that must be used with 2018 or later updates. Because of the new incompatibilities, the target will be moved from April 2017 to March 2019 (SHA-2 code signing update).

First error indicates that ci.dll didn't get updated; second indicates that something happened to winload that shouldn't have (that error can appear if the header checksum isn't set properly, though i did do that). nointegritychecks attribute must be set to yes in the bcd store for the Vista boot volume. Then, in that case then update level is important. As for Edge, it appears you obtained an x86 version. The x64 version does not work presently due to increased reliance on newer security/crypto APIs.

Please disregard what I said about updates, I thought you were referring to BSODs by "death screen". Are you running x86 or x64 Firefox?

Those with newer updates can use the new extended kernel with the ntoskrnl that has been uploaded to the folder. The vanilla ntoskrnl can still be used for now, since the patched code integrity module still does the heavy lifting for unblocking ntdll modding.