win32

I saw that coming... While I do respect Pale Moon and its developers for maintaining possibly one of the last independent web browsers around (enough to have gifted the x64 versions of 28/likely 29 to Vista), I will also wear the Browser badge with pride. Most people use a webpage viewing application covered in Chrome, a few stragglers need an Explorer to guide them through the Internet, others live on the Edge, and some like roasted fox. But Browser is where I stand. It's just like the "no name" grocery brand, which does quite well here in Canada.

oh, it could be something like this: Maybe it picks up on the OS version and then refuses to load if it sees the wrong one. First it was Qt 5.10+ (Vista), allegedly user mode components of later NVIDIA drivers (Vista), AMD drivers (Windows 8) as well as assorted miscellaneous drivers (Windows 2000). I think we really do need a way to make the OS universally identify as a later one, The way to do this for 2000 is probably quite simple, but for all x64 operating systems post-Longhorn reset (including XP x64), I'm not sure yet. or maybe they made the value little-endian? I'll look into that.

How about the status of vmx86.sys?

Is there any non-UWP/DX12 software that really cannot run on W7? The only missing win32 API function that I've seen called is user32!SetCoalescableTimer by the Office 2019 installer and it should be trivial to add. Vegas Pro 17 says in its system requirements that it needs Windows 10 but the installer says that it requires Windows 7/8. The Whatsapp desktop application says that it needs Windows 8 but runs on 7. Probably just people taking W7 EOS too seriously, even though Windows 8 as a client OS had its EOS in 2016. Mind you, it's quite difficult to trick VMware installers (unless you can get the OS to effectively become NT 6.2, which may cause web browsers to freeze). So that Workstation 11/12 method should work.

Lots of news. I managed to work around ntdll somewhat. My ntext (ntdll with a new section and updated checksum) was successfully hooked by kernel32 through forwarded functions. But programs that call ntdll directly didn't go as well. Firefox would crash or pseudo-load hogging up several CPU threads. So I think a completely new wrapper dll that forwards to ntdll is necessary. I was almost successful in getting the Windows 7 compatibility shimming framework to work (a modified aclayers.dll that fakes Windows 7 SP1 instead of RTM and acppage.dll in particular). But the latter calls registry-related functions from kernel32 instead of advapi32. So I added them to kernel32 forwarding to advapi32 but it didn't work as it would keep forgetting the compatibility options (those reg functions are slightly different on 7 than Vista but very difficult to implement). So it may be better to modify the Vista versions of the files, but it's not that clear cut to me, unless I were to replace one of the existing compatibility options (somehow I think no one really bothers with the 2003 SP1 option).

Go to the folder where your screen reader is located and make a file named nvda.exe.local (or whatever the name of the exe is). Copy the original dlls into the screen reader's folder. Only if you want to use my ntoskrnl/ntkrnlmp on a UEFI system.Though you could use that loader/driver I mentioned earlier. But if you just need to use ntdll, it won't be needed anymore.

I have resigned myself to declaring that ntdll on Vista and up is indeed off limits. I again went to XP x64 for some inspiration and installed (Vista-compatible) Blender 2.90 on it. Several functions were missing like InitializeCriticalSectionEx. That function imports RtlInitializeCriticalSectionEx from ntdll, which also was introduced in Vista. So that requires doing the near-impossible, import table expansion. Then I looked at One-Core-API. As @Ximonite pointed out, ntext helps extend ntdll. ntext is a layer between kernel32 and ntdll, and most of ntext is imports and forwards respectively from/to ntdll. No new imports unless we make our own binaries, but forwards are indeed exports from the file. The people designing the PE format certainly had some nice tricks up their sleeves! Though I was forwarding functions to ntdll from kernel32 in Windows 2000 back in June, so my memory is going I guess. So this ntext would be a copy of ntdll with new and upgraded functions. But what about programs that call ntdll directly (which is frowned upon for win32 applications as kernel32 is what they're supposed to call as an intermediary)? A patcher that changes import table references from ntdll to ntext in a particular program is needed. Preferably, I'd like to make the file that ntoskrnl loads and is integrity-checked a decoy named ntext (which would be the original ntdll), while everything else calls a modified ntdll (so no changes to import tables are necessary). But changing the reference to ntdll I found in ntoskrnl did nothing.

Here is KB4566371 for Windows NT 5.x: https://mega.nz/file/Us9GSQ6a#wDnAvUagKV05btOMEd5jBXI6_14tkmoDAcp-xyHxo1I

Technically Vista can take advantage of WDDM 1.1 features. I use driver version 320.92 x64 and DWM RAM usage remains stable even with over 25 windows open, as opposed to increasing linearly as what happens with WDDM 1.0. I found this, 38x drivers running on Vista: But how exactly? The kernel mode part has exported missing functions since 372.90.

http://web.archive.org/web/20200809134931/http://download.windowsupdate.com/msdownload/update/software/ftpk/2008/09/windowssoundschemes-x86-intl-setup2_b29dd063f9c350c45568ec24699731643ecc10e9.exe

It's just version modded, along with some other changes to prepare for the eventual modifications. sprintf_s is going to be hard to add, as it's over 5000 bytes when counting its dependent functions/subroutines, which are new to Windows 7. But RtlDowncaseUnicodeChar isn't, and it will be replicated in ntdll. What could also be done is driver-level modding where the first kernel mode driver that calls sprintf_s is compared with the last one that does not call it (for NVIDIA, that's the difference between 372.70 and 372.90 btw). Then in the newer driver, we patch around the call or try to replicate the old behaviour. And hope there are no bugchecks. BWC did something like that, but it did eventually have its caveats (ATi HD5000-7000 series apparently can't do full motion video on win2k).

We don't need to go back that far for Electron apps. Visual Studio Code 1.46 works and it's based on Chromium 78. If Discord and Steam were x64 native, they'd probably work. We need to get into ntdll (both x86 and x64) for later Chromiums to work. And now that ntoskrnl modification is starting, ntdll modification should be coming soon. And yes, based on recent comments, the current path will be maintained.

Well, it appears that MS got around to improving Haswell, though there are still some issues. I haven't been able to test it due to issues with Windows Update on my Kaby Lake though. Now I'm thinking; do I rebase the extended kernel on the September 2020 versions of files, thus abandoning the April 2017 versions? Or do I still work on LoadLibraryExW from build 6519 since that is flawless, while this one is not (mind you, the UAC permission issues may lie elsewhere).

Yes. Hoping there are no issues that may arise once the appropriate functions are added.

So none of the instability was induced by a OS version bias. Now I just need an ntoskrnl version to tie to the dumps that you have posted previously and hopefully I can look into those.

So there seems to be something wrong with my custom osloader.efi. Unfortunately there is no EFI hardware here for me to test it with, so any corrections will take awhile. Does my ntkrnlmp.exe work with the regular winload.efi and nointegritychecks = 1 (yes) in the boot entry? Though this could also be used in theory, but I need to test it: https://github.com/Mattiwatti/EfiGuard

I don't see a picture.

Delete osloader.exe and just download my osloader.efi that I just added to the extended kernel folder. Then replicate my bcdedit instructions (including the new one above).

Your Vista is UEFI? That changes everything. osloader.exe is a modified version of winload.exe which is intended only for MBR/BIOS systems, though you will be able to use the same ntkrnlmp as everyone else. So I checked out winload.efi and it's indeed very similar to the MBR version. So hopefully the patched osloader.efi works. So for UEFI users, just follow this instruction as opposed to the similar one for BIOS users: bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} path \Windows\system32\osloader.efi

Even if you make a copy of your working boot entry with the MS files (with everything unchanged), as in my second suggestion?

Yes you can, though there are some limitations. Newer Firefoxes (above 64) will have some problems with videos and the address/search bars.

You have to follow these steps to load my custom osloader.exe and ntkrnlmp.exe: In CMD, do this: bcdedit /copy {current} /d "Windows Vista Unlocked" Keep note of the GUID value you get in this form: {91274567-89ab-cdef-00ff-nca000ffffff}. Replace this with whatever value you get when you copy it. Then do these commands: bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} nointegritychecks 1 bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} path \Windows\system32\osloader.exe bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} kernel ntkrnlmp.exe

Strange. Is my osloader.exe present? If it is, try making a new entry like this: bcdedit /copy {current} /d "Windows Vista Test" ...and see if it works.

Do bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} detecthal 0 (replacing the value in the brackets with yours, of course)

Nope, there isn't. What do you get when you run bcdedit? Odd. But apply the reg key, reboot then make a folder named explorer.exe.local in X:\Windows (X being the drive letter where Windows is installed) and place the MS version of shell32.dll there.