win32

You must rename ole32x1.dll to ole32.dll. It was titled ole32x1 since that was part of my internal versioning system (shell32 is actually shell32x10, for example). But it doesn't reflect the other names in the directory so I'll change it.

But IE10? Well I think it was decoupled from the OS unlike IE4-6 so it may be possible but I see it as too much work for something that is almost obsolete. How well does it render anyway, nowadays?

Firefox 78 x64 does work, but you need to open up firefox.exe in CFF Explorer, go into the import table, select ntdll.dll and change the entry RtlQueryPerformanceCounter to NtQueryInformationProcess. I try to avoid touching ntdll as it's impossible to redirect it. Office 2013/16/19 doesn't work presently due to them using a 32bit installer and of course, the 32bit kernel isn't finished yet. But it appears that I will need SetWaitableTimerEx. And perhaps there will be more undocumented 32/64bit functions the programs themselves will need.

The inf of 451.67 for the MX110 still has sections for NT 6.2 and 6.3. Have you tried installing the inf through device manager? That inf even has entries for the RTX 2000 series under NT 6.2/6.3 even though NVIDIA only lists support for 7 and 10 on their site (only 10 for mobile GPUs).

I have decided to prioritize the x86 extended kernel over the x64 Haswell Logon Bug Fix as the latter is non-fatal, while lacking functions for x86 software is (unless you switch to a newer OS of course). Unfortunately there seems to be severe restrictions on what can be done to the x86 kernel32.dll. Unlike with the x64 one, you cannot put the export table wherever you like. And even moving the reloc and rsrc tables (plus the directory addresses) makes the PE32 image bad. So I cannot make a new section before rsrc that would house the expanded export table like in the 2000/XP extended kernels. At present my only solution is to remove seldom-used functions from the export table to ensure that enough room is present for mine. Nonetheless, oCam 511.0 is working (515 may work on vanilla Vista). You do it by the book and your hard work is rejected. update: After eliminating the debug directory and moving down the import table, I only have enough room for about four functions. Actually I can put the code in a section below .reloc like I've done with x64, leaving .text open for a bigger export table. But it would be rather difficult to move a thousand+ bytes worth of it. At least everything between 7DE37F10 and 7DE38F10. SECOND UPDATE: I was finally successful in placing a new export table section between .data and .rsrc without breaking the image. Here is the specific procedure: -Open up kernel32.dll in WildBill's PETool. Go to the .rsrc section. -Click "Insert section before..." on the Sections drop-down menu. Select your preferred name and size. -However, the section will not be the preferred size by default. To make it so, select "Consume slack..." from the Sections drop-down menu and press OK on the dialog that appears; the amount of slack expansion offered by default is the max. Any deviation from these three steps produces breakage! -Then use BWC's PE Maker to move the export table.

The July 2020 IE9 update for Server 2008 blocks Vista.

The update.exe module in the WhatsApp x64 installer is still 32bit. And I noticed they only support Windows 8 and above. Though it probably works on Windows 7 too since all Windows 8+ functions are currently in a broken state in my kernel. But I noticed that the application itself is stored in X:\Users\User\AppData\Local\SquirrelTemp\WhatsApp-2.2027.10-full.nupkg\. I extracted it from that package with 7zip and it ran.

That is the intention. I do believe that the logon init problems are connected to the random services/explorer having trouble starting. Though windbg hasn't helped at all. Sticking onto a VM with my file causes it to freeze when the boot screen is running. But I've noticed that BSODs ceased after making the wildcard import call RtlGetFileMUIPath, though it still causes automatic reboots. Others to try are: LdrGetDllHandleEx and RtlDetermineDosPathNameType_U, I also noticed that the Vista x64 implementation of LoadLibraryExW was very similar to the one in XP x64 (except for not calling SRWLock functions and some other minor differences), which doesn't have the same problem. Though I'm not sure if NT 5 versions of functions would be a good fit for an NT 6 kernel. Then I looked at the One-Core-API version of the function, where an auxiliary LoadLibraryExW is called in its kernelbase.dll, which leads back to the original one in kernel32.dll. Maybe I could use something like that. In the meantime I added K32GetModuleBaseNameW, K32GetModuleBaseNameA and SetThreadGroupAffinity. This will allow Logitech Gaming Software 9.02 and .NET 4.8 to work.

The version check is very complicated. First you must tell fcwin2k/nnn4nt5/Application Verifier x86 to trick the downloaded setup executable into thinking it's on 7 SP1. But then another version block appears, references W7, 8.1 and 10 1607+. This is done by a file named SetupShim.exe. For some reason I can't get around that. So I located the install files in X:\User\AppData\Local\Temp\PdnSetup. This appears to include the files needed to run the software. You can also run the two MSIs in the folder once you go into Orca and drop the "LaunchCondition" table. It will error out at the end but don't press OK: copy the files from the Paint.NET folder in Program Files (x86) to a safe place before the Windows Installer deletes everything. However, it appears that programs running under .NET 4.8 on Vista need SetThreadGroupAffinity (which is relatively easy to implement). I haven't tried with 4.7.

VMware Workstation 10-12 installers (and possibly earlier) will need the original Vista kernel32.dll. If they try loading with mine, then they proceed to call all kinds of absent ntdll functions. But 11 and 12 still do not install because the Windows Installer is apparently too old for them (do they need 5.0?). So it appears that a LoadLibraryExW replacement is needed to solve the Haswell+ logon bugs. The hotfix substantially changed the structure of the function beyond the changes between Vista and 7; these changes were carried over to all later versions of the function through at least Windows 10 1809, it seems. But as a such a crucial function to the OS, it is rather complex. Indeed, a full implementation of it as in the W7 hotfix would require two new functions (BaseGetProcessDllPath and BaseReleaseProcessDllPath) that in themselves are quite complex. So I tried substituting them for two functions imported from ntdll plus several other differences. This caused the OS to reboot several seconds after the boot screen had faded out (so before the orb appeared). So it looks like I'm going to implement the Windows 10 1809 version of LoadLibraryExW since it doesn't call those two functions. But it asks for LdrGetDllPath and RtlReleasePath, which do not even exist in Windows 7. RtlReleasePath is quite simple, but LdrGetDllPath is extremely complex. So I need to look for a suitable replacement for LdrGetDllPath. So far I haven't been able to do so (I tried RtlGetFullPathName_U), as I've only been able to get the cursor to appear before automatically rebooting.

You will have to use Application Verifier on Vista to fake Windows 7. In the case of an installer, you will have to track down the name of its temp installer file if they also do version checks. Once you have the program in Application Verifier, check the Compatibility box and then the HighVersionLie box under it. Right-click "Properties" on HighVersionLie and set your preferred OS version like 6 major, 1 minor, build 7601 etc.

I have received the Windows 7 logon failure hotfix as well as the set of kernel32/kernelbase dlls preceding the ones in the hotfix. kernel32 is very similar, with the only differences in the text (code) section of the file being in the debug directory. These differences are superficial, mostly consisting of changes in the timestamps. But kernelbase (which was part of kernel32 in Vista and earlier) is a very different story, with all kinds of small patches scattered throughout the text section. It may take awhile to implement. Tentatively, this seems to be an issue with a previous implementation of LoadLibraryExW. I have also finished implementing K32EnumProcess and GetActiveProcessorCount series in x64 kernel32.

yeah, that also happened to me a lot. it's one of those things that got better over time.

Yes, this bug also affects quotes on here. All of them are dated as "just now". So it appears that this bug appeared with my earliest revision to kernel32 this afternoon. I had commented out the Windows 8 function GetCurrentPackageId, but another one was fixed, GetSystemTimePreciseAsFileTime; that was previously typoed as GetSystemTimePreciseAsFileTIme. So I typoed it again and now the date problems and the download progress bar are fixed. Indeed, this is what this function consists of on Windows 8: retn 0 Makes me wonder how it could work on W8 in the first place. I also fixed up some code in a subroutine linked to the Power*Request functions. That fixes the Visual Studio Code CPU utilization issue.

I have done changes to uxtheme and dwmapi.dll (x64 in both cases) that strips them of any code associated to the new functions in each file, making them true stubs pointing to memory addresses far out of the file's range. Firefox 68 ESR and 78 (regular) are unaffected by the change, while the new stub-like properties of the functions do not affect logonui/winlogon in any way like my earlier attempts did, allowing for the OS to run with them. Windows Explorer is also stable with them. And furthermore, I got Firefox 68+ address and search bars working like normal after these changes! But it cannot automatically download Widevine CDM. So now I can focus on adding the last five functions (K32EnumProcess plus the ones in my post above) to x64 kernel32.dll. x86 kernel32 is actually quite difficult to modify in some way. Doing a "paste write" of the code into HxD like I do for x64 files breaks the x86 files in some way. And a "paste insert" seems to work, but it doesn't replace the existing zero bytes, it just pushes them farther down so to speak, making the file bigger and presumably why this would break an export table located below it (as I found to happen with x64 files where the export table was already relocated by me). update: actually there is another bug where the download progress bar is not updated in all browsers from Serpent/New Moon to Firefox 78. I'll investigate that one further. And some fonts on DDG in Firefox 78 didn't appear (perhaps they failed to download, possibly linked to Widevine CDM failing to download). In any event, you can still redirect Serpent and New Moon to the original Vista DLLs. These problems seem to be linked to kernel32.

Have you tried the Boingo client? I used that exclusively after installing the extended kernel. I remember the native Intel wireless manager was quite useless to begin with (used a 3945ABG WLAN adapter) and it may have had the same issue as you, but I cannot confirm since that laptop has its own issues now.

