win32

It is a bit of a precautionary step (I had trouble loading them with my initial modded mfplat.dll and the OS/subsystem minor versions untouched), but yes they do!

Using the W7 versions of mf.dll, mfplat.dll plus msmpeg2adec.dll and msmpeg2vdec.dll (plus my newest kernel32.dll), I have restored H.264/AAC support to newer Firefoxes. You will 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. The issues facing later releases of Chromium, as far as I can tell, seem to be rooted in RtlFreeOemString's subroutines, which seem to differ between Vista and 7. With this in mind, I may start tampering with ntdll.dll in spite of its lack of redirect-ability and its digital signature (which other usermode dlls lack; but that changes in Windows 8). If I were to start extending ntdll, you would have no choice but to boot with my version and likely have to disable driver signing enforcement (which is how I run my 2012R2 in order to use my GPU drivers anyway). While I'm at it I could add NtOpenKeyEx (which later Chromiums ask for) as well as RtlQueryPerformanceCounter in order to simplify the process of preparing new Firefoxes. And all of those functions that some installers call when running with my kernel32.dll! And maybe ensure that winSAT works when display drivers use my user32.dll!

It does seem quite possible, with the instructions given in the post referenced by @Ximonite. You can skip the hex modification part for win7's storport since Vista supports MSI interrupts.

Right now, it could help with the usermode parts of display drivers, but nothing for the kernel mode part yet.

Yes, it is.

A new bugfix for shell32.dll is to be released, where Shell_NotifyIconGetRect will now redirect to Shell_NotifyIconW due to some bugs with my implementation of the former which are fixed when calling the latter. SHAssocEnumHandlerForProtocolByApplication is also in the pipeline; however, the Opera components I looked at were all 32bit so that again will take awhile for those interested. As for the Windows codecs, it appears that these functions will needed to be added to the following files. Then we should be able to use the AAC/MPEG-4 decoders from Windows 7 (msmpeg2adec.dll and msmpeg2vdec.dll): kernel32 SetThreadIdealProcessorEx GetThreadGroupAffinity mfplat MFCopyImage MFCreateVideoMediaType MFGetStrideForBitmapInfoHeader Of course, some parts of those mfplat functions are hideously complex though. But I don't they'll beat my XP x64-based LoadLibraryExW rewrite (mostly done, but some subroutines need to be fixed up). On another note, by nop-ing the first few instructions of VerifyVersionInfoW in kernel32, you can effectively disable all version checks, with negative side effects like browsers thinking they're running on Windows 10 (so Serpent has the W10 appearance complete with oversized window controls on top of the native ones and newer Firefoxes expecting Windows 10 crash). I am considering offering a version of kernel32 with the gimped VerifyVersionInfoW to be used in cases where version checks are otherwise impossible to avoid.

Don't worry about it dude. You can create a video if you like.

I thought it was you, considering that the browsers are in German (yeah I actually did a DDG search for "Vista extended kernel" yesterday). What's funny though is that one of the recommended videos is "RIP Windows Vista 2006-2020", posted a few hours ago.

Orca is quite simple: all you have to delete (aka "dropping") the LaunchCondition table and the version checks are gone.

What is that driver? If it won't boot in safe mode, I have a feeling it's a very important driver like a disk controller driver or something like that.

So you just have SP2 with no further updates? I recommend having at least Platform Update and Platform Update Supplement. If not that, then try updating to Vista's EOL (my level of updating) or even use the later Server 2008 updates.

It isn't integrated into Windows 95 setup. It's in a separate folder on the CD-ROM.

Here is something that @XP-x64-Lover said awhile back. Perhaps it could be somewhat relevant to this situation: Perhaps Vista needs to be updated to at least 2018/19 level of updates. I'll look at the dumps when I can get back into Vista, as it's a real pill for me as well.

