ReactOS official compatibility target and the new build system

[Jérôme Gardou]

Dear reactos developers.

Once again, bringing reactos build to cmake arises questions. When this 
"port" has begun, it was decided that import libraries would be shipped 
with build environment, the now famous RosBE.

This decision was made considering that :
     1) functions exported by dlls do not change often.
     2) Building an import library is a process that requires unneeded 
extra time.
     3) 1 makes 2 unworthy.
     4) If dll A imports function from dll B, it's not necessary to 
build B before A.
     5) Solving 4 solves the problem of cross-dependency.

As our target is win2k3 sp1 compatibility, a wise choice would be to 
choose import libraries that expose function only present on win2k3 sp1. 
The problem is that some wine dlls export functions that are from other 
windows versions, and, worse, use them.
Let's see why this is a problem.
     - function A is a vista function from dll foo
     - function B is an XP function from dll bar
     - for some reasons, B implementation calls A.
As you're clever developers ;-), you've seen that this would raise an 
error from the linker, as A is not present in our libfoo.a

Hopefully, those cases are not too widespread, but they exist.

Let's consider solutions that have arisen as of now :
     1) Implement A as an inline function in headers, so anyone 
requiring it has it.
     2) Linking bar.dll to some winefoo.dll, which forwards everything 
from foo.dll and exports the function A.
     3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, 
and "#else" with a win2k3 compliant implementation.
     4) Oh dreams -> Ideally, convince wine to do it themself 
(./configure --wintarget=2k3sp1).
     5) Change our target to win7, so we're ahead of wine. :-p
     6) Do not change anything, and let our user mode libraries be a 
complete inconsistent anarchy.

As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6:
     1 is the best solution for easy winesyncs. We guard inline 
implementation by #ifndef BUILDING_FOO_DLL
     2 would put a whole mess in system32 directory, but should be the 
most easy thing to do.
     3 requires some extra work when syncing wine dlls. Though doing it 
often would reduce hassle.
     6 isn't what I'd wish.

What do you think? Your input is much appreciated.
Best regards.
The french speaking cmake team :-)

[Ged Murphy]

The target is only win2k3 in the kernel. Everything else is open to
discussion (in fact, IMO even the kernel compatibility is open to
discussion)

You should, and must, provide as much functionality as possible with the
latest versions of Windows.
You can still provide many of the capabilities of Windows 7 using only an
NT5.2 kernel. It's only the internal architecture which limits this, and in
terms of many win7 capabilities, this kernel isn't a limiting factor.

2010/11/13 Jérôme Gardou [e-mail]
> As our target is win2k3 sp1 compatibility,

[Adam Kachwalla]

You could probably provide the compatibility on an NT 3.1 kernel if you  
tried hard enough. After all that's where it all started; newer versions  
just added more services and made a stupid mistake of putting the GUI in  
kernel space (while it increased performance of the GUI significantly, it  
also means the OS is now more vulnerable to crashes)

On Sat, 13 Nov 2010 13:10:37 +1100, Ged Murphy [e-mail] wrote:
> The target is only win2k3 in the kernel. Everything else is open to  
> discussion (in fact, IMO even the kernel compatibility is open to
> > discussion)
>
> You should, and must, provide as much functionality as possible with the  
> latest versions of Windows.
> You can still provide many of the capabilities of Windows 7 using only  
> an NT5.2 kernel. It's only the internal architecture which limits >this,  
> and in terms of many win7 capabilities, this kernel isn't a limiting  
> factor.
>
> 2010/11/13 Jérôme Gardou [e-mail]
> > As our target is win2k3 sp1 compatibility,
-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Jérôme Gardou]

This policy is inconsistent with the fact that we advertise reactos as 
win2k3 sp1. Otherwise we should as well provide a config applet to let 
the user choose that, as wine does.

Le 13/11/2010 03:10, Ged Murphy a écrit :
> The target is only win2k3 in the kernel. Everything else is open to 
> discussion (in fact, IMO even the kernel compatibility is open to 
> discussion)
>
> You should, and must, provide as much functionality as possible with 
> the latest versions of Windows.
> You can still provide many of the capabilities of Windows 7 using only 
> an NT5.2 kernel. It's only the internal architecture which limits 
> this, and in terms of many win7 capabilities, this kernel isn't a 
> limiting factor.
>
> 2010/11/13 Jérôme Gardou <[e-mail] 
> mailto:[e-mail]>
> As our target is win2k3 sp1 compatibility,
>
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

Wine can do that as they only provide usermode. (we actually allow something
slightly along these lines by allowing the user to decide whether they're
running on a server or workstation. It's an option in one of the cpl
applets)
If you did what Wine do then the user would expect to interface with a
Windows 7 kernel too, meaning they would try to install drivers for said
version.

What I meant is that you must advertise as a certain version for the kernel
so the user knows what they're dealing with.
However this does not stop you from adding features of the later kernels,
nor does it stop you from adding services and APIs from later versions. The
more you add the more likely you are to run more modern software.

In fact, my point about full win2k3 compatability being up for discussion at
the kernel is directly related to this. I think you _should_ be adding
features from the newer kernels where possible. This will greatly reduce the
amount of work required if the decision is ever made to leap to the NT6
kernel. however you must advertise to users that it's still an NT5.2 kernel
so any drivers required will load.

Ged.

2010/11/13 Jérôme Gardou [e-mail]
> This policy is inconsistent with the fact that we advertise reactos as
> win2k3 sp1. Otherwise we should as well provide a config applet to let the
> user choose that, as wine does.
>
> Le 13/11/2010 03:10, Ged Murphy a écrit :
>
> The target is only win2k3 in the kernel. Everything else is open to
> discussion (in fact, IMO even the kernel compatibility is open to
> discussion)
>
> You should, and must, provide as much functionality as possible with the
> latest versions of Windows.
> You can still provide many of the capabilities of Windows 7 using only an
> NT5.2 kernel. It's only the internal architecture which limits this, and in
> terms of many win7 capabilities, this kernel isn't a limiting factor.
>
> 2010/11/13 Jérôme Gardou [e-mail]
> > As our target is win2k3 sp1 compatibility,
>
> Ros-dev mailing list
> [e-mail]://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

I fully agree with Ged. There is no reason to think "I won't do something a better way because it's implemented poorly in Win2k3, and ROS's official target is Win2k3". All what is said applies mainly to the kernel, and ideally in future our Win32 subssytem should have shim support for compatibility modes, and should share as much nice arcitectural features from Win7 as possible.

WBR,
Aleksey Bragin.

From: Ged Murphy 
Sent: Saturday, November 13, 2010 1:45 PM
To: ReactOS Development List 
Subject: Re: [ros-dev] ReactOS official compatibility target and the newbuild system

Wine can do that as they only provide usermode. (we actually allow something slightly along these lines by allowing the user to decide whether they're running on a server or workstation. It's an option in one of the cpl applets) 
If you did what Wine do then the user would expect to interface with a Windows 7 kernel too, meaning they would try to install drivers for said version.

What I meant is that you must advertise as a certain version for the kernel so the user knows what they're dealing with.
However this does not stop you from adding features of the later kernels, nor does it stop you from adding services and APIs from later versions. The more you add the more likely you are to run more modern software.

In fact, my point about full win2k3 compatability being up for discussion at the kernel is directly related to this. I think you _should_ be adding features from the newer kernels where possible. This will greatly reduce the amount of work required if the decision is ever made to leap to the NT6 kernel. however you must advertise to users that it's still an NT5.2 kernel so any drivers required will load.

Ged.

2010/11/13 Jérôme Gardou [e-mail]

This policy is inconsistent with the fact that we advertise reactos as win2k3 sp1. Otherwise we should as well provide a config applet to let the user choose that, as wine does.

Le 13/11/2010 03:10, Ged Murphy a écrit : 
    The target is only win2k3 in the kernel. Everything else is open to discussion (in fact, IMO even the kernel compatibility is open to discussion)

You should, and must, provide as much functionality as possible with the latest versions of Windows.
    You can still provide many of the capabilities of Windows 7 using only an NT5.2 kernel. It's only the internal architecture which limits this, and in terms of many win7 capabilities, this kernel isn't a limiting factor.

2010/11/13 Jérôme Gardou [e-mail]

As our target is win2k3 sp1 compatibility,

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
  Ros-dev mailing list
  [e-mail]
  http://www.reactos.org/mailman/listinfo/ros-dev

--------------------------------------------------------------------------------

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Adam Kachwalla]

I am also in agreement here. And there are some things I'll admit that NT  
5.2 doesn't do as well as NT 6.1 does... like for example lack of UIPI and  
UAC (may a bird poo on my head such that I do not get shot for saying  
that) and the ever so old GINA system for example.

And of course why not a compatibility shim? Maybe we can get the best of  
both worlds: the compatibility of NT 5.2 and stability of NT 6.1 (sorry  
for sounding like a CEO)

On Sat, 13 Nov 2010 22:02:42 +1100, Aleksey Bragin [e-mail]  
wrote:
> I fully agree with Ged. There is no reason to think "I won't do  
> something a better way because it's implemented poorly in Win2k3, and  
> ROS's official target is Win2k3". All what is said >applies mainly to  
> the kernel, and ideally in future our Win32 subssytem should have shim  
> support for compatibility modes, and should share as much nice  
> arcitectural features from >Win7 as possible.
> WBR,
> Aleksey Bragin.
>
> From: Ged MurphySent: Saturday, November 13, 2010 1:45 PM
> To: ReactOS Development ListSubject: Re: [ros-dev] ReactOS official  
> compatibility target and the newbuild system
>
> Wine can do that as they only provide usermode. (we actually allow  
> something slightly along these lines by allowing the user to decide  
> whether they're running on a server or >workstation. It's an option in  
> one of the cpl applets)If you did what Wine do then the user would  
> expect to interface with a Windows 7 kernel too, meaning they would try  
> to install drivers for said version.
>
> What I meant is that you must advertise as a certain version for the  
> kernel so the user knows what they're dealing with.
> However this does not stop you from adding features of the later  
> kernels, nor does it stop you from adding services and APIs from later  
> versions. The more you add the more likely >you are to run more modern  
> software.
>
> In fact, my point about full win2k3 compatability being up for  
> discussion at the kernel is directly related to this. I think you  
> _should_ be adding features from the newer kernels where >possible. This  
> will greatly reduce the amount of work required if the decision is ever  
> made to leap to the NT6 kernel. however you must advertise to users that  
> it's still an NT5.2 kernel >so any drivers required will load.
>
> Ged.
>
> 2010/11/13 Jérôme Gardou [e-mail]
> > This policy is inconsistent with the fact that we advertise reactos as  
> > win2k3 sp1. Otherwise we should as well provide a config applet to let  
> > the user choose that, as wine does.
> >
> > Le 13/11/2010 03:10, Ged Murphy a écrit :
> > > The target is only win2k3 in the kernel. Everything else is open to  
> > > discussion (in fact, IMO even the kernel compatibility is open to  
> > > discussion)
> > > You should, and must, provide as much functionality as possible with  
> > > the latest versions of Windows.
> > > You can still provide many of the capabilities of Windows 7 using only  
> > > an NT5.2 kernel. It's only the internal architecture which limits  
> > > this, and in terms of many win7 >>>capabilities, this kernel isn't a  
> > > limiting factor.
> > >
> > > 2010/11/13 Jérôme Gardou [e-mail]
> > > > As our target is win2k3 sp1 compatibility,
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Timo Kreuzer]

I have thought about the multiple Windows version thing some time ago
and had some ideas.
One idea is to Reorganize the functionality, similar to the way it's
done in Windows 7.
some of the win32 dlls would become wrapper dlls and forwarding to the
actual implementations. These wrapper dlls would be tiny and we could
have different sets of wrapper dlls for different windows versions. They
might also forward to different implementations of the same api on
different versions if required. This could be done on runtime, with
something similar to sxs, only user configurable rather than manifest based.

So instead of importing the vista function RegDeleteTree from
kernel32.dll a wine dll would import it from something like
API-ROS-Core-Registry.dll

This way we could as well cleanup our dependency tree and layout stuff
more window 7 alike

[Jérôme Gardou]

Then let's have a kernelbase.dll, as win7 does.

Le 13/11/2010 12:16, Timo Kreuzer a écrit :
> I have thought about the multiple Windows version thing some time ago
> and had some ideas.
> One idea is to Reorganize the functionality, similar to the way it's
> done in Windows 7.
> some of the win32 dlls would become wrapper dlls and forwarding to the
> actual implementations. These wrapper dlls would be tiny and we could
> have different sets of wrapper dlls for different windows versions. They
> might also forward to different implementations of the same api on
> different versions if required. This could be done on runtime, with
> something similar to sxs, only user configurable rather than manifest based.
>
> So instead of importing the vista function RegDeleteTree from
> kernel32.dll a wine dll would import it from something like
> API-ROS-Core-Registry.dll
>
> This way we could as well cleanup our dependency tree and layout stuff
> more window 7 alike
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Adam Kachwalla]

The only issue here is that we'd have to duplicate a lot of coding effort  
 from Wine - if we are to use most Wine code then we don't have to bother.  
We can just use the existing Wine DLLs as they are at this stage.

IMO if it ain't broke, don't fix it. :)

On Sat, 13 Nov 2010 22:16:11 +1100, Timo Kreuzer [e-mail]  
wrote:
> I have thought about the multiple Windows version thing some time ago
> and had some ideas.
> One idea is to Reorganize the functionality, similar to the way it's
> done in Windows 7.
> some of the win32 dlls would become wrapper dlls and forwarding to the
> actual implementations. These wrapper dlls would be tiny and we could
> have different sets of wrapper dlls for different windows versions. They
> might also forward to different implementations of the same api on
> different versions if required. This could be done on runtime, with
> something similar to sxs, only user configurable rather than manifest  
> based.
>
> So instead of importing the vista function RegDeleteTree from
> kernel32.dll a wine dll would import it from something like
> API-ROS-Core-Registry.dll
>
> This way we could as well cleanup our dependency tree and layout stuff
> more window 7 alike
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Ged Murphy]

Microsoft already provide similar technology known as virtual dlls.
It was a technology designed for MinWin.

They split functionality of dlls into ‘api sets’  These can be seen in Win 7
in the system32 dir with the prefix ‘api-ms-win-core--<num of>-1-0.dll’.
WinMin components link against these virtual dlls which load up the real
libs listed in apisetschema.dll.
However this involves modification to the loader.

On 13 November 2010 11:16, Timo Kreuzer [e-mail] wrote:
> I have thought about the multiple Windows version thing some time ago
> and had some ideas.
> One idea is to Reorganize the functionality, similar to the way it's
> done in Windows 7.
> some of the win32 dlls would become wrapper dlls and forwarding to the
> actual implementations. These wrapper dlls would be tiny and we could
> have different sets of wrapper dlls for different windows versions. They
> might also forward to different implementations of the same api on
> different versions if required. This could be done on runtime, with
> something similar to sxs, only user configurable rather than manifest
> based.
>
> So instead of importing the vista function RegDeleteTree from
> kernel32.dll a wine dll would import it from something like
> API-ROS-Core-Registry.dll
>
> This way we could as well cleanup our dependency tree and layout stuff
> more window 7 alike
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Am 13.11.2010 12:31, schrieb Ged Murphy:
> Microsoft already provide similar technology known as virtual dlls.
> It was a technology designed for MinWin.
>
> They split functionality of dlls into ?api sets?  These can be seen in
> Win 7 in the system32 dir with the prefix ?api-ms-win-core--<num
> of>-1-0.dll?. WinMin components link against these virtual dlls which
> load up the real libs listed in apisetschema.dll. 
> However this involves modification to the loader.

Not, if we really put the code into these libraries instead of making
them virtual libraries that are being redirected again to kernelbase.dll

[Jérôme Gardou]

So, for kernel we keep our own importibs, adding exports one after the 
other while we implement them, and for user mode dlls we keep win7 
compatible ones?

We need an official stance on this matter.

Le 13/11/2010 03:10, Ged Murphy a écrit :
> The target is only win2k3 in the kernel. Everything else is open to 
> discussion (in fact, IMO even the kernel compatibility is open to 
> discussion)
>
> You should, and must, provide as much functionality as possible with 
> the latest versions of Windows.
> You can still provide many of the capabilities of Windows 7 using only 
> an NT5.2 kernel. It's only the internal architecture which limits 
> this, and in terms of many win7 capabilities, this kernel isn't a 
> limiting factor.
>
> 2010/11/13 Jérôme Gardou <[e-mail] 
> mailto:[e-mail]>
> As our target is win2k3 sp1 compatibility,
>
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Adam Kachwalla]

Sounds like a plan. And then gradually implement necessary kernel  
functionality as it is needed.
On Sun, 14 Nov 2010 01:18:36 +1100, Jérôme Gardou  
[e-mail] wrote:
> So, for kernel we keep our own importibs, adding exports one after the  
> other while we implement them, and for user mode dlls we keep >win7  
> compatible ones?
>
> We need an official stance on this matter.
>
> Le 13/11/2010 03:10, Ged Murphy a écrit :
> > The target is only win2k3 in the kernel. Everything else is open to  
> > discussion (in fact, IMO even the kernel compatibility is >>open to  
> > discussion)
> > You should, and must, provide as much functionality as possible with  
> > the latest versions of Windows.
> > You can still provide many of the capabilities of Windows 7 using only  
> > an NT5.2 kernel. It's only the internal architecture >>which limits  
> > this, and in terms of many win7 capabilities, this kernel isn't a  
> > limiting factor.
> >
> > 2010/11/13 Jérôme Gardou [e-mail]
> > > As our target is win2k3 sp1 compatibility,
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Ged Murphy]

This has always been the official stance back from the day when Thomas
implemented the first usermode Vista API in reactos.
We've had this discussion many times from that moment.

Kernel targets 2k3 (additionally with any newer architecture if possible /
applicable.
Usermode targets the latest version of Windows.

Ged.

2010/11/13 Jérôme Gardou [e-mail]
> So, for kernel we keep our own importibs, adding exports one after the
> other while we implement them, and for user mode dlls we keep win7
> compatible ones?
>
> We need an official stance on this matter.
>
> Le 13/11/2010 03:10, Ged Murphy a écrit :
>
> The target is only win2k3 in the kernel. Everything else is open to
> discussion (in fact, IMO even the kernel compatibility is open to
> discussion)
>
> You should, and must, provide as much functionality as possible with the
> latest versions of Windows.
> You can still provide many of the capabilities of Windows 7 using only an
> NT5.2 kernel. It's only the internal architecture which limits this, and in
> terms of many win7 capabilities, this kernel isn't a limiting factor.
>
> 2010/11/13 Jérôme Gardou [e-mail]
> > As our target is win2k3 sp1 compatibility,
>
> Ros-dev mailing list
> [e-mail]://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Ged Murphy [e-mail] wrote:
> Kernel targets 2k3 (additionally with any newer architecture if possible
> / applicable.
> Usermode targets the latest version of Windows.

This means that we always need to ensure that applications properly 
detect ReactOS as NT 5.2 all the time and don't expect features of newer 
Windows versions. Otherwise they could make false assumptions about the 
kernel capabilities.

Unfortunately, this isn't always the case as demonstrated e.g. by 
r39384. For some reason, the VMware Tools Installer (which of course 
supports NT 5.x), tried to import NT6-specific functions like wcsncpy_s 
from msvcrt.dll.
It's most-likely related to the fact that our msvcrt.dll still had the 
version number 42.4.0.0 at that time, but shows a problem that can arise 
if we mix targets.

The version number of msvcrt.dll has been changed to that of the 
corresponding DLL in 2k3 SP1 later on, but let's assume that we had 
implemented all NT6-specific functions in msvcrt.dll and changed the 
version number to that of the Vista DLL.
Some poorly written application might assume that it runs on Vista now 
and expect much more from the whole system: Other DLLs should be the 
Vista versions as well, some Vista-specific features might be requested 
and it might even attempt to use the NT6 version of a bundled driver.
This is of course a very specific case, but we cannot reliably say that 
no such Windows application exists.
We can only prevent these problems by providing an OS targetting a 
single Windows version from kernel-mode up to user-mode.

Therefore I appreciate Jérôme's option 3) for targetting a single 
Windows version (NT 5.2) while at the same time enabling us to add code 
for a later target change.

Most of our DLLs still have that 42.4.0.0 version number by the way, so 
this should be another thing to fix to ensure compatibility.

Cheers,

Colin

[Ged Murphy]

You misinterpreted what I said.
I didn't say usermode reports as being Win7, I said it can and should target
features of Win7.

Usermode should and does report as NT5.2.
It actually doesn't have a choice as the APIs which you use in usermode to
discover the version (GetVersionEx, VerifyVersionInfo) actually query
hardcoded values stored in the kernel.

Ged

On 13 November 2010 18:07, Colin Finck [e-mail] wrote:
> Ged Murphy [e-mail] wrote:
> > Kernel targets 2k3 (additionally with any newer architecture if possible
> > / applicable.
> > Usermode targets the latest version of Windows.
>
> This means that we always need to ensure that applications properly detect
> ReactOS as NT 5.2 all the time and don't expect features of newer Windows
> versions. Otherwise they could make false assumptions about the kernel
> capabilities.
>
> Unfortunately, this isn't always the case as demonstrated e.g. by r39384.
> For some reason, the VMware Tools Installer (which of course supports NT
> 5.x), tried to import NT6-specific functions like wcsncpy_s from msvcrt.dll.
> It's most-likely related to the fact that our msvcrt.dll still had the
> version number 42.4.0.0 at that time, but shows a problem that can arise if
> we mix targets.
>
> The version number of msvcrt.dll has been changed to that of the
> corresponding DLL in 2k3 SP1 later on, but let's assume that we had
> implemented all NT6-specific functions in msvcrt.dll and changed the version
> number to that of the Vista DLL.
> Some poorly written application might assume that it runs on Vista now and
> expect much more from the whole system: Other DLLs should be the Vista
> versions as well, some Vista-specific features might be requested and it
> might even attempt to use the NT6 version of a bundled driver.
> This is of course a very specific case, but we cannot reliably say that no
> such Windows application exists.
> We can only prevent these problems by providing an OS targetting a single
> Windows version from kernel-mode up to user-mode.
>
> Therefore I appreciate Jérôme's option 3) for targetting a single Windows
> version (NT 5.2) while at the same time enabling us to add code for a later
> target change.
>
> Most of our DLLs still have that 42.4.0.0 version number by the way, so
> this should be another thing to fix to ensure compatibility.
>
> Cheers,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Ged Murphy [e-mail] wrote:
> Usermode should and does report as NT5.2.
> It actually doesn't have a choice as the APIs which you use in usermode
> to discover the version (GetVersionEx, VerifyVersionInfo) actually query
> hardcoded values stored in the kernel.

Sure, but you don't consider the example I've given (VMware Tools 
Installer).
We were already reporting ReactOS as NT 5.2 at that time, but obviously 
the installer just queried the msvcrt.dll version to determine its 
features. And when finding out that it's 42.4.0.0, it consequently 
expected Vista features we were missing.

What I want to say is that we cannot just report ReactOS as NT 5.2 
through the common version functions, but also need to ensure that the 
DLLs have the same versions as their NT 5.2 counterparts.
And when this has been changed, adding APIs of newer Windows versions 
(like wcsncpy_s) would hardly make any sense if we don't need them to 
please some Wine-synced DLLs using newer APIs.

Colin

[Jérôme Gardou]

Imagine an even worse written application :
fptr = GetProcAdress(hDll, "SomeVistaExport");
if(fptr)
     Vista = TRUE;

I know at least one application that does it, and this is... wine tests!

Le 13/11/2010 19:41, Colin Finck a écrit :
> Ged Murphy [e-mail] wrote:
> > Usermode should and does report as NT5.2.
> > It actually doesn't have a choice as the APIs which you use in usermode
> > to discover the version (GetVersionEx, VerifyVersionInfo) actually query
> > hardcoded values stored in the kernel.
>
> Sure, but you don't consider the example I've given (VMware Tools 
> Installer).
> We were already reporting ReactOS as NT 5.2 at that time, but 
> obviously the installer just queried the msvcrt.dll version to 
> determine its features. And when finding out that it's 42.4.0.0, it 
> consequently expected Vista features we were missing.
>
> What I want to say is that we cannot just report ReactOS as NT 5.2 
> through the common version functions, but also need to ensure that the 
> DLLs have the same versions as their NT 5.2 counterparts.
> And when this has been changed, adding APIs of newer Windows versions 
> (like wcsncpy_s) would hardly make any sense if we don't need them to 
> please some Wine-synced DLLs using newer APIs.
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev