[WIP] Windows Vista Extended Kernel

[D.Draker]

3 hours ago, win32 said:

memcpy_s and memcpy are not equivalent as memcpy_s has an extra parameter (buffer size) where a memory address should go.

Could the last officially working kernel.sys from the Dixel's 373.19 (Siemens) driver be attached with these newer drivers ? I tried it with 372.95 Quadro driver and everything worked fine and dandy ! I just replaced this file and that's it ! But with 373.19 kernel it didn't allow me to use CUDA and Physx with 375 and all of the later ones.

[win32]

2 minutes ago, D.Draker said:

Could the last officially working kernel.sys from the Dixel's 373.19 (Siemens) driver be attached with these newer drivers ? I tried it with 372.95 Quadro driver and everything worked fine and dandy ! I just replaced this file and that's it ! But with 373.19 kernel it didn't allow me to use CUDA and Physx with 375 and all of the later ones.

Yes, it is possible, but I am not very sure of what breaking changes would have been made in that period.

[D.Draker]

4 hours ago, win32 said:

I think that there is a version check in the init procedure of the driver (.sys file) that returns, iirc, STATUS_NOT_SUPPORTED.

Indeed there is , of course . 

"When nvlddmkm.sys is loaded, it detects OS version. If I want to install 412.40, I need to replace 3839 with 3FAB, then nvlddmkm.sys will not be unloaded."

Do you know the values for Win 7 / Vista to help Jacob.

 

Thanks.

https://msfn.org/board/topic/179590-nvidia-geforce-rtx-error-code-43-on-windows-10-version-1607/#comment-1169708

[D.Draker]

4 hours ago, win32 said:

I have a few results

Can I send you a PM with a link to a special driver for MSI desktops. GT1060-1080 are officially supported and no need to mod the inf.

It works with my Titan X very well.

[win32]

1 hour ago, D.Draker said:

Indeed there is , of course . 

"When nvlddmkm.sys is loaded, it detects OS version. If I want to install 412.40, I need to replace 3839 with 3FAB, then nvlddmkm.sys will not be unloaded."

Do you know the values for Win 7 / Vista to help Jacob.

 

Thanks.

https://msfn.org/board/topic/179590-nvidia-geforce-rtx-error-code-43-on-windows-10-version-1607/#comment-1169708

In the case of 376.11, at offset D373D0h, there is this line:

60 5D A7 FF E8 E7 E0 84 FF 48 8D 0D C4 5D A7 FF

It is updated to:

60 5D A7 FF E8 E7 E0 84 FF EB 24 0D C4 5D A7 FF

The problem is that the other instructions on this line reference data that may have moved around in other versions so two lines below it is this code that should remain constant between the versions:

84 C0 74 0A B8 BB 00 00 C0 

(on 376.11 it should be from offset D373F1h to D373F9h)

If you can't find the line above, change this second set of values to:

84 C0 EB 0A B8 BB 00 00 C0

 

[win32]

48 minutes ago, D.Draker said:

Can I send you a PM with a link to a special driver for MSI desktops. GT1060-1080 are officially supported and no need to mod the inf.

It works with my Titan X very well.

It was another user who used those test drivers, as my GPU tops out at 342.01.

[D.Draker]

3 hours ago, win32 said:

It was another user who used those test drivers, as my GPU tops out at 342.01.

OK , maybe if you upgrade later just don't forget to write , it's not 373.19 , a bit lower ... but still a very good/fast one. 372.93 or something like that.

[Jakob99]

I'm grateful for the research into Nvidia drivers, but unfortunately, the newest Nvidia I have is from 2009 and has Vista support

I would, however, be happy to test out any mods for Intel Skylake and AMD Radeon R4 Stoney Ridge. I just procured an Acer Spin 5 SP513-51 with it Tuesday. Only thing is I'm not sure if NVMe support was modded to Vista. I also have an 11th Gen Tiger Lake, but for whatever reason Windows 7 doesn't even load despite using an ACPI.sys patch designed for it that strangely allows Windows 8.0 to load. I also have a Celeron N3050, but I'd have to WindowsToGo Vista due to lack of eMMC driver support and all of the makers of the unofficial WindowsToGo feature such as Rufus and Aoemi do not support Vista.

[winvispixp]

I have the 372.54 which works on vista with gtx 10 series

but of course it has the same issues as the other ones as far as performance goes 

