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
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
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@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.
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
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
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
Eric Kohl wrote:
I think we should _not_ try to make the non-portable DLLs portable because of the following reasons:
- 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.
- 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.
- 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
"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
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
--- Alex Ionescu ionucu@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
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:
- 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.
- 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).
- 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
Hi Eric,
--- Eric Kohl eric.kohl@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:
- 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.
- 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.
- 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
-
Alex Ionescu -
eric.kohl＠t-online.de -
Ge van Geldorp -
Gunnar Dalsnes -
Jakob Eriksson -
Jason Filby -
Steven Edwards -
Thomas Weidenmueller