win32

It will work, and I'm pretty sure that BWC's .NET 3.5 needs the extended kernel (only earlier beta releases don't).

It allows Firefox to use Windows 7 Media Foundation codecs, enabling playback of videos like Twitch and YouTube livestreams.

Those secur32 functions are forwarded from sspicli.dll, a file introduced in Windows 7. So on paper, only a few export entries need to be added to secur32 which is really easy to do. sspicli in turn delay-loads some functions from sechost.dll, which is also a semi-new file (since there are many existing functions as well as new ones). I tried something like this, and so far the latest version of Edge crashes silently. I'm trying to figure it out. And also, I compared Opera 47 (last to load all extensions) and 48 (first with problems) myself. A new locale-related function is called by 48: EnumSystemLocalesEx. ResolveLocaleName is imported by both. EnumSystemLocalesEx is in Vista, but it calls an underlying function that changed considerably between Vista and 7; one of which is that it calls a function that ResolveLocaleName relies heavily on (and was not in Vista until recently). That will have to be looked at.

Try unchecking everything except for HighVersionLie. But if you got it to load before, then those checks probably weren't enabled. Very strange that this is happening...

I think you may have got the x86 version.

I thought you were referring to updates to Chromium as a whole. This problem seems to go back earlier than even the extension problem. If Chromium and .NET didn't exist, my life would be a lot easier.

Weird. I did the same things as you. Removing opera took away the aero glass, but putting it back also put the glass. And also, it appears that CryptRetrieveTimeStamp and CryptVerifyTimeStampSignature need to be added to crypt32 to get LibreOffice 7.0.3 to work. I'll get on that.

You have to set it for opera.exe. Also, Application Verifier was purged when MS removed non-SHA-2 signed downloads: http://web.archive.org/web/20200802190511/https://download.microsoft.com/download/B/6/D/B6D4DF81-0C26-4BA5-BD57-50B7C0935421/ApplicationVerifier.amd64.msi Some people were speculating if the SHA-2 deprecation had something to do with the extended kernel release...

That is possibly due to it detecting Vista. I believe that it will refuse to update if it detects XP/Vista. The fix is to set NT 6.1 in Application Verifier (which will also fix Aero Glass in Opera instead of that XP appeasing junk).

I also modified an existing function to make it more true to the Windows 7 equivalent. It appears that this modification didn't go as planned, so that part has been reverted (the new function remains) and the file updated.

Since it is working fine, I added it to the folder but haven't decided to update the installer yet.

Not yet, as I planned to add this and several other functions (and some new modded dlls to run Chromium Edge) for a release later in the month.

Yes, with the switch enabled. But the issue with the sandbox breaking things is not related to the new function either, as I found out earlier today. Need to check it out further...

I added that function. Seems to be have some issues which prevent Opera 72 from launching with sandbox for now, but it works fine with --no-sandbox.

I haven't been able to help hardware support yet. I did get some ideas very recently about what is causing Haswell problems however. I am becoming convinced that the HAL needs to be modified to deal with the timing problems. As the HAL seems to be one of the more "protected" system files like ntdll and win32k, it could be tricky. Need to determine if that really is the culprit, by cross-comparing with 6519 and 7601 versions (the former also doesn't have timing problems). Believe me, my Kaby Lake laptop is really crummy but I'd like it a lot more if Vista were to function properly on it.

x86 builds of Firefox are still being made.

That .NET problem doesn't seem to be tied completely to the extended kernel. For example, with and without the extended kernel, here is the situation of the Visual Studio Community installer: .NET < 4.6: error message stating 4.6 is needed .NET 4.6/4.61: launches .NET 4.6.2+: exception in kernel32. Unfortunately .NET debugging is a little complicated but I should get to it soon if obfuscation isn't a problem.

Yes.

My inbox is open and is only 68% full, so there shouldn't be a problem. There are lots of posts relating to obscure Chinese software (like 360 extreme explorer, even though Qihoo 360 has numerous shady practices and the program in its default config connects to government-owned servers), so I don't think posting a link should be a problem.

Very interesting. I wonder what is this player? My idea of replacing the files is mostly to do with the initial setup of the audio devices, to see if it would create those extra registry entries.

I looked into that in the case of my hardware, which has both Vista and 7 installed. While it is Realtek audio, it seems that the extra reg info under that key being generated is a function of the OS and not the inf/drivers themselves, as the Realtek driver in this case is a Vista-era driver with no NT 6.1 section in its inf, used on both OSes. The oemx part is also automatically generated when the inf is copied to the Windows\inf folder. Probably a function of the sequence in which extraneous drivers are installed. Looking at the other keys under Audio, I see: Capture: same amount of devices, FxProperties is the same but Properties has more on 7. The same thing generally everywhere else. Not sure about the registry structure that would result from NVIDIA HD audio, but it must be similar. MMDevices falls under the MMDevice API (mmdevapi.dll), and the Windows 7 version seems to be compatible after some minor modifications. Though apparently not on its own, as Windows Audio service breaks and so does the Vista audio control panel (mmsys.cpl). Perhaps the rest of the audio subsystem needs to be replaced? mmsys.cpl just needs a missing function in comctl32.dll (version 5.82 branch). But W7's comctl32.dll doesn't need any W7 functions so that will be worth a try as well.

It is indeed used, so once again MS documentation is wrong. Though it is unclear what it is used for based on my disassembly. I would have to modify ntoskrnl, but with an important distinction: you can copy with a different name to your existing ntoskrnl and give it its own boot entry, keeping your existing ntoskrnl intact if problems arise.

Any method of updating through defender would rely on a method of enabling SHA-2 endpoints. I don't think I can say much about that here.

That would be the one used to enable local redirection. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options] "DevOverrideEnable"=dword:00000001 But, don't the latest definition updates work on Vista again as suggested above?

Based on further review of Chromium behaviour, it seems that on both Vista and 7 it does the same procedure to check for locales, using functions introduced in Vista or earlier. The error message indicates that the default locale is defined, but default data is not, presumably referring to the manifest data for the extensions. The nuclear solution would be to modify ntoskrnl and set its RtlGetVersion (also PsGetVersion to be sure, even though it is obsolete as of XP) to 6.1.7601, thus everything in kernel mode would think they are running on Windows 7. Personally I connect my GPU to my 15 year old monitor with DVI, and use Realtek onboard HD audio. On another note, the user-mode version check bypass in ntext is not as effective as possible, as I realized that VerifyVersionInfo functions call RtlVerifyVersionInfo which is presently only in ntdll, and thus uses ntdll's RtlGetVersion. However, RtlVerifyVersionInfo is a bit of a handful, and with the limitations on implementing ntext functions, it will take awhile.