win32

That 7zip component simply calculates the checksums for the executable. It does not check for any digital signatures tied to it. My Windows 2000 does in fact allow me to check for digital signatures/certificates via file properties in Explorer. So XP should as well. I just checked a Vista update from this year. Click the Digital Signatures tab, then click "Details", and then "Advanced" tab. Under "digest algorithm", it says sha256.

Yes, I had considered it: Then, I thought: would it be impeded by the code signing requirements (which are not present on XP/2003)? But again, AeroGlass gets around them. This seems to have some useful information: https://www.ethicalhacker.net/columns/heffner/intercepted-windows-hacking-via-dll-redirection/ (specifically the part about building a "stub" DLL - I've got almost no C/C++ knowledge but when I do read C, it does make a good deal of sense to me) Perhaps I would then muck around with the kernel32 import table so that it would import these functions from the ntext and hope it will work. This would also make system file replacement mandatory for 32 bit binaries. But my plan B (which is now a plan C) was to simply replace them with BWC's implementations of K32* functions, which simply expand upon the lesser versions of those functions in psapi.dll.

I also do have v3.0e and also don't have an issue. But check your PM for a possible solution.

shimgvw.dll has a completely different structure in late Whistler and XP than Windows 2000. Do you have any shell extensions loaded? The Windows 2000 version of shimgvw.dll is perfectly capable of doing full screen previews.

Only with local DLL redirection, and I think they will likely be blocked because those DLLs will not have a valid signature. But again, DWM can be hooked by AeroGlass for Win8.1+...

For the kernel32 functions? Seems non-practical. Either you'd have to modify each program's export table to point to shell32 for those functions or (easier) add the entries to kernel32's export table but have them forward to shell32. In this case, you may as well create a completely new dll that containing nothing more than those functions. But there are still a few things left to try to fix the functions in kernel32 and shell32.

Yes, you can. Though in this case, I've found that a DEP-related crash covers up a buffer overflow exception that would have occurred without DEP.

MS forced hardware vendors to supply x86 and x64 drivers for WHQL certification starting with Vista. But there were devices such as printers that were released only a couple of years before Vista that were challenged in the x64 driver department. And when you have 2 or 3 GB of RAM, the advantages of x64 are not as profound as they would be with loads of RAM (and even with 12 GB of RAM and a PAE-capable OS, you can still get by on x86). As an ex-Core Duo user, that would be part and parcel of a decent configuration for Vista yet it is a 32 bit CPU. And then there's Steam and Office 2013+ installers. They are quite popular yet they don't exist in a 64bit form. But indeed, I've faced many challenges on x86 that haven't surfaced in x64. Indeed crashes that occur when calling NtQuerySystemInformation and NtQueryInformationProcess are a real PITA. I've just noticed that those two functions have received minor upgrades on 7 (but not on x64, which is why it works there). But ntdll is off limits due to it having a mandatory signature and signtool refuses to sign dlls (probably why no one really does deep-down modifications to 8.x and 10 since the signing requirements are very stringent, even compared to Vista/7). So I decided to implement the Windows 7 versions as subroutines in kernel32.dll, as it is possible to successfully implement some ntdll functions in kernel32. But that just trips DEP, so that's a non-starter. I'll have to file this one away in the "MS paranoia impedes power users" folder. In fact, the next function I was going to implement, K32EnumProcesses also calls the functionally-deficient ntdll functions mentioned above, so it's dead in the water. Yet again, our hopes rest with the BWC versions of those functions. Thanks a lot, M$.

I had done a bit of work on the x86 kernel32, by adding relocations, but I'm still getting nowhere with Advanced Chrome 74/84. I'll try adding a few more functions to kernel32 to bring it closer in line with the x64 one anyway. And I'll revisit x86 shell32 in due time (I've found a possible working stub for SetExplicitUserModelID or whatever it's called). It's just that I've focused on win2k stuff for the past few days...

It can be anything. Just make a new text document and rename it to winword.exe.local. and yes, repeat.

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection Just like the thing I did to fix SHA-2 encryption in Office 2007 in Windows 2000, you can create a *.exe.local file for each office application and copy dssenh.dll to the office14 directory, along with possibly older versions of crypt32.dll, schannel.dll and rsaenh.dll.

I've found out that MSDN's documentation was lying to us: http://web.archive.org/web/20080919081500/http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx No, they can't. But you can go into HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs and delete most entries (except for the DllDirectory one or else you will get a BSOD on bootup), including the one for kernel32. Then create a vmtoolsd.exe.local file in its directory and copy over the MS kernel32.dll. I just did and I stopped getting the VC++ runtime error, but I didn't get anything else (though I'm actually running on real hardware, a ThinkPad T41). And my own bug was related to the vmware tools installer (yours is the "toolbox") for Vista and up. It gets past that function with BWC's kernel, though again he has the relocs (two or three in that particular function). In fact, my own ignorance of relocs seems to be responsible for many of the issues with my Vista x86 kernel32 (doesn't seem to be as important in x64)!

it would be the same on an x64 system. The only thing that really changes on x64 is that x86 components come under a "Wow6432Node" key.

I decided to try the vmware tools executable from version 15, and it's even worse. It calls WakeAllConditionVariable then it starts leaking memory like crazy and hogging up the CPU. I checked your kernel32 in PE Tool and noticed that there doesn't seem to be any relocs in your part of the code. As I've read today in WildBill's patch thread, they do seem to be quite important. PE Tool seems to be quite helpful in terms of recommending reloc placement. Also, these vmware tools installers should not be calling all of these XP/Vista API functions since they run fine on vanilla Windows 2000. This is the same trap the vmware installers were running into with my Vista extended kernel. The fix was to have the installer use the MS kernel32.dll in that case, but I'm struggling with how to enable local DLL redirection in Windows 2000. Various sources say it's possible, but the reg key that worked in Vista changes nothing in Windows 2000.

What do you get when you run it through dependency walker? Or ollydbg or IDA's debugger?

I just realized that the MS C++ Library falls under msvcirt.dll as opposed to the C Runtime library. So you may want to try BWC's version of that. And there are extended versions of comctl32/dbghelp/advapi32/etc. in KB2508429-v17, which have resolved most of the New Moon/Serpent dependency issues.

On XP, change the 6A 00 6A 01 6A 06 sequence to 6A 00 6A 01 6A 05.

What version of msvcrt.dll are you using?

So I tried this together with your ntdllx4 and BWC's v30e. and sorry dude, things aren't working very well. -system clipboard is broken - no drag-and-drop and pasting possible -New Moon still doesn't start (access violation at 77F8F281 in ntdll.dll) and then an invalid window handle error. -WinMgmt, SoundMAX helper components and Dependency Walker fail to load. IDA Pro 4.5 gives off an error at 0x70873baf when closing. -Parts of web view used for Control Panel and the page that appears when opening the WINNT folder are broken. -Add/Remove Programs is broken. But these problems go away when BWC is taken out of the picture and WildBill's KB2479629-v3 is used instead of the extended kernel. The only problem present in such a configuration is that New Moon now is missing a function or two each in dbghelp.dll, user32.dll, advapi32.dll, iphlpapi.dll and ws2_32.dll (as well as the whole of uxtheme.dll). I used a .local file and copied over some of BWC's applicable files to deal with those dependencies, but that didn't help for the ones called by xul.dll, which are user32.GetWindowRgnBox and advapi32.SystemFunction036. After seeing the horrors of extreme file mixing, perhaps I could help with the auxiliary files

cool. I had actually forked your ntdllx3 (so I could use XP's sysdm.cpl, 2003 SP2's service engine and Whistler 2419's theme engine) and made my own with a few extra functions that no others had. I don't have a lot of my win2k stuff with me now so I forgot what they were, but just open up 2003 SP2's services.exe in dependency walker and the functions that are missing are the ones that I put in mine. The attempt to backport the service engine and the theme engine failed though. But I just copied the functions verbatim from 2003 SP2. But it would be great to use your ntdll since it has support for SxS (manifest/local) files which is important to my Vista extended kernel, and would help for the few older programs that have compatibility issues with the win2k extended kernel (for example, WindowBlinds 3.5 thinks I'm running XP and that makes it... not work - fcwin2k/nnn4nt5 doesn't help and I haven't found a way to patch it to bypass the error).

WildBill's ntdll has more functions than BWC's.

It works fine with BWC's files. Ximonite made his latest ntdll based on WildBill's ntdll and added all of BWC's functions to it. But it doesn't mix well with BWC's kernel32. And WildBill stopped working on his extended kernel files years ago, so they don't have nearly as much functions as BWC, so they can't run roytam1's browsers.

W7 shouldn't be too difficult, as I think that most system files remain unsigned as in Vista. But I'm not aware of any real software incompatibilities with W10 yet. I'm only aware of the DX12 stuff, UWP stuff, and Office 2019's installer asking for SetCoalescableTimer (Windows 8 and up). XP has One-Core-API.

It still has a long way to go, but I do hope that further updates push it more. Indeed, it doesn't have every function that many Vista display drivers use, and x64 import tables are a pain to deal with. And also digital signatures. Another option is to mod the drivers themselves, where you look at what the incompatible functions do. and compare them with whatever the last compatible version did. BWC has done that, and both approaches may have to be done to get stuff working (pure XP x86 NVIDIA drivers with his extended core have serious problems with some DX9 programs, which are fixed by some of his modded versions).

WSUS Offline Update ESR 9.2.5 (a front end for wsusscn2.cab it appears) still gets most XP x86 and Server 2003 x64 updates as of now. Seemingly, the only thing that fails is WMP11, but that was probably served through the MS Download Center as opposed to Windows Update.