win32

You have to follow these steps to load my custom osloader.exe and ntkrnlmp.exe: In CMD, do this: bcdedit /copy {current} /d "Windows Vista Unlocked" Keep note of the GUID value you get in this form: {91274567-89ab-cdef-00ff-nca000ffffff}. Replace this with whatever value you get when you copy it. Then do these commands: bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} nointegritychecks 1 bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} path \Windows\system32\osloader.exe bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} kernel ntkrnlmp.exe

Strange. Is my osloader.exe present? If it is, try making a new entry like this: bcdedit /copy {current} /d "Windows Vista Test" ...and see if it works.

Do bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} detecthal 0 (replacing the value in the brackets with yours, of course)

Nope, there isn't. What do you get when you run bcdedit? Odd. But apply the reg key, reboot then make a folder named explorer.exe.local in X:\Windows (X being the drive letter where Windows is installed) and place the MS version of shell32.dll there.

ntkrnlmp.exe is available again, as I have managed to make it work. What's different about it? -New section added at end of file -Export table moved to this section -Version number changed to 6.1.6002.19741 What was breaking it in the first place? Rebuilding its PE Header. The same thing happens on XP x64. Just update the checksum and you'll be fine. Once again, I wonder how the version change will affect newer drivers. For brevity, here are the installation instructions: I will start patching it accordingly, and hope to bring ntdll in the fold soon. Both ntdll and kernel32 may also be bumped to version 6.1, as it appears that some Qt 5.10+ binaries like to not load after a version check.

WineD3D takes DX10/11 calls on 2000/XP and translates them to OpenGL calls. To have real DX10/11 on XP/2003 would require working WDDM drivers. But even getting newer WDDM 1.1 drivers on Vista (earlier ones work) is going to be very difficult, so I can't imagine XP. Apparently some people have hacked WDDM support into Server 2003, but I never found proof.

The "sign in" icon differs between classic and Polymer. Classic's "sign in" has those words in a solid blue rectangle. Polymer's "sign in" icon has those words blue-on-white in a blue-bordered rectangle next to an avatar icon. Which invidio.us instance is the best? I can't use Polymer on my Pentium M laptop as it's impractically slow.

Not at this time, as I still have to figure out large chunks of Vista. I'd really want to focus on NT 5.2 (XP x64 and Server 2003) anyway, though, and it may play second fiddle to Windows 7. But application compatibility issues on Windows 7 are not very real either, and no true win32-based replacement exists for the OS even though it's 11 years old.

Nope, it needs functions in user32: SetGestureConfig, CloseGestureInfoHandle and GetGestureInfo. I have an extended x86 user32 somewhere but I don't have it here with me. Though it doesn't rely much on the outmoded ntdll functions so I think a release is in order soon. And it's hard to force an install using Application Verifier, as you need to trick the temp file it creates (seemingly), and its name changes every time it's created. But even a x86 kernel32 with a borked VerifyVersionInfoW changes nothing.

http://web.archive.org/web/20200810043039/https://download.microsoft.com/download/7/3/D/73D3721D-17E7-4D7A-9C64-5CCD0DD285B1/Windows6.1-KB2483177-x64.msu

I discovered that I was unable to load ntoskrnl even if I replaced the MS signature with a custom one. This method is used in a tutorial to reinstate proper PAE support in Vista x86. I think bootmgr needs to be modified as well in order for it to work. But I've had a few other things happen in my life lately (for example, right now, most sounds, sound warped to me) so I haven't been able to do as much as I've wanted to do so. And then I'm still trying to work out ntdll and LoadLibraryExW.

I think that XP x64 can have most of the Vista kernel extension work ported to it. Many ntdll functions that have remained the same between Vista and 7 x64 are also identical in XP x64! And no system files have authenticode digital signatures attached to them so it would actually be easier. But I don't think it would be worth it unless you could get WDDM and UEFI working as well as in Vista.

Copy over the W7 versions of mf.dll, mfplat.dll plus msmpeg2adec.dll and msmpeg2vdec.dll to system32. You may have to use a tool like CFF Explorer to change the Operating System and Subsystem Versions from 6.1/6.2 to 6.0 before applying these files to your system. You're not the first one who has reported that error. You'll have to find it somewhere, since it's a pretty standard Windows system file.

Are you using 64bit Firefox? Did you apply the reg from the extended kernel folder? Did you make a file named firefox.exe.local in the Firefox folder?

Yes, it's working again on 95 for me. But what a day to pick to shun it, even if it ended up being temporary.

so it loads ntoskrnl.exe anyway. Thus I'm pulling the modified file for now. For this reason, I'm returning to the drawing board for ntoskrnl.

I apologize for this apparent mishap. This is what detecthal = 1/true actually does (from https://geoffchappell.com/notes/windows/boot/bcd/osloader/detecthal.htm): so it loads ntoskrnl.exe anyway. Thus I'm pulling the modified file for now.

I'm very puzzled by this. I repeated my own steps - success. Replaced the ntkrnlmp file with the one from the mega folder - success. Then I noticed that I had detecthal = yes which none of you had. So I changed one to no (0) and I got the same error. So, I'll add this to the instructions bcdedit /set {91274567-89ab-cdef-00ff-nca000ffffff} detecthal 1

So, the same as me. What results do you get when you run bcdedit (without parameters) in CMD?

I'm running on this kernel right now. What's your level of updates and version number of current ntoskrnl.exe?

File temporarily pulled due to quality control issues.

I'm working on an Haswell+-specific issue, which is completely unrelated to the Ryzen problems. Luckily someone posted kernel dumps of their Ryzen crashes earlier on (I have no Ryzen myself, and literally no room for it), so I'll try to correct those issues once I start seriously modifying ntoskrnl (I already changed the version to 6.1 and moved the export table to a new section at the end of file, and have no issues). And didn't you say that you ran Vista on Ryzen too? Were there any issues with your config?

Yep, I had overlooked the fact that all NT 6 OSes use the exact same boot manager/loader. In fact, I now recommend installing Vista after 8.x/10 as an easy way to escape the Metro boot screen.

Then, it will not work until the 32bit version of shell32.dll is released. It may take some time because its functions are very buggy.