Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

On 8/10/2022 at 4:20 PM, win32 said:

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

Well , I figured out what's at fault here . It's the newly released shell32.dll . If I replace it with the version from the kernel released on 26.10.2021, all is back to normal.

So I can use the newest kernel32 alond with the old shell (file date stamp is 05 December 2020) and all is fine in this case . Any chance this could be looked into ?

Sorry for too many questions.

Link to comment
Share on other sites


18 hours ago, D.Draker said:

Hi , interesting , do you mind me asking, is there a benefit in using 373.06 over the 377.83 from my tutorial ? I mean , this one's much older . Perhaps better FPS ? 

Anyways , I don't mind to try ! What "timer driver" and where to downlaod it ? Instructions on how to install that driver ? Thanks.

P.S. I'm curious why do we need a timer driver for Nvidia drivers ? Yes , I read they may have timing troubles after 347.88 on certain systems . Is this the reason ?

And I'm assuming it works only with the ex-kernel installed.

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.
 

18 hours ago, D.Draker said:

Also , what did you do to the DX diagnostins so it finally reports the right amount of VRAM ? Mine still says I have 2.5GB of VRAM on a 12GB card  , lol. I even have some games run into troubles . They simply won't utilize more than the amount which is reported by the DX tool.

I did not do anything. The memory listed is the GPU memory (1 GB) + shared system memory (3 GB).

Link to comment
Share on other sites

18 hours ago, D.Draker said:

Well , I figured out what's at fault here . It's the newly released shell32.dll . If I replace it with the version from the kernel released on 26.10.2021, all is back to normal.

So I can use the newest kernel32 alond with the old shell (file date stamp is 05 December 2020) and all is fine in this case . Any chance this could be looked into ?

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

Link to comment
Share on other sites

9 hours ago, win32 said:

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

It's this file : shell32.dll

EDIT : This is the last one that works fine for me. Its newer version , not.

 

shell32.dll.png

Edited by D.Draker
Link to comment
Share on other sites

8 hours ago, win32 said:

I did not do anything. The memory listed is the GPU memory (1 GB) + shared system memory (3 GB).

Well , weird , I even tried with a card that has a much lesser VRAM pool (3GB vs 12GB). In this case GTX 780 TI , and it still says 2.5GB, look at the pic. please.

This time it gave me 100mb more , lol. On any card that has more than 4GB of own memory, not shared, it reports 2.6Gb of total VRAM. Ridiculous.

Screenshot_20220829.png

Link to comment
Share on other sites

9 hours ago, win32 said:

1 - There isn't. I am still missing a few functions to run 377.83.
2 - 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. 

1 - Oh , I see , you want only the ones that work without modding. As far as I know, in 373 only one function memcpy_s is missing in the original Vista. 

2 - I'd still like to test it apart from the kernel because there's a weird timing issue in the later drivers (after 377.xx branches). Some folks wrote it started even earlier,

but mosty with Haswell , esp. with core i7 "K" . The drivers can't properly switch between the power states. For example, the card gets stuck in this very low power state (P8)

and crashes when I launch any demanding game . This is a well known and decsribed problem, even without the modding , esp. on win7 systems and x79 - x99 boards.

https://www.reddit.com/r/nvidia/comments/303ow1/gtx980_tdr_crashing_and_recovering_at_random_not/

https://forums.evga.com/Atention-everyone-Driver-crashes-with-9709298092980ti92Titan-X-are-driver-related-m2350184.aspx

https://www.reddit.com/r/nvidia/comments/36x5ot/just_had_a_gpu_driver_crash_while_browsing_at/

https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/226944/im-just-desprate-now-every-driver-crashing/

https://www.nvidia.com/en-us/geforce/forums/geforce-graphics-cards/5/462208/nvlddmkmsys-tdr-error-watchdogsys-intelppmsys/?topicPage=6

I also had a crash with intelppmsys while testing any 4xx.xx modded drivers (info in the last link). So I decided to hold the horses in the tuturial. 4xx.xx delayed in my release for now.

Of course I'll test with new ex-kernel when you release it , just wanted to find the root cause .

So I thought that this precise timer could help a bit , maybe. 

Link to comment
Share on other sites

12 hours ago, D.Draker said:

2 - I'd still like to test it apart from the kernel because there's a weird timing issue in the later drivers (after 377.xx branches). Some folks wrote it started even earlier,

but mosty with Haswell , esp. with core i7 "K" . The drivers can't properly switch between the power states. For example, the card gets stuck in this very low power state (P8)

12 hours ago, D.Draker said:

So I thought that this precise timer could help a bit , maybe. 

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

Link to comment
Share on other sites

On 8/26/2022 at 4:58 PM, win32 said:

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

I replaced memcpy_s with memcpy in that driver and it worked absolutely fine without the use of any 3rd party drivers . I did that just out of curiosity . What am I missing ?

Link to comment
Share on other sites

3 hours ago, D.Draker said:

I replaced memcpy_s with memcpy in that driver and it worked absolutely fine without the use of any 3rd party drivers . I did that just out of curiosity . What am I missing ?

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.

Link to comment
Share on other sites

2 hours ago, win32 said:

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.

373.06 doesn't have that function and you wrote that some mysterious timer helped you to run it . You mean you changed it like I wrote in my tutorial ? 

This worked for me: KeQueryMaximumProcessorCount , on both , Kabylake and a very old board with x3470. On all drivers up to 377.83 .

Later ones , no. Oh , and 32 bit still doesn't work at all  , even with 373.06.

 
Link to comment
Share on other sites

3 hours ago, D.Draker said:

373.06 doesn't have that function and you wrote that some mysterious timer helped you to run it . You mean you changed it like I wrote in my tutorial ? 

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.

Link to comment
Share on other sites

13 hours ago, win32 said:

1 - 373.06 does call memcpy_s.

2 - I did not modify the GPU driver;

3 - 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.

4 - 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.

1 - Earlier you wrote that "seems like" it doesn't .

2 - I got that right from the start.

3 - A very wise decision , I like it very much.

4 - Did you try the earlier ones ? Like 376.11 , 376.84 ?

BTW , I expected something like this on the processors with fake cores and we discussed it my thread. All of my CPUs don't have fake cores.

Or even if some of them have , I turn them OFF in the BIOS. The stupid fake HT nonsense only makes troubles anyways.

Link to comment
Share on other sites

@win32, what is your opinion of HPET ? Can it help ?

"I use this option since Vista days and it never caused any issues at 90-150us, actually it helped with X-FI drivers, if i used 2MHz (HPET off) i got some 250-350us spikes time to time"

https://forums.guru3d.com/threads/another-look-at-hpet-high-precision-event-timer.368604/

BTW , bcdedit /set useplatformclock true doesn't work for me. Is there another command ?

https://www.neowin.net/forum/topic/1075781-tweak-enable-hpet-in-bios-and-os-for-better-performance-and-fps/

 
Link to comment
Share on other sites

steam kinda works but it can't connect to the server to update 
if you copy the steam directory from a pc that has it already you can launch it in offline mode (assuming that you are logged in but still can't launch anything because "it's not installed")

Edited by winvispixp
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...