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