win32

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.

The dislike counter has only briefly disappeared for me, about 5 days ago. Seems like they are doing A/B testing as usual. I do wonder if Invidious will continue to fetch them once the feature is actually removed from official YouTube clients.

There are too many missing functions to think about copying over the 6519 HAL. And there is another consideration to make. Several pointers to HAL functions are loaded into two dispatch tables in ntoskrnl at boot. These replace various stubs and other functions, and allow ntoskrnl (and other drivers) to call the HAL without explicitly importing the functions. The main TSC synchronization function is inserted into the table and called by various functions in ntoskrnl. I will have to check that out.

I believe I wrote about 6519, the first build of 7 x64 to have leaked in terms of a complete fix. There was a partial fix for Vista in that time (some of the timer discrepancies were fixed but not all). I am not sure which update introduced it, as the Server 2008 updates became cumulative rollups in the fall of 2018 and now that Kaby Lake laptop is in very poor shape.

The program specific overrides take precedence over global settings.