Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

  • Days Won


win32 last won the day on June 30

win32 had the most liked content!

Community Reputation

287 Excellent

About win32

Profile Information

  • OS
    Windows 2000 Professional
  • Country


  • Country Flag

Recent Profile Visitors

2,180 profile views
  1. No. It doesn't have enough functions for BWC's kernel32.dll (so it can't boot with it) and his extended kernel doesn't have enough functions for New Moon/Serpent either.
  2. I've narrowed this down along with other similar limitations. The system lockups are due to me running in debug mode; in fact, pressing PrintScreen will lock up the system! The only issue with dependency walker/debugging of programs using my extensions is that trying to track GetProcAddress/LoadLibrary functions will cause a buffer overflow exception. Aside from that, debugging with redirected DLLs is very possible. The obvious solution is to replace the system files with mine, which I was able to do early on, yet now it appears that winlogon/logonui can no longer accept them. And they don't redirection. While Brave and its main DLLs don't seem to export any W7+ functions from DLLs other than kernel32.dll, I decided to copy the rest over and now get a fault in kernel32 at 78DFEC00h, which corresponds to an import table entry for RtlFreeOemString ("Frees the string buffer allocated by RtlUnicodeStringToOemString.") from ntdll, which is called by two subroutines in kernel32. Further investigation required. Visual Studio Code now works, not hindered by my unfinished implementation of Shell_NotifyIconGetRect, but thanks to the fixing of another bug in another function I implemented. Do not, under any circumstances, try to reimplement ntdll functions in other DLLs (except for ntdll functions that are forwarded from kernel32, in kernel32)! There are issues though, with the module that implements extensions/plugins, spdlog.node. It uses up lots of CPU time bringing CPU usage to ~94% on my Xeon X5670. I'll try that soon, once I get the x86 ball rolling, since there doesn't seem to be any x64 binaries available for Windows. In fact, my earlier post about shelving MS Edge and Office 2016+ due to disobedient installers was in error, since I just checked and found that the installers are indeed 32-bit. I've turned into Tim Apple with his OS' relentless pursuit to abandon 32bit binaries. Actually Windows 7 x86 kernel32 code is far simpler than the x64 equivalents, so I have an even better feeling about it. Just need to work quickly enough before x86-32 everything is deprecated!
  3. That was version 11 on Windows 2000, which exhibited some other deficiencies compared to it on XP. But you should try updating the root certificates.
  4. Unfortunately things aren't working out with Brave: And I have identified two conditions that may cause a system to lock up; first, running chrome_pwa_launcher.exe from Brave's folder or attempting to use Netflix in Firefox 68 ESR and later. In the second case, it seemed to be due to GetCurrentPackageId, which is a Windows 8 function. Firefox also does exhibit completely different behaviour if tricked into thinking it's on 8.x, as most UI elements don't work in that case. You can disable buggy functions by opening your local copy of a dll in ExportTableTester, and simply changing "XXXXFunction" to "XXXXFunctio_". But Electron-based Visual Studio Code seems to be in a better place. The only thing holding that back is my incomplete implementation of Shell_NotifyIconGetRect. All I have to do for that one is add a chunk of the function (as in a part that is separated from the rest), two subroutines with a chunk each, as well as a couple of new qword values in the data section. Luckily, all of its imports are accounted for in the Vista version. I can't think of a good, modern Chromium browser to try. It seems that they are all undesirable in some way, and their only good purpose is to view heavily-DRMed content that roytam1's or Tobin's browsers can't handle. With the expanded complexity of the project in mind, I have scrapped the idea for the tutorial. I am working on alternative means of distribution for the kernel extensions. Please contact me for more information.
  5. That doesn't actually change any hex values, just the way it is displayed to IDA. So it doesn't actually change locations. And I'm unable to run New Moon/Serpent with ntdllx4 as they throw exceptions in kernel32.
  6. Heads up about Firefox installers (78.0.1 to be exact). To install, add "setup.exe" to the list of applications in Application Verifier x86 and adjust version settings accordingly. Firefox 68.9 ESR is mostly working, except for a quirk involving the address/search bars. There are no default search engines and no way to add them. Thus, if you want to load pages directly from the address bar, you have to specify the protocol (like http;// or ftp://). Please note that the uxtheme.dll I'm using is a little stubby, but it does seem to be a far-fetched link. And I'd think that uxtheme would be OK being stubbed as, much like with dwmapi, uxtheme only needs to accommodate themes compatible with Windows Vista and not those for Windows 7. Perhaps some more debugging is needed. As for 78.0.1, it appears we will now need K32GetPerformanceInfo in kernel32.dll. The Firefox executable now also calls for RtlQueryPerformanceCounter in ntdll.dll. The thing is that, ntdll seems to be untouchable in NT 6.0! There's tonnes of extra data beyond the specified sections, which CFF Explorer does not handle gracefully. Stud_Pe does recognize the extra data, and makes new sections beyond it. But I still haven't tried adding any code since, as RtlQueryPerformanceCounter can easily be substituted for something like NtQueryInformationProcess. In fact, now that I extended kernel32.dll and modified firefox.exe, it seems to work similar to 68.9 ESR with the same bug. I'll get to the bottom of this! UPDATE: Turns out that windbg still works with my kernel extensions. So, this is what happens with Firefox 68.9 ESR: Where is search engine information stored in modern Firefox? Furthermore, it thinks I have no Windows Media Foundation. Maybe if I extended it (mf and mfplat.dll) it would work. Maybe. And now for Visual Studio Code: to install it, add VSCodeUserSetup-x64-1.46.1.tmp (or whatever the exe is called, just with a tmp at the end) to Application Verifier x86. It needs these functions: shell32 Shell_NotifyIconGetRect user32 ChangeWindowMessageFilterEx SetWindowDisplayAffinity kernel32 PowerClearRequest PowerCreateRequest PowerSetRequest QueryUnbiasedInterruptTime RaiseFailFastException K32GetMappedFileNameW (this one is for Brave browser based on Chromium 83) But apparently Office 2016+ and MS Edge installers (click-to-run) don't like local files, so they won't install.
  7. I could see them calling reg keys like HKLM\Software\Microsoft\Windows NT\CurrentVersion and calling KeBugCheck or something similar if they saw (or did not see) a certain version. But I don't think that happened in that case. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x139--kernel-security-check-failure Yours had a 3 in parameter 1, so a corrupted LIST_ENTRY. But the issue seems to only be restricted to Windows 8's dxgkrnl.sys; there seem to be no issues with the ones in 7 and 8.1. Perhaps the last working and first broken driver need to be compared, or dxgkrnl.sys needs to be replaced with a 7 or 8.1 version (preferably 8.1). There must be some differences in 8's dxgkrnl.sys compared to the 7 and 8.1 versions, and perhaps the driver no longer accommodates for that one since it's no longer a targeted/supported platform. More specifically, DXGCONTEXT::SubmitPresentHistoryToken needs to be compared between the three OSes. Going back to Vista, I admit that the road to an extended ntoskrnl.exe/dxgkrnl.sys/etc will be tricky. Even with Windows 2000's kernelmode driver extension, some XP display drivers were quite unstable in certain games; BWC had to edit the drivers further to improve functionality. But it will be interesting to see how far we go.
  8. PE Maker is incompatible with x64 files. While it will show some basic information about x64 files, you cannot edit them nor manipulate their import/export tables. Use CFF Explorer to change the subsystem versions (they will appear in the table that appears after clicking "optional headers").
  9. I looked at the Vulkan driver (both vulkan dlls in VulkanRT-Installer.exe) and it doesn't seem to have any dependency issues on Vista. I'm stuck on a GTX 260/Quadro FX 3800 so I can't test anything though. Perhaps the Vulkan applications have their own compatibility issues? Though, while I'm at it, here are the missing functions in ntoskrnl required for Skylake graphics: strncpy_s wcscpy_s IoUnregisterPlugPlayNotificationEx swprintf_s strcpy_s RtlUnicodeToUTF8N vswprintf_s _vsnprintf_s vsprintf_s _snprintf_s KeSetCoalescableTimer strnlen sprintf_s strcat_s memcpy_s wcsncpy_s Most of these functions exist in Vista but without the "_s" appended to them.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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)!
  15. 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.
  • Create New...