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