Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

Mike McCormack mike at
Wed Mar 29 05:15:47 CST 2006

Willie Sippel wrote:

> Probably true. But Wine has several problems where a 'real' fix is so very 
> complicated that we won't see something anytime soon, probably for years to 
> come (like the DIB engine, planned for years, but nobody seems to even work 
> on it). In the recent two years, Wine became unusable for many users - I even 
> know some guys that switched back to Windows because of 'fixes' to Wine that 
> render lots of application unusable, due to regressions expected when those 
> fixes were commited. Those 'fixes' should never make it into CVS if there's 
> not even a realistic timeframe for fixing the regressions. 

How do you propose that we figure out if there's going to be regressions 
or not before the patches are committed?

Isn't it just better to start with a patch that is "right", but will 
still show regressions, then fix those regressions, as opposed to 
starting with a patch that is wrong, and then hacking on it forever 
trying to solve the unsolvable problems that causes?

> The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering 

My counter example is richedit.  As a half-baked wrapper around the edit 
control, it rotted in the CVS for at least 4 years until Krzysztof 
finally rewrote the whole thing.  If the half-baked version never 
existed in the first place we would have had a working richedit control 
alot sooner.

It might be a little bit harder to get things done by avoiding hacks at 
the start, but it's *alot* harder to get rid of the hacks once they're 
there.  People will complain and complain forever that the hacky version 
worked for them once for one application, even if the new version does 
alot better for all applications.


More information about the wine-devel mailing list