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(a)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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev