compatibility vs. correctness

[Matthias Kupfer]

Hi folks,

yesterday a user shows me a program what is working properly under windows, 
but not working under reactos. It was an open source program and it was easy 
to figure out the problem. It was an invalid win-api-call (wrong parameter 
value). Due to this situation I would like to ask one question. How 
compatible reactos should be? Even fault compatible?

Matthias
-- 
Matthias Kupfer          Telefon [phone]
Wilhelm-Firl-Straße 21   Mobil [phone]
09122 Chemnitz

[Zachary Gorden]

In this instance, if it's the program's fault, we should get them to patch
their end of things.  Just because Windows was tolerant of this specific
sloppiness doesn't mean we should be.  What app was it anyways?  Cause if
it's an older one and was written for older versions of Windows, it might be
an issue that MS itself already fixed in later versions, but allowed the bad
call to go through for backwards compatibility purposes.

On Sun, Dec 7, 2008 at 11:25 AM, Matthias Kupfer [e-mail]:
> Hi folks,
>
> yesterday a user shows me a program what is working properly under windows,
> but not working under reactos. It was an open source program and it was
> easy
> to figure out the problem. It was an invalid win-api-call (wrong parameter
> value). Due to this situation I would like to ask one question. How
> compatible reactos should be? Even fault compatible?
>
> Matthias
>
> --
> Matthias Kupfer          Telefon [phone]
> Wilhelm-Firl-Straße 21   Mobil [phone]
> 09122 Chemnitz
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

Zachary Gorden wrote:
> Just because Windows was tolerant of this specific sloppiness doesn't mean

we should be.

I completely disagree.
We need to replicate the Windows API as closely as possible, warts and all.
This is what compatibility is all about

Ged.

[Zachary Gorden]

I suppose I should have phrased that statement better.  We know Windows let
that pass, and it was likely due to backwards compatibility.  But if that
code was compiled using something like VC++8, would it even be valid and
produce a binary that functioned the way you'd expect?  Case in point, in
Petzold's book, it talks about ways to access the HI/LOW values to deal with
the mousewheel, if I recall correctly.  If you tried to use that code and
compile it in VC++8, the resulting executable's mousewheel behavior would be
messed up.  However, if you ran the executables, the mousewheel would behave
as expected.  An instance of MS preserving backwards compatibility due to
sloppy/incorrect coding in old executables, but also them not letting you
continue to use that practice/method when you're writing new code or
recompiling the old code and essentially targeting newer versions of
Windows.

I suppose this boils down to what the app is, and what that app did to allow
it to take advantage of MS' maintaining backwards compatibility.  If we're
going to also reproduce the worts, we need to make sure we do so correctly.

On Sun, Dec 7, 2008 at 12:07 PM, Ged [e-mail] wrote:
> Zachary Gorden wrote:
> > Just because Windows was tolerant of this specific sloppiness doesn't
>
> mean
> we should be.
>
> I completely disagree.
> We need to replicate the Windows API as closely as possible, warts and all.
> This is what compatibility is all about
>
> Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

This makes no sense.

Can you please provide a specific example of what the API call was,  
and what the invalid parameter was?

On 7-Dec-08, at 1:22 PM, Zachary Gorden wrote:
> I suppose I should have phrased that statement better.  We know  
> Windows let that pass, and it was likely due to backwards  
> compatibility.  But if that code was compiled using something like VC 
> ++8, would it even be valid and produce a binary that functioned the  
> way you'd expect?  Case in point, in Petzold's book, it talks about  
> ways to access the HI/LOW values to deal with the mousewheel, if I  
> recall correctly.  If you tried to use that code and compile it in VC 
> ++8, the resulting executable's mousewheel behavior would be messed  
> up.  However, if you ran the executables, the mousewheel would  
> behave as expected.  An instance of MS preserving backwards  
> compatibility due to sloppy/incorrect coding in old executables, but  
> also them not letting you continue to use that practice/method when  
> you're writing new code or recompiling the old code and essentially  
> targeting newer versions of Windows.
>
> I suppose this boils down to what the app is, and what that app did  
> to allow it to take advantage of MS' maintaining backwards  
> compatibility.  If we're going to also reproduce the worts, we need  
> to make sure we do so correctly.
>
> On Sun, Dec 7, 2008 at 12:07 PM, Ged [e-mail] wrote:
> Zachary Gorden wrote:
> > Just because Windows was tolerant of this specific sloppiness
>
> doesn't mean
> we should be.
>
> I completely disagree.
> We need to replicate the Windows API as closely as possible, warts  
> and all.
> This is what compatibility is all about
>
> Ged.
>
> 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

Best regards,
Alex Ionescu

[Steven Edwards]

2008/12/7 Zachary Gorden [e-mail]:
> I suppose I should have phrased that statement better.  We know Windows let
> that pass, and it was likely due to backwards compatibility.  But if that
> code was compiled using something like VC++8, would it even be valid and
> produce a binary that functioned the way you'd expect?  Case in point, in
> Petzold's book, it talks about ways to access the HI/LOW values to deal with
> the mousewheel, if I recall correctly.  If you tried to use that code and
> compile it in VC++8, the resulting executable's mousewheel behavior would be
> messed up.  However, if you ran the executables, the mousewheel would behave
> as expected.  An instance of MS preserving backwards compatibility due to
> sloppy/incorrect coding in old executables, but also them not letting you
> continue to use that practice/method when you're writing new code or
> recompiling the old code and essentially targeting newer versions of
> Windows.

I am sure if if lower the NTDDI or WINVER variables then it will
compile a correct binary.
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Aleksey Bragin]

In fact, this is what Wine's regression tests are for too. They test  
not only correct, but also incorrect and tricky situations, where  
behavior is undocumented.

Certainly, I strictly disagree with offers like "let's enhance  
ReactOS API and add a few ROS-specific functions", "let's hack XXX  
WinAPI to do better parameters check", and similar things. Especially  
if there is a real-life testcase (like app you mentioned).

This all comes from the idea, that Microsoft(R) itself is not a  
stupid company, and if it is an indeed serious fault, it's fixed in a  
recent version of their operating system, thus enabling us to fix it  
also. If it's not, then we have to mimic it, otherwise forget about  
compatibility.

WBR,
Aleksey.

On Dec 7, 2008, at 9:07 PM, Ged wrote:
> Zachary Gorden wrote:
> > Just because Windows was tolerant of this specific sloppiness  
> > doesn't mean
>
> we should be.
>
> I completely disagree.
> We need to replicate the Windows API as closely as possible, warts  
> and all.
> This is what compatibility is all about
>
> Ged.

[Stefan Ginsberg]

I totally agree with this.
  If we reimplement the Win32 API, we have to replicate the exact behaviour that code expects -- not make up our own 'perfected Win32' clone. We don't define the Win32 API, we reimplement it. If our primary goal is application compatibility, then correctness _IS_ compatibility.
  You think that sucks? You want to improve the API? Hey, go implement some similar but 'perfected' API then -- but don't call it Win32. Win32 has never been like that.
> From: [e-mail]
> Date: Sun, 7 Dec 2008 23:17:23 +0300
> To: [e-mail]
> Subject: Re: [ros-dev] compatibility vs. correctness
>
> In fact, this is what Wine's regression tests are for too. They test  
> not only correct, but also incorrect and tricky situations, where  
> behavior is undocumented.
>
> Certainly, I strictly disagree with offers like "let's enhance  
> ReactOS API and add a few ROS-specific functions", "let's hack XXX  
> WinAPI to do better parameters check", and similar things. Especially  
> if there is a real-life testcase (like app you mentioned).
>
> This all comes from the idea, that Microsoft(R) itself is not a  
> stupid company, and if it is an indeed serious fault, it's fixed in a  
> recent version of their operating system, thus enabling us to fix it  
> also. If it's not, then we have to mimic it, otherwise forget about  
> compatibility.
>
> WBR,
> Aleksey.
>
> On Dec 7, 2008, at 9:07 PM, Ged wrote:
> > Zachary Gorden wrote:
> > > Just because Windows was tolerant of this specific sloppiness  
> > > doesn't mean
> >
> > we should be.
> >
> > I completely disagree.
> > We need to replicate the Windows API as closely as possible, warts  
> > and all.
> > This is what compatibility is all about
> >
> > Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

[Jeff Smith]

Ged wrote:
> Zachary Gorden wrote:
> > Just because Windows was tolerant of this specific sloppiness doesn't mean
>
> we should be.
>
> I completely disagree.
> We need to replicate the Windows API as closely as possible, warts and all.
> This is what compatibility is all about
>
> Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

My view is that we should implement ReactOS as 'the way Windows should 
have been' this could lead to faster or more stable environment. I also 
realize that Windows has a need for the warts in terms of compatibility. 
so What I think would make both camps happy (plus help troubleshooting 
issues in the future) is either make ReactOS correct, and release a 
'warts compatibility patch' that tries to implement the bugs for 
compatibility.

the other option would be to put the bugs for compatibility in, but have 
a program built into ReactOS that enables/disable the bugs for 
compatibility. This will do 1 major thing for the developers, it'll 
allow them to fix every bug without wondering if it has to be there for 
compatibility.

I intend to switch to ReactOS as soon as it's ready, in a perfect world 
ReactOS (atleast as I see it) would retain compatibility without the 
problems of Windows. I know this isn't a perfect world, I just hope my 
suggestion is of help.

[Maya Posch]

Like a kind of compatibility mode, yes. To me this makes the most sense 
as well. Strive for perfection first, then add a compatibility mode for 
the apps which didn't take the API docs too seriously. It also means 
that we'd be following the Win32 API 100% instead of merely copying 
'Real-Life' Windows, which to me is a good thing.

Maya

Jeff Smith wrote:
> My view is that we should implement ReactOS as 'the way Windows should 
> have been' this could lead to faster or more stable environment. I also 
> realize that Windows has a need for the warts in terms of compatibility. 
> so What I think would make both camps happy (plus help troubleshooting 
> issues in the future) is either make ReactOS correct, and release a 
> 'warts compatibility patch' that tries to implement the bugs for 
> compatibility.
>
> the other option would be to put the bugs for compatibility in, but have 
> a program built into ReactOS that enables/disable the bugs for 
> compatibility. This will do 1 major thing for the developers, it'll 
> allow them to fix every bug without wondering if it has to be there for 
> compatibility.
>
> I intend to switch to ReactOS as soon as it's ready, in a perfect world 
> ReactOS (atleast as I see it) would retain compatibility without the 
> problems of Windows. I know this isn't a perfect world, I just hope my 
> suggestion is of help.
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

I don't really know why everyone is discussing this. This isn't something
that's up for debate, this is the way it is and it's not going to change.
We replicate the Windows API's 100%, if this means introducing a flaw or
bug, then so be it. 
The original post from Collibri highlights why it's so important to do this.

Just so everyone knows the ReactOS stance on this:
- We must replicate the actual behaviour or the API's, not a personnal
preferred behaviour.
- MSDN should not be relied on, it isn't always correct.
- The Wine tests are designed for this exact thing, use them whenever
possible, or write your own test cases if it's not covered by them.
- The target usermode API we are aiming at is currently xp. Vista API's
(which we also implement) are an obvious exception to this.

If anyone feels compelled to improve the API's, then apply for a job at
Microsoft. This is where the API behavioural decisions are made, not in
ReactOS.

Hope that clears this up.

Ged.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jeff Smith
Sent: 08 December 2008 01:36
To: ReactOS Development List
Subject: Re: [ros-dev] compatibility vs. correctness

Ged wrote:
> Zachary Gorden wrote:
> > Just because Windows was tolerant of this specific sloppiness doesn't

mean
> >
>
> we should be.
>
> I completely disagree.
> We need to replicate the Windows API as closely as possible, warts and

all.
> This is what compatibility is all about
>
> Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

My view is that we should implement ReactOS as 'the way Windows should 
have been' this could lead to faster or more stable environment. I also 
realize that Windows has a need for the warts in terms of compatibility. 
so What I think would make both camps happy (plus help troubleshooting 
issues in the future) is either make ReactOS correct, and release a 
'warts compatibility patch' that tries to implement the bugs for 
compatibility.

the other option would be to put the bugs for compatibility in, but have 
a program built into ReactOS that enables/disable the bugs for 
compatibility. This will do 1 major thing for the developers, it'll 
allow them to fix every bug without wondering if it has to be there for 
compatibility.

I intend to switch to ReactOS as soon as it's ready, in a perfect world 
ReactOS (atleast as I see it) would retain compatibility without the 
problems of Windows. I know this isn't a perfect world, I just hope my 
suggestion is of help.
_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sylvain Petreolle]

Aren't Wine tests based on a personal preferred behaviour (not really sticking to windows in some cases) or MSDN ?
It would render them unreliable too.

Kind regards,
Sylvain Petreolle

Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net

----- Message d'origine ----
> De : Ged [e-mail]
> À : ReactOS Development List [e-mail]
> Envoyé le : Lundi, 8 Décembre 2008, 13h02mn 04s
> Objet : Re: [ros-dev] compatibility vs. correctness
>
> I don't really know why everyone is discussing this. This isn't something
> that's up for debate, this is the way it is and it's not going to change.
> We replicate the Windows API's 100%, if this means introducing a flaw or
> bug, then so be it. 
> The original post from Collibri highlights why it's so important to do this.
>
> Just so everyone knows the ReactOS stance on this:
> We must replicate the actual behaviour or the API's, not a personnal
>
> preferred behaviour.
> MSDN should not be relied on, it isn't always correct.
> The Wine tests are designed for this exact thing, use them whenever
>
> possible, or write your own test cases if it's not covered by them.
> The target usermode API we are aiming at is currently xp. Vista API's
>
> (which we also implement) are an obvious exception to this.
>
> If anyone feels compelled to improve the API's, then apply for a job at
> Microsoft. This is where the API behavioural decisions are made, not in
> ReactOS.
>
> Hope that clears this up.
>
> Ged.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jeff Smith
> Sent: 08 December 2008 01:36
> To: ReactOS Development List
> Subject: Re: [ros-dev] compatibility vs. correctness
>
> Ged wrote:
> > Zachary Gorden wrote:
> > > Just because Windows was tolerant of this specific sloppiness doesn't
>
> mean
> > >
> >
> > we should be.
> >
> > I completely disagree.
> > We need to replicate the Windows API as closely as possible, warts and
>
> all.
> > This is what compatibility is all about
> >
> > Ged.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> My view is that we should implement ReactOS as 'the way Windows should 
> have been' this could lead to faster or more stable environment. I also 
> realize that Windows has a need for the warts in terms of compatibility. 
> so What I think would make both camps happy (plus help troubleshooting 
> issues in the future) is either make ReactOS correct, and release a 
> 'warts compatibility patch' that tries to implement the bugs for 
> compatibility.
>
> the other option would be to put the bugs for compatibility in, but have 
> a program built into ReactOS that enables/disable the bugs for 
> compatibility. This will do 1 major thing for the developers, it'll 
> allow them to fix every bug without wondering if it has to be there for 
> compatibility.
>
> I intend to switch to ReactOS as soon as it's ready, in a perfect world 
> ReactOS (atleast as I see it) would retain compatibility without the 
> problems of Windows. I know this isn't a perfect world, I just hope my 
> suggestion is of help.
> _______________________________________________
> 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

[Magnus Olsen]

Wine test have helped me many times found bugs in our gdi32
I rember frist time I run it. it crash whole ReactOS after that
I started fixed each crash. After that I try fix bug after bug
that wine test show in gdi32. without them it should have
taken longer time to found some bugs or some bugs should
simple be missed. I say wine test is good, and real usefull.
But some test does not work on XP but works on 2000
same goes with VISTA. it show how stuff work diffent or
been broken also on windows betwin diffent version.

----- Original Message ----- 
From: "Sylvain Petreolle" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: Monday, December 08, 2008 6:32 PM
Subject: [ros-dev] Re : compatibility vs. correctness

Aren't Wine tests based on a personal preferred behaviour (not really 
sticking to windows in some cases) or MSDN ?
It would render them unreliable too.

Kind regards,
Sylvain Petreolle

Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net

----- Message d'origine ----
> De : Ged [e-mail]
> À : ReactOS Development List [e-mail]
> Envoyé le : Lundi, 8 Décembre 2008, 13h02mn 04s
> Objet : Re: [ros-dev] compatibility vs. correctness
>
> I don't really know why everyone is discussing this. This isn't something
> that's up for debate, this is the way it is and it's not going to change.
> We replicate the Windows API's 100%, if this means introducing a flaw or
> bug, then so be it.
> The original post from Collibri highlights why it's so important to do 
> this.
>
> Just so everyone knows the ReactOS stance on this:
> We must replicate the actual behaviour or the API's, not a personnal
>
> preferred behaviour.
> MSDN should not be relied on, it isn't always correct.
> The Wine tests are designed for this exact thing, use them whenever
>
> possible, or write your own test cases if it's not covered by them.
> The target usermode API we are aiming at is currently xp. Vista API's
>
> (which we also implement) are an obvious exception to this.
>
> If anyone feels compelled to improve the API's, then apply for a job at
> Microsoft. This is where the API behavioural decisions are made, not in
> ReactOS.
>
> Hope that clears this up.
>
> Ged.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jeff Smith
> Sent: 08 December 2008 01:36
> To: ReactOS Development List
> Subject: Re: [ros-dev] compatibility vs. correctness
>
> Ged wrote:
> > Zachary Gorden wrote:
> > > Just because Windows was tolerant of this specific sloppiness doesn't
>
> mean
> > >
> >
> > we should be.
> >
> > I completely disagree.
> > We need to replicate the Windows API as closely as possible, warts and
>
> all.
> > This is what compatibility is all about
> >
> > Ged.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> My view is that we should implement ReactOS as 'the way Windows should
> have been' this could lead to faster or more stable environment. I also
> realize that Windows has a need for the warts in terms of compatibility.
> so What I think would make both camps happy (plus help troubleshooting
> issues in the future) is either make ReactOS correct, and release a
> 'warts compatibility patch' that tries to implement the bugs for
> compatibility.
>
> the other option would be to put the bugs for compatibility in, but have
> a program built into ReactOS that enables/disable the bugs for
> compatibility. This will do 1 major thing for the developers, it'll
> allow them to fix every bug without wondering if it has to be there for
> compatibility.
>
> I intend to switch to ReactOS as soon as it's ready, in a perfect world
> ReactOS (atleast as I see it) would retain compatibility without the
> problems of Windows. I know this isn't a perfect world, I just hope my
> suggestion is of help.
> _______________________________________________
> 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