Ximonite

Is there a reason why you suggested v10 of this update instead of v17?

Status Update: The first public beta of KernelXE R2 is out. I have been experiencing a very weird issue on my bare metal test system. Once KernelXE R2 is installed, explorer refuses to launch, but almost every program works completely fine. I also experience the same issue with Dependency Walker "generating errors" that win32 found in the original KernelXE with BWC files present, but there aren't BWC files present in my test machine. I have no idea what causes this kind of stuff to happen and I don't know if anyone else here on MSFN does either. Also, the .idata section that displays in IDA but isn't actually a section appears in the initial Public Beta 1, but not rv2.

I found the link to this update. http://download.microsoft.com/download/1/2/0/120BCFA4-DF31-4E0F-8739-935A4C69AF82/NDP1.1sp1-KB2604044-X86.exe

I have a PC with Vista running bare metal. CPU: AMD Ryzen 5 1500x (4 cores at 3.8GHz) (older AGESA so Vista works) 8GB RAM (2133MHz) GPU: 2 x NVIDIA GeForce GTS 450 (SLI) HDD: 250GB Seagate Barracuda (with Vista on it) SSD: Kingston A1000 240GB (with Windows 8.1 on it) MOBO: MSI B350 PC MATE Windows Vista Ultimate SP2 x64 (Boxed copy) It runs very well. Only struggle is that I need a DVD to get SP2 and the USB drivers on it.

It's my own Windows 2000 extended kernel. Since there are already 2 different extended kernels for Windows 2000 (not including mine) which have their own exclusive functions not found in the other, I made my own that includes everything from both existing extended kernels and a few extras. The main goal of KernelXE is to remove the problem of losing any exclusive functions of one extended kernel by choosing the other one. What I'm working on right now is the second release of KernelXE. The original KernelXE thread has information on what it is and this one will too once KernelXE R2 is released.

I feel like our K32* implementations are pretty good, since the decompiled code for both of ours are very similar to the Windows 7 functions. I wonder how NtQueryInformationProcess could be causing issues with shell32.SetCurrentProcessExplicitAppUserModelID, especially since the implementations I have seen don't even call NtQueryInformationProcess. Here is the one non-stub I have seen: mov eax, lpString test eax, eax jnz short loc1 push [esp+AppID] ; lpString call ds:lstrlenW inc eax add eax, eax push eax call ds:CoTaskMemAlloc mov lpString, eax push [esp+AppID] ; lpString2 push eax ; lpString1 call ds:lstrcpyW xor eax, eax retn 4 loc1: mov eax, 80004005h retn 4 lstrlenW and lstrcpyW from kernel32. CoTaskMemAlloc from ole32. lpString is a dword that is 0 in the file and only accessed by shell32.SetCurrentProcessExplicitAppUserModelID and shell32.GetCurrentProcessExplicitAppUserModelID SetCurrentProcessExplicitAppUserModelID.hex

