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