win32

I had to build my own api-ms-win-core-delayload-l1-1-0.dll and api-ms-win-core-delayload-l1-1-1.dll. I also had to make a patch to prevent it from continuously polling a non-existent ALPC port. I may also have to write a bcp47mm.dll to go along with it, because the DLL isn't working for much other than Chromium due to a null function pointer somewhere. The breakage point is between 5547 and 5555 as a result.

With the Vista extended kernel, I have managed to get up to 111.0.5520 working with sandbox, and up to about 111.0.5550 without sandbox. However there is some problem with shared memory brokering that has broken it in both cases. Couldn't map an API change to it yet, as this code is well abstracted from the win32 API.

This function was actually introduced in Windows 10. And WinHTTP functions are also needed for 112. I think most if not all of those were added in Windows 8.

This video is wrong. If it were the Longhorn kernel booting up, you would see the Longhorn logo appear instead of the XP one, as the bitmaps are stored in ntoskrnl. Also, other kernel mode system components would be incompatible. NTDLL would be incompatible due to a change in syscalls between 2600.5512 and 4074. XP still boots at all, because it does not actually boot from a kernel named ntoskrnl.exe; in this case, the user also has a file named ntkrnlpa.exe in their system32 folder. This is a variant of ntoskrnl for single-processor systems that support PAE. The user would have needed to change boot.ini to boot from ntoskrnl to actually try using this kernel. And it would probably fail early on due to incompatibilities with the HAL and the like. But I think you could get a DWM-type experience with XPDM if someone did a lot of hooking work to capture each window, seize the borders and captions, create bitmaps of window contents and "play" around with them to make animations, etc.

IE is no longer useful for web browsing. Old intranet stuff would likely not even benefit from IE10/11. But IE10/11 do have some limited uses in non-browsing situations; the license authentication for Autodesk products may still use it (but you can spoof IE10 in Group Policy and run it anyway), and the installer for Adobe CC products has used IE since 2015 or 17. Even the authentication component of Chromium Edge requires IE11. But I suspect these applications will have moved on from IE once I have implemented all the "black box" functions and "black box" function flags to existing functions that would make these newer browsers or at least rendering engines work. Also, I think it's hypocritical of Adobe to still depend on IE when they made such a big fuss over discontinuing their Flash players and timebombing the final versions.

Most of my precious time has been devoted to the Chromium issue, which is continuously unfolding as they gradually remove legacy codepaths. The job object server is nearly functional (right now it isn't, but Chromium seems to be OK with it, in --no-sandbox at least). Then I need to add some things to NtQueryInformationProcess and that should get Chromium 111 100% functional. Some more functions will need to be added for Chromium 112.

Version 8.0.0.0 (as written in the properties of the exe) from 2012. It is listed as an option under "rebuilder".

That would be the PE checksum. Tools like CFF explorer can set it automatically, but in this driver it is located at offset 170 and is this: 7B 1D 09 01 01 00 E0 01 00 00 04 00 00 00 00 00 This would be changed to: E1 69 09 01 01 00 E0 01 00 00 04 00 00 00 00 00

Find this line: 84 C0 74 0A B8 BB 00 00 C0 E9 B9 18 00 00 44 38 and change it to EB 0C 74 0A B8 BB 00 00 C0 E9 B9 18 00 00 44 38

https://github.com/win32ss/win32-api-reversals But this is not complete. There are many functions I implemented by copying over blocks of hex codes from newer DLLs, because I did not know C well at the time. There are some other functions that are too messy for me to put up ATM. Here is the installer source code (needs to be updated to support copying to places other than System32/SysWOW64, installing drivers, and adding a GUI): https://github.com/win32ss/nt6-unofficial-update-installer-engine And this tool builds a list of export pragma directives for a wrapper. It supports PE32, PE32+, and both named and ordinal-only exports: https://github.com/win32ss/export_pragma_builder

2. Try GetProcessIoCounters. 3. It is hard to find a suitable one for K32GetModuleInformation, maybe try FindFirstStreamW. As for K32GetProcessMemoryInfo, I meant to say GetEnvironmentVariableA. It should fit in there.

I think CloseHandle may also work. Maybe QueryProcessAffinityUpdateMode. Possibly QueryFullProcessImageNameW and GetEnvironmentVariable respectively. If those are the only two functions imported from kernel32, you can change the import DLL name to psapi.dll and the function imports to GetModuleInformation and GetProcessMemoryInfo.

Yes, I did. No difference in performance. I believe it is because of a call to NtAlpcSendWaitReceivePort that should only be made once, to obtain some cache information; however it never receives it, which means this call is made constantly until it can be received, or it probably gives up after an untold number of calls and gets on with the loading process. So there is an ALPC port in Vista that seems to be unable to answer a certain type of message required by DirectWrite.

I now got it running on Vista in --no-sandbox mode after making some adjustments to locale API to allow Windows 10's dwrite.dll to load. However, the performance is very poor. It now takes up to a minute to launch the browser instead of it taking a few seconds. It should be easier to get dwrite.dll on 7 (no kernel32 functions need to be modified/upgraded on 7), but 7 still won't be able to run these new versions of Chromium because no changes have been made to the job object API there. There is also the possibility that performance will be very poor as well. VxKex will provide that and more, eventually.

No.

It is possible it checks the file versions of nvlddmkm.sys or nvd3dumx.dll. In my case the version is written as 24.21.13.9811. So it would have to be changed to 24.21.14.4229 using a resource editor or by searching for the version values in a hex editor (these are UTF-16 characters).

Does your nvcpl look like this? Still using 398.11 on the GTX 650. I never had nvwss.dll, and yes, only that mobile option is available for some reason.

I found that there are ultimately four reasons why Chromium is broken on NT 6.x: 1. New imports in kernel32 and userenv. They can all be stubbed, not hard to fix. (Vista/7; 8.x has them) 2. Use of job object APIs in ways that are only supported on 8.x (without sandbox) and 10 (with sandbox) 3. Use of new NtQueryInformationProcess class for enumerating process handles; if it can't be used, the content process will be terminated (8.0 and below, sandbox only) 4. Use of new DirectWrite factories, like IDWriteFactory3, which was introduced in Windows 10 #1 is taken care of, I'm getting there with #2 and then I should be able to do #3. #4's solution is actually quite simple; copy over a Windows 10 DWrite.dll to use with Chromium using DLL redirection methods (I used 10.0.17763.1 and I think 10240 and up should work too). Then patch these DLL names in the import table with a hex editor or CFF explorer: api-ms-win-core-libraryloader-l1-2-0.dll -> kernel32.dll api-ms-win-core-localization-l1-2-2.dll -> kernel32.dll This is sufficient to run the latest Chromium browser snapshot on Windows 8: Right now there are truly missing functions on Windows Vista and 7, in api-ms-win-core-delayload-l1-1-0.dll and api-ms-win-core-delayload-l1-1-1.dll. Some of those return function pointers so they can't be stubbed.

Yes it does, but it uses some different syntax (FirefoxFix=1 instead of BuildNumber=7600 for fixing Firefox fonts, for example).

No it would not work. The problem is that UpdateProcThreadAttribute does not support Job Objects as an attribute until Windows 10 (actually since build 98xx where it works too). I actually suppressed the UpdateProcThreadAttribute error on Vista and it does not "crash" as such, but pages do not work, probably because it still does not actually initialize the job objects as such.

You are correct. I see that 382.16 is an "iCafe" driver and that most of the NVCPL components were removed, even though the inf still has all the "instructions" to install it. I did make a package combining the 382.16 driver with NVCPL components from 381.65 (untested for now because I am still working on job objects), but if that is not required, the byte sequences in the other thread are valid for modding the driver.

strnlen. Maybe it could be temporarily replaced by strlen.

The 38x drivers actually added a function that was removed from the 39x versions, which I did not add yet. Oddly enough I do have notes about 382/384 drivers, which apparently reached a black screen instead of outright crashing (or producing an orb). I suppose I could add it soon. The orb may be caused by conflicts with other drivers. Do you have a discrete NIC and/or are you using unofficial USB 3.x drivers?

The Chrome version 110 will come out in February, and Chromium-based browsers and applications will base themselves off 110 starting from then. Right now it is still somewhat obscure. Opening a file and checking its version information would be slower than what GetVersionEx does, which is to make a call to another function which accesses a data structure located in memory. But Chromium already did both and still does now. I think the big difference is that some Windows 8+ specific code paths are still being skipped in Opera.

The October 2020 version works if it is set to "big picture" mode. You will see store information and everything. But sometime after that, the login window switched to being rendered by CEF (Chromium) so it is not possible to sign in as there is no text, graphics or buttons on the login screen now. As for the Intel drivers, I have a couple of systems that can use them but they are in very poor shape. Various differences in rendering quality are known to exist between Vista and 7 and I don't want Vista to be compromised by any changes I do. So I'll try to do something that doesn't "change" Vista to its detriment. Also, the Vista extended kernel will be able to run Chromium 110 and 111, at least with --no-sandbox. I will try to get the sandbox working in time for the main release of Chromium 110 in February. I am adding the appropriate functions to kernel32 and userenv. I just checked the Chromium source code and discovered that the version nags are persistent now because they are not calling GetVersionEx* or similar to check the version, but they are checking the version number of kernel32 instead.