win32

I just reviewed all changes: -Windows 7/8 functions added to kernel32 to support Firefox 106+, a couple of games, and Blender -DXGI extension added to run newer WxWidget x64 version of PCSX2 and others asking for CreateDXGIFactory2 -ole and user32 extensions to run many Qt 6 applications -Extension to bcrypt: add support for PBKDF2 hashing algorithm -PowerShell Core up to at least version 7.0.1 working -Several applications such as x64dbg and Telegram will now run if spoofed to Windows 7 (the fault of the VC++ 2012/13 runtime) -NTOSKRNL extension added, compatible with NVIDIA drivers 378 (adds support for all Pascal except GT 1030) in full, and 398 on some systems (supports all Pascal plus OpenGL 4.6). A modified version of 378 (and 398, which may not work properly on some systems) will be made available through the extended kernel website.

It does not fully work; the optional kernel mode component is missing function ObGetObjectType. I hope to add it soon. The other important function in the newer releases is technically kernel mode as well: NtQuerySystemInformationEx. I have some compliant functions like KeQueryLogicalProcessorRelationship but I may need to add additional classes or refine existing ones for that to work as it should.

That's not why it has problems on 2000... that's because of some user32 functions that have "RawInput" in their names. But yes I made a stub of CreateFile2 months ago and now I will add it. I added the pointer functions awhile back. I also have another function used by the TBB runtime to add.

My ideas about win32k in 2000/XP are very speculative, but based on what Vista/7 do; in the latter two, graphics drivers call dxgkrnl through win32k through gdi32 to do things like initialize Vulkan. If anything needs to be added to win32k in 2000, I think BWC has covered it. But there are other things that win32k in 2000 needs to have, like raw input support (that's why PCem/86box/Blender have issues with keyboard input).

I added WerUnregisterRuntimeExceptionModule and got Firefox 106 running. So it should not be too long.

This is not very relevant to this topic, but one would have to fill in the gaps and add XP/2003 functions in addition to the Vista+ functions for that to work properly. Then perhaps it could work, but there are some other ways in which the kernel side differs (XP has a distinct dxgkrnl, 2000 does not, but most XP graphics drivers were successfully ported to 2000, so perhaps the dxgkrnl functionality was implemented in win32k in 2000).

These functions were already in Vista's ntoskrnl but not exported previously: wcstomb_s wcsncpy_s wcsncat_s wcscpy_s wcscat_s vswprintf_s vsprintf_s swprintf_s _vsnwprintf_s _ultow_s _snwprintf_s _snwscanf_s Maybe Server 2003 has some of them too, as that was when they started to be very concerned about buffer overflows in the kernel. I then added these functions with my own driver (unreleased due to isolated bugs on a small number of configurations while using certain drivers, but otherwise NVIDIA 398 is stable): memcpy_s KeQueryMaximumProcessorCountEx KeQueryLogicalProcessorRelationship strncpy_s _snprintf_s KeQueryUnbiasedInterruptTime (this is still a stub, which relies on the biased interrupt time; lacking time to implement the proper implementation in the driver which grabs the bias value from elsewhere in the shared kernel data iirc) I decided to upload the more complicated function implementations to here: https://github.com/win32ss/win32-api-reversals/tree/main/kernelmode There is also some preliminary work on improving dxgkrnl to use Vulkan with NVIDIA drivers on Vista, and perhaps attempts at WDDM 2.x support in the far off distance.

I have been extremely ill for the past two days, and there is more to the extended kernel than issues with the user mode part of a driver (either that, or there are deficiencies in the DirectX graphics kernel which are causing this). We are already dealing with the nightmare that is the NVIDIA 39x drivers, where it seems that success is very random, as many users are already booting up to the "orb" and getting stuck on it.

This is what is happening: https://www.chromium.org/updates/ua-reduction/ User agents are being simplified. Chromium on Windows will now use "Windows NT 10.0; Win64; x64" in all cases. However, there is a replacement called "user agent client hints", which will contain much of the information that user agents currently contain, such as Windows versioning (that is how Windows 11 usage gets tracked). The specification supports tracking Windows NT 6.1+, but Vista and below will be lumped into the same category (though only Vista is currently capable of running UA-CH compatible browsers stably): https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform-version Firefox and Safari do not support UA-CH at this time, and will likely keep their user agent format the same for now.

I was able to integrate gcc (using mingw64) into vs code using the official instructions on the vs code site, but it seems that gdb doesn't work at all with the extended kernel. I need to fix that. As it stands I can compile and build applications within VS code, but I must run them outside of VS code. So only printf/cout-ish debugging for now!

I believe the property pages are quite similar. I think they just added some more options and features.

The official and many of the unofficial ntdll.libs are missing certain functions like RtlGetVersion presumably because they are duplicated by kernel32 functions in practice, or possibly also because they aren't officially documented in any capacity. The ntdll libs in this repository contain RtlNtStatusToDosError as well as everything else: https://github.com/vxiiduu/VxKex

Are you running 107.0.5289.0? Here it is different: I think I will boot into Windows 8 anyway, in case it uses some esoteric way to check for NT 6.1 and up (like presence of kernelbase, system file versions, etc).

Unfortunately it would be difficult because no debugging symbols are available for NVIDIA drivers (they have a "symbol server", but it has no debugging symbols in it). It is not very easy to identify which part of the driver is responsible for a certain task.

It will support other drivers as well; the next one in my sights is the Process Hacker 2.39 driver. I will also add functions for Intel and AMD drivers, and also other system drivers such as Windows 7 file system drivers (which support TRIM).

It is certainly better than the regular ACPI timer, but I found that it did not help very much on Haswell+. There is a better, more precise timer than ACPI that apparently did improve things on those systems (but still not perfect): invariant TSC-based timer. Windows 7 supports this but it actually is rarely used in practice. I enabled it in Vista with a test HAL, but it wasn't released because it didn't boot on some systems.

373.06 does call memcpy_s. I did not modify the GPU driver; instead I decided to implement the function in my own custom driver which can do many different things. It interfaces with ntoskrnl and exists because of some limitations in ntoskrnl itself. And yes I tried 377.83 by changing the functions awhile back. It would not boot, so I decided to start on an alternative method that covers a broader variety of drivers.

I don't think you're missing anything, as it appears that memcpy_s was never called. But I had problems with changing KeQueryLogicalProcessorRelationship in later drivers.

I will work on interfacing the driver with the HAL like I've done with ntoskrnl, to allow for improved system timing.

I think I can. Is this the 32 or 64 bit shell32?

There isn't. I am still missing a few functions to run 377.83. The timer driver is no longer a timer driver, but that was its original purpose. It will be part of the next extended kernel. I did not do anything. The memory listed is the GPU memory (1 GB) + shared system memory (3 GB).

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: