win32

I think this is the Windows 7 hotfix applicable to this situation: https://support.microsoft.com/en-us/help/2615701/-logon-process-initialization-failure-error-message-and-the-logon-process-does-not-start-in-windows-7-or-in-windows-server-2008-r2 But for some stupid reason it keeps redirecting me to a failed attempt to sign in to a M$ account. And of course the hotfix system has been dismantled so no attempts at comparison can be made between that and regular Windows 7 files, in order to backport to Vista. But I don't think that is the exact problem, as this is from late 2011 and Haswell was only released in 2013. And it also doesn't mention the behaviour where the logon process does initialize but other services don't. And I'm sure there are many people who are using Windows 7 without this hotfix and never having logon process issues on Haswell and later. It's not in Simplix pack and it doesn't appear that a future update superseded it unless the modifications made in this hotfix were discreetly carried over to later versions. But for what it's worth, it appears that the changes were mostly in kernel32.dll (which is broken up into several files on Windows 7) as well as the Local Session Manager. Plus WOW64 and Terminal Services. But I'm not sure what these changes are. I also found some potential registry-based solutions for dealing with individual services not starting up: https://support.microsoft.com/en-us/help/943996/some-services-do-not-start-in-windows-vista-and-windows-7 Also, did the logs/event viewer produce any information of substance? @burd And I just checked out 372.90's kernelmode (NVLDDMKM.SYS) driver. Only one function missing in ntoskrnl.exe, which is memcpy_s. The usermode Direct3D shim driver (nvumdshimx.dll) is missing the following functions in user32.dll: GetDisplayConfigBufferSizes QueryDisplayConfig DisplayConfigGetDeviceInfo Those functions are also called by the 372.70 version of the file. Maybe that's why you get such crappy D3D performance with those drivers! I'm definitely adding those ones to user32. UPDATE: turns out 365.19 also does call them. But they also don't support 1000 series where this problem happens. And MS is lying about DisplayConfigGetDeviceInfo being in Vista: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-displayconfiggetdeviceinfo I certainly don't have it and I do have every update up to Vista's EOL.

I appear to have exhausted all reasonable options for modifying the import table aside from rebuilding it from scratch. But shell32 calls over 1200 functions so that is practically impossible. The procedure for doing this on x86 is considerably easier thanks to PE Maker. So I decided to call NtQueryInformationFile instead and now Waterfox Classic 2020.3.1 including e10s works. We are back on track. Even took a peek inside Server 2019's uefi.sys and dxgkrnl.sys. The latter has what appears to be calling dozens of functions missing from ntoskrnl.exe , yet uefi.sys only has about 4.

Yes! So only user-specified programs can use the kernel extensions, which can easily lock out malware that relies on W7+ functions yet doesn't have local/manifests specified for it. I'd think that it would work for installers as well, as all program-linked libraries will call the local dlls instead of the system ones. Bootstrapped ones that check for OS versions are gonna be harder to work of course, but a few posts back I found a solution for new GIMP installers with general advice applicable to installers of such stubbornness. You can use Orca to modify/drop LaunchCondition tables in msi installers. For everything else, version spoofing through Application Verifier will work. In cases where a bootstrapped installer in a temp folder checks as well, you just need to get the name of that installer (but not path) and feed it to Application Verifier.

Vista and Windows 2000 are the last two major revisions to the Windows NT kernel (NT 10.0 doesn't count since it was hastily bumped from 6.4 at the last minute and 1507 doesn't really add much from 8.1 win32-wise). Lots of major functionality that we take for granted, like USB mass storage support (2000), desktop composition (Vista) and proper NT DirectX support (2000) was introduced in those two OSes, with their minor kernel revisions adding relatively minor things or ones that were of poor quality, like XP's firewall and WLAN client; the former didn't support blocking outgoing connections and the latter doesn't support connecting to WPA2-EAP networks (or maybe it does but I couldn't manage it with the built-in client; had to use Boingo client that also works on Windows 2000). Vista fixed them both.

You don't have to do so unless you're planning on replacing your system files with mine. With a manifest or local file in the program folder, it will simply use the modified files present in the program folder (if they're not present there, then it will look in x:\windows\system32 or syswow64). I'd like to say that in such a scenario, an old file of mine should work well with a newer MS file since the differences are relatively minor. ESR 68 seems to ask for nothing more than about 5 extra functions in user32. If they're simple enough (few import and subroutine calls within), I could have them done in a day! Nice. I use an HP Z600 with a Xeon X5670 for Vista (and Windows 2000)!

Even in 2018 it was crazy; less than three years after Windows 10 was released, yet that's all my new HP laptop officially supported (what a mess that thing is). But if I bought a laptop in 2004, three years after Windows XP came out, I would have official support for not just XP, but 2000, 98 FE/SE and even NT 4 (ThinkPad T41)! And that laptop has sleep-related bugs with Windows 10 that the officially-unsupported 8.1/2012R2 doesn't have! Even with all of the MS lock-in, relatively few new win32 API functions have been added after Windows 8 so it looks like forcing software incompatibility with Vista exkernel/7/8.x will be difficult for years to come.

I've got classic working partially (non-e10s and container tabs work); just need to get over the shell32 import table*/buffer overflow hurdle. I haven't touched Current but I've been looking closely at SeaMonkey 2.53.x and Firefox 68.9 ESR. Both use a few extra functions compared to Pale Moon and Waterfox Classic. *Stud_PE allows extensive modification of PE32+ import tables, but the first thing I tried was simply adding a function to the full import table. This created a new section with the new import plus dummy entries. Indeed, you cannot split an import table and thus seemed to mess up the file. I will try moving the import table, but Stud_PE can trigger DEP in that scenario. I'll try on my Banias Pentium M laptop. I have a Kaby Lake laptop that could be fit for that purpose. I do plan on installing Vista eventually (need to get a empty DVD-R!) to test a possible kernelmode extension that would support drivers designed for later versions of WDDM. The problem is that I still wouldn't have all of the material necessary for trying to diagnose the timing init problems, like a nullmodem/serial cable or even ports to debug the kernel from another machine using windebug. Would the problems occur when the OS is virtualized? Kernel debugging in such a case would be easier. And I heard someone say that same problem affected Windows 7 at one time. Further details about that fix would be helpful. Some users have been able to share Office 2013 ISOs from IA while others requesting W7 ISOs have been banned immediately. So I'd recommend erring on the side of caution. But I'm sure that others would be willing to promote it in their videos. No new functions seem to have been added recently to Vista's system binaries, and the security updates the files have received have made them slightly bigger. This will change the memory addresses of the new code thus causing the process to deviate slightly from those for the files I use, as most of the labour involved in extending the kernel is the result of adjusting memory addresses being called by instructions. To keep everything simple, I will provide WUC links to updates containing my versions of the files allowing everyone to play along regardless of update level. Perhaps I will provide updated instructions for the last versions of files once Vista ESU support ends.

How will Tobin feel about this? There has only been one minor glitch where the title/URL/bookmark/tab bar briefly expanded when I was on YouTube. But I may have seen it before on 2012R2. Waterfox Classic 2020.3.1 is working too, but only in non-e10s mode (same as Pale Moon). I need to finish up SetCurrentProcessExplicitAppUserModelID in shell32.dll before e10s will work, it appears. I finished implementing CoGetApartmentType in ole32.dll, and it appears that dwmapi.dll is OK with stubs since the OS doesn't actually use the functions that newer Firefox-based browsers ask of that file. And there are some extra functions in user32.dll and uxtheme.dll that will be needed to make Firefox 68.9 ESR happy. More updates: K32GetModuleInformation will be added to kernel32 to accommodate SeaMonkey 2.53.x. And the thing that keeps e10s from working in Waterfox is that earlier one part of SetCurrentProcessExplicitAppUserModelID was bugged in a way similar to that of SetThreadErrorMode a few pages back. Problem is that NtQueryInformationProcess is not imported by the original Vista file, and there is no room to expand the import table (and I haven't found a good way to move import tables in x64 binaries yet). So first I tried adding NtQueryInformationProcess as a subroutine to shell32.dll. But that causes waterfox to crash with a BEX64 error (related to DEP/NX). And NtQueryInformationProcess has a syscall function in it. According to Intel 64 manual, syscall is a "Fast call to privilege level 0 system procedures". And as such, it is inappropriate for shell32 and should only be in ntdll.

Welcome to MSFN! Yeah, even back when it was the newest MS OS. I heard all kinds of things about it back then, but I only saw one PC running it during that period, which was promptly upgraded to a pirated W7. And it wasn't mine (I had XP with 1 GB of RAM). I actually started using Vista eight years after I first used Windows 7. And now most people I know have stopped using W7 as well.

Update on the OS version faking situation. Application Verifier is indeed the best tool for this purpose on Windows NT 6.x, and I've found a trick that should allow installation of GIMP 2.10.2 and later on Vista. It will be important to keep in mind for other installers. The main GIMP installer (gimp-2.10.xx-setup-x.exe) does not do any version checking on its own. But a file spawned by it, named gimp-2.10.xx-setup-x.tmp does. It will be located in your X:\Users\UserXXXX\AppData\Local\Temp in a semi-cryptic but usually most-recent folder, but you actually don't need to track it down; with Application Verifier, you can simply go to File -> Add Application and change the filter from Programs to All Files (*.*) to add the name of the application/temp installer/etc. you need to hoodwink, even if it's not in the folder shown in the dialog. So you will be ready the next time you fire up an installer which creates temp files. Some like VMware version check in both the main executable and in the temp executables. To put the version faking to work, set the properties in HighVersionLie, listed under Compatibility in the Tests tree. Major version 6, minor version 1, build number 7601 and service pack major 1 should be good enough in most cases for now. Now that the x64 kernel32.dll is finished (but needs to be tested), it is time to determine which functions need to be extended in auxiliary user-mode binaries. The list will grow somewhat longer over time. shell32.dll SetCurrentProcessExplicitAppUserModelID GetCurrentProcessExplicitAppUserModelID There may be a couple more that Waterfox calls but I can't remember them at present. I will once I get back to my Vista machine in about 12 hours. user32.dll CloseTouchInputHandle GetTouchInputInfo RegisterTouchWindow SetCoalescableTimer (Office 2019 installer) mf.dll MFCreateDeviceSource MFEnumDeviceSources mfplat.dll MFCreateDXGIDeviceManager MFCreateDXGISurfaceBuffer MFCreateMFByteStreamOnStream MFCreateSourceResolver MFPutWaitingWorkItem MFTEnumEx MFCreateMFByteStreamOnStream I don't see the need to extend advapi32.dll. Only ten new exports (four documented ones) were added to it in Windows 7; a lot more were added in 8 (some were taken away in 8.1), but I highly doubt that these are used by widely available software, as in not custom corporate stuff or part of the OS. If you have evidence to the contrary, please tell me.

There have been many polls like this in the earlier days of this forum, but none in the era of Windows 8/10. I wonder how the recent changes to Windows will have affected opinions towards Windows and its various releases. Due to poll limitations, the poll options for earlier/more obscure versions have been combined.

There is no UWP without win32, right (on desktop Windows 10)? I haven't looked at the way it's done on Windows 10, but on 2012R2 the WinRT/appx/XAML binaries usually link back to ntdll and the various api-ms-win-*, many of which used to be part of the main usermode Windows NT binaries. At this point in time, I'd think of trying to port over the Windows 10 explorer along with the store infrastructure. I think that there would be a lot of copying of the api-ms-win-* for XAML/WinRT/UWP/etc. from a Windows 10 install. Would this work? I still have my doubts as the Windows 2000 explorer has never been successfully ported to XP (no WinRT/XAML involved, and much simpler, but not everyone thinks of adding API functions to XP's files). And it wouldn't be very practical as win32 is still extremely popular.

It successfully compiled in the Vista x64 build environment so it wouldn't hurt to try in the XP/2003 x64 one.

I have now ported over K32EnumProcessModules, K32EnumProcessModulesEx, GetCurrentPackageId and GetSystemTimePreciseAsFileTime. GetCurrentPackageId should work, but it's not perfectly true to the 2012R2 implementation as some instructions ended up being shorter (due to a short proximity between addresses in the file making the call instructions one byte shorter than before. one workaround for a similar issue seen in an earlier post can prove problematic). If there are issues, I will promptly correct them but I don't see why it wouldn't work ATM. K32GetProcessImageFileNameA/W are also done; now all I have to do is K32QueryWorkingSet(Ex) and GetNumaNodeProcessorMaskEx. P.S. I have no way of actually running Vista right now, and will not for several days. I'll try setting up VMs on my Kaby Lake laptop but I am a little lazy when it comes to that, especially with no way to easily slipstream updates (used to the convenience of HFSLIP and nLite). And building a new wim with updated files will take some time since I do want it to be based on a clean install. Once those are finished, I think that the vast majority of Windows 7 software will be satisfied. There are still about 18 other functions (mostly of the K32* variety), but in practice they are seldom used by popular applications (but if you do have software that uses these functions, please tell me). Since the Steam client is still 32bit, I think that starting on the 32bit version of kernel32.dll (and extending user32. shell32, and Media Foundation libraries) is a greater priority than ensuring the re-implementation of all Windows 7/8 functions. And then it's on to the kernelmode stuff like ntoskrnl/dxgkrnl/win32k etc. I have so many ideas about making extensions to so many operating systems. I'd thought about making kernel extensions for OSes like Windows 95 (usermode), NT4, VxDEX for Windows 95 to run Windows 98 VxD drivers, or even 3.0 to get it to run 3.1x software (forget about the last two for now; not many tools for looking into and editing NE/LXs). And one idea in particular was very perverted: adding UWP support to Vista/7. But I decided to focus on the most practical idea: extending Vista.

I have now fixed the import calls and added K32EmptyWorkingSet. So about 26 more functions to go in kernel32! OBS Studio 19.2.0 is mostly working now, but there are a few missing functions in MFPlat.dll (Media Foundation Platform), like MFTEnumEx (used to find video/audio decoders) and MFCreateMFByteStreamOnStream. While it picks up on audio, it doesn't record or show video and creates tiny (corrupt) files. Or it may be because it forces a D3D11 renderer and my DX10 native GPU doesn't seem to work very well with DX11 (Cities: Skylines is unplayably glitchy in D3D11 mode on Vista and 7 but fine in D3D9 mode on XP x64). I think that the media foundation extensions will be fun, as I may even introduce the functions from Windows 8 as opposed to just the ones new to 7. That would mean adding stuff like Direct3D 11-based video APIs. Though adding DX11.1+ features will be pointless if the drivers available for Vista can't use them. And getting WDDM 1.1+ drivers on Vista is going to be one difficult undertaking, but probably easier than porting WDDM 1.0 drivers to XDDM (Windows 2000 Display Driver Model). And I've found another limitation of LOCAL files. Programs don't like being debugged when redirection is taking place to files within folders; they throw a fault in StackHash_**** when trying to launch them through Dependency Walker. But if the same file is loaded from system32 as opposed to the program directory, with no redirection taking place, the program works (as well as possible) through Dependency Walker. So I thought about .manifest files, which give you the option to redirect only the files specified within them. Here is an example of the contents of a manifest file used for DLL redirection: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" name="redirector" type="win32" /> <file name="kernel32.dll"> </file> </assembly> But it appears that manifest files don't seem to help much in that regard. So I guess you will have to replace your system files with mine if you're planning on debugging programs using my files. Once I get a wide array of programs working stable, I hope that you do one of your excellent videos about the kernel's capabilities. You create some great promotional tools for Vista, and this one will explore some uncharted territory for the OS. On one last note, this isn't the only new kernel extension project that helps Vista users out: The tutorial specifically mentions building for x86, but I built it in the Vista x64 build environment in the Windows 7 DDK, so it could help with certain classes of drivers. Will it help for modern GPU drivers? Not really. NVMe and USB 3? Sure.

Yes. I just need to do about ten more patches of call near ptr to call cs: in the nine existing functions, and then I'll be adding more. These are other missing ones that I've found to be called by programs: GetNumaNodeProcessorMaskEx GetCurrentPackageId GetSystemTimePreciseAsFileTime plus their dependencies and sister functions Those are going on the list along with the other unimplemented K32 functions as well as TryAcquireSRWLockShared (not sure why I shelved it earlier - perhaps because it's really a ntdll function but it doesn't matter since nothing really seems to call them directly from ntdll so it can go into kernel32, like BWC has done). Anyway, I really like these x64 dlls. MS gets to do its own thing in its own code section, while I can just make a section for myself and move the export table to its own section and things are good. All of the existing functionality of Vista is retained and not a single beat is skipped. And if you choose not to replace your existing kernel32.dll and just use the modified one on a per-program basis using .exe.local redirectors, you will be preventing the direct execution of malicious executables requiring W7+ functions. I'm also thinking about compatibility shims - One-Core-API expanded the amount of shims available in XP to include OSes like Vista/7/8.1/10. I think that I need something like that to get some installers to run since that seems to go above and beyond what Application Verifier can provide.

Very interesting. It's nice to find out all of the ways to customize and modify NT 6.x much like we have been doing to NT 5.x for many years. Unfortunately that doesn't mitigate the risk of it being overwritten by updates though. Though I think that guy who was trying to get fully slipstreamed Vista install media with all updates-to-present would be interested. On another note, this snippet of code is giving me a lot of trouble: xdata:0000000078E6D07F loc_78E6D07F: ; CODE XREF: SetThreadErrorMode+4A↑j .xdata:0000000078E6D07F lea rdx, [rsp+30h] .xdata:0000000078E6D084 call near ptr RtlSetThreadErrorMode .xdata:0000000078E6D089 nop .xdata:0000000078E6D08A cmp eax, ebx .xdata:0000000078E6D08C jge short loc_78E6D092 .xdata:0000000078E6D08E mov ecx, eax .xdata:0000000078E6D090 jmp short loc_78E6D056 GIMP crashes when it encounters the nop. I know that it should be xdata:0000000078E6D07F loc_78E6D07F: ; CODE XREF: SetThreadErrorMode+4A↑j .xdata:0000000078E6D07F lea rdx, [rsp+30h] .xdata:0000000078E6D084 call cs:RtlSetThreadErrorMode .xdata:0000000078E6D08A cmp eax, ebx .xdata:0000000078E6D08C jge short loc_78E6D092 .xdata:0000000078E6D08E mov ecx, eax .xdata:0000000078E6D090 jmp short loc_78E6D056 But IDA doesn't like me patching that and turns it into this .xdata:0000000078E6D07F ; --------------------------------------------------------------------------- .xdata:0000000078E6D084 db 9Ah ; š .xdata:0000000078E6D085 db 0C0h ; À .xdata:0000000078E6D086 db 0E8h ; è .xdata:0000000078E6D087 db 0DFh ; ß .xdata:0000000078E6D088 db 78h ; x .xdata:0000000078E6D089 db 6 .xdata:0000000078E6D08A db 0 .xdata:0000000078E6D08B ; --------------------------------------------------------------------------- No better of course and it crashes on the shambolic non-code. I tried just placing the W7 version of RtlSetThreadErrorMode into my kernel32, but it called something in a completely unrelated function just above it (GetCurrentProcessorNumberEx+2) and failed there. I also wonder why RtlSetThreadErrorMode was implemented in Vista but SetThreadErrorMode wasn't until 7. update: So I noticed two calls to the same import, CsrClientCallServer (78DFE090). The one at 78DA0B24 looks like this: FF 15 66 D5 05 00 While the call to it at 78DA0BA1 is like this: FF 15 E9 D4 05 00 Perhaps I need to deduce something from that. Putting these somewhere else will direct them to a completely different memory address, so I need to figure out how to get to call 78DFE8C0 (RtlSetThreadErrorMode). update: Apparently, a call cs:* only will call memory addresses below it, using the FF 15 ** ** 0* 00 format. But a quick look at XP x64's kernel32 reveals that the import table is at the beginning of the file, so call cs:* must refer to addresses above them. And the format for those is FF 15 ** ** FF FF (for close ones seemingly) or FF 15 ** F5 FF for ones very far away, with options for going in between. In the end, I was able to call RtlSetThreadErrorMode using hex code FF 15 36 18 F9 FF. And it fixed everything SetThreadErrorMode! YIP YIP HOORRRRRRRRRRRAY!!!!!!!!!!!!!!!!!!! I will promptly correct the other functions. 10 hours ago I actually doubted myself enough that I briefly thought that I went in wayyyy over my head with this supposed vapourware project but now it is anything but!!! I even did a little editing of the photo in there. Still some missing functions so other components may not work well but I think I've got all figured out.

Actually, 2.10.0 x64 runs on Vista. Download gimp-2.10.0-x64-setup.exe from https://download.gimp.org/mirror/pub/gimp/v2.10/windows/ and you will notice that the installer doesn't block Vista like those for later 2.10 releases. The module that calls SetThreadErrorMode in later releases doesn't call it in this one. huh? 404? what a shame since 2.10.2's installer blocks Vista!

Update on x86 extension: I have refined the implementation of SetThreadErrorMode, (Rtl)TryAcquireSRWLockExclusive and (Rtl)TryAcquireSRWLockShared. On the x64 side, I've got SetThreadErrorMode and its dependency BaseSetLastNTError. x86 SetThreadErrorMode is based on Windows 2000 extended kernel code, though all others are based on Windows 7 code. Next up is GetCurrentProcessorNumberEx (needed by Pale Moon 28.10.0) and the entire K32* series of functions (there are about 25 of them). And then a few stragglers in user32 and shell32 will be added. The manual patching instructions will be updated once kernel32.dll is filled out with all of the planned functions. On another note, I have found a limitation of the DLL redirection scheme. While it works wonderfully for say, kernel32.dll where the program will call the local version, and even other system dlls (not located in the local directory) would refer back to the local version, it appears that ntdll.dll is exempt from it. Mind you I haven't applied the reg key mentioned in the article yet that would allow system-wide DLL redirection. And as it stands, all program execution (as in GIMP 2.10.8 and a recent version of oCam) using my x86 kernel32/ntdll combo fails ATM. Yes, I did try renaming the local ntdll to ntdl1 then adjusting kernel32's import table accordingly. That still didn't work out as a fault occurred in the main ntdll at 0x77E0F7B3 (RtlInitializeNtUserPfn). I will keep investigating. update: x86 ntdll is unbootable, but x64 kernel32 still boots to a stable system, now with K32GetProcessMemoryInfo implemented.

You would have to add the kernel32.dll to the install.wim inside your ISO and I'm not sure exactly how to directly replace files within a wim/esd. But, with my updated instructions there is no need to replace system files - simply backup your modified kernel32.dll somewhere else and then add it to the folders of programs where it would be necessary, along with the xxxx.exe.local to redirect your programs to your updated file.

Yes, but be mindful of any differences in memory offsets and addresses when compared to the versions shown here. And I'd be quite concerned about other missing API functions if that's pre-Platform Update (which I think it is).

I have since revised the instructions due to the corruption issues I experienced. If all tables are good (you can check them each in CFF), then you don't have anything to worry about anyway though they will be useful with future updates.

.xdata is the preferred nomenclature.

Oh yeah, I remember discussion on the use of .manifest files to redirect DLLs in XP, and I did try it a little bit in Vista where it worked, but forgot about it after it failed in 2000. Another method of redirection is explained here: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection So instead of replacing kernel32.dll, you can simply create yyyyy.exe.local in the same directory as yyyyy.exe and plant the custom kernel32.dll in the directory as well, avoiding the effects of monthly updates.

Yes, that would definitely be possible; just change all references in the target program's import table from kernel32 to the modified kernel33. However, that may be very complex in the case of programs that have many dependencies on other files that in turn have unresolved dependencies on kernel32 (which would be resolved with a modified kernel32/kernel33). As it appears that putting the new code/stubs in separate tables from the original MS code maintains the OS' stability, I decided that modifying system files would work best, though it will prove somewhat undesirable for those who continue to update the OS. But I've been thinking about HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs, which seems to direct applications to system DLLs; perhaps I could have two entries for both kernel32 and kernel33 (kernel32 = kernel32.dll and kernel32 = kernel33.dll), thus rendering the reboot and replacement of system files unnecessary? But I'm booted into Windows 2000 right now, and I'm not sure if that key exists in Vista. UPDATE: it does exist in Vista, but I had to take ownership of it to edit. I'm going to try changing the kernel32 entry to say "kernel32.dll, kernel33.dll" and see what happens. another UPDATE: unfortunately the system and applications don't recognize the x86 kernel33.dll with the extra function.