Very weird that a Vista function would work on XP but not Vista. In NtQuerySystemInformation, there are jumptables that look very similar C++ switch statements (they probably are C++ switch statements in the source code). I noticed that in the Vista version, the first jumptable has 57 cases and the second one has 49 cases, but the 7 version has 63 cases in the first jumptable and 61 cases in the second jumptable. These may be the subparameters you are talking about. The hex rays decompiler displays names of what I assume are the subparameters you are talking about when decompiling your implementation of K32GetPeformanceInfo. This may be helpful. if ( InformationLength >= 0x38 ) { v4 = NtQuerySystemInformation(SystemBasicInformation, &SystemInformation, 0x2Cu, 0); if ( v4 >= 0 && (v4 = NtQuerySystemInformation(SystemPerformanceInformation, &v14, 0x148u, 0), v4 >= 0) && (v4 = NtQuerySystemInformation(SystemFileCacheInformation, &v21, 0x24u, 0), v4 >= 0) ) Status = NtQuerySystemInformation(SystemProcessInformation, hMem, InformationLengtha, &ResultLength); Now we just need to figure out which cases in the jumptables correspond with each subparameter, if that's even what the jumptables are for. Making wrappers for the new functions is a really good idea, especially now that Windows Update works on Vista again. I really hope that someone figures out a way to get ESU updates through Windows Update. The reason why I didn't try making wrappers for KernelXE R2 is because I don't have to worry about Microsoft updating basically any of the files. usp10.dll and gdiplus.dll are still updated by Microsoft, but I'm pretty sure those don't have any reason to be modified.

As long as the Office 2019 setup doesn't care about fResume always being 1, then the code I provided should be good enough. I don't remember where the code for my implementation of K32GetPeformanceInfo came from, but if it doesn't work, I'm planning to try out GetPeformanceInfo from One Core API because it works on XP. It does have a fairly big function chunk which will be annoying to reattach to the rest of the function. The K32 functions in KernelXE R2 came from many different places, including your x86 kernel32.dll, so there's a lot of potential for something to be wrong with my implementations. I also know for sure that there are many missing security patches in my implementations of basically everything. I get to look forward to going through 8 years of security patches and going through every change to every function and figuring out what goes where in the Windows 2000 files. That's going to be one hell of an experience for me and one huge benefit to people using Windows 2000. Are you planning to upgrade your extended kernel files to the latest ones from the Server 2008 ESU updates? That would be very helpful, but would become obsolete quickly. Feature support will stay the same though, since Server 2008 is only getting security updates now. Kinda unrelated, but do you know of any tools for adding relocations other than WildBill's PE Tool? I don't like how I have to wait about 10 seconds every time I add a relocation. I have heard that there is some tool out there that automatically finds and adds all the needed relocations to .reloc, but I don't know if it actually exists or not.

Speaking of DST updates, there was one in October 2019 that hasn't been made into a .reg file. Also, it would be nice if all the DST changes were in one .reg file so new people need to look back and find all of them.

If @TECHGEEK's WINWORD.EXE is x86, then it would be a good idea to see if SetWaitableTimerEx from KernelXE R2 is enough to make Word happy. It's not really a good implementation, but it's probably good enough for some programs. Here is an x64 implementation of SetWaitableTimerEx that is similar to the one in KernelXE R2: mov [rsp+pfnCompletionRoutine], r9 mov [rsp+lPeriod], r8d mov [rsp+lpDueTime], rdx mov [rsp+hTimer], rcx sub rsp, 38h mov [rsp+38h+fResume], 1 ; fResume mov rax, [rsp+38h+lpArgToCompletionRoutine] mov [rsp+38h+var_18], rax ; lpArgToCompletionRoutine mov r9, [rsp+38h+pfnCompletionRoutine] ; pfnCompletionRoutine mov r8d, [rsp+38h+lPeriod] ; lPeriod mov rdx, [rsp+38h+lpDueTime] ; lpDueTime mov rcx, [rsp+38h+hTimer] ; hTimer call SetWaitableTimer add rsp, 38h retn I attached the hex code for this function to save time just in case @win32 considers adding it to kernel32. SetWaitableTimerEx.hex

There is a native x64 version of Office 365.

This is something I have thought of doing in the future. I may spend a bit of time on it now and see what I can do.

I have not tested UMDF 1.0 on Windows 2000, but it is something I plan to test at some point. The next thing planned after KernelXE R2 is a feature pack update for Windows 2000. UMDF 1.0 is one of these components I plan to add to this feature pack update. For Windows 2000 updates, my main priority right now is KernelXE R2 and that will be my main priority until sometime (hopefully) early next year.

I remember you posting that link somewhere

My favorite company for each onboard device: Ethernet: Intel Audio: Realtek USB 3: ASMedia

Almost all of the code was taken from other files, and the code that wasn't was written in IDA. Yes, I actually wrote code in IDA.

Here is what I found right after the KiServiceTable: dword_472614 dd 0FBh ; DATA XREF: sub_55351A+FD↓r unk_472618 db 18h ; DATA XREF: sub_55351A+102↓o db 20h db 2Ch db 2Ch db 40h db 2Ch db 40h db 44h db 0Ch db 18h db 18h db 08h db 04h db 04h db 0Ch db 10h The dword value is the amount of entries in the KiServiceTable. The other values below (only the first 16 shown) are the amount of bytes popped from the stack at the end of each function.

Summary: For a long time, there have been 2 choices for extended kernels and both of them have their exclusives that aren't present in the other extended kernel. WildBill's extended kernel has many exclusive ntdll functions, SxS support, and a few exclusive functions in other files. BlackWingCat's extended kernel has many exclusive kernel32 functions (and some in other files). The big issue is that ntdll and kernel32 cannot be mixed, forcing people to choose between a better kernel32 or a better ntdll. The main goal of KernelXE is to eliminate this issue. ⚠️ This is beta software. Don't expect it to be stable. ⚠️ KernelXE Lite: KernelXE Lite is a smaller and reduced version of KernelXE that only contains files that are stable and compatible with BlackWingCat's extended kernel. KernelXE Lite is not compatible with full KernelXE and is meant to be installed on top of BlackWingCat's extended kernel. rv1 changes: Added custom BlackWingCat ntdll.dll with RtlIpv6StringToAddressExW and RtlSetLastWin32Error. ⚠️ Make sure to install the WildBill Update Collection BEFORE KernelXE. It is required and your system will be unbootable if you install KernelXE first. ⚠️ Downloads: KernelXE v0.2.4.2 KernelXE v0.2.5-rv1 Lite WildBill Update Collection The future of KernelXE and what I have been doing: As kernel32 grew, problems started to occur, like blank spaces in code, bugged code, and not enough space to add certain things. I decided to re-extend kernel32. This means redoing the entirety of .patch, which is where all non-Microsoft code is stored. Specifically in kernel32, I haven't had enough space in .data to add the data needed for some LCID related functions that are extremely commonly used in programs. I have already re-extended gdi32, and I may re-extend some other file if I need to. There won't be a new release of KernelXE for a long time, but when it finally comes, KernelXE may actually be a suitable alternative to BlackWingCat's extended kernel. Changelog: Public Beta 1: Initial Public Release Public Beta 2: Exported real CreateActCtxW as CreateActCtxB to prevent explorer.exe crashing. Added CreateActCtxW stub to take care of programs that call it while fixing the real function. Moved QueryUnbiasedInterruptTime, SetThreadStackGuarantee, K32EmptyWorkingSet, and GetNativeSystemInfo to .text Added idndl.dll, normaliz.dll, and the nls files normaliz.dll uses to the update package. v0.2.3: First version of KernelXE with new versioning system Full changelog inside update installer. v0.2.3.1: Added updated DirectSound library Added updated hotplug.dll and stobject.dll Added Windows Server 2003 msvcrt.dll Added BlackWingCat's Reiwa compatible locale.nls v0.2.4: Added PAE Added this HAL Timer fix Added Windows Vista msvcrt.dll Added KeAcquireInStackQueuedSpinLockRaiseToSynch and HalConvertIdtToIrql to all HALs Added KernelXE branded bootscreens Added some ntoskrnl functions (list in full changelog) v0.2.4-rv1: Added exFAT stuff (update.inf was weird) v0.2.4.1: Removed exFAT stuff Fixed and cleaned up update.inf Replaced Vista msvcrt with Server 2003 msvcrt (Vista msvcrt causes a BSOD related to winsrv) Added Kernel Mode Driver Framework Added WinUSB v0.2.4.2: Added some user32 stubs requested by piotrhn Added a missing piece of code in CreateActCtxB Updated msvcrt to 7.0.6002.22755 (Vista) Changed version block to check if the NT major version is 5 and removed NT minor version checking. Fixed loading bar not appearing in bootscreen Lots of new files Programs: Relocation Section Editor - Only one that handles huge relocation tables like the one in ntoskrnl. Executable | Source Code

I don't completely understand what you're asking, but I can tell you the locations of all the files. Either way, it's useful information. All DLL files from KB951748 go in C:\WINNT\system32 All DLL files from KB2817183 except vgx.dll go in C:\WINNT\system32 All SYS files from KB951748 go in C:\WINNT\system32\drivers vgx.dll goes in C:\Program Files\Common Files\Microsoft Shared\VGX Also, here are links to the updates: KB2817183 | KB951748

You could connect the drive to another computer, extract the updated files from KB2817183 and KB951748, and replace the old files on the drive with the new ones.

Here is Extended Core v16a repacked with SFXCAB.

Something I want to do is port some Windows XP Native API functions to Windows 2000. Since every entry in the KiServiceTable corresponds to a function, I wonder if the KiServiceTable can be expanded or if there's a different way to add these functions to ntdll, since the functions could call ntoskrnl functions (NtModifyBootEntry does).

This information is specific to Windows 2000, but how the Native API Functions work and how to find the code for them is similar on other versions of Windows. Table with every Native API function: https://j00ru.vexillium.org/syscalls/nt/32/ Summary of what Native API Functions are and how they work: Native API Functions are functions stored in kernel-space but can be called by user-space applications. User-space applications will usually call forwarded exports in kernel32 that point to exports in ntdll. The code an export will eventually reach in ntdll will look like this: mov eax, ##h lea edx, [esp+4] int 2Eh retn 2Ch A software interrupt is used to transfer code execution to one of the addresses in the System Service Descriptor Table (also known as the KiServiceTable). The KiServiceTable is contained in ntoskrnl and the address of the KiServiceTable is copied to an exported value called KeServiceDescriptorTable. This is the relevant code: INIT:005535EE mov ds:KeServiceDescriptorTable, offset off_472228 This is the most reliable way to find the address of the KiServiceTable. The address may not be 472228, but the beginning of the KiServiceTable will always have this comment at the end of the first line: ; DATA XREF: sub_55351A+D4↓o Finding the code for a certain Native API Function: If the name of the Native API Function starts with "Nt", then the export in ntoskrnl probably points to the actual function code. Finding the function code may be as simple as that, but most of the time, it isn't. There are a few Nt exports that do not point to the actual function code. In this case, it will point to the same code execution transfer code found in ntdll, but inside of ntoskrnl. These functions will also have a matching function with the same name except for "Zw" instead of "Nt" at the beginning. The export with Zw at the beginning will point to the code that transfers code execution to an address in the KiServiceTable. If the function is one of the few Nt functions which have exports that don't point to the actual function code, or is only a Zw function, then finding the KiServiceTable will be required. To find the KiServiceTable, find the line of code above that copies the KiServiceTable to KeServiceDescriptorTable in ntoskrnl. The address 5535EE will most likely be where this code is. In the example code above, the KiServiceTable is located at address 472228. The KiServiceTable will look like this (only the first 16 lines shown here): off_472228 dd offset sub_4C5C12 ; DATA XREF: sub_55351A+D4↓o dd offset sub_4FA4EE dd offset sub_4FD362 dd offset sub_4FA518 dd offset sub_4FD398 dd offset sub_45BE3E dd offset sub_4FD3D8 dd offset sub_4FD418 dd offset NtAddAtom dd offset sub_4F63E6 dd offset NtAdjustPrivilegesToken dd offset sub_4E5660 dd offset sub_4E5616 dd offset NtAllocateLocallyUniqueId dd offset sub_44AB84 dd offset NtAllocateUuids The first address will correspond with value 00h in this code: mov eax, ##h lea edx, [esp+4] int 2Eh retn 2Ch The next will correspond with 01h, then 02h, etc.

There is technically one, but only kernel32 has had functions added to it and not that many functions have been added, so you're not gaining very much functionality.

Here is a working link for .NET Framework 4.0 RC3 for Windows 2000. https://drive.google.com/file/d/14Nez-acl5BIogH7eyBHNBwmpTwoFbnbx/view?usp=sharing