Programs that heavily rely on NT 6.x APIs list

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Quim
Posts: 193
Joined: Wed Jul 04, 2018 11:45 pm

Programs that heavily rely on NT 6.x APIs list

Post by Quim » Fri May 24, 2019 2:30 am

We should have a list of these programs that heavily rely on NT 6.x APIs....

dizt3mp3r
Posts: 1412
Joined: Mon Jun 14, 2010 5:54 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by dizt3mp3r » Fri May 24, 2019 10:47 am

Should we? Instead should ReactOs not just implement all the NT5 APIs, then all s/w that uses NT6 APIs will simply fail.

The NT6 APIs can be implemented one by one.

We don't need a list of Programs that heavily rely on NT 6.x APIs we just need a list of programs that fail on ReactOs.

karlexceed
Posts: 435
Joined: Thu Jan 10, 2013 6:17 pm
Contact:

Re: Programs that heavily rely on NT 6.x APIs list

Post by karlexceed » Fri May 24, 2019 4:17 pm

I mean... The easiest way is to look for:

"System requirements: Windows Vista or newer."

Quim
Posts: 193
Joined: Wed Jul 04, 2018 11:45 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by Quim » Sun May 26, 2019 5:11 am

karlexceed wrote:
Fri May 24, 2019 4:17 pm
"System requirements: Windows Vista or newer."
There are some Windows Vista + programs that are runnable in ReactOS.
The point is what applications require a true NT 6.x kernel (even using compatibility shim, NT 5.2 kernel cannot help to run these apps).

Quim
Posts: 193
Joined: Wed Jul 04, 2018 11:45 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by Quim » Sun May 26, 2019 5:30 am

karlexceed wrote:
Fri May 24, 2019 4:17 pm
"System requirements: Windows Vista or newer."
There are some Windows Vista + programs that are runnable in ReactOS.
The point is what applications require a true NT 6.x kernel (even using compatibility shim, NT 5.2 kernel cannot help to run these apps).
With software specifically leaving NT5 behind, ReactOS is expanding its target to support NT6+ (Vista, Windows 8, Windows 10) software. Colin, Giannis and Mark are creating the needed logic in NTDLL and LDR for this purpose. Giannis has finished the side-by-side support and the implicit activation context, Colin has changed Kernel32 to accept software made for NT6+, and Mark keeps working on the shim compatibility layer. Although in a really greenish and experimental state, the new additions in 0.4.8 should start helping several software pieces created for Vista and upwards to start working in ReactOS. Microsoft coined the term backwards compatibility, ReactOS the forward compatibility one.
From https://reactos.org/project-news/reactos-048-released

wdstudios
Posts: 35
Joined: Mon Aug 13, 2018 8:53 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by wdstudios » Tue May 28, 2019 8:16 pm

karlexceed wrote:
Fri May 24, 2019 4:17 pm
I mean... The easiest way is to look for:

"System requirements: Windows Vista or newer."
You'd think so, but a lot of these restrictions are arbitrary and artificial. I know from experience that World of Warcraft could be run on Windows XP for quite a while after XP support was officially dropped. All you needed was some special kind of SHA support. For 32-bit versions of XP, this came with Service Pack 3, but for x64 Edition, I had to hunt down some specific updates. Now there's an artificial restriction where the game is programmed to check your OS and throw an error message if it doesn't like what it finds, regardless of whether or not it could actually run.

karlexceed
Posts: 435
Joined: Thu Jan 10, 2013 6:17 pm
Contact:

Re: Programs that heavily rely on NT 6.x APIs list

Post by karlexceed » Tue May 28, 2019 11:01 pm

Quim wrote:
Sun May 26, 2019 5:30 am
The point is what applications require a true NT 6.x kernel (even using compatibility shim, NT 5.2 kernel cannot help to run these apps).
What API call would a program make that couldn't be emulated via a forward-compatibility shim?
wdstudios wrote:
Tue May 28, 2019 8:16 pm
a lot of these restrictions are arbitrary and artificial.
I said it was easiest, not most precise... :D

Plus, from a normal end-user perspective, if software says it needs Vista and runs without complaint using a Vista shim, then that's just a technicality.

Quim
Posts: 193
Joined: Wed Jul 04, 2018 11:45 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by Quim » Wed May 29, 2019 6:52 am

karlexceed wrote:
Tue May 28, 2019 11:01 pm
What API call would a program make that couldn't be emulated via a forward-compatibility shim?
Drivers for modern hardware (Windows 7 + and now Windows 10) is a good example. Unless there is some kind of compatibility shim that can emulated NT 6.x driver support under NT5.2 kernel...

PurpleGurl
Posts: 1762
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Programs that heavily rely on NT 6.x APIs list

Post by PurpleGurl » Wed May 29, 2019 8:27 am

There seems to be a misunderstanding here and a misuse of "shims." The idea is to have actual API sets that will work with the newer programs. A shim almost implies adding stubs or tweaking parameters to fool the program into running. So instead of adding fake APIs to trick anything, real APIs will be subbed in as needed on the fly. So set the program as requiring a newer version and ROS will give it what it needs. At least that's my understanding of how they want it to be. And to tweak that more, maybe they could make it to trapping errors about things being missing and launch it again as the version that calls for the missing APIs, and dynamically enabling that API set as needed. And it could even record the version adjustment in the registry so in the future, it just runs with the correct APIs the first time without needing to play detective. There should be no problem with things not running if there is a complete and reliable API set for each.

Drivers is a totally different matter and is not the same as dealing with apps. I don't think there is a way to reliably create driver shims or get HAL to announce a different kernel version on a driver by driver basis. I am not sure how that could be done, and it seems like it would increase the complexity and harm performance. For instance, what if there were multiple kernels of differing versions and each version running whatever drivers that were made for it. I am not sure how that could be pulled off, and even if it could, imagine the complexity. And imagine someone using drivers of not only other versions but ones that are incompatible with the HW. I am not sure how you'd recover from that except for a special recovery console that can identify and remove the culprit(s). But if multiple kernels of different reported versions could be used, I would like it made to where the others don't run unless needed. Still to me, going down this road sounds like a nightmare.

Thinking more about the above driver idea, I wonder if going with NT6 would make that any easier. I think Windows 7 has an intermediate driver layer or something. I think this because you can replace certain drivers under Windows 7 without a reboot. So you can use sound and networking almost immediately. So it is like there is a drivers' driver that allows for dynamic situations. So if the drivers have an abstraction layer of their own, then maybe my previous idea about running multiple kernels, or at least fragments of kernels doesn't sound as absurd. I'm mostly just brainstorming.
Last edited by PurpleGurl on Fri May 31, 2019 1:19 pm, edited 2 times in total.

wdstudios
Posts: 35
Joined: Mon Aug 13, 2018 8:53 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by wdstudios » Wed May 29, 2019 9:44 am

karlexceed wrote:
Tue May 28, 2019 11:01 pm
Plus, from a normal end-user perspective, if software says it needs Vista and runs without complaint using a Vista shim, then that's just a technicality.
As I already pointed out, that's a huge "if". Can a shim be made that deliberately mis-reports the Windows version number when programs check for it?

PurpleGurl
Posts: 1762
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Programs that heavily rely on NT 6.x APIs list

Post by PurpleGurl » Wed May 29, 2019 10:11 am

Actually, instead of a "shim," it would be a real Vista/7+ API. Since programs can be confused by the presence of newer APIs than reported, ROS will simply supply the missing APIs on demand. The files involved might be given different names and then proxied to use whatever API set requested. And the OS could keep track of which versions of APIs are used by which programs. That is much like the SxS stuff.

As for misreporting versions upon requesting newer APIs, I don't see why not. For instance, why not intercept the error message and run the program again being reported as the newer version and making the newer APIs available? Then of course, it can edit the compatibility database in the registry so it simply knows to report a newer version and provide a newer API set.

I am not sure how wise it would be to report a newer version only after encountering an API, since it might have already asked for the version. But that seems unlikely since if it is asking for newer APIs, then it likely doesn't know the version. And again, it should record to the registry as soon as it discovers one of the newer API sets is required.

karlexceed
Posts: 435
Joined: Thu Jan 10, 2013 6:17 pm
Contact:

Re: Programs that heavily rely on NT 6.x APIs list

Post by karlexceed » Wed May 29, 2019 4:16 pm

Quim wrote:
Wed May 29, 2019 6:52 am
Drivers for modern hardware
Drivers =/= applications. Drivers are so closely tied to the kernel and have such a large impact on overall system performance and stability that using any kind of compatibility mechanism seems foolish.
wdstudios wrote:
Wed May 29, 2019 9:44 am
Can a shim be made that deliberately mis-reports the Windows version number when programs check for it?
Doesn't Windows do this with their Compatibility Mode functionality?
When a program shall run in compatibility mode, then the shim is put between the application and the shim replaces the GetVersionEx function, so that the application does not call GetVersionEx from kernel32.dll but the GetVersionEx in the shim. The shimmed functions then implement the behaviour of previous Windows versions. GetVersionEx is an easy sample, each Windows version returns its own version numbers in GetVersionEx, so when faking an old Windows the GetVersionEx function now not returns the Windows 7 version numbers but for example the Windows XP version numbers. So the application will believe it is running on Windows XP.
From: https://superuser.com/questions/133746/ ... ndows-work

How compatibility shims work on Windows:
https://docs.microsoft.com/en-us/previo ... 4(v=ws.10)

wdstudios
Posts: 35
Joined: Mon Aug 13, 2018 8:53 pm

Re: Programs that heavily rely on NT 6.x APIs list

Post by wdstudios » Wed May 29, 2019 9:23 pm

karlexceed wrote:
Wed May 29, 2019 4:16 pm
Doesn't Windows do this with their Compatibility Mode functionality?
Good luck finding a Win7 compatibility mode when using XP. That would be proof that Microsoft is secretly in possession of a time machine.

karlexceed
Posts: 435
Joined: Thu Jan 10, 2013 6:17 pm
Contact:

Re: Programs that heavily rely on NT 6.x APIs list

Post by karlexceed » Wed May 29, 2019 10:30 pm

Aside from the fact that XP is still receiving patches and therefore could in theory be aware of newer versions of Windows; you only asked about a shim mis-reporting the version of Windows in general, not whether or not it did so for newer versions. And this is exactly what ReactOS will do in theory - the "forward compatibility" that Quim quoted from the 0.4.8 release notes. The method of accomplishing this is the same whether going forward or reverse.

PurpleGurl
Posts: 1762
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Programs that heavily rely on NT 6.x APIs list

Post by PurpleGurl » Wed May 29, 2019 11:14 pm

However, ROS is gong beyond just misreporting the version. They already are using some NT 6 APIs due to Wine. They didn't want to keep having to rewrite a number of parts in Wine, so better to just give it what it needs. So some NT 6 API support is already here.

The devs said in other places that they would come up with a forward compatibility system that would give the right versions of APIs for the programs that need them. So software that can run on XP is not given access to the newer APIs we have or may add, while the newer ones are. Due to the need for NT 6 APIs for some internal components and the desire of so many to run newer stuff, the devs are working on different compatibility with the newer versions besides mere shims. The other things needed to pull this off already exist, such as side-by-side assemblies (SxS).

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests