DIB Engine : passing all tests

Massimo Del Fedele max at veneto.com
Wed May 27 02:11:56 CDT 2009


Ben Klein ha scritto:

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

I begin thinking to not be clear enough in what I write......
2 Last words:

1) Huw's starting engine *was* a driver's one, and many people told it was
the right way. Worse, it forked driver from inside gdi32, which was awful
to maintain.

2) My engine insertrs itself between gdi32 and the display driver; I begins
to be tired repeating that it's a step through the final design on where
DIB are handled fully inside gdi32. The step is, imho, necessary to split
DIB handling from DDB without having to rewrite at once half of gdi32 + half
of winex11.drv and maybe others.
It is *not* the final step, now it wants to be. It's made so to prepare
the switching in a painless way, *if* accepted.
If not, just prepare to have the sampe problems we had with mshtml
switching on each gecko change. In my case that broke a lot of stuffs.
> 
> 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.
again, I agree with that. Defining what is "the right way" is still a
mysterious matter.

  Wine's patch acceptance policy specifically
> prohibits "hack it until it works,

which hack ?????
  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.
> 

Strange enough, as the consensus on Huw's design was great, and it used
a *real* external driver, and *not* an intermediate one as mine.
But I start thinking that the requirements and consensus are very fluid and
moving matters, lately.

Btw, sorry all but I begins to be tired of telling same stuffs again and
again. I made a proposal for something that *could* help the migration to
final design, a *working* proposal, not just a prototype, and I believe on it.
If that's not what most devels think, for me is ok.
The engine will be available as a patch for whom needs/likes it, point.

Last work about accepting or not hacks: I never proposed such patches.
The most "hacky" stuff I sent (and was rejected, with a motivation that
could be right) was the addition of page size handling inside wineps.drv.
Motivation was that the printer driver shoul be rewritten for cups without
lpr usage. I agree. But by now *is* using lpr and *is* lacking support
for page size and other stuffs.
So I asked myself : it's better to wait up we have the "complete right code",
leaving the printer driver missing stuffs, or for the moment extend it while
waiting for the right one ? I would have chosen the second solution, but as usual
is a matter of taste.

Max




More information about the wine-devel mailing list