No subject

engine into GDI32 wherever applicable (so the current DIB-related
methods will be reimplemented with a possibly optional DIB engine).
This also seems to be in keeping with Max's end-goal architecture - to
integrate with GDI32.

A little while ago I was trying to run an app that uses Win16 DIB.DRV
(I forget which app it was). My research indicated that although
DIB.DRV was an actual driver (similar in architecture to Max's
proposed DIB engine) in Win16 systems, in Windows 95 the functionality
was rolled into GDI. For my app, this means that (in theory) exposing
appropriate, existing DIB functions to my Win16 app in the form of a
virtual DIB.DRV should work. For Max's engine, we're looking at
diverging from Microsoft's modern architecture and switching back to
something that was "good enough" 25 years ago.

We all know AJ wants things to be done "the right way" the first time.
I agree with this policy, because it makes for more maintainable code,
less duplication, etc. Wine's patch acceptance policy specifically
prohibits "hack it until it works, then worry about it later" style
programming, and the consensus of devs seems to be that adding a new
DIB *driver* as an intermediary between GDI32 and hardware drivers is
the wrong way to go about things.