Advanced File Progress Dialog

[EmuandCo]

Extensions will not break compatibility as long as we do not interfere with ABI and regular API's behavior. It is the programmers' fault if they use wrong way of feature detection. GNU did many extensions on Unix staying source, and to a limited extent, binary compatible.

There is no wrong way to access APIs. We are no GNU Linux toy which may have it's own rules. And if it works in Windows and not in ROS then it's not the programmer's fault, then it's ours. If the entrypoints change or just the order of the APIs we are f***ed.

[erkinalp]

Publicly visible entrypoint change counts as ABI change. You can put as many calls entry points into non publicly-used parts of ABI as you like. Order of calls, on the other hand, can be wrapped via the compatibility system for userland calls.

[Z98]

You vastly underestimate the ability of programmers to utilize undocumented APIs. Especially seeing as ReactOS is open source. And no one has ever made a convincing case for why the project would want to extend the Win32 API. It doesn't make things easier for us, it actually increases work. Anything that the project's developers want to experiment with, they can do behind the scenes in the actual implementations without having to change the API or ABI. And speaking as a programmer that already has to deal with the differing API levels between XP, Vista, 7, and 8, the last thing I want is for ReactOS to suddenly add another extension that doesn't even exist on vanilla Windows.

[erkinalp]

And no one has ever made a convincing case for why the project would want to extend the Win32 API

There will exist many distributions of ReactOS in the future. Some of them will make modifications to provide a tighter integration for free software, say, Firefox or VLC. The users will request us to merge these extensions, because these extensions would make the aforementioned software faster with tight integration.

[PurpleGurl]

There is no wrong way to access APIs. We are no GNU Linux toy which may have it's own rules. And if it works in Windows and not in ROS then it's not the programmer's fault, then it's ours. If the entrypoints change or just the order of the APIs we are f***ed.

Well, I agree to a point. But I think the problem as Z98 has said before is if you have a chimera, and the program assumes it is a certain version when it checks for just one API, but the other APIs of that same version of Windows are not there, then it can get confused, crash, or run in a less than stable manner. If they were to check that all APIs of the assumed version were there, and then checked for the version below it if all were not there, then they could avoid problems.

But like you said, we don't have to worry about all that as long as we duplicate Windows behavior.

There will exist many distributions of ReactOS in the future. Some of them will make modifications to provide a tighter integration for free software, say, Firefox or VLC. The users will request us to merge these extensions, because these extensions would make the aforementioned software faster with tight integration.

I agree. That is like bundling IE into Windows. That was why IE still seemed faster than Firefox for a number of years, despite what the Firefox evangelists said. IE's renderer is a required component of Windows. Could you imagine a tightly-integrated Chrome (or Iron, Waterfox, Palemoon or similar for 64-bit)?

[EmuandCo]

There will exist many distributions of ReactOS in the future. Some of them will make modifications to provide a tighter integration for free software, say, Firefox or VLC. The users will request us to merge these extensions, because these extensions would make the aforementioned software faster with tight integration.

Well... nope. We don't have to do anything which does not follow our chosen path and this path is a Windows OS which is and stays binary compatible. Design stuff ... why not, but the WinAPI will NOT change.

[Tonix]

There will exist many distributions of ReactOS in the future. Some of them will make modifications to provide a tighter integration for free software, say, Firefox or VLC. The users will request us to merge these extensions, because these extensions would make the aforementioned software faster with tight integration.

In this moment there are not Reactos distribution other then the official, some one is planning to do one.
If someone fork the project is free to include integration for everything,
is free also to remove totally win32 subsystem.

The goal of reactos is to let avery application written for windows run on it,
and probably this target will never be reach and stop at 99% of compatibility.

Introduce innovation and api changes don't help to reach the target.

There is also another big problem in introducing API changes:

an application can check for an API that is reactos specific an refuse to run if it exist,
someone want this?

[erkinalp]

Yes, that means explicitly Windows only like some MS applications do in strange ways. This means they can do explicitly ReactOS only, too, which will broaden our userbase

[PurpleGurl]

There is also another big problem in introducing API changes:

an application can check for an API that is reactos specific an refuse to run if it exist,
someone want this?

I know who would have the most incentive to do that. Suppose you want the official Direct X and Open GL support and go to install DirectX 9.0c, and they get the message, "This product can only be installed on systems running Genuine Microsoft Windows." (Actually, that is a bad example, since Microsoft won't retroactively make software for a discontinued Windows version not work on anything but their discontinued Windows version.) Actually, it would be more damaging if NVidia or AMD were to pull something like that. And yes, I know who might want to push that. Microsoft might want to deny a "Certified" emblem to companies whose products will run on anything but Microsoft Windows. So then driver manufacturers might try to analyze to see if they are running on Windows or something very close.

[middings]

There will exist many distributions of ReactOS in the future. Some of them will make modifications...

Making a modification is making a commitment to maintain that modification's code. Forever, maybe.