I've had a similar problem a few times. It was fixed by disabling/reenabling the network connection from the network connections folder.

MPSS is only compatible with Windows 7 and above. Its driver is only available for x64 systems: https://software.intel.com/content/www/us/en/develop/articles/intel-manycore-platform-software-stack-mpss.html?wapkw=mpss#about https://www.pugetsystems.com/labs/hpc/Intel-Xeon-Phi-with-Windows-510/ You cannot run Windows applications natively on the Phi, as the Phi itself runs on an embedded Linux.

Perhaps. It would have to be implemented through the NTFS/ReFS drivers. My confidence is low since my success rate for kernel mode extensions is still 0%, But I have tracked down what appears to be the functions referencing "DisableDeleteNotification" and "DisableDeleteNotificationDrain" in the 2012R2 ntfs driver; fsutil querys "DisableDeleteNotify" to check TRIM status. So a backport is possible.

I'll add GetActiveProcessorCount (plus associated functions GetActiveProcessorGroupCount, GetMaximumProcessorCount and GetMaximumProcessorGroupCount) once I get back to the x64 files. My x86 kernel32.dll is about 25% finished. I am holding off a wider release until the x86 files are completed and a few bugs are fixed.

No. It doesn't have enough functions for BWC's kernel32.dll (so it can't boot with it) and his extended kernel doesn't have enough functions for New Moon/Serpent either.

I've narrowed this down along with other similar limitations. The system lockups are due to me running in debug mode; in fact, pressing PrintScreen will lock up the system! The only issue with dependency walker/debugging of programs using my extensions is that trying to track GetProcAddress/LoadLibrary functions will cause a buffer overflow exception. Aside from that, debugging with redirected DLLs is very possible. The obvious solution is to replace the system files with mine, which I was able to do early on, yet now it appears that winlogon/logonui can no longer accept them. And they don't redirection. While Brave and its main DLLs don't seem to export any W7+ functions from DLLs other than kernel32.dll, I decided to copy the rest over and now get a fault in kernel32 at 78DFEC00h, which corresponds to an import table entry for RtlFreeOemString ("Frees the string buffer allocated by RtlUnicodeStringToOemString.") from ntdll, which is called by two subroutines in kernel32. Further investigation required. Visual Studio Code now works, not hindered by my unfinished implementation of Shell_NotifyIconGetRect, but thanks to the fixing of another bug in another function I implemented. Do not, under any circumstances, try to reimplement ntdll functions in other DLLs (except for ntdll functions that are forwarded from kernel32, in kernel32)! There are issues though, with the module that implements extensions/plugins, spdlog.node. It uses up lots of CPU time bringing CPU usage to ~94% on my Xeon X5670. I'll try that soon, once I get the x86 ball rolling, since there doesn't seem to be any x64 binaries available for Windows. In fact, my earlier post about shelving MS Edge and Office 2016+ due to disobedient installers was in error, since I just checked and found that the installers are indeed 32-bit. I've turned into Tim Apple with his OS' relentless pursuit to abandon 32bit binaries. Actually Windows 7 x86 kernel32 code is far simpler than the x64 equivalents, so I have an even better feeling about it. Just need to work quickly enough before x86-32 everything is deprecated!

That was version 11 on Windows 2000, which exhibited some other deficiencies compared to it on XP. But you should try updating the root certificates.

Unfortunately things aren't working out with Brave: And I have identified two conditions that may cause a system to lock up; first, running chrome_pwa_launcher.exe from Brave's folder or attempting to use Netflix in Firefox 68 ESR and later. In the second case, it seemed to be due to GetCurrentPackageId, which is a Windows 8 function. Firefox also does exhibit completely different behaviour if tricked into thinking it's on 8.x, as most UI elements don't work in that case. You can disable buggy functions by opening your local copy of a dll in ExportTableTester, and simply changing "XXXXFunction" to "XXXXFunctio_". But Electron-based Visual Studio Code seems to be in a better place. The only thing holding that back is my incomplete implementation of Shell_NotifyIconGetRect. All I have to do for that one is add a chunk of the function (as in a part that is separated from the rest), two subroutines with a chunk each, as well as a couple of new qword values in the data section. Luckily, all of its imports are accounted for in the Vista version. I can't think of a good, modern Chromium browser to try. It seems that they are all undesirable in some way, and their only good purpose is to view heavily-DRMed content that roytam1's or Tobin's browsers can't handle. With the expanded complexity of the project in mind, I have scrapped the idea for the tutorial. I am working on alternative means of distribution for the kernel extensions. Please contact me for more information.

That doesn't actually change any hex values, just the way it is displayed to IDA. So it doesn't actually change locations. And I'm unable to run New Moon/Serpent with ntdllx4 as they throw exceptions in kernel32.