[ros-dev] 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 :-)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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 

>
> As our target is win2k3 sp1 compatibility,
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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  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 

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.___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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 >



As our target is win2k3 sp1 compatibility,


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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 

>  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 
>
>>
>> As our target is win2k3 sp1 compatibility,
>
>
> ___
> Ros-dev mailing list
> ros-...@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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   
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
Ros-dev@reactos.org
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.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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---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  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
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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-- 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



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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 >



As our target is win2k3 sp1 compatibility,


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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  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 
  

As our target is win2k3 sp1 compatibility,

  
  
___
Ros-dev mailing list
Ros-dev@reactos.org
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.___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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 

>  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 
>
>>
>> As our target is win2k3 sp1 compatibility,
>
>
> ___
> Ros-dev mailing list
> ros-...@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Colin Finck]

Ged Murphy  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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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  wrote:

> Ged Murphy  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
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Samuel serapion]

Doesn't windows use SxS to provide multiple versions of some dlls? I know
its not for exacly the same purpose but perhaps coupled with some sort of
app compat wizard we could really set hard version targets... but ofcourse
it would mean building many dlls more than once
On Nov 13, 2010 2:09 PM, "Colin Finck"  wrote:
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Colin Finck]

Ged Murphy  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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Javier Agustìn Fernàndez Arroyo]

what about just try to make a Windows XP (the most widely desktop OS used
nowadays) clone?
this discussion can only be finished in a bad way for ReactOS IMO

On Sat, Nov 13, 2010 at 7:36 PM, Samuel serapion wrote:

> Doesn't windows use SxS to provide multiple versions of some dlls? I know
> its not for exacly the same purpose but perhaps coupled with some sort of
> app compat wizard we could really set hard version targets... but ofcourse
> it would mean building many dlls more than once
> On Nov 13, 2010 2:09 PM, "Colin Finck"  wrote:
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[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  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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Timo Kreuzer]

Am 13.11.2010 19:36, schrieb Samuel serapion:
>
> Doesn't windows use SxS to provide multiple versions of some dlls? I
> know its not for exacly the same purpose but perhaps coupled with some
> sort of app compat wizard we could really set hard version targets...
> but ofcourse it would mean building many dlls more than once
>

With the approach I described above (wrapper dlls) you would compile the
code once and only a number of wrapper dlls that forward the exports
would be linked several times. It also saves disk space.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev