win32

You typed "GetConsoleWindow..txt" when it is "GetConsoleWindow.txt", That will not work. My intent for scanexp was to work for forwarding all the original exports to the original file when building a wrapper. To get all of them, you would have to go into dependency walker, open the original file, and CTRL-A on the lower table of function names, then right-click to do as shown here: Paste into the text file.

Nope. If you are referring to the hex changes, they simply refer to a "jump" in the code, which would jump over a check for NT 6.0, or ignore the check and go to the code that would run if NT 6.1 or higher was detected, instead of halting the initialization and returning an error code (which basically says "not supported").

What I meant to say is that some functions might be easier to stub on one architecture than the other. That function is not going to be available to the driver.

I thought about that again. KeQueryLogicalProcessorRelationship is very similar to GetLogicalProcessorInformationEx, and the stub for that function worked better on 32 bit than 64 bit applications. It might be the opposite here.

The original kernel32 would still exist, but it would be renamed to something else (i.e. kernel33). The new kernel32 still needs to export every function that the original kernel32 has, in addition to the new functions. And yes you can write as many functions in a .c/.cpp file as possible, but keep organization techniques in mind.

I see that EB 24 is from my x64 patching instructions for 376.11, while EB 0C is from x86. The difference is that the x64 patch would "jump" over more code than x86, but I think they should actually be equivalent, as the x86 and x64 compilers arranged the version checking code differently. I'm not sure about 94 51 / 33 07, as I don't seem to have encountered them. You could alternatively take the 74 0A next to the 84 C0 and make that EB 0A, but I am not sure if it would make a difference. I suspect there is a deeper issue on x86.

I do not have a good answer for the 32 bit driver issues. I presume that the same functions are called as on 64 bit, right? If so they should work equally as well, unless there was an obscure issue specific to the architecture (in the last XP x64 NVIDIA drivers, multi monitor capability is broken because of an signed 32 bit integer becoming a unsigned 64 bit integer, iirc).

For 376.11 x86, the version check can be bypassed by finding the line: 53 FF D6 E8 86 97 4E FF 84 C0 74 0A B8 BB 00 00 Change it to this: 53 FF D6 E8 86 97 4E FF EB 0C 74 0A B8 BB 00 00 376.53 is very similar: 53 FF D6 E8 82 55 4E FF 84 C0 74 0A B8 BB 00 00 to 53 FF D6 E8 82 55 4E FF EB 0C 74 0A B8 BB 00 00

Thank you all for your feedback. It does appear that I left out quotation marks in my calls to icacls. And as for the issues with backup restoration, I had originally built the feature around the ability to restore an unbootable system, which is why it requests that you input the Windows folder path. As such it can restore any file not loaded into memory quite easily. As for situations where the backup runs online, it is tougher. The MOVEFILE_DELAY_UNTIL_REBOOT flag in MoveFileEx would not be suitable, as ntoskrnl would be loaded when that would take effect. Perhaps the files in memory can be moved somewhere else before moving the backups. A scheduled task-executable could delete the folder containing these files at next boot.

I believe this particular issue happens on all Vista. A lot of the breakage that has occurred is attributed to ChangeWindowMessageFilterEx; looks like it will have to be looked over quite heavily.

I meant compilers and linkers themselves. Clang works now, which is important for the MozillaBuild toolchain. Many functions were added on the WOW64 side, including kernel32, ole32, shell32, user32, dwmapi, uxtheme and powrprof. However there seem to be issues with some of them, that testers did not discover at first.

The first one will definitely be easier to add than the second. The second actually is implemented in ntoskrnl (in the official version), and there are a few ways of handling it differently. GetThreadErrorMode will be even easier to implement than either of those. And also, I found through a bit of experimentation that several of the functions are failing because the stub dll must be explicitly loaded into memory before it can be used. But the system procedures for verifying that the dll is available are quite lax. If the dll is missing altogether, it will give an error stating the function entry point is missing like usual. But if the dll is physically there but not loaded into memory, it "works" but as soon as you try calling the function, it fails due to a null pointer. So there will have to be some major adjustments to each (32 bit) DLL to confirm that the dll is loaded into memory beforehand. This issue did not seem apparent to me when testing started months ago and 32 bit applications like SeaMonkey started to work. I would have thought that whatever resolved the memory addresses for the functions would check to see that an available dll (as the name is available in the export table) was loaded before trying to call it.

K32GetModuleInformation on x64 only. This release was mostly about fixing bugs and bringing WOW64/x86 up to x64 functionality (more x86 DLLs available than before, but that is not 100% yet either).

I released a new extended kernel. "FirefoxFix" and "SuperVerFix" are removed from osver.ini. You can use BuildNumber=7600 for Firefox instead, and use the regular version spoofing in other places too where those options would have been used previously. CPU-Z (and other hardware verification software) works again, as does PCSX2 (x86 versions; the newer x64 native builds are still a ways to go, due to reliance on DX 11.3 runtime) and some newer compilers/linkers should work too. A new installer is also used, which lacks the path issues of the previous one. It has a built-in backup facility, and the installer can restore backups from another OS install or a PE environment by specifying the path of the Windows directory of your Vista install. It can be obtained through all the known channels.

First instinct tells me that they did something to win32k that doesn't work so good for you. What happens if you try installing without GPU drivers or in safe mode? Maybe it is best to stick to a 2021 win32k, because late 6002 era win32ks are not the most stable either; they can cause the system to crash if you close Firefox windows. I believe this happens if they are not maximized. This happened on both my main workstation with a Quadro FX 3800 and a laptop with Intel HD Graphics 3000. That 6.0 section is probably a big void. Hopefully I can get a stable ntoskrnl extension regime going, but I won't be able to do much for now.

In other news, I am getting a GTX 650, which seems to work with every NT 6 GPU driver made up until the end of support, so I will be able to test new drivers on my own soon, and provide my own patching instructions, as some of the possible patches are non-trivial to devise. However based on experiences with both Pascal (and RTX 3xxx on Windows 8.1), it seems that the ability for new drivers to work with old cards does not foretell their ability to run with new cards.

ksecdd.sys is in system32\drivers, unlike the two others. I presume the nvidia driver is not in system32\drivers, or it would be shown as present. You can adjust dependency walker's paths so it can look in system32\drivers as well.

Yes.

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

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

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

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

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

I think that there is a version check in the init procedure of the driver (.sys file) that returns, iirc, STATUS_NOT_SUPPORTED. memcpy_s and memcpy are not equivalent as memcpy_s has an extra parameter (buffer size) where a memory address should go. I have a few results from 375.63 and 372.90 on a GTX 1060. 375.63 had no DirectX acceleration available in dxdiag but Aero/DWM was working. 372.90 didn't have working Aero, but it did allow external monitor outputs to work, so it barely worked. I did patch those two to remove the version check, and I will probably patch the 376.11 for the version check and memcpy_s. I believe 38x and up do not do the version check for NT 6.0.

@Jakob99 I added those functions for x64 and wow64. But I haven't added memcpy_s to the publicly available ntoskrnl, because the GPU drivers tested with the ones that had the added functions had issues with DirectX. I wanted to fix that as well, and updating the DirectX kernel and watchdog.sys is required to update DirectX to Windows 7/8 level. watchdog.sys from Windows 7 should have worked on Vista, but it caused the system to boot with a blank screen (but working sounds), so the Vista version will have to be modified. I also have to update the NTFS driver. It lacks TRIM support and there is a bug that I identified with it that all other NTFS drivers seem to lack. But it should be encountered very rarely (NT 4's USB drivers seem to be involved).