win32

The dislike counter has only briefly disappeared for me, about 5 days ago. Seems like they are doing A/B testing as usual. I do wonder if Invidious will continue to fetch them once the feature is actually removed from official YouTube clients.

There are too many missing functions to think about copying over the 6519 HAL. And there is another consideration to make. Several pointers to HAL functions are loaded into two dispatch tables in ntoskrnl at boot. These replace various stubs and other functions, and allow ntoskrnl (and other drivers) to call the HAL without explicitly importing the functions. The main TSC synchronization function is inserted into the table and called by various functions in ntoskrnl. I will have to check that out.

I believe I wrote about 6519, the first build of 7 x64 to have leaked in terms of a complete fix. There was a partial fix for Vista in that time (some of the timer discrepancies were fixed but not all). I am not sure which update introduced it, as the Server 2008 updates became cumulative rollups in the fall of 2018 and now that Kaby Lake laptop is in very poor shape.

The program specific overrides take precedence over global settings.

Must be x86 Chrome. I implemented this function a long time ago on x64 and there is a Chromium 97 build somewhere working on Vista.

MinorVersion=1 and BuildNumber=7601 in many cases. You may also need FirefoxFix=1 or Win7SuperVerFix=1. That is in addition to Enabled=1 of course.

The version spoofing takes effect when you save the file, so not at all.

Here are some more details for usage of osver.ini. You can set settings per-application as above (set Enabled=1 as well), or set them for the entire system by making an entry appended with "[global]". To accommodate every version checking method used by an application, several options are available. Unfortunately I also found that breakage became a significant possibility very quickly, so keep that in mind when using the version spoofers. You can set these values to 1: Win7SuperVerFix Win8SuperVerFix Win10SuperVerFix FirefoxFix (a lighter version of Win7SuperVerFix) You can also set these values: MajorVersion MinorVersion BuildNumber CSDVersion (the service pack string) PlatformId (caution, as the standard value of 2 is used to indicate that the OS is Windows NT. 1 represents 9x and 0 represents Win32s) For example, Firefox installers would need MinorVersion=1. You may have to briefly set it under [global] for installers that copy executables to a temp folder and do the version checks there.

They are the same as the previous version. This should now be fixed in the latest installer. Although it is recommended that users who have already run the installer rename kernel32.dll.bak to kernelol.dll in syswow64.

Actually, there is no "SteamFix" defined. But for Steam you could attempt "SuperWin7VerFix=1". There is also a SuperWin8VerFix and a SuperWin10VerFix.

Not yet. I may have to implement a lot more stuff on x86 first.

Changes in the latest Vista Extended Kernel release: A new function has been added to user32 in x64. This should help with newer Adobe applications. Two new functions have been added to ntdll. This will allow Windows 7 WordPad to run. That function was contributed by Ximonite. Most of the K32* series of functions have been implemented to kernel32 x86. The SetDefaultDllDirectories bug is now fixed for x86 applications. Run x86 VLC and you will see the difference. GetLogicalProcessorInformationEx is also implemented on x86, without issue. Version spoofing is now implemented. Make a file in your Windows directory named osver.ini. If you have Firefox/Thunderbird 91 or above installed, or Waterfox G4 installed, copy the path of the executable to the file and place it in brackets. Write "Enabled=1" below. Then write "FirefoxFix=1" below. Then run Firefox/Thunderbird/Waterfox. Font rendering also differs slightly with this option set on older versions of those browsers.

I installed these drivers on a terrible HP laptop. Not much information provided by HP on it. Also, I just recalled that there was another set of unsigned generic USB 3 drivers that also worked.

I think these are the ones.

Yes, I did get one digitally signed set working at USB 3 speeds. I don't believe they are posted in the forum however. I will send them if needed.

It now appears that the partial fix for the Haswell TSC drift issue was in a update released between 2017 and 2019. While this issue only seems to have appeared with the Haswell CPUs, fixes for the issue do date back to build 6519 (released in December 2007), as I have tested on my Kaby Lake laptop. In a series of reboots, all services started and there were no issues with application execution.

