Re: #2 - Mdi Win16/32 Split
On January 2, 2004 10:31 am, Steven Edwards wrote:
Split up the Win16/32 MDI support a bit.
Any idea what the status of the Win16/32 split is? What DLLs are still not properly split? -- Dimi.
Hello Dimi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote:
Any idea what the status of the Win16/32 split is? What DLLs are still not properly split?
Its hard for me to say but most of the problems lies in user/gdi/kernel now. The Win16/32 Cleanup is closely tied to the MS_VC+PSDK porting so even if we remove a dependancy on a Win16 function it does not really mean the cleanup is done. The Win32 functions may still depend on other Wineisms. I would say overall its at 50% or more now. There are still a few minor things to clean in shell32, comdlg32 and ole32 but I would rate them at 80 to 90% done. Some WINE functions support the Win16 and Win32 ANSI and Unicode case so in those cases we have to duplicate the code and or rewrite the 32bit cases. I think tools/winapi_check/winapi_check can check for Win16/32 Cross calls. Its hard to get a handle around the problems because WINE on Linux and ReactOS differ once you get in to User, GDI, Kernel and NTDLL. There are some cases where we can use WINE code in these modules and others where we cant so even if we split the Win16/32 code it doesnt mean we can make use of it. 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. I would like to break with NT compatiblity a bit and implement some WINEisms in ReactOS so when DLL seperation part 2 is done we can make use of Winedos for our NTVDM. In the long run we may end up adding all of the Win16 stuff back in if we ever want to create a WOW subsystem for ReactOS. Its still going to need to be split and cleaned up though because we dont want a dos or Win16 app to be able to crash the Win32 subsystem. Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
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. -- Dimi.
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.
On January 11, 2004 09:56 pm, Ge van Geldorp wrote:
o you guys really believe that a pile of 107 patch mails while Alexandre was unavailable would have been a better idea?
Absolutely. It's way better than a big huge patch. A huge patch is meaningless for anybody reviewing, we can just put it in and hope it works. Smaller patches have _many_ advantages: -- can be easily reviews -- since people can understand them, they can comment on them -- these discussions result in a lot of useful information -- all this info gets archived for future hackers (_very_ useful)\ -- even if the patches are bad, they document a dead end so others don't have to waste time going there ... and so on ... Yes, you seem to be frustrated by the tight control that Alexandre uses on the Wine tree. I know, I've been many times, and I can tell you that I've got worked up over this a number of times. But I'd be hard pressed to look back and list a single instance where he wasn't correct in rejecting my changes. Also, you don't seem to appreciate that you get access to a _huge_ codebase of high quality code. And the reason it's good code, it's because of this tight control. I am sorry to say but I've sensed a bit of a "if you don't like it, screw you" attitude, and that's not helpful. We've tried hard to make our code useable as much as possible "as is" in you tree, because we believe cooperation will help both our projects. This attitude is not at all in this spirit. And if you think you can just fork the Wine codebase, and take it from here, you're only going to shoot yourself in the foot. We went over this issue before, I think we all understand we need to work together on this one, if we are to get some decent results before the turn of this (very young) century... -- Dimi.
Hi, --- Ge van Geldorp <ge(a)gse.nl> wrote:
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.
I do quite a bit of work to keep things in sync and thats by working as much as I can by working out of winehq CVS but that doesnt mean the rest of the ReactOS developers are going to follow. I still try to merge thier patches as I can but I am only one person. A big part of the problem with us merging some of the changes for the controls back in is: 1. They dont add much to WINE except cleaning up the TWEAK_WINELOOK stuff. I would have already started sending patches to remove this code from Winehq but I am wanting uxtheme to come along a little more so we can see if we can create a Win 3.1 theme before I throw all of the Win3.1 style support out the Window. 2. We have quite a few hacks in our support of the controls. In quite a few cases such as Menu and Scrollbar support its not just a matter of a recompile but a major rewrite. If you guys want to share more code then I will create a dummy implementation of Win32k.sys for WINE so we can share everything. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
On Mon, 12 Jan 2004, Steven Edwards wrote:
1. They dont add much to WINE except cleaning up the TWEAK_WINELOOK stuff. I would have already started sending patches to remove this code from Winehq but I am wanting uxtheme to come along a little more so we can see if we can create a Win 3.1 theme before I throw all of the Win3.1 style support out the Window.
Well, I personally think we should get rid of the Win31 look -- it's dated, and I don't think people still use it. If they do, the way to implement it is through uxtheme. And if there is enough motivation to move it there (even though I doubt there will be without users), the code can always be found in the CVS archive.
2. We have quite a few hacks in our support of the controls. In quite a few cases such as Menu and Scrollbar support its not just a matter of a recompile but a major rewrite. If you guys want to share more code then I will create a dummy implementation of Win32k.sys for WINE so we can share everything.
We should have these discussions more often, and you guys should push for ways to share as much code as possible. Right now these thing come out once in a blue moon during a heated argument, and we just find out that you can't share more code because of this hack or another. This is just justification for the current situation instead of a more proactive stance to correct it. WineConf will a good chance to flush these things out. You guys should assemble a list of problems (as seen on your end), and we should try to come up with a plan that maximizes the amount of files you can reuse "as is" (keyword: "as is"). -- Dimi.
--- "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
WineConf will a good chance to flush these things out. You guys should assemble a list of problems (as seen on your end), and we should try to come up with a plan that maximizes the amount of files you can reuse "as is" (keyword: "as is").
We are going to put together a action list in a few days for Wineconf. I and two other ReactOS developers that I know of will be attending so we will have plenty to talk about. Also on the code sharing side we have some nice enhancments to regedit that you guys may want to merge. I wont have the time to do a diff of Winehq vs ReactOS cvs for a while so if you want to pick over Thomas's code feel free. Mainly we just converted the bitmaps to icons and made it look more like Windows regedit. Also there are some fixes for writting string values. http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/ Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
On Mon, 12 Jan 2004, Steven Edwards wrote:
Mainly we just converted the bitmaps to icons and made it look more like Windows regedit. Also there are some fixes for writting string values.
http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/
I will try to extract stuff, thanks, but by glancing over the thing, the CVS log is not too informative: -- some more fixes -- more improvements -- updated regedit (and some minor changes) Yes, changes were made. That I know, no need to restate it in the log :))) This goes in part to the big patch problem we were discussing. By having unstructured commits in CVS like this, it's going to be real hard to come up with meaningful patches. -- Dimi.
On Mon, 12 Jan 2004, Steven Edwards wrote:
http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/
BTW, I don't know who "weiden" is (he seems to have made all the commits), maybe he can help me with this questions. Does the commit with this log: updated regedit (and some minor changes) mark a resync with the Wine CVS? I think we have to come up with a protocol in the future (maybe we can sit down with Alexandre at WineConf and discuss this) so that I'll be able to tell in the future with _what_ version of regedit in the Wine tree was this resynched from. Right now you're making changes on your tree, we on ours, the result is a hard to figure out mess. We really need to fix this somehow. -- Dimi.
On January 2, 2004 01:12 pm, Steven Edwards wrote:
Its hard for me to say but most of the problems lies in user/gdi/kernel now. The Win16/32 Cleanup is closely tied to the MS_VC+PSDK porting so even if we remove a dependancy on a Win16 function it does not really mean the cleanup is done. The Win32 functions may still depend on other Wineisms.
Man, we're beating around the bush :) We have two tasks: 1. split Win16/32 code 2. compile the split Win32 code with MS_VC+PSDK Look, I took a shot at creating a "Porting" page (attached). Legend: N = Not available C = Compiles B = Builds (Compiles & Links) xx% = Percentage of porting work complete It is partly based on the spreadsheet you sent out some time ago. Can you please: 1. Check that I got that info right 2. I didn't miss anything 3. Fill in the places where you know stuff builds with MS_VC+PSDK or you have any information of the status of the porting effort. 4. Report on the ReactOS column: what is already imported in ROS? 5. Any news on the Alpha port? We have to start somewhere, and with a bit of luck and work, we can fill this chart in time for WineConf! :) -- Dimi.
participants (4)
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Ge van Geldorp -
Steven Edwards