And look at that, Aero Glass is back. And it looks much better than the blue window borders in the last official versions. Remember, Vista is not XP! Visual Studio Code 1.46 (based off of Electron/Chromium 78) is working, as is PassMark PerformanceTest 10.0 x64 (except for the DX12 part obviously).

I am now running Vista x64 on my i5-7200U laptop, using UEFI-CSM and GPT. I used vLite to slipstream the hotfix and driver referenced in this thread: It is not digitally signed for NT 6.0 so I couldn't install it from USB as I hoped. Instead I extracted the contents of my vLited ISO to a folder and ran setup from within 2012R2. The first reboot failed with a blank screen, but setup ran smoothly after that. Later on, a prompt appeared for me to approve/reject an unsigned driver; that was the XHCI driver. Which works fine by the way. But Windows Update has proven very problematic. It took two attempts to install Platform Update Supplement and the system boots to a 0x1E BSoD after installing the 2018-11 full rollup. This cheat of installing Platform Update, Platform Update Supplement then the rollup worked in a VM I had recently set up but it appears I will have to go with the WSUS-based approach that I conjured up previously and hope it doesn't blow up in my face this time. Luckily Vista has a decent VHD-based imaging utility (Windows Complete PC Backup in Business, Enterprise and Ultimate) that will save my bacon next time around.

Not yet, but I've just installed Vista on my i5-7200U laptop and I'm working on getting my Intel HD Graphics 620 drivers working. That work should also benefit those using other GPUs. Also keep an eye on the NTOSKRNL extender project as that seems to have added many functions and also compiles for Vista x64.

shell32, right? I'll get to that soon.

Yes, TryAcquireSRWLockExclusive is present in the x64 kernel and will be in the x86 one. Thanks for explaining the decoder issue in detail as well; that part of Media Foundation was one I hadn't picked up on, especially with regards to the changes between Vista and 7. I could see the creation of a basic installer/script that dispatches a *.local folder with my files to a selected program folder with the program name indicated by the user. This could also check for the DLL redirection reg key; if not present, it could offer to apply it then prompt a reboot. But it would be difficult to have a solution for the replacement of system files as it would compete with the ESU updates that are still offered on a monthly basis and thus the files in those updates would continuously replace mine.

Yes, Widevine is also unable to find the MF files and Firefox 68/78 asks me to download the Media Feature Pack for N/KN versions of Windows. The mf.dll/mfplat.dll files are indeed less advanced than in 7 and above so perhaps I'll prioritize extending those files.

To fix that, you will have to copy kernel32.dll to system32 then delete it from the Firefox folder.

These shortcomings can be fixed if you copy kernel32 to system32 and delete it from the Firefox folder. However, the purpose of listing extended kernel-compatible software in a thread dedicated to indicating vanilla software compatibility is usually discouraged (see 98SE and XP threads). So I think a new thread should be started for extended kernel compatible software.

You must rename ole32x1.dll to ole32.dll. It was titled ole32x1 since that was part of my internal versioning system (shell32 is actually shell32x10, for example). But it doesn't reflect the other names in the directory so I'll change it.

But IE10? Well I think it was decoupled from the OS unlike IE4-6 so it may be possible but I see it as too much work for something that is almost obsolete. How well does it render anyway, nowadays?

Firefox 78 x64 does work, but you need to open up firefox.exe in CFF Explorer, go into the import table, select ntdll.dll and change the entry RtlQueryPerformanceCounter to NtQueryInformationProcess. I try to avoid touching ntdll as it's impossible to redirect it. Office 2013/16/19 doesn't work presently due to them using a 32bit installer and of course, the 32bit kernel isn't finished yet. But it appears that I will need SetWaitableTimerEx. And perhaps there will be more undocumented 32/64bit functions the programs themselves will need.

The inf of 451.67 for the MX110 still has sections for NT 6.2 and 6.3. Have you tried installing the inf through device manager? That inf even has entries for the RTX 2000 series under NT 6.2/6.3 even though NVIDIA only lists support for 7 and 10 on their site (only 10 for mobile GPUs).