Hi guys:
May I suggest something? I believe that the current code flow ros-wine is something like this
Let's hope this ASCII drawing won't break on the way
ROS developers WINE developers | | | | v v ROS Code <--- merges ---> WINE Code
^ | ---- Here seems that things won't merge quite well sometimes that takes considerable work and also a source of lost work.
So what about this? I beleive it will be better for everybody in the long run.
ROS developers ------- (ROS + WINE changes) -----><--------------- WINE developers | | | (ROS only changes) | v v ROS code in <--- Automatic Mirroring (scripts?)---- WINE code in cvs server (subversion?) of common code
I bet WINE people will be happy with this without doubt (thing won't change too much for them)
I guess there will be some friction at the beginning here(maybe) because now ROS developers have to use both systems also ROS code implementing things not present or better than the one in wine will need to be merged into WINE but the good part is that is only once. Also ROS needs to be changed to be able to receive WINE code without changes but again this is only once and also does not needs to be done for all dlls/applications at once. I suggest to do this in small scale to see how it works. Well guys you all know more about this than me so I guess you could improve this.
Regards Waldo Alvarez
________________________________
From: ros-dev-bounces@reactos.com on behalf of Alex Ionescu Sent: Tue 12/21/2004 1:41 PM To: ReactOS Development List Subject: Re: [ros-dev] more sharing with Wine?
Gunnar Dalsnes wrote:
Hi,
I'm tired of fixing bugs in code ported from wine <x> years ago. In most cases the bugs has already been fixed in the wine code we ripped from, but the ros variant is forked so much its impossible to inc. those fixes into ros, so the only choice is to rip the whole wine source over again, loosing any possible fixes/improvements we had made to the ros variant vs. the wine variant.
Take for example the file lib\kernel32\misc\profile.c. This file is 99.9% unchanged from wine, and only includes and some prototypes needed changes. I want to move files like this into wine subdirs. like lib\kernel32\misc\wine\profile.c and generate an initial diff lib\kernel32\misc\wine\profile.diff with changes made to make it run on ros using the wine porting headers. It does not mean that this diff will contain ERR changed to DPRINT etc. Only the bare changes to make it compile. Moving files into wine dirs in off course not necesary, but it makes it clear that this file(s) are shared thus there are rules to follow when changing them.
I have made scripts that updates our profile.c, using the profile.diff and any updated profile.c from wine, and i have made a script for generating patches that we send to wine. It all seems to work fine. HELP: where does the winehq2ros.patch files used in comctl32 etc. fit into this?
The only problem is wines strange unicode strings, their FIXME, ERR etc. and indentation. I think its worth it if we can share more, but dunno if the majority agrees.
From what i can see, much of kernel32 and ntdll can be shared this way, and probably much stuff in user32/gdi32 also.
Regards Gunnar
Personally, what bugs me is that if Wine fixes something, it's our responsability to merge it and cope with it. If we fix something, it's still our responsability. This latter statement bugs me. Of course it's up to us to implement Wine's changes, but why should we be the ones that also send our pathces back to wine, and have them all formatted back into Wine mode. It seems unfair to me that they don't submit their bug fixes to us, and it's up to us to sync and make them proper, while it's ALSO up to us to wineize our patches and send them to Wine.
Anyways, whatever tool/script makes importing Wine's code into ROS and making it look nice is 100% OK with me.
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev