win32

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

The 32 bit part of it is very broken now. I am trying to fix it. However, I consider the new 64 bit enhancements to be finished.

Firefox nightly (and some beta builds) have had this issue since version 93. It is always corrected in time for the late betas (b7-b9) and the general release. I haven't been able to track it down.

Some of these are implemented, on both 32 and 64 bit. But GetThreadErrorMode and GetMaximumProcessorCount are indeed lacking from at least one of the platforms. GetLogicalProcessorInformationEx is somewhat buggy as well, but it has been fixed for a yet to be released update. This update will also simplify the version spoofing to remove the "VerFix/FirefoxFix" switches. You can simply use the regular MajorVersion/MinorVersion/BuildNumber values for the applications that would have used them.

I just made a wrapper for kernel32, which called itself kernel32.dll, with the original kernel32 renamed to something else. The benefit of this method is that the original kernel32 is not modified and thus does not change in size, so no rebasing is required. But you would have to know how to use VC++ or a similar IDE (but with VC++ and x86 code, you can very easily do inline assembly). You will have to export every function the original kernel32 does, and forward it to the original kernel32 (renamed "kernel33" or something similar). To accelerate the process, I wrote an application called "scanexp" (which should run on NT 3.51/95 and up) that scans a list of function names (as in the type of list you would get if you ctrl-a a dll's function list in dependency walker then copied into a txt file) and turns them into pragma directives indicating that they are export forwards. Dependency Walker doesn't grab ordinal-only exports as easily, but if you manually input the numbers they will be enumerated properly as well. Usage is as follows: -name of text file with function names -name of c/cpp file you want to make with the pragma directives -name of file to export forward to

UserBenchmark component UBMSkillBench.exe now calls CreateFile2, but it doesn't seem to affect the ability to perform the benchmarking process, for now anyway. But just in case, I wrote this out: HANDLE CreateFile2(LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationDisposition, LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams) /* win32 - March 17 2022 Tonight, I noticed UserBenchmark calling this Windows 8 function. I'm not sure what the point is of this function; the documentation page says a lot about UWP usage, and a few extra flags which CreateFileW may be also be able to use on later OSes. */ { if(!pCreateExParams) return CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, NULL, dwCreationDisposition, 0, NULL); return CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, pCreateExParams->lpSecurityAttributes, dwCreationDisposition, pCreateExParams->dwFileAttributes | pCreateExParams->dwFileFlags | pCreateExParams->dwSecurityQosFlags, hTemplateFile); }

The latest ones should be working with extended kernel. In fact, I got the Visual C++ 2022 compiler/linker working on Vista with an older IDE: Yes, the compiled applications link against the supplied VC++ runtime and the signatures of this runtime like the padding with int 3/CC are evident if you look at the resulting code in a hex editor. I warn people trying to compile for x86 (and especially if TEB/PEB is involved) that there are some optimization issues. None of the optimization switches work to fix that problem.

If this is what I think it is (NT 4), then I think it may not be possible to generate a dump early in boot. I could not in Vista when it was time to initialize ntdll as well. If you bugcheck early enough, no text will be printed on screen except for the four bug check parameters.

I was always told that NT4 was exceptionally tough. I'm not even sure if the approaches we use for 2000 and Vista are applicable here. I used wrappers written in C for NT4 over kernel32. But that is a very touchy subject because of the potential sources of "inspiration" for the wrapper code.

If it doesn't boot, then you might have to consider doing that.

Yes, Northern Canada got off this very lightly relative to southern areas, especially far northern Quebec, NWT and Nunavut. Unfortunately I live in the deep south of Canada.

Yes. But don't rebuild the PE header. That doesn't work out as well. The checksum needs to be corrected every time the file is modified.

You can do it in CFF Explorer. Go to rebuilder, only check "Update Checksum", "Rebuild" then save.

Install NT 4 SP5 in a VM (better in a VM because you can take snapshots) or on a real PC and replace kernel32 with that one. I will remind you that the PE checksum must be corrected before using it or else you will bugcheck. And you cannot redistribute these files publicly in the forum.

Yes.

IDA Pro does not like to assemble things very well, so you will have to go into the hex view to modify the import calls. In x86, the import calls directly reference the memory address of the import table entry as opposed to an offset. So the hex codes for the import call instruction will be (in little-endian notation): FF 15 B8 C0 F3 77 Local function calls remain offset based, so you can just go to edit -> patch program -> assemble and type in "call 77f01762h".

You put the memory address of the function in the wrong place (00000040 is near the beginning of the file; not the end where .xdata is located). In IDA Pro you will notice two numbers on the status bar: The one on the left, 0005B840 is the offset memory address and the one that Export Table Tester uses, as well as hex editors. So that is where you want to put the address of the function. And then there are a few other concerns, especially with regards to the export table: if you do not move it to an empty space in the file, such as farther down as .xdata, with lots of expansion room, you may end up running into other code or data.

Imports are really hard to work with, if they are not there in the file already. There are a couple of things you can do. Either you get the imported function from the imported file and try implementing it in the target file, if it's simple. Or you take other import entries to simple functions, reimplement the simple functions in the file itself and rename the now unused import to the one you want. However, you have to make sure the new import name is not too long as the import names are packed together very close.

Rebuild the PE header? No. Just set the checksum but make sure you do not rebuild the header. Warning: LordPE silently rebuilds PE headers when a file is saved.

Completely rewriting kernel32 will prove very difficult. And IDA's pseudocode is not always compilable without other changes, and may be incorrect. But if you don't write anything in C, you can go into IDA, outline the entire function and go to "Edit -> export data". Then copy and paste that hex code into the target file, and find the starting address for the beginning of the hex code and then add an entry in the export table that references the starting address. After pasting in the new function, you will have to fix up the imports, function calls and data references to ensure that will work somewhat.

Those are stubs that I deprecated a long time ago. I now grab my code from newer versions of Windows using IDA pro or write my own (you can do it in C, then disassemble if you don't know asm well). SetThreadErrorMode calls RtlSetThreadErrorMode in ntdll. Perhaps you can call RtlSetThreadErrorMode locally by putting it in kernel32. K32GetModuleFileNameExA is the same as GetModuleFileNameExA in psapi.dll. In fact every function that starts with "K32" was originally in there. But I don't believe kernel32 can call psapi because psapi relies on kernel32.

Threads are started/loaded serially like all drivers.