win32 Posted September 25, 2020 Author Share Posted September 25, 2020 (edited) 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. Edited September 25, 2020 by win32 5 Link to comment Share on other sites More sharing options...
asdf2345 Posted September 25, 2020 Share Posted September 25, 2020 2 minutes ago, win32 said: 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. 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. Is it only RTLQueryPerformanceCounter, or are there other functions? 298KB looks big for just one function. Does the application need to be modified to query RtlQueryPerformanceCounter from ntext.dll? I don't see any other modded files that could redirect the function to ntext.dll. Also, although I doubt there are any AMD64 SSE1 processors, what makes SSE2 a requirement? Link to comment Share on other sites More sharing options...
win32 Posted September 25, 2020 Author Share Posted September 25, 2020 (edited) 17 minutes ago, asdf2345 said: Is it only RTLQueryPerformanceCounter, or are there other functions? 298KB looks big for just one function. Does the application need to be modified to query RtlQueryPerformanceCounter from ntext.dll? I don't see any other modded files that could redirect the function to ntext.dll. Also, although I doubt there are any AMD64 SSE1 processors, what makes SSE2 a requirement? 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. Edited September 25, 2020 by win32 5 Link to comment Share on other sites More sharing options...
tamarindojuice Posted September 26, 2020 Share Posted September 26, 2020 (edited) -- Edited December 7, 2020 by tamarindojuice Link to comment Share on other sites More sharing options...
burd Posted September 26, 2020 Share Posted September 26, 2020 @win32 i see ntext in the folder , is it usable currently or just there incomplete and how would one get it to work? Link to comment Share on other sites More sharing options...
win32 Posted September 26, 2020 Author Share Posted September 26, 2020 38 minutes ago, burd said: @win32 i see ntext in the folder , is it usable currently or just there incomplete and how would one get it to work? It's perfectly usable. To use it, just do something like this: On 9/25/2020 at 10:45 AM, win32 said: 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. The next kernel32 update will call ntext instead of ntdll as well. 2 Link to comment Share on other sites More sharing options...
dr_st Posted September 27, 2020 Share Posted September 27, 2020 This is a wonderful project. I want to see it succeed. So far the extensions are for Kernel32.dll and Ntdll.dll, right? I wonder if the same principles can be applied in extending the functionality of other system DLLs. For example, the Win7 version of Schannel supports quite a bit more ciphers, which will become more and more important down the road (some servers already reject any TLS ciphers that are SHA1). I don't know if the required functionality is in Schannel itself, or one of the DLLs it uses. 1 Link to comment Share on other sites More sharing options...
win32 Posted September 27, 2020 Author Share Posted September 27, 2020 18 minutes ago, dr_st said: So far the extensions are for Kernel32.dll and Ntdll.dll, right? I wonder if the same principles can be applied in extending the functionality of other system DLLs. For example, the Win7 version of Schannel supports quite a bit more ciphers, which will become more and more important down the road (some servers already reject any TLS ciphers that are SHA1). I don't know if the required functionality is in Schannel itself, or one of the DLLs it uses. 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. 3 Link to comment Share on other sites More sharing options...
25495k Posted September 27, 2020 Share Posted September 27, 2020 27 minutes ago, win32 said: 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. is there a download link ? Link to comment Share on other sites More sharing options...
oldhardwareandsoftwaremustlive Posted September 28, 2020 Share Posted September 28, 2020 If this extends the kernel of Vista so that it would run windows 7 programs would that mean that drivers would work too? (ex. GTX 1660 Win7 driver on vista) Link to comment Share on other sites More sharing options...
win32 Posted September 28, 2020 Author Share Posted September 28, 2020 20 minutes ago, oldhardwareandsoftwaremustlive said: If this extends the kernel of Vista so that it would run windows 7 programs would that mean that drivers would work too? (ex. GTX 1660 Win7 driver on vista) 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. 1 Link to comment Share on other sites More sharing options...
burd Posted September 29, 2020 Share Posted September 29, 2020 9 hours ago, win32 said: 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. could the old drivers 368.XX - 372.70 be fixed easily? compared to the 400.XX drivers? Even an old fully functional driver could help , currently applications and many games crash with nvwgf2umx.dll error specifically and with DirectX and Vulkan both broken and Opengl not supporting many low tier apps its hard to do much especially on Pascal. Link to comment Share on other sites More sharing options...
win32 Posted September 29, 2020 Author Share Posted September 29, 2020 26 minutes ago, burd said: could the old drivers 368.XX - 372.70 be fixed easily? compared to the 400.XX drivers? Even an old fully functional driver could help , currently applications and many games crash with nvwgf2umx.dll error specifically and with DirectX and Vulkan both broken and Opengl not supporting many low tier apps its hard to do much especially on Pascal. 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. Link to comment Share on other sites More sharing options...
burd Posted September 29, 2020 Share Posted September 29, 2020 (edited) 3 hours ago, win32 said: 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). It didnt start with your files the drivers are just broken on vista , your files dont fix those errors , there are many instances where i get this error , IE9 64bit , Steam games , sometimes in windows score assessment (winsat i think) , All of them 64bit , 32bit dxdiag works fine , while 64bit crashes https://imgur.com/a/fnYuj2c one thing to note is that , the steam games would just crash without your modified files , but with it , it would probably run with proper drivers since it crashes on the nvidia D3D10 dll now. Edited September 29, 2020 by burd 1 Link to comment Share on other sites More sharing options...
asdf2345 Posted September 29, 2020 Share Posted September 29, 2020 17 hours ago, win32 said: 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. It's probably more worth it to look at the 382.33 drivers, as that supports all the way from the GT 1030 to the GTX 1080 Ti Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now