win32

This driver did not succeed in calibrating the timers, but I used it to help me run 373.06:

It may have called RtlGetVersion directly, read the PEB, or worse, read SharedUserData which means a driver would have to modify it. Anyway, I now have a driver that synchronizes the RTC with other system timers. I see that even my Xeon X5670's RTC runs slow on Vista. So I will try on here, then I will offer it to others.

I see that ReShade falls back to DXGIFactory1 on Windows 7 or earlier. It's the same thing I did, but I'm not sure why they failed unless this tries to call some of the interface methods exclusive to DXGIFactory2. I worked on the D3D kernel mode synchronization objects and it is very difficult. So it will take some time to get Vulkan.

I added DXGICreateFactory2 to get PCSX2 x64 working recently. So this will work for TeamTalk as well:

Good. That's one of the functions I added.

I haven't been able to get those to run yet. And .NET 4.x is like a bit too much of a black box to me compared to native code and .NET Core. Yes it's a Vista issue.

Yes, the VS 2010 IDE relies on the .NET 4.x runtime which is largely broken with 4.7 and above. You will have to use the VS 2008 IDE.

No. As for the Audacity installer, there are some missing functions. But it is 32 bit, and adding functions (presumably user32 ones) will cause substantial breakage at this time.

We will soon be able to use OBS 28.0 beta 2 as well as PCSX2 x64 (wxWidgets version for now - Qt version has complicated Windows 10 1803 functions): The small DirectX extensions seem to be working. I want to take them further and go in the direction of newer graphics drivers, Vulkan and ultimately DX12 (it will come in some way - either with Vulkan using vkd3d or D3D12on7 with 2018/19 GPU drivers; and a tiny possibility of using WDDM 2.0 drivers, but that could be quite complicated)

Several auxilliary applications provided with Calibre are indicated to not work even with the patched Qt files nor Vista extended kernel (Vista extended kernel works fairly well for Qt 6.x at this time, but it needs the special Qt6Core library for Calibre). I ran both Calibre and the ebook viewer. There was one module that the ebook viewer tried to load that Calibre did not: mfplat.dll, which is missing a few functions introduced in Windows 8. Those are linked to DXGI (DirectX Graphics Infrastructure). Windows 7 with its platform update is not up to the same level in DXGI as Windows 8 (DXGIFactory2 interface methods are all stubs on Windows 7), but it is possible that further stubs may be sufficient for the auxilliary applications to function.

Which kind of error is bcrypt producing? I added some functions to bcrypt that will be in the next release.

I noticed that several applications tried to call the unavailable function CreateRemoteThreadEx, often through the VC++ runtime, and crash, if they were spoofed to NT 6.1. As these applications may require a spoof to NT 6.1 to bypass version checks in the future, I am adding that function.

Did you install the kernel files or are you still redirecting them? The latter case seemed to cause those problems in my (2020) testing.

Now coming to the extended kernel, Qt 6 application support: The kerning issues happen even on NT 6.4. I will look into that as well, but there is also some more work to do to get Qt 6.3.1 and later working as well.

The api-set DLLs that are supplied as part of the OS as opposed to being distributed with the VC++ runtime are tied to apisetschema.dll, and will not function unless apisetschema is updated to reference the api-set and the redirections it makes. Wine has a solution for it, but it involves its own apisetschema iirc and it may not be suitable for Windows. Most of the functions exported from the DLL exist in earlier versions of Windows (think NT 4 or 5; only a few are actually exclusive to 7 or 8), so a traditional export-forward DLL is better suited to OSes from the pre-api-set era. If your application only uses functions that are present in your version of Windows, this DLL will work fine; if they're missing, the application will try calling a null pointer and crash, which a good debugger will pick up. Link to the binary: https://cdn.discordapp.com/attachments/834206126878752808/1004433792037027951/api-ms-win-core-com-l1-1-0.dll Link to the source (which is just a def file and an entry point): https://github.com/win32ss/win32-api-reversals/tree/main/windows8/api-ms-win-core-com-l1-1-0

The newer Adobe CC setups would be hopeless anyway. I once tried running the CC 2019 installer awhile back on Windows 7, and it did not render any text making it useless. Then I realized I had IE 8. I upgraded to IE 11 and it started working. The system requirements for Adobe CC do not say anything about IE either. IE isn't as tied into the shell these days, but I think it would constitute a significant amount of wasted effort. I would need a bit of convincing to justify updating IE. Not even the fact that MS Account integration in Chromium Edge relies on IE 11 convinced me to work on it.

.NET Core is still supporting Windows 7 for now. But it is hanging on by a thread. But some Qt 6 applications have gone straight to Windows 10 only. And the big thing on Windows 10 seems to be winuser (user32) functions, mostly related to DPI scaling. I should work around those once .NET Core is settled (only thing is that Vista's support for neutral locales is almost non-existent, so I am implementing a neutral locale table). That will take me a few days as I want to ensure that the revised locale support is up-to-snuff and as good as Windows 8/10 (noting that most improvements were done in 7).

I think .NET Core 6.0.6 is working good now. dotnet --help no longer fails. I will have to test further and work on a couple of minor issues. In the process, I have determined how MS will likely disable .NET Core on Windows 7. Calls to BCryptCreateHash are first done with a flag only supported on Windows 8 and up, then again without the flag if the call fails. They will remove that second fallback call right away in a cleanup of legacy code.

Correct.

I have pushed the new extended kernel to the usual sites. Now I am working on the next thing and making progress: It is almost done, there are just some issues with BCrypt now, PowerShell 6.0.1 works completely now but that is .NET Core 2.0:

The usual sites now have the new release, which should have improved 32 bit compatibility.

Support for installing Chromium extensions, saving their settings, as well as keeping cookies and other settings has been implemented: The original objective was to fix the "CultureNotSupported"-related exceptions that prevented .NET Core 5 from working, but under the belief that the .NET and Chromium issues were connected, I worked on solving the issue using Chromium. It turns out that .NET's issues are unrelated.

I don't know very much about theming. I know that I did make *everything* dark on Windows 2000, but I never tried on Vista. Things like the main part of Explorer don't seem to be easily changeable like they used to be. I know some people who know theming better, perhaps I'll ask them if there's a way to do it without significant patching of the shell or Explorer.

Vulkan is the successor to OpenGL. Some newer games may require it, and there is also a Vulkan wrapper for DirectX 12. A few people have asked me about Vulkan applications. I may write OpenGL applications in the future, yes. No, there is no need to buy that card. I am using a GTX 650 and don't consider using the low end Pascal cards. I just need something that works good for the GTX 650, and 372.70 is not it.

I hadn't been able to pay much attention to this as I was trying to correct another shortcoming that applies to all drivers: lack of DirectX kernel functions to run Vulkan. Then I tried running several OpenGL samples I built and noticed that 372.70 could not run them if they were x64, just x86. So in the coming days I will try an early 38x driver to replace this one.