Firefox 91-based Waterfox continues to run on Vista, and my extended kernel's implementation of Windows 8 API is still minimal. But it is not enough for Steel Bank Common Lisp, so both Vista and 7 users are out of luck due to the non-presence of CancelWaitableTimer: https://sourceforge.net/projects/sbcl/files/

About that, the experimental extended kernel version was able to install Office 2019 and almost run it. I've yet to try Office 2013 or 16, as the current version spoofer works for 2019 but not 2013/16 for a few possible reasons. Most of the others are a little iffy, if only because they are first-party software, and it tends to be harder to get newer versions running of those than third-party ones (which is also true of Windows 2000; struggles with parts of Office 2007 while it can run every version of LibreOffice and OpenOffice that XP can). I think a couple of those are x86 native electron apps while iTunes is win7-compatible with a Windows 10-tailored version block (I do have a likely solution for it). So the former will be available when x86 matures (the kernel32 functions are plentiful for those now, but I haven't started on the other dlls) while the latter will be attempted very soon.

91 ESR is working with the hex patches I described earlier. 92 beta as well, but 93 developer also has issues for me. But remember that 93 developer is bleeding edge and instability should be anticipated. I would be concerned if the crashes stuck around to beta, however.

Which GPU and driver are you using? I haven't encountered that issue on NVIDIA driver 342.00 using Quadro FX 3800.

For those wanting to run Firefox 89+ on Vista, open xul.dll in a hex editor and search for the hex sequence FC 1C 01 00 00 C7 46 08 B0 1D 00 00 31 C9 BA 04 and change the bolded numbers to 72 17 and then again with 6B 2D 04 C7 47 FC 1C 01 00 00 C7 47 08 B0 1D 00 Notice how 1DB0 is hex for 7600 and 1772 is hex for 6002.

I notice that the only publicly available 373.19 is from MSI. Perhaps it's part of a driver branch for OEMs and only MSI decided to make the driver they got publicly available? However, 372.93 and 373.06 are available from NVIDIA as reference drivers. The former for Windows 10 but the latter as an NT 6.x mobile driver: https://www.nvidia.com/download/driverResults.aspx/108323/en-us Also of note, NVIDIA's reference driver also calls memcpy_s.

I later checked the drivers 372.90 and 375.63. The former does not contain the Vista block, although I don't have the NVIDIA hardware to drive anything past 342.00 (not here with me right now, anyway). I assume that 373.19 is a special case as it was intended for Vista, which would explain why it actually runs on Vista without needing memcpy_s in ntoskrnl? And has it been tested with Pascal cards, which are apparently worse off than Maxwell and earlier on Vista?

ntoskrnl cannot be easily wrapped. Thus, I will only be able to provide one patched version of it. And another note, NVIDIA drivers after 372 fail to initialize if version 6.0 is detected and send the NTSTATUS REQUEST_NOT_SUPPORTED. NVIDIA had no problem providing barely-documented Windows 2000 support until late 2010 yet they have shifted to blocking operating systems, even those that are technically capable of using the drivers (Windows 8.1 with RTX 3xxx, early Windows 10 builds and soon Vista).

In most cases, yes, but there may be issues with temp-folder based installers that are spawned from another installer. By the end of September. I have close to enough new features to justify a new release, but I think I can stuff some more in. And I also need to test. I have every K32 function implemented for both architectures, SetDefaultDllDirectories fixed on both archs, ResolveLocaleName (basic implementation) and soon some other things. I hope to get many basic x86 applications running. The kernel32 wrapper itself is probably more compatible than it was at another point in the extended kernel's existence, as it doesn't rely on the original kernel32 having SetDefaultDllDirectories (which was added to Vista in 2013). But that will soon not be the case, as it will call functions from my NTDLL wrapper, and that will need a modified ntoskrnl to work.