I can send it to you (or you can download it from asus's website for gtx 1060 3gb dual oc)

[D.Draker]

On 6/2/2022 at 11:23 PM, win32 said:

In the case of 376.11, at offset D373D0h, there is this line:

60 5D A7 FF E8 E7 E0 84 FF 48 8D 0D C4 5D A7 FF

It is updated to:

60 5D A7 FF E8 E7 E0 84 FF EB 24 0D C4 5D A7 FF

The problem is that the other instructions on this line reference data that may have moved around in other versions so two lines below it is this code that should remain constant between the versions:

84 C0 74 0A B8 BB 00 00 C0 

(on 376.11 it should be from offset D373F1h to D373F9h)

If you can't find the line above, change this second set of values to:

84 C0 EB 0A B8 BB 00 00 C0

 

I'll try to mod 390.67 'cause it looks even better than 376.11 . Why ? Let's see :

1st - No missing dependencies in the main 32 bit driver .

2nd - Much newer.

3 - more GPU's supported .

4 - No checks , like you said . I can't find this 60 5D A7 FF E8 E7 E0 84 FF 48 8D 0D C4 5D A7 FF.

So patching only the 84 C0 74 0A B8 BB 00 00 C0 would be enough ?

5 - There's no bloody memcpy_s in the .sys! (replacing which was a failure)

But some others . Of course I'll replace them too .

KeQueryLogicalProcessorRelationship, 

wcsncpy_s

wcscpy_s

strncpy_s

Are they important ? What do you think ? 

What I think the problem with DirectX is not because of the missing calls , but because the card is not meant for Vista .

I'll try it on the previous gen. 900 series Titan X.

@Jakob99, about Intel you could have said earlier , lol. To answer your question , it would be a similar mod . To spare you some time .

I read folks had success with the beta XP drivers for Hasvell. BUT (a big but) , only the earlier CPUs in this line worked.  No aero , as you might guess.

[D.Draker]

 

Also about 390.67 

6 - No missing dependencies in nvwgf2um.dll DX10+ driver.

7 - No missing dependencies in nvcompiler32.dll, nvcuda32.dll, nvcuvid32.dll, nvd3dum.dll

8 - iCafe drivers tend to have less missing dependencies in general.

9 - Looks like the last 32bit driver.

I have a couple of questions , do I need to rebuild the cheksum ,or just change the values ? 

Did you sign the dll after you patched?

Did you pack them back with 7zip ? I mean for the installer.

Do we need to remove KSECDD.SYS BCryptGenRandom ? 

 

Just in case someone wants to join:

https://drivers.softpedia.com/get/GRAPHICS-BOARD/NVIDIA-GeForce-iCafe-Graphics-Driver-390-67-64-bit.shtml

https://drivers.softpedia.com/get/GRAPHICS-BOARD/NVIDIA/NVIDIA-GeForce-iCafe-Graphics-Driver-390-67.shtml

[win32]

On 6/4/2022 at 1:07 PM, D.Draker said:

KeQueryLogicalProcessorRelationship, 

wcsncpy_s

wcscpy_s

strncpy_s

The first one is quite complicated, similar to GetLogicalProcessorInformationEx in user mode, and used to obtain a lot of CPU information such as cache, core #, package #, etc. Unaware of a good replacement. The last three are string manipulation functions. It's possible they could only be used for debugging strings, and no actual driver functionality.

16 hours ago, D.Draker said:

I have a couple of questions , do I need to rebuild the cheksum ,or just change the values ? 

Did you sign the dll after you patched?

Did you pack them back with 7zip ? I mean for the installer.

Do we need to remove KSECDD.SYS BCryptGenRandom ? 

I would recommend updating the checksum, but it is possible that my patching could make it unnecessary. On 32 bit, disabling DSE should make it unnecessary anyway.

Any signature I make would not be "trusted" as I don't have MS' private key. So disabling DSE would be required.

I didn't repack the installer.

Vista has it so it shouldn't need to be removed.

[D.Draker]

13 hours ago, win32 said:

The first one is quite complicated, similar to GetLogicalProcessorInformationEx

First off , thanks , you are very helpful , as usual.

It looks like a telemetry function , no ? Earlier drivers didn't have it and worked just fine. Anyways, the less those plonkers know about my CPU, the better ... lol.

I've been (and shall be) away for some days from my testing Vista PC. Only a good one is here near me (which I don't want to mess with). So I tried to change just one bit 

in the sys :  wcsncpy_s was changed to just wcsncpy , to be precise, and then I tried to load it on a junk win 7 PC x64 - nothing worked . It says a corrupted driver smth like that.

The PC starts just fine, but with a generic driver only.

Of course I disabled the driver signature and rebooted before I installed it. Looks like this procedure doesn't fully disable the checks on win 7 x64. Would it be the same with Vista ?

That's why I asked about signing them . Selfsigning maybe ? 

[win32]

14 hours ago, D.Draker said:

It looks like a telemetry function , no ? Earlier drivers didn't have it and worked just fine. Anyways, the less those plonkers know about my CPU, the better ... lol.

Programs like CPU-Z use the kernel32 equivalent. Software could use this data and transmit it to who-knows-where, but they could also use it to determine CPU information necessary for multi-threading or something like that.
 

15 hours ago, D.Draker said:

in the sys :  wcsncpy_s was changed to just wcsncpy , to be precise, and then I tried to load it on a junk win 7 PC x64 - nothing worked . It says a corrupted driver smth like that.

Some tools may "rebuild the PE header" (CFF Explorer has it as an option checked by default and stud_pe does it automatically without telling you) and that is fatal for drivers.

I haven't tried any signing, as I always found self-signing to be worthless in general to Windows. On Windows 8, I modified explorer. Windows 8 would no longer run explorer, even with self-signing. I had to disable DSE to run it.

I think in both cases, it may be best to look at the previous drivers without these functions and try to transplant the old equivalent functions into them. However, symbols are never released for drivers so it could be very difficult.

[D.Draker]

8 hours ago, win32 said:

Some tools may "rebuild the PE header" (CFF Explorer has it as an option checked by default and stud_pe does it automatically without telling you) and that is fatal for drivers.

So you mean I need to patch the drivers and then prevent the tool to automatically rebuild the PE header while letting only the checksum to be fixed ?