win32

No, though it seems that experiences have been mixed with the installer. Even if not giving it admin privileges things should be fine, as it wouldn't even be able to manipulate any files in that case. It is possible that this may be related to the Haswell+ timing issues, as it is possible that some of the commands issued by the installer failed.

I tried adding those functions, which are actually forwarded from secur32 to sspicli.dll, the latter of which is a completely new DLL from Windows 7. Not much success thus far with launching Edge.

That is intentional on VB's part. Around versions 4.1.30/4.2/4.3 they implementing something called "hardening" which checks the digital signatures of certain system files. I tried signing my files, but the cert chain terminated "too early" for VB. So try these newer builds with hardening removed: https://forum.ru-board.com/topic.cgi?forum=5&topic=49006&start=2160#17

Find vmx86.sys in system32\drivers on the system you copied VMware from, then copy it to the Vista system.

I don't believe so, as it seems to have something to do with extensions disabling by default and refusing to update.

The current stable 3.0.11 works on XP, while later versions of the extended kernel allow for 3.0.0 (and a few after that iirc) to work mostly, but it crashes if you load one of the setting pages...

Brazil stopped observing DST, thus the DST sections were removed.

I found this article very interesting to the subject of implementing system services, even if it's about the WRK: http://web.archive.org/web/20090707233000/http://www.dcl.hpi.uni-potsdam.de/research/WRK/?p=28 And also check these out: https://j00ru.vexillium.org/syscalls/nt/64/ https://j00ru.vexillium.org/syscalls/win32k/32/ https://j00ru.vexillium.org/syscalls/win32k/64/

10.x is good, and is what I use on Vista. Maybe I should install it on my 2012R2 laptop as well, because 15 doesn't cut it on there. For example, error handling has deteriorated; try dragging and dropping files from a compressed folder open in 7zip on the host; 10 gives you an error and continues on its merry way, but 15 crashes the VM. That combined with other Vista-related issues shows how VMware should regret laying off their entire U.S. development team. They probably knew the most, as shown by the deteriorating quality of their recent products. Also, I'm terrible at synchronizing the development files between both locations. I brought my ntk32 files over here, but forgot to do the same for my kernel32 and shell32.

I still plan to get it out by the end of month. There are some 64 bit additions I did early in the month, and then I found out to make x86 kernel32/ntdll functions work so there will be some big x86 changes. Unfortunately the development cycle is quite unstable due to a commitment to live part-time at another location where there is little acceptable hardware for Vista.

Does anyone know which version is the last one to work and the first one to fail (on RTX 2xxx and GTX 1xxx of course)? I already did a quick mod of 460.89's main kernel mode driver looking at the version checking spots that didn't seem to be in the earlier (372.70 for example) ones I've checked. It's a big shame since 8.x has some big advantages at install time to those who aren't accustomed to NT 6.x-style slipstreaming like me. And is 2012R2 far more suitable to workstation conversion than 2016/2019 (but unsure about 2008 R2 and 2008).

Anyway, NVIDIA did officially dump 8.1. This driver query service only returns results for 7 and not 8.1: https://www.nvidia.com/download/index.aspx?lang=en-us

This sounds similar to NVIDIA drivers also blocking earlier builds of Windows 10. Which driver version are you using?

I see that MS stuffed Visual C++ with several functions that get called based on the OS they're running on; SetThreadDescription is one from 10, while GetCurrentPackageId is one from 8, and they infamously did the same with XP functions to shut out 2000. Firefox and Chromium browsers do not load on Vista if Application Verifier is set to Windows 8/10 on those applications. It's OK for now as they're not really needed, but they may be once Windows 7 is scuttled and they settle on a hard version check to shut it out. The thing that concerns me most is display driver support, because that changed significantly between 8.1 and 10 (WDDM 1.3 to WDDM 2.0). And as we found out, some of those version checks are hard to deal with. The only solution seemingly is to correct VerifyVersionInfo in ntdll and of course, that means making wrappers for 7 and 8.1 with that and RtlGetVersion.

What updates do you have?

