win32

I am working on patching a newer version of winload.exe/efi and seeing if that will work better. But for now, yes, either the previous extended kernel version, or the latest extended kernel version with updates from 2017 or 18.

ntext is deprecated in favour of ntdll, so no modification of executables is necessary to run Firefox/Waterfox. This required patched versions of winload, ntoskrnl, and ci.dll. This makes Vista as a whole easier to modify, but also reduces forward compatibility of the extended kernel (for now).

It appears that the modified winloads and ntoskrnl are not happy with newer versions of the HAL/win32k/etc. The modifications are relatively minor, so it wouldn't be difficult to rebase off newer versions of such, though I am quite concerned about the performance hit associated with newer Windows binaries since late 2017.

I am unable to replicate any complications caused by sfc /scannow. I ran it then rebooted as prompted. Extended kernel files were replaced with the previous MS files. Then I installed the extended kernel and rebooted. The extended kernel files were present again and no issues were present.

Not even one reboot after running sfc does the installer work?

This "Universal Theme Patcher" is what I used: https://cdn.discordapp.com/attachments/447531495062503456/556252683569332246/UniversalThemePatcher_20090409.zip

That probably happens because you ran the installer more than once in an OS session. The in-use system files are renamed while the new ones are copied to their old positions. Before rebooting, the renamed files are the ones that remain in use, so they are untouchable. You do have April 2017 updates, right?

Yes, my custom uxtheme is patchable. Indeed I believe that the one I've included has been patched.

The original installer script did not take into account those with usernames containing spaces. I have since adjusted it to work with such usernames.

I'm not sure about it, as it seems that .NET is a bit of a black hole as far as Vista is concerned. Versions 4.6.2 and above have some antipathy to Vista in some way, and I have trouble figuring it out.

No, unless MS recognizes the extended kernel files as "legitimate" and grants us the use of their authenticode signatures to sign them.

I haven't figured out how to get the Steam browser to work yet, though Chrome x64 and Firefox x64 should work easily if extracted from the installers (for the latter anyway) or downloaded as portables. Not sure about Adware...

The DLL is signed only as SHA-2, but I don't believe that is the reason as Vista doesn't normally block execution of user-mode code with "invalid" signatures, and the other runtime DLLs packaged with PM are cut from the same cloth and work normally.

Delete api-ms-win-core-memory-l1-1-0.dll from the Pale Moon folder and then it will run, falling back to Vista-compatible binaries in system32 installed by the VC++ 2015-19 runtime. This is the second program broken by Windows 10-derived runtime libraries (Code::Blocks was the first). Though in this case, there are no missing functions, but apparently that DLL delay-loads some functions that are certainly valid, but have ".dll" attached to them, making them invalid.

There was an addition to the firewall API that allows newer versions of simplewall to run. But it turns out many of the other functions in the file are outdated which made it not function properly so no release for that yet. I also made modified versions of dbghelp/dbgcore which can be used for newer applications like Code::Blocks that need them in their program folders. And then there's still the issue of ntoskrnl blocking modified ntdll and win32k. I seem to have detected the functions responsible for the checks of the image hashes (which will also be good for 7, 8.x and possibly even 10) but have yet to attempt a patch as I'm still quite busy.

Device Manager indicates that he used the MPS Multiprocessor HAL, which doesn't use ACPI. I just tried that HAL on X58 (which also works fine with ACPI) and confirmed that it does kill hyperthreading, along with Enhanced Intel SpeedStep.

I see the first thing happening whenever windows are opened. Not sure why that happens since explorer is x64 and everything running under it should be. Which version of Kaspersky would that be?

No, put it in syswow64

Yes, I have noticed both bugs. The WMP one should have been fixed with the latest kernel32 x86 (or by using the x64 WMP, as Vista defaults to the x86 one). The second one is because of an IE9 rendering issue.

Indeed, the thing about 2000 getting drivers after Vista was too strange to be true. I found some Vista drivers that support 8111 series: https://drivers.softpedia.com/get/NETWORK-CARD/REALTEK/Realtek-RTL8168-8111-LAN-Driver-61913052007-for-Vista64.shtml#download

Realtek 8111E, apparently. But the sources I've seen apparently put the last Vista driver package in 2009, while they continued to make Windows 2000 drivers afterwards. I'd expect XP x64 drivers to be backward compatible on Vista: https://drivers.softpedia.com/get/NETWORK-CARD/REALTEK/Realtek-Gigabit-Ethernet-Driver-5786-for-2K-XP.shtml

I don't believe such drivers for XP exist, and my initial driver-based attempts to mod for Vista failed. I will try to see if it likes DX 11.1 binaries better than 11.0 ones, but that might take awhile to realize. For USB3, try this:

I made an experimental version of ntoskrnl that is unable to change the key, but it isn't the one that is in the folder IIRC, as I found the registry key to have little effect on the system. I thought it had more of an impact on the OS then, but now it doesn't seem that way. The idea to change the version numbers in ntoskrnl came from 2000/XP, where it is more substantial.

I started working on winload.efi again but I continue to struggle with digital signature verification. The same things that were successful to bypass protections on winload.exe are not successful on winload.efi.

steamui.dll actually needs SetThreadErrorMode so it wouldn't run. I think it would work with kernel32 forwarding to the same ntk32 that is part of the wow64 extended kernel, but i haven't been able to test.