win32

This still holds true for x64 Windows, where x86 and x64 versions of an ntdll function lead to one ntoskrnl function. So now I need to determine why the NtQueryInformationProcess implementation was good enough for x64 but not x86 K32* functions on Vista. So much to learn! And also user32/win32k should have a similar relationship for many of the former's functions, but what I've seen so far in win32k is ambiguous. There are offsets leading to tables like that, but they're scattered all over the place and not all of them lead to a function.

I am going to wait. All resources exhausted by Vista and 7.

maybe that specific part of dxgkrnl can be patched. but if it's like win32k.sys in Vista where changing a single byte anywhere causes a BSOD, then I'm not sure what to do. I don't plan much for 8.x right now anyway.

contrary to my earlier beliefs, I haven't found any specific NT 6.2 blocking code in the kernel mode driver (in fact there is Vista stuff in 17.9.3). So try replacing dxgkrnl.sys with the one from 8.1.

Not very many working ones, anyway. The K32* functions make all the difference for compatibility and the ones that are most commonly used fail with calls to NtQueryInformationProcess and NtQueryInformationThread. Same thing with some shell32 functions. I'm trying to find an alternative to upgrading the ntoskrnl versions of NtQueryInformationProcess and NtQueryInformationThread to the ones from Windows 7, as those are very time-consuming to change.

though you need the 32bit runtime for 32bit programs and the 64bit runtime for... you know.

Do you have the Visual C++ 2013 runtime installed?

I am going to come out and show what I referred to as project SUBJECT CLASSIFIED in the past to some people: People are starting to ask for newer programs to run on 7 and application compatibility is starting to collapse for the OS as well (though many of those incompatibilities remain truly forced for now). So a week ago I decided that it was about time to start a proactive response to the impeding avalanche (July 2021 or whenever Chromium is supposed to kill 7 support, and possibly .NET 5.0). In the four months working on Vista I learned many things which I will apply to this project. I had no idea what I was doing when I started this in mid-June, though after five days I realized what was necessary to get new applications running! Will it be difficult for me to manage the extension of four separate operating systems? Well, I think we will be back down to two in a few years as x86 slowly dies and the sources of our collective grief go x64 which is a considerably easier platform to expand on. Qihoo 360 is definitely ready...

yeah, i figured out major version and build number spoofing, but minor version spoofing seems to be harder. As I said before I will try to make an auxiliary function to indirectly feed it the minor version since directly feeding it fails.

I am planning on adding whatever Windows 8/10 functions are necessary for those versions of the browsers to work, so it should happen.

The best I can come up with is going to application verifier x86 and adding these files from the steam folders in program files and program files (x86): steam.exe steam_monitor.exe steamservice.exe steamwebhelper.exe then going to application verifier x64 and adding these: steamwebhelper.exe html5app_steam.exe x64launcher.exe For each one, go to Compatibility on the tree to the right of the file lists and check HighVersionLie. Then click on it and type 6 in major version, 1 in minor version, 7601 in build number and 1 in service pack major. Then "OK" and then save on the main window. A hex edit may also be needed for steam.exe, steam.dll and steamservice.dll if Steam starts complaining about the OS version: And use this so it doesn't react to the files being modified: And someday, I'll find a way to make Vista NT 6.1 so none of this will be needed.

You need to delete other attachments to free up space, or become a forum sponsor.

It would be very difficult to duplicate the work I did for the 2017-based files for those. But you may want to try local DLL redirection, where you add a key to the registry using one such file in the extended kernel folder, reboot, then copy the required files to each program's folder, then make a file in the program folder named xxxx.exe.local (where the program name is xxxx.exe). There are some limitations, but there should be a good chance of success for what you want to run. For future projects, I am considering ways to split off the extended functions into their own files so they don't disturb the original system files and are more resilient to updates. One-Core-API does something like adding the new functions forwarding to the new function file from the otherwise unchanged old system file, but that still means that updates will still replace the files, if not worse. The ideal solution would be to, for example, have kernel32 be nothing but forwards to two files: kernelol, which is the existing kernel32, and kernelex, which has the code for the new functions. Or even better, I could change the KnownDLLs entry for kernel32 to kernel33 (so hopefully, programs calling kernel32 will go to kernel33), and make the forwarder kernel33, the existing one kernel32 (so windows updates only update that file without any adverse effects), and kernelex.

There is some other non-Vista stuff I'm working on, and this would fit right in with it. But it would take longer because of the Vista stuff. And yes, everything from that "other" project will go back to Vista.

which version of .NET is it? Are you running it from the exe or msi?

Today, I learned something about those API Set DLLs (api-ms-win-core-*) while working on an auxiliary project (its contents will be eventually incorporated into this one). The legacy win32 subsystem DLLs like ole32/kernel32/user32 etc. started forwarding functions to the API Set DLLs in 7; this practice became more prevalent in 8 and 10. To the layman, it appears that these functions have been reduced to stubs, as they appear in the API Set DLLs. But many of the legacy DLLs are also being paired up with *base dlls (kernel32 = kernelbase, ole32 = combase, user32 = win32u(?). etc.). So I found that where an implementation does not exist in the legacy file, you must look in the corresponding base file. And that's where I found out that my implementations of VerLanguageInfoW and ResolveLocaleName were indeed useless stubs. Thus, a November update will be coming to fix those functions and possibly others affected by the same issue.

If there's a SP1 update, then it has been included in SP2. What are these .NET problems?

Extending DLLs by adding functions and new code will be the way to go. Anything else will typically result in failure.

Yes, it's definitely possible to extend the DLLs much like I've done for Vista. And perhaps something will be done for 7 as software continues to drop support for it. But starting with Windows 8 and especially with 10, things get weird with those One-Core API set DLLs. They make everything look very stubby.

Since Vista, Windows system files are language-neutral, with all language-specific resources being stored in .mui files. For the files in system32, you will find these in the en-US folder. Windows 9x displayed a message like "this program expects a newer Windows version. upgrade your Windows version." instead of falsely claiming that the program is not win32.

No. WMP11 as well. There are also many third-party applications in the past few years that draw Windows 7/8-style window borders even though they're on XP. Looks horrible, especially if the system in question has ClearType disabled.

No. USP 5.1 is just an alternative to SP4 UR1. HFSLIP includes DX9.0c, IE6 SP1, post-EOS updates, XP embedded updates etc. And nLite is also an alternative to HFSLIP; they almost do the exact same things.

That is the same thing as in the post above. While it does work somewhat, it stops working after returning from standby/hibernation. RMClock continues to work in such cases and works well on the T60, but is not an option for Westmere or newer.

What are those functions? Not long ago, I found out that there is a Windows 7 Pro key under my workstation, and I might just use it. I know that user32.SetCoalescableTimer is needed to run Office 2019 setup (Office 2019 itself does run on Windows 7, with the help of a script from MDL), so I might work on something for that.

Maybe DXVK would work. It does target Linux/WINE, but there has been success in using it for games on Windows 7: https://github.com/doitsujin/dxvk/releases download the tar.gz and extract the files in the x64 folder to your game folder. forget it. just realized there are no d3d12 binaries. Though I wonder what would happen if the DirectX graphics kernel was replaced with the one from W7 (dxgi.dll, dxgi.sys, etc.). I think if it works, then graphics drivers would work as on W7. Windows 10 beta/1507's files may also provide an opportunity.