more sharing with Wine?

[Gunnar Dalsnes]

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

[Alex Ionescu]

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

[Jason Filby]

Hi Alex

I would say that this is because right now WINE are making more
changes to the user-mode DLLs that we share with them than we are. If
we change our debug standards then there won't be much to change at
all.

Cheers
Jason

On Tue, 21 Dec 2004 13:41:12 -0500, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   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.

[Ge van Geldorp]

>   From: Gunnar Dalsnes
>
>  HELP: where does the winehq2ros.patch files used in comctl32 etc. fit 
>  into this? 
I use them to keep track of differences between Wine and ReactOS. The merge
process currently works like this:

a) Check if any changes were made to the ReactOS code since the last merge
b) Copy new Wine code over to the corresponding ReactOS directory
c) Patch using the winehq2ros.patch file
d) If a) showed any differences, see if they are already present in the Wine
code too, if not merge them back in, submit them to Wine (if appropriate),
create a new winehq2ros.patch file
e) Make everything work again
f) Compile the changelog entry, crediting each Wine developer

Step f is by far the most time-consuming (and dull) part.

Gé van Geldorp.

Gunnar Dalsnes wrote:

>   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. 
First or all we have to distinguish between portable and non-portable DLLs.

Portable DLLs, like comctl32.dll, can be shared between ReactOS and Wine 
because they do not use non-portable features of the underlying OS. In 
most cases they only use the Win32-APIs.

Non-portable DLLs are not portable because they use features that differ 
between ReactOS and Wine. Examples are kernel32.dll because consoles are 
implemented in different ways, gdi32.dll and user32.dll because the use 
the INT2E interface to call into win32k.sys.

The non-portable DLLs are:
ntdll.dll, kernel32.dll, advapi32.dll, gdi32.dll, user32.dll,

I think we should _not_ try to make the non-portable DLLs portable 
because of the following reasons:
1) We always need to ensure that a DLL works on ReactOS. Wine developers 
cannot check whether one of their patches break a DLL on ReactOS.

2) Don't mix ReactOS code and Wine code. This is bloating the ReactOS 
DLLs and we'll have two sets of debug APIs (DPRINT/CHECKPOINT vs. 
FIXME/ERR/WARN/TRACE) in one DLL.

3) Don't replace working ReactOS code just because you think you can. I 
don't want to see a lot of my work getting thrown away without a major 
_technical_ benefit. And I don't want to face a situation where I am at 
an exhibition (like LinuxWorld Expo) and a visitor tells me that the 
ReactOS developers didn't write any user-mode components because each 
and every component has been merged with Wine and the ReactOS code has 
been replace by Wine code just because it simplifies your work.

Regards,
Eric Kohl

[Thomas Weidenmueller]

Eric Kohl wrote:

>   Non-portable DLLs are not portable because they use
> features that 
>  differ between ReactOS and Wine. Examples are kernel32.dll because 
>  consoles are implemented in different ways, gdi32.dll and user32.dll 
>  because the use the INT2E interface to call into win32k.sys. 
Especially the Int2E thing _could_ be solved if wine agreed on 
co-operation. Basically all we'd need is a shared interface for 
NtUser/NtGdi entry points. while wine's user32/gdi32 would call local 
NtUser/NtGdi stubs that connect to the wine server, reactos would inline 
the function and do actual syscalls. it would be doable but that'd 
require quite some changes in the wine code - and i believe wine doesn't 
want to do that for the sake of execution speed...

As long as we share one set of entry points, it'd be possible...

Regards
Thomas

[Jakob Eriksson]

Thomas Weidenmueller wrote:

>   Eric Kohl wrote:
>
> >   Non-portable DLLs are not portable because they
> > use features that 
> >  differ between ReactOS and Wine. Examples are kernel32.dll because 
> >  consoles are implemented in different ways, gdi32.dll and user32.dll 
> >  because the use the INT2E interface to call into win32k.sys. 
>
>  Especially the Int2E thing _could_ be solved if wine agreed on 
>  co-operation. Basically all we'd need is a shared interface for 
>  NtUser/NtGdi entry points. while wine's user32/gdi32 would call local 
>  NtUser/NtGdi stubs that connect to the wine server, reactos would 
>  inline the function and do actual syscalls. it would be doable but 
>  that'd require quite some changes in the wine code - and i believe 
>  wine doesn't want to do that for the sake of execution speed...
>  
How could that possibly be slower?

