7 Dec
2008
7 Dec
'08
6:22 p.m.
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 <gedmurphy(a)gmail.com> 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
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev