win32

what files and offset are mentioned in the error dialog? I'm on 2012R2 right now.

This modification would change the 2 to a 4. I presume this blocks NT 6.2 and everything above it. Windows 10 wouldn't need this file due to native DX12 binaries.

I found a version block for Windows 8/8.1 in the file, but nothing for Vista. So I think the D3D parts of 368.xx/372.70 are like this: 900 series and below: works on Vista as with old drivers Pascal support added in these new drivers that have no official Vista support, so no workie on Vista Drivers have specific Windows 7 directives, so Pascal probably works when Windows 7 directives are in force. So I think that once I can get the drivers to use the Windows 7 directives, that may be enough to get D3D working as good as Windows 7. Possibly including 12 unless DXGI does not cooperate.

Or, if you want to use the original d3d12.dll, I found a check for Windows 8 in here: .text:000000018000622C mov [rsp+270h+VersionInformation.dwMajorVersion], 6 .text:0000000180006234 mov r8, rax ; dwlConditionMask .text:0000000180006237 mov [rsp+270h+VersionInformation.dwMinorVersion], 2 .text:000000018000623F lea rcx, [rsp+270h+VersionInformation] ; lpVersionInformation .text:0000000180006244 mov [rbp+170h+VersionInformation.wServicePackMajor], bx .text:0000000180006248 call cs:VerifyVersionInfoW .text:000000018000624E test eax, eax .text:0000000180006250 jnz short loc_1800062B7 In an hex editor, look for the sequence 06 00 00 00 4C 8B C0 C7 44 24 38 02 00 00 00 48. Change it to 06 00 00 00 4C 8B C0 C7 44 24 38 04 00 00 00 48.

Shouldn't be hard, as the DX11 components are equivalent if not more comprehensive on 8.x than 7, and 7/8.x users usually use the same drivers:

Maybe, but the older Vista DX Graphics Kernel may get in the way (hopefully not, and if so, I hope that expanded ntoskrnl will eventually bring the W7 version to Vista). Apparently they have specific blocks for 8.x too. I just need a copy and I'll look at it.

Yes, the leaked 2000 SP1 source code. But it wouldn't be a great idea to mess around with it and only about 15% of the entire source code leaked. But someone made a functioning open source kernel32.dll. There are more details about it in his PE Tool thread: Ximonite is basing his win2k stuff around WB's files, so maybe he could take this further. But it does depend on his skillset, which is unknown to me. I don't really know C++, just enough assembly to aggressively patch stuff, which doesn't need source code of course. And then one could advance to creating FOSS versions of other win2k components like ntdll, user32, the HALs, etc. And then go even further by adding desktop composition support, newer DirectX support (or resort to WineD3D or DXVK) etc. These could also be compiled for x64, and we could build a WOW64 framework to go along with that. Maybe embrace .wim-based installs too. Though it will take a very long time for one guy to rebuild the whole OS. There were a solid thousand (probably more) working on Windows 2000 which took over 3 years to make, with 1 billion USD in development costs. To make reasonable progress in reasonable time, this would have to become a dayjob, but how would we able to cover the costs of daily expenses and testing hardware? I wish I were 8-way SMP-capable. One CPU would work on extending Vista, one works on Windows 2000, another one on Server 2003, NT4, Windows 7, one actively learns C (moving on to other things once I'm done of course), one learns C++ (same as before), while the last one does the normal daily tasks expected of a person.

Well, Windows 2000 is probably the only OS with updated browsers that doesn't swap when browsing on 512 MB of RAM. Even modern light Linux distros and a standard XP/2003 (not sure about a heavily nLited one) can't manage that.

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.

The incompatibilities are probably incremental. First, official Vista support was dropped after 365.19. Then the user mode DX part of drivers (365.19, 372.70] does not export missing functions, but fails on the officially unsupported NT 6.0. Then 372.90 introduces some missing functions. And the latest W7 ones have like 40 missing functions! The user mode issues, if not corrected, would probably persist once the kernel mode parts of later drivers are fixed. Hopefully the user-mode fix will be applicable to those 382.33 drivers as well as later ones.

did this start with my modified files? If there's an error, please tell me more (is it the same one that occurs with winSAT? if so, maybe an update to ntext could help). I'll look at the 372.70 files (though this is my busy week, I'm now split between semi-free and busy weeks until December). I think something could be done directly about those if I find they version check and discriminate right in those files, like the newer drivers on old Windows 10 releases.

Drivers will take awhile (need to really extend ntoskrnl/ntrknlmp), especially newer NVIDIA drivers that are needed for RTX and GTX 16xx. I'll have to add like 40 functions for the 41x drivers. Some are very complex and there is no guarantee of stability.

So far, the following x64 DLLs have been extended: kernel32.dll dwmapi.dll ntdll.dll (wrapper, named ntext.dll) ole32.dll shell32.dll user32.dll uxtheme.dll As a result, Windows Media Foundation from Windows 7 Platform Update was successfully transplanted. The same could be done for Windows 7's crypto binaries. Based on something I did for Windows 2000, you will have take into account the associated binaries like crypt32 and secur32, and possibly dssenh.dll.

It's perfectly usable. To use it, just do something like this: The next kernel32 update will call ntext instead of ntdll as well.

I think it's KB951748-v2 (can't find a KB957579 for Windows 2000). You can get it here: http://download.windowsupdate.com/msdownload/update/software/secu/2009/11/windows2000-kb951748-v2-x86-enu_0fcfe0691a771a95e39538b99cc28442c08e0efa.exe

No links to or snippets of the code are actually published in this thread or the news article. So it's fine. It would be frowned upon to do anything with this code around these parts, but I'd think maybe some NT4/win2k modder could see some value in this (moreso NT4 than W2K for the reasons Dibya said). But if we keep disassembling the binaries for the newer OSes we could hit a jackpot...

Yes, I did implement it. And it should be one of the few stable functions, as it doesn't call outdated ntdll functions that others do (banking on ntext x86 to fix that though!). Though you don't have to replace your main kernel32.dll in this case. The addition of a string to the registry and a .local file in the Windows Defender folder along with my kernel32 should suffice.

https://www.bleepingcomputer.com/news/microsoft/the-windows-xp-source-code-was-allegedly-leaked-online/ XP SP1 and 2003 RTM. Some AMD64 stuff in there as well (six months before the Athlon 64 came out!). Circulating underground for several years, but has now surfaced. Note: if the AMD64 code (though most of it seems to be platform agnostic, except for obvious stuff like ASM) for many ntdll functions is the same as it is in 2003 x64 SP2, then you have a bit of Vista/7 x64 code to play with as well, based on my disassembly. So I guess we'll all have to shield ourselves from an onslaught of new exploits.

All ~1810 functions in Vista's ntdll are exported from ntext and then forwarded to ntdll. Then I added a large code section to house RtlQueryPerformanceCounter and future functions. Only applications that call RtlQueryPerformanceCounter need to use this wrapper ATM. You can go into CFF Explorer -> Import Directory and change the entry for ntdll.dll under the "Module Name" column to ntext.dll. That can also be done with a hex editor, as the only likely reference to ntdll in the application would be in the import/delay load import tables. I just decided to compile it with the SSE2 switch. the best that VC++ offers (though it may not do much for a wrapper DLL, admittedly). Since most Windows 7+ applications probably need SSE2 to begin with, I don't see much harm in this decision.

I compiled the NTEXT wrappers. SSE2 required. Note: the linkout.pl script makes an assumption that VC++ adds an extra underscore to functions that start with one. That is not true with VC++ 9, so such functions had one too many underscore for me. Though VC++ 6-8 may be different... The wrappers can be imported in place of ntdll.dll. New releases of kernel32.dll will refer to ntext instead of ntdll. The x64 ntext.dll has a modified RtlQueryPerformanceCounter, and it works good with Firefox 80. But there is a significant issue with the function in its unmodified form; it appears that any call to ntdll functions causes a "privileged instruction" error. So instead of calling the export-forwarded ZwQueryPerformanceCounter, I placed it directly in my dll as a subroutine and that fixed it. The x86 wrapper will need a little extra work since x86 ntdll is much farther behind W7 than the x64 ones.

I do think that needs to be done, specifically for vmx86.sys. I don't have version 15 handy, but the file from version 16 is missing a lot of functions (an ntoskrnl update should fix that, but it will take awhile for that to be done). And there's the VMware Authorization Service issue which also needs to be dealt with somehow.

I think they're fixable, but they may take some time. I need to analyze those files I mentioned, but only after I clear out the registry of existing VMware references since I have an older install of Player that went awry (even running an installer causes a crash!).

VMware Authorization Service (vmware-authd.exe) failed to start, right? And I'd also be surprised if the drivers like vmx86.sys are still compatible at this stage. I'd check them all with Dependency Walker.

I tracked down the Perl script that effectively automates the process of making wrapper DLLs, especially for DLLs like ntdll which exports over 1800 functions: http://web.archive.org/web/20070526114542/http://www.craigheffner.com/security/linkout.txt This will prove essential for Vista and any future work for 7. And maybe even more so for 8.x and 10. Though ActivePerl 5.26's installer errored out with this: (0x80004005) the specified application is not a valid application for this OS platform. Indeed, Windows Installer definitely knows it's "running" on 6.1.7601 SP1 based on the error log. I found the executable for the "state tool" and it had a subsystem version of 6.1, so that may have been the reason for the error, so perhaps I will follow BWC and disable the subsystem version testing like he did, after all (which will only work with system32 file replacement). And just use Strawberry Perl anyway; it seems to work far better with Vista. On another note, it appears that a new hack in my ntoskrnl (not released yet) to prevent it from changing CurrentVersion from NT 6.1 to 6.0 in the registry has fixed some OS functionality. When I added CoGetApartmentType to ole32.dll, I could no longer modify Sidebar widgets nor open folders with downloaded files through browsers. But I can do that with my modified ole32 once CurrentVersion is changed permanently. But not everything thinks it's on NT 6.1 yet (like RtlGetVersion), which is still a big problem that no one has solved since it arose in 2005. Windows compatibility mode will not solve it.

Well, technically we aren't using their branding anymore since they just abandoned what we're using now. We now have a different product to theirs with different branding, which is most of what they wanted. Though there may still be some sort of trademark attached to their old branding. And Serpent isn't resolved though I don't think they are too pleased about us brand leeches either way (either we piggyback on their current unofficial branding or simply seize/gift ourselves their old branding). And New Moon could still evoke memories of Pale Moon (for an unfortunate few anyway).