Leaderboard

I will work on modding 372.70 usermode components. I just looked at nvd3dumx.dll (D3D usermode driver for x64 components) and I found this suspect code: .text:00000001806B94AF mov cs:VersionInformation.dwOSVersionInfoSize, 11Ch .text:00000001806B94B9 mov cs:VersionInformation.dwMajorVersion, 6 .text:00000001806B94C3 mov cs:VersionInformation.dwMinorVersion, 1 .text:00000001806B94CD mov cs:VersionInformation.wServicePackMajor, r15w .text:00000001806B94D5 call cs:VerifyVersionInfoW So it is actively checking for NT 6.1. No doubt these changes will have to be done for later usermode components. UPDATE: and so does 365.19. So I'll have to check other files.

To prevent user confusion, I strongly recommend disregarding the tutorials and contacting me directly instead about the extended kernel. The original post was removed as it was continuing to confuse users. There will be further discussion about the evolution of the extended kernel in the coming pages.

Hm, I think you're out of luck on this one, but you can still try Snappy Driver Installer which might get the gpu drivers running. https://sdi-tool.org/download/ It's 21gb large, DriverPack doesn't work on vista so you have to use SDI Inform me if SDI installs the drivers correctly, run the windows experience index after installing the gpu drivers, then wait for it to finish the benchmarks. You should get Aero Glass and other Aero effects if it's 3+ EDIT: Yeah, might be the reason. Still, give it a try, might work although it might have to use an engineering sample

Any chance you'd also take a look at AMD drivers? They stopped working in mid-2015 when they changed driver branches (introduced with the RX 300 series: https://www.guru3d.com/files-details/amd-catalyst-15-15-download.html).

--

bloons td6 works on vista extended krnl (It's a steam game)

Works as not advertised. No bearing of KB4474419 and KB4490628 on the August 2020 SHA-1 endpoint retirement, and no bearing of the August 2020 SHA-1 endpoint retirement on Windows 7 SP1.

@dencorso: You probably missed reading ... and the 3 following posts (exchange between me and @Vistapocalypse ), especially this: Historical progression of facts: 1. WD/MSE on Vista stopped being update-able directly from Windows Update (or via their integrated [manually] "Check for Updates" feature [which also evokes WU]) in the start of July 2019, when Microsoft changed the WU delivery infra to employ only SHA-2 endpoints (the SHA-1 ones were still on-line at the time...) 2. WD/MSE users on Vista had to turn to manually fetching files (for 32-bit OSes) mpas-fe.exe/mpam-fe.exe and running those to get the definitions of their M$ antispyware/antimalware "solution" up-to-date; these standalone files (links of which can be found on http://www.microsoft.com/en-us/wdsi/defenderupdates ) were, at the time, still dual-signed (i.e. both SHA-1+SHA-2 code signatures), so running them and installing updated defs was working.... 3. Towards the middle of October 2019, M$ stopped dual-signing those files (as well as their "ingredient" files), updated versions came as only SHA-2 signed; while running an SHA-2 only signed file is not necessarily a problem on Vista SP2 patched fully until its EOS (April 2017), it is in this case because the security app/OS has to verify the integrity of both the engine and updated definitions, before installing/integrating them... Without SHA-2 support in the OS, definitions for both WD/MSE would stay at their last dual-signed version and become stale in a few days... For posterity, the last dual-signed version of the off-line updaters was v1.303.1946.0, sharing the same mpengine.dll v1.1.16400.2 ... 4. To overcome [3], Vista SP2 users had to manually download and apply some KBs, targeting Vista's Server counterpart, WS2008, which bring SHA-2 support to the Vista OS; with that implemented, mpas-fe.exe/mpam-fe.exe [SHA-2 only] could properly update off-line their respective M$ security apps... NB: While the finer details were not very clear then, installing those SHA-2 enabling M$ updates on Vista has the following shortcomings: 4.1. Vista's Windows Update Agent (wuaueng.dll) is not being updated to its SHA-2 compatible version (M$ made it sure, via checks, that only the supported WS2008 SKUs got that privileged treatment, not poor EoS'ed Vista , despite them both sharing NT 6.0) , so connection to the new SHA-2 only Windows Update endpoints was/is not feasible; hence, WD/MSE could not connect to WU and be updated, again, via that route (as in the era before July 2019) ... 4.2. Vista's build number is changed to 6.0.6003 (SP2 = 6.0.6002) and that fact by itself made the WU SHA-1 endpoints give it the cold shoulder (this is OT in this discussion, but if available dual-signed Vista updates were not installed prior to the migration to SHA-2 support, these would no longer be offered via WU[SHA-1] 5. On the first week of August 2020, M$, as announced, shut down permanently their WU SHA-1 endpoints, cutting off completely Vista SP2 (with/without SHA-2 enabled support) and, I'm sure you know already, WinXP This had, of course, no bearing on either WD/MSE on Vista, but is at least related to this thread's title... 6. Closing in on recent times, v1.321.xxxx.0 was/is the last Vista compatible series of offline security updates (i.e. files mpas-fe.exe for WD & mpam-fe.exe for MSE); that series introduced engine file (common for both installers) mpengine.dll v1.1.17300.4; the last version in that series was 1.321.2290.0, released on Aug 28th 2020: Next series of off-line installers,1.323.xxxx.0, introduced new engine version 1.1.17300.5, but that one is no longer compatible with Vista/NT6.0: So Vista SP2 (with SHA-2 support installed) users of either WD/MSE can't manually update their definitions past v1.321.2290.0 (close to a month stale as it is...) M$ continue to advertise on their "Security Intelligence" () portal that they offer off-line updaters for "Windows Defender in Windows 7 and Windows Vista", and in fact I have sent them feedback informing them of the current predicament Vista users find themselves in, but they have yet to respond to my report... BTW, next series v1.325.xxxx.0 is closing in... PS1: There have been reservations expressed by members here, notably @Vistapocalypse, about the efficacy of running Vista's native WD or a considerably old, nag-free, version of MSE on Vista, and probably with good justification ... But this is NOT the gist of this post; so please refrain from such remarks here... PS2: As of this writing, I have employed a "hack" to keep updating my WD with defs past Aug 28th, which essentially boils down to keep using the last compatible engine, v1.1.17300.4, with definitions (files *.vdm) prepared for the non-compatible engine 1.1.17300.5; for now, it seems to just work; but the two engine versions are close enough/similar; I bet when a future engine version is released, say 1.1.19xxx.0, the new definition files it will come with won't be backwards compatible with v1.1.17300.4 - it'll then be GAME OVER! PS3: I haven't yet jumped into @win32's Extended Kernel, especially since I'm on a physical machine (so not on a VM I can experiment with), but also because I am on 32-bit, which presents special challenges towards the ExtKernel goal... If @win32 has already implemented TryAcquireSRWLockExclusive in his kernel32.dll wrapper, then that would be the ultimate solution for Vista users wanting to keep their WD/MSE installation updated with current definitions/engine! PS4: A new project has come to light (first mentioned here by @burd ) that restores WU[SHA-2] support to Vista SP2 past last August's breakage; the legality of that project is still unclear; also unclear is whether WU connection is being restored to either WD/MSE, so that the apps could (again) download updated definitions directly from WU (Vista Extended Kernel would be required for successful installation...). I guess that's it!

Who the hell cares, its a few £/$ via Paypal, your not buying house or a car.

AMD 785g, Onboard LAN working, in windows ME. USB2.0 ports, PS/2 ports, pci and pcie slots. onboard SATA kinda works (in IDE mode it runs in msdos compatibility mode as a generic storage controller) fix with promise ATA133 pci card and PATA IDE ATA133 SSD. onboard video is sufficient for setup (16 color 640x480) (Fix with X300 series pcie or PCi 7000) onboard audio is hdac97, so fix with soundblaster pci. (DO NOT connect cdrom to the ATA133 PCI card, except during initial install. it slows the card terribly and will horribly bottleneck the SSD.) Complete the install then disconnect cdrom, connect a wireless AC to gigabit ethernet bridge to the LAN port with a length of cat6, and install all updates and hotfixes, then install a usb DVD drive to have a working optical drive. Disable onboard gpu and AC97 hdaudio in bios to free up IRQ's, make sure boot mode is set to legacy BIOS only, and install only a single 1gb stick (or 512m if anyone makes one) of ddr3. use an OPTERON CPU. A FX series chip might work but have not tested that. I only tested this with an Opteron 3380 as I have water cooling and it is a real pain to take it all off and unmount the mb just to swap cpu's. Limit memory with setup switches as usual, then edit system INI appropriately once install is complete. make sure all usb controllers are set to legacy usb support, and 2,0 mode with 1.1 compatibility fallback enabled. use a DVI converter to get HDMI out from the card's DVI port. (video only no audio) and connect external speakers to the soundblaster PCI card. what doesnt work: USB3.0, HDac97 audio, onboard Radeon HD8xxx graphics (except basic 16 color mode) R9 390x (replaced it with PCIe x300 series) SATAIII (set to IDE mode it sort of works, generic IDE controller in msdos compatibility mode). Cool and Quiet. (Use K8 powernow driver to get it working). and of course, only one core is used.