AFAIK it could be a set of macros, different for Wine and ReactOS.

regards,
Jakob

[Jakob Eriksson]

Eric Kohl wrote:

>  
>  I think we should _not_ try to make the non-portable DLLs portable 
>  because of the following reasons:
>  1) We always need to ensure that a DLL works on ReactOS. Wine 
>  developers cannot check whether one of their patches break a DLL on 
>  ReactOS.
>
>  2) Don't mix ReactOS code and Wine code. This is bloating the ReactOS 
>  DLLs and we'll have two sets of debug APIs (DPRINT/CHECKPOINT vs. 
>  FIXME/ERR/WARN/TRACE) in one DLL.
>
>  3) Don't replace working ReactOS code just because you think you can. 
>  I don't want to see a lot of my work getting thrown away without a 
>  major _technical_ benefit. And I don't want to face a situation where 
>  I am at an exhibition (like LinuxWorld Expo) and a visitor tells me 
>  that the ReactOS developers didn't write any user-mode components 
>  because each and every component has been merged with Wine and the 
>  ReactOS code has been replace by Wine code just because it simplifies 
>  your work. 

I heartily agree with 1 and 2, but I don't think I understand half of 3.
Don't ditch anything without a technical benefit, I agree.


But I dont understand:

"I don't want to face a situation where I am at an exhibition (like 
LinuxWorld Expo) and a visitor tells me that the
ReactOS developers didn't write any user-mode components because each 
and every component has been merged
with Wine and the ReactOS code has been replace by Wine code just 
because it simplifies your work."

If the visitors statement sometime in the future was correct, would that 
be a bad thing?

regards,
Jakob

[Alex Ionescu]

>   "I don't want to face a situation where I am
> at an exhibition (like 
>  LinuxWorld Expo) and a visitor tells me that the
>  ReactOS developers didn't write any user-mode components because each 
>  and every component has been merged
>  with Wine and the ReactOS code has been replace by Wine code just 
>  because it simplifies your work."
>
>  If the visitors statement sometime in the future was correct, would 
>  that be a bad thing?
>
>  regards,
>  Jakob
>
>  
Yes. How would you feel when all your work gets deleted and replaced by 
something else, which works worse but is easier to work with in the 
current context? And then having people come up saying you're not doing 
anythign else but copying on another project.

Best regards,
Alex Ionescu

[Jakob Eriksson]

Alex Ionescu wrote:

>  
> >   "I don't want to face a situation where
> > I am at an exhibition (like 
> >  LinuxWorld Expo) and a visitor tells me that the
> >  ReactOS developers didn't write any user-mode components because each 
> >  and every component has been merged
> >  with Wine and the ReactOS code has been replace by Wine code just 
> >  because it simplifies your work."
> >
> >  If the visitors statement sometime in the future was correct, would 
> >  that be a bad thing?
> >
> >  regards,
> >  Jakob
> >
> >  
>  Yes. How would you feel when all your work gets deleted and replaced 
>  by something else, which works worse but is easier to work with in the 
>  current context? And then having people come up saying you're not 
>  doing anythign else but copying on another project.
>  

If it is easier to work with in the current context, then it's bound to 
work better sooner or later.

To people saying I'm just copying another project, I would respond:
"If it's that easy, why don't you show us how easy it is to write an NT 
kernel and hardware support?"

Or something like this:
"It would be like saying Linus Torvalds is not doing anything else but 
copying the GNU libc and user mode utils.
That doesn't make any sense."




regards,
Jakob Eriksson

[Steven Edwards]

--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   Yes. How would you feel when all your work gets
> deleted and replaced by 
>  something else, which works worse but is easier to work with in the 
>  current context? And then having people come up saying you're not doing 
>  anythign else but copying on another project. 
Give a example where the Wine code has worked worse and I might agree with you.
If its easier to work with and fixes bugs then I would say its better.

Thanks
Steven



		
__________________________________ 
Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 
http://celebrity.mail.yahoo.com

[Gunnar Dalsnes]

>   The non-portable DLLs are:
>  ntdll.dll, kernel32.dll, advapi32.dll, gdi32.dll, user32.dll,
>   
They are not portable as a dll, but much code is still portable. With 
some goodwill from wine we could even make these dlls portable if we 
wanted too.

>   I think we should _not_ try to make the non-portable
> DLLs portable 
>  because of the following reasons:
>  1) We always need to ensure that a DLL works on ReactOS. Wine developers 
>  cannot check whether one of their patches break a DLL on ReactOS. 
After ripping code from Wine I usually discover lots of other bugs in 
ros (and wine) too, so imo sharing more code is a great "tool" for 
discovering bugs and shortcomings in ros.

>   
>  2) Don't mix ReactOS code and Wine code. This is bloating the ReactOS 
>  DLLs and we'll have two sets of debug APIs (DPRINT/CHECKPOINT vs. 
>  FIXME/ERR/WARN/TRACE) in one DLL. 
The "porting" headers are just macros. Whats bloated about that? Others 
have suggested to convert to wine style debug macros for all ros umode 
dlls, and i agree. Also i like the strlenW etc. macros wine uses. 
Unfortunately we would have to live with the strange unicode strings (it 
seems).

>   
>  3) Don't replace working ReactOS code just because you think you can. I 
>  don't want to see a lot of my work getting thrown away without a major 
>  _technical_ benefit.  
As i said, i'm tired of fixing ros bugs in forked wine code, so 
obviously it isn't working (correctly). The chances for your code to get 
thrown away (sometime in the future) is much greater when not sharing, 
as someone (like me) notice that the ros version has lots of bugs thats 
fixed in wine, and rips the code all over again...

>   And I don't want to face a situation where I am at
>
>  an exhibition (like LinuxWorld Expo) and a visitor tells me that the 
>  ReactOS developers didn't write any user-mode components because each 
>  and every component has been merged with Wine and the ReactOS code has 
>  been replace by Wine code  
I don't see the point in maintaining two different impl. just so we can 
say "We wrote it". And we/ros contribute to Wine thus its as much ros 
"property" as Wines. Sure, a lot of code will be "lost" during an 
initial merge, but thats most duplicate code anyways. Afterwards, 
changes will go both ways, and everyone will be happy.

>   just because it simplifies your work. 
It's not about simplifying work. Sharing code will be more work, but it 
makes sure we have the most up-to-date, bug free code.

Gunnar

[Steven Edwards]

Hi Eric,

--- Eric Kohl <eric.kohl(a)t-online.de> wrote:
>   Non-portable DLLs are not portable because they use
> features that differ 
>  between ReactOS and Wine. Examples are kernel32.dll because consoles are 
>  implemented in different ways, gdi32.dll and user32.dll because the use 
>  the INT2E interface to call into win32k.sys. 
 
Yes I think we need to push the Wine people at the next Wineconf to help us make those 
dlls more portable.

>   I think we should _not_ try to make the non-portable
> DLLs portable 
>  because of the following reasons:
>  1) We always need to ensure that a DLL works on ReactOS. Wine developers 
>  cannot check whether one of their patches break a DLL on ReactOS. 
Right but we can check via regression tests. I did this with the Wine edit control in
user32. I
was able to merge all of the Wine patches in and then run the tests to make sure we still
passed.
 
>   2) Don't mix ReactOS code and Wine code. This is
> bloating the ReactOS 
>  DLLs and we'll have two sets of debug APIs (DPRINT/CHECKPOINT vs. 
>  FIXME/ERR/WARN/TRACE) in one DLL. 
I think we should just dump the ReactOS debug APIs and use the Wine ones.

>   3) Don't replace working ReactOS code just because
> you think you can. I 
>  don't want to see a lot of my work getting thrown away without a major 
>  _technical_ benefit. And I don't want to face a situation where I am at 
>  an exhibition (like LinuxWorld Expo) and a visitor tells me that the 
>  ReactOS developers didn't write any user-mode components because each 
>  and every component has been merged with Wine and the ReactOS code has 
>  been replace by Wine code just because it simplifies your work. 
And I agree with this as well. No one should blindly replace code but if 
existing ReactOS code is broken and I can point to a real world app that
needs it then we either have the option of writting it from scratch or 
seeing if we can import the Wine code. Abiword was totally hosed without
the crypto functions from Wine. I could have just stubbed the code out 
and it might have worked but at least what we have now is semi-working.

Thanks
Steven



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail