#2 - Mdi Win16/32 Split

[Ge van Geldorp]

> From: Dimitrie O. Paun
> Sent: Monday, January 05, 2004 05:33
> 
> On January 2, 2004 01:12 pm, Steven Edwards wrote:
> > http://cvs.reactos.com/cvsweb.cgi/reactos/lib/user32/controls/
> > Is a good example of a place where we have been able to 
> > import a large chunck of WINE user32 code without a lot of
> > nasty changes.
> 
> BTW, did any of the fixes from your tree been ported back to 
> Wine? I guess not, and that's just not nice. You guys need to 
> adopt a decent system of keeping track of what sources where 
> imported from Wine, what got merged back to Wine, etc. I'd be 
> willing to help, if you guys are interested.

One of the first controls to be ported was the static control. I
submitted the fixes back to Wine, but the patch was dropped, 'cause
someone said one of the flags worked a little bit differently on
Win95/98. Well, guess what, I really don't care about 95/98 and I'm
certainly not going to install it to figure it out. I think Casper
Hornstrup had a similar experience recently with a LockResource16 call
in ole32.dll.

Ofcourse, I do realize that patches are dropped for good reasons (I
submitted a patch to comctl32 recently where someone pointed at a better
solution), but in general I get the feeling that I should be thankful if
a patch gets accepted.

Another case is the mega-shell32 patch that Martin Fuchs submitted.
Serious work on shell32 began around 17 dec, just as Alexandre was about
to go on vacation. So we (actually, 95% of the work was done by Martin)
used the ReactOS CVS repository. I just counted, there were 107 separate
commits to shell32 between 17 Dec and 02 Jan (I can't count the commits
after 02 Jan easily). Do you guys really believe that a pile of 107
patch mails while Alexandre was unavailable would have been a better
idea?

I am more than willing to do a little bit of extra work to keep our
trees in synch but the simple fact remains that if the only way to get
something accepted into Wine is to create a new Win95 installation and
see how things work there I'm probably not going to bother.

Gé van Geldorp.