I do think so, but it may be a little difficult to find the exact culprit (hal.dll's timer-related functions are virtually identical between 6002 and 6519, maybe somewhere else is a problem). Technically MS partially fixed them in a very recent update, but other users have told me the improvements are too marginal for me to do anything about them. There is another option if I can never correct the problem in the files themselves, an "enforcer" that runs at boot that forces all services set to "automatic" to try and start again if they don't start initially, probably using sc.exe.

Yes, once the 32 bit kernel extensions are taken further.

No, I don't either. To add code, you can do so with any good hex editor by writing it to the area where you want it. It can be tricky translating offsets to memory addresses though. The current export table will probably have no room for expansion, which means you will have to use WildBill's PE Tool to create a new section before .rsrc that must fit the export table with up to a few thousand hexadecimal bytes for extra functions. BWC's PE Maker can be used to move (and add to) the export table. Then put the new code starting at the beginning of the old export table. The new imports thing is tricky, especially with a DLL that already has an import table. BWC managed to import new functions using some special set of routines which call LoadLibraryA and GetProcAddress. It may be possible to export forward some functions, like calling ntdll.RtlSetLastWin32Error when it is not imported. (mind you this failed when I tried with NtQueryInformationProcess in Vista x64 shell32). That is why I built completely new wrapper DLLs, where I can add new imports to a new import table at the end of the file using CFF Explorer (please let it make a new import table at first, otherwise it will put it in the reloc section which will kill the table if you ever add relocs) or Stud_PE. That and also I had trouble with importing certain functions in Vista x64 WOW64 so I had to call them directly. There are also some special considerations for NT4, as it appears you will need to upgrade existing functions in gdi32/user32 (and probably in other files too) and the kernel-mode analog, win32k, plus add functions in ntoskrnl. I think you can do this with wrappers, by taking the original file, deleting the export table entry for the existing entry and then replacing it with a forward export to the wrapper (but even then, you will need to give the export table some breathing room). The wrappers do seem to work with ring3-to-ring0 "stub" functions, like Nt/Zw* series in ntdll. As I also said, the functions exist in some very old NT (and even 9x) versions of Windows, but they may have changed over the years. So you could build extra wrappers with the updated functions and have my wrappers and existing Windows files refer to them instead of the outdated functions. I grant permission to other kernel extenders to use my upcoming wrapper DLLs for other Windows OSes, and to modify them to allow them to run on their OSes, as long as I remain credited (perhaps add a tag in company name field in file properties like "created by win32, modified by piotrhn for improved functionality with NT 4).

I don't have access to any Pentium-branded Haswells, Only that Kaby Lake i5 and someday, a Haswell i3 if its owner stops using it completely in favour of their phones and tablets. But I've never had any issues with software execution on my Xeon X5670 machine (which is somewhat similar to i7-970/980), including live local kernel debugging. It is quite possible that Vista x86 doesn't use whatever timer/hardware feature is responsible for these problems (if it is). Whatever design change has made Vista x64 so buggy on newer hardware seems to have been short-lived, as it is not in XP x64 or even Windows 7 build 6519 (from December 2007, so early in the development cycle). On the other end of the spectrum, I guess I could check some later Longhorn x64 builds (as in post-reset, as the reset point is 2003 SP1 RC) to see where this problem started, but they are typically very unstable compared to Windows 7 builds. Build 5048 wouldn't even install on a semi-period-correct ThinkPad T60 because it somehow didn't like the ACPI tables!

You will need Application Verifier: http://web.archive.org/web/20200803205552/https://download.microsoft.com/download/B/6/D/B6D4DF81-0C26-4BA5-BD57-50B7C0935421/ApplicationVerifier.amd64.msi It may or may not work. Go to application verifier (not the x64 one, as installers are usually 32 bit, even now) as it will appear in the start menu, Go to file -> add application and then go to "Tests". Make sure everything is unchecked except for HighVersionLie under Compatibility. Right-click properties and adjust major version to 6, minor version to 1, and build number to 7601. This may not work with the main installer, as it may be bootstrapped and the version check may be done with one of the child installers. You will probably need something like process hacker to track those down if that happens.

I'm not terribly sure that was the culprit. I think it is a hardware timer-based issue, in which Vista probably used a timer that was discontinued or became buggy with Haswell which XP x64 and 7 don't use, though I need confirmation. Local kernel debugging doesn't want to work for me on that laptop. LoadLibraryExW are quite similar on XP x64 and Vista.

Big news for users of 32 bit software: Having the ntdll and kernel32 functions in the same file has fixed the problems with importing certain ntdll functions, which means that 32 bit extended kernel development is going strong. Indeed, the functions in this wrapper import ones that are present in NT 3.51 and up (discounting RtlSetLastWin32Error from XP, but that could be thrown in easily), making this set of Windows 7 functions backportable to much older OSes in theory.

That is my kernel with no changes whatsoever! And also, I am testing my shellnew.dll wrapper. Calls to SetCurrentProcessExplicitAppUserModelID are succeeding. The other four I have yet to test due to the lack of maturity of ntk32, but I noticed a substantial side effect of decoupling the wrapper from shell32, in that the functions called by these functions are quite old. This means that the shellnew wrapper can be used on every Windows NT version dating back to Windows NT 4.0, and possibly all of Windows 9x, provided the functions are added to the shell32 export table and forward to shellnew. Shell_NotifyIconGetRect can be redirected as well on those OSes, and possibly NT 3.51 with NewShell, while the redirect to SHAssocEnumHandlers is not possible on anything below Vista as that function appeared with Vista.

Nope, there isn't a difference in the driver model or kernel of POSReady 2009 compared to regular XP.

Just add "z" to "mega.n" and you will be able to access the mega folder. I don't understand though, this seems to tie the timing problems to graphics drivers, and apparently this is fixed by installing XP ones. He said he added D3D9ex support, but the XP drivers I checked so far only have inf mods (many others are pure WDDM drivers). Using XP drivers is not a valid solution anyway. I want Vista to take advantage of DX 11.2, D3D12on7 (since it has problems on 8.x with its DX components) and Vulkan. That's not happening with XP drivers.