Re: [ros-dev] arwinss does not mean compatibility
On Feb 18, 2010, at 5:14 AM, James Tabor wrote: We see the leak due to the compatibility of ReactOS. We use tools from the Net to examine the GDI handle counts. Might I add a point, these tools are written for Windows. ;^) How do we really know that the same leak does not occur with arwinss. Are there tools to measure this? Please tell me what apps are these, so I could test them. I really wonder if they are gonna work in arwinss too :). WBR, Aleksey. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] arwinss does not mean compatibility
Well a quick overview, Arwinss is allocating from two places, Gdi32 and Win32k. Most likely based on what I read from the source, (wine) Gdi32. I'm not sure if you are passing everything to the ProcessEnvironmentBlock-GdiSharedHandleTable which originates in win32k, if not GDIView may not work. Both cases, it will not work or keep an accurate count of the object handles. Now Reading Again So in the case of (wine) Gdi32, the max allocations are about 16360, per process heap I guess, not sure. The check in win32k is still there in gdiobj.c but is that being used? DC, SURFACE and PALETTE as I can see. Regions are being allocated in (wine) Gdi32. Looking again, everything else too. Example, For Dc; alloc_dc_ptr by alloc_gdi_handle in (wine) gdiobj.c. Region just calls alloc_gdi_handle. Why GDIView? It is off the shelf and it is not ours! http://www.nirsoft.net/utils/gdi_handles.html On Thu, Feb 18, 2010 at 5:52 AM, Aleksey Bragin alek...@reactos.org wrote: On Feb 18, 2010, at 5:14 AM, James Tabor wrote: We see the leak due to the compatibility of ReactOS. We use tools from the Net to examine the GDI handle counts. Might I add a point, these tools are written for Windows. ;^) How do we really know that the same leak does not occur with arwinss. Are there tools to measure this? Please tell me what apps are these, so I could test them. I really wonder if they are gonna work in arwinss too :). WBR, Aleksey. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] arwinss does not mean compatibility
The point was made on IRC, if we are having issues, I'll just have to use arwinss then. This was in reference to the region leak. We see the leak due to the compatibility of ReactOS. We use tools from the Net to examine the GDI handle counts. Might I add a point, these tools are written for Windows. ;^) How do we really know that the same leak does not occur with arwinss. Are there tools to measure this? Are there checks in wine to make sure wine does not exceed a limit? So far, from the patches added to arwinss from ReactOS, there are limitations to the use of wine. These same patches have been added to ReactOS after porting wine. Is it safe to assume, we have these same limitations in ReactOS? Can we help that we use wine 24/7 when we sync/port from wine? ReactOS has the same bugs if we do. Over and over this has been the issue in the past. Pick on someone else for this leak, I'm not looking for it anymore, James There was a leak before I started to fix it. Bug 4980 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
why? Sent from my iPod Andrew Faulds (andrewweb) On 21 Jan 2010, at 18:50, Alwyn Tan alwyn@gmail.com wrote: I blame andrewweb. On Wed, Jan 20, 2010 at 10:31 AM, Aleksey Bragin alek...@reactos.org wrote: On Jan 20, 2010, at 11:14 AM, Ged Murphy wrote: James Tabor wrote: Although Jim likes the hyperbole, he is right. Arwinss is a stop gap solution that should eventually be deprecated except for the X11 module and used as a basis for verifying the 'correct' win32 subsystem. I'm for both! One will not replace the other... I have no idea how that got started! Amazing! Posted this before! I'll show how this got started... http://www.reactos.org/wiki/index.php? title=Arwinssdiff=27579oldid=27578 It was news to me too I wrote that after seeing this: http://www.reactos.org/wiki/index.php? title=Arwinssdiff=27396oldid=27018 and similar changes there done when I was away. As every piece of software, Arwinss (Wine32) is a stopgap between v1.0 and v3.0. When something better evolves, surely we'll use it. WBR, Aleksey Bragin. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
James Tabor wrote: Although Jim likes the hyperbole, he is right. Arwinss is a stop gap solution that should eventually be deprecated except for the X11 module and used as a basis for verifying the 'correct' win32 subsystem. I'm for both! One will not replace the other... I have no idea how that got started! Amazing! Posted this before! I'll show how this got started... http://www.reactos.org/wiki/index.php?title=Arwinssdiff=27579oldid=27578 It was news to me too Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Now that I understand the driver concept behind arwinss I think that arwinss is the right approach for the project. Looking at the current development approach win32 user and kernel components will not be finished anytime soon and will probably never work 100%. We're just missing specialised developers to achieve that. Furthermore mixing Wine and ReactOS codes on function level like done in those components complicates matters dramatically and consumes energies that could be used in better ways. Summing that up: I like the idea, should indeed be a big push for application compability. Actually I'm surprised we don't see a big controversial discussion around this idea like everyone expected. Concerning the picture on page 25 of the presentation: I remember having seen the start menu side bar cropped like this before in some of my tests. Was it StretchDIBits, or rather StretchBlt? I'll find out. Best regards, Gregor Schneider P.S: Quite interesting how the press judged this announcement: ReactOS about to restart is what I read today on a german technology news page. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Thanks! Press as usual likes flashy topics, so of course everyone edited the news text as he liked, but I like it. ReactOS needed some kick, it was quite sad to see some kind of stagnation (even though everyone did their best, it's just lack of human resources for specific tasks). If we make arwinss (or however it's going to be branded) succeed quickly, it's the best ever road to switch to beta with huge apps support, and put resources into more interesting things like real hardware bringing up, file systems support, and finally, after so many years, actually start using our OS. It would be fantastic to notice ReactOS in general web/whatever statistics sum ups. On Jan 19, 2010, at 10:03 PM, Gregor Schneider wrote: Now that I understand the driver concept behind arwinss I think that arwinss is the right approach for the project. Looking at the current development approach win32 user and kernel components will not be finished anytime soon and will probably never work 100%. We're just missing specialised developers to achieve that. Furthermore mixing Wine and ReactOS codes on function level like done in those components complicates matters dramatically and consumes energies that could be used in better ways. Summing that up: I like the idea, should indeed be a big push for application compability. Actually I'm surprised we don't see a big controversial discussion around this idea like everyone expected. Concerning the picture on page 25 of the presentation: I remember having seen the start menu side bar cropped like this before in some of my tests. Was it StretchDIBits, or rather StretchBlt? I'll find out. Best regards, Gregor Schneider P.S: Quite interesting how the press judged this announcement: ReactOS about to restart is what I read today on a german technology news page. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
I gave up on arguing. Instead I'll just use this to push my own ideas. I also have a secret plan of a Complete rewrite that will bring ReactOS to the next level not yet sure about the details, but I think it will incorporate something like virtualization and cloud computing. *muahahaha* Gregor Schneider wrote: Now that I understand the driver concept behind arwinss I think that arwinss is the right approach for the project. Looking at the current development approach win32 user and kernel components will not be finished anytime soon and will probably never work 100%. We're just missing specialised developers to achieve that. Furthermore mixing Wine and ReactOS codes on function level like done in those components complicates matters dramatically and consumes energies that could be used in better ways. Summing that up: I like the idea, should indeed be a big push for application compability. Actually I'm surprised we don't see a big controversial discussion around this idea like everyone expected. Concerning the picture on page 25 of the presentation: I remember having seen the start menu side bar cropped like this before in some of my tests. Was it StretchDIBits, or rather StretchBlt? I'll find out. Best regards, Gregor Schneider P.S: Quite interesting how the press judged this announcement: ReactOS about to restart is what I read today on a german technology news page. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
You sir are what i would call a visionary who makes his dreams work. I wish you the best of luck. -- brian ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Gregor Schneider wrote: Actually I'm surprised we don't see a big controversial discussion around this idea like everyone expected. Maybe because we already had this one in July: http://www.reactos.org/pipermail/ros-dev/2009-July/011896.html As I'm not a Win32k dev, I shouldn't argue about technical details. But I still don't believe that all the points expressed in e.g. http://www.reactos.org/pipermail/ros-dev/2009-July/011933.html are suddenly invalid, so that we can easily say that Arwinss is the better architecture. For me, it looks like the slides want to give this impression. Of course, I also want to see ReactOS going forward and Arwinss can surely help for now. But simply accepting it as our new official Win32k architecture I don't think we can make it that easy after all previous opinions. Best regards, Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
On Tue, Jan 19, 2010 at 3:23 PM, Colin Finck m...@colinfinck.de wrote: Maybe because we already had this one in July: http://www.reactos.org/pipermail/ros-dev/2009-July/011896.html As I'm not a Win32k dev, I shouldn't argue about technical details. But I still don't believe that all the points expressed in e.g. http://www.reactos.org/pipermail/ros-dev/2009-July/011933.html are suddenly invalid, so that we can easily say that Arwinss is the better architecture. For me, it looks like the slides want to give this impression. Of course, I also want to see ReactOS going forward and Arwinss can surely help for now. But simply accepting it as our new official Win32k architecture I don't think we can make it that easy after all previous opinions. There is no reason things cannot be developed in parallel. Samba 3 and Samba 4 have been in parallel development for how long now? I mean, we don't want to drive anyone away from ReactOS development, or throw out the work everyone is doing on the current win32k.sys and friends. Why could we not have the best of both worlds. Sure i would add a little bit of extra time to the build time and to build both subsystems. It should be possible to add some infrastructure to allow for the user to pick or switch the subsystem they are using. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
I'm all for ARWINSS (and yes, I'm still alive). I think it's good to have something that's up and running in a near future so that ros developers can focus on other things. As for the whole double delopment, I'm not so sure. One will always be depricated somehow, unless you have a lot of people maintaining it. Sure, we can keep the old one for reference maybe, but I don't think it has to be an installation decision taken by the user. -Gregor On 2010-01-19 21:37, Steven Edwards wrote: On Tue, Jan 19, 2010 at 3:23 PM, Colin Finck m...@colinfinck.de wrote: Maybe because we already had this one in July: http://www.reactos.org/pipermail/ros-dev/2009-July/011896.html As I'm not a Win32k dev, I shouldn't argue about technical details. But I still don't believe that all the points expressed in e.g. http://www.reactos.org/pipermail/ros-dev/2009-July/011933.html are suddenly invalid, so that we can easily say that Arwinss is the better architecture. For me, it looks like the slides want to give this impression. Of course, I also want to see ReactOS going forward and Arwinss can surely help for now. But simply accepting it as our new official Win32k architecture I don't think we can make it that easy after all previous opinions. There is no reason things cannot be developed in parallel. Samba 3 and Samba 4 have been in parallel development for how long now? I mean, we don't want to drive anyone away from ReactOS development, or throw out the work everyone is doing on the current win32k.sys and friends. Why could we not have the best of both worlds. Sure i would add a little bit of extra time to the build time and to build both subsystems. It should be possible to add some infrastructure to allow for the user to pick or switch the subsystem they are using. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
On Tue, Jan 19, 2010 at 8:23 PM, Colin Finck m...@colinfinck.de wrote: Maybe because we already had this one in July: http://www.reactos.org/pipermail/ros-dev/2009-July/011896.html As I'm not a Win32k dev, I shouldn't argue about technical details. But I still don't believe that all the points expressed in e.g. http://www.reactos.org/pipermail/ros-dev/2009-July/011933.html are suddenly invalid, so that we can easily say that Arwinss is the better architecture. For me, it looks like the slides want to give this impression. Of course, I also want to see ReactOS going forward and Arwinss can surely help for now. But simply accepting it as our new official Win32k architecture I don't think we can make it that easy after all previous opinions. I agree with Colin on this. I think arwinss is a great idea, but I still see it as a temporary solution until the real win32 subsystem can match it. Ged ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Technically Arwinss may not be the best possible architecture, but IMHO right now is the only viable one in order to reach beta in reasonable time. Sure, we will always see how a more native implementation could be more efficient at the end, but the reality is that given the current human resources it is not a realistic approach, it simply won't happen in many years with the actual resources. Arwinss allows us to use most of a working win32k subsystem (wine's) with minimal effort, thus saving huge amount of work. So we can focus in implementing other very needed areas to have a complete os. Why to invest an huge resources that we don't even have to implement something what is already done, better or worse? After we have the needed partitions, filesystems, complete kernel compatibility, etc, if we have more resources, we may consider t keep the the native win32k ss development, with the advantage of having a complete and working system to compare and test against, and most probably with more resources after we deliver an usable system. ReactOS goals are to achieve maximum windows compatibility at both application and driver/kernel components. We don't have any part finished. Arwinss solves with minimal effort the application APIs side that would require he largest effort otherwise, so we can dedicate our very limited resources to finish the other parts. It is just my opinion, but I see it so clear. I hope you all understand this: the best architecture can be the worst one if there is no a realistic plan to develop it. Jose Catena DIGIWAVES S.L. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Well, you don't have to be unnecessarily sarcastically cruel about it. I use all three major OSes and I use whatever fits to my needs. Most of the time, Linux does fit my needs. But, I want to play PC games, which are usually Windows games and their DRM schemes hook into the system deeper than Wine allows, so ReactOS could work out there. Anyway, you didn't give a reason to NOT use arwinss as the official win32 subsystem... On Tue, Jan 19, 2010 at 5:11 PM, James Tabor jimtabor.ros...@gmail.comwrote: The same thing with the kernel, we can use Linux instead! Create a distribution with it and call it Lindows! Oh wait! That ship has set sail and moved on~! On Tue, Jan 19, 2010 at 3:54 PM, Sir Gallantmon ngomp...@gmail.com wrote: I don't see any real reason for maintaining both branches of win32 subsystem. Arwinss still aims to be driver compatible, right? So, what do we gain by fully replicating the Win32 subsystem as Microsoft Windows does it? The idea of using Wine code to further the levels of compatibility in ReactOS is a good idea, and it has potential to make ReactOS a good choice for thin-client and terminal server systems because of the X11 driver. I personally prefer X11 SSH tunneling over VNC/RDP, because I don't need to see the entire remote desktop, just the applications I want to run from there. Additionally, Linux distros might include ReactOS and use their virtualization solutions to integrate apps installed to ReactOS into the overall Linux desktop. Nobody would ever really see the ReactOS desktop, but ReactOS would ensure more complete compatibility with Windows apps and games. I think Arwinss should be the new official win32 subsystem, but meh... No ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
performance, and probably compatibility On Wed, Jan 20, 2010 at 1:18 AM, Sir Gallantmon ngomp...@gmail.com wrote: Anyway, you didn't give a reason to NOT use arwinss as the official win32 subsystem... On Tue, Jan 19, 2010 at 5:11 PM, James Tabor jimtabor.ros...@gmail.comwrote: The same thing with the kernel, we can use Linux instead! Create a distribution with it and call it Lindows! Oh wait! That ship has set sail and moved on~! On Tue, Jan 19, 2010 at 3:54 PM, Sir Gallantmon ngomp...@gmail.com wrote: I don't see any real reason for maintaining both branches of win32 subsystem. Arwinss still aims to be driver compatible, right? So, what do we gain by fully replicating the Win32 subsystem as Microsoft Windows does it? The idea of using Wine code to further the levels of compatibility in ReactOS is a good idea, and it has potential to make ReactOS a good choice for thin-client and terminal server systems because of the X11 driver. I personally prefer X11 SSH tunneling over VNC/RDP, because I don't need to see the entire remote desktop, just the applications I want to run from there. Additionally, Linux distros might include ReactOS and use their virtualization solutions to integrate apps installed to ReactOS into the overall Linux desktop. Nobody would ever really see the ReactOS desktop, but ReactOS would ensure more complete compatibility with Windows apps and games. I think Arwinss should be the new official win32 subsystem, but meh... No ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
On Tue, Jan 19, 2010 at 6:11 PM, James Tabor jimtabor.ros...@gmail.com wrote: The same thing with the kernel, we can use Linux instead! Create a distribution with it and call it Lindows! Oh wait! That ship has set sail and moved on~! Although Jim likes the hyperbole, he is right. Arwinss is a stop gap solution that should eventually be deprecated except for the X11 module and used as a basis for verifying the 'correct' win32 subsystem. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Good catch! On Tue, Jan 19, 2010 at 7:05 PM, Steven Edwards winehac...@gmail.com wrote: On Tue, Jan 19, 2010 at 6:11 PM, James Tabor jimtabor.ros...@gmail.com wrote: The same thing with the kernel, we can use Linux instead! Create a distribution with it and call it Lindows! Oh wait! That ship has set sail and moved on~! Although Jim likes the hyperbole, he is right. Arwinss is a stop gap solution that should eventually be deprecated except for the X11 module and used as a basis for verifying the 'correct' win32 subsystem. -- Steven Edwards I'm for both! One will not replace the other... I have no idea how that got started! Amazing! Posted this before! ReactOS is an unique project platform and to just have one sole project is not what this project is about. What have we learn from Arwinss to date, the source of our win32k issues is wine itself. (ref r44800) It's an add on to X11, so wine thinks per process and not the whole of it. Meaning, it draws based on one application and does not consider the full X11 environment. So it's hacked to work. Arwinss attempts to move beyond this and with wine using our kernel in itself is amazing! This is why we have both now. James Reference: http://www.reactos.org/archives/public/ros-diffs/2009-December/034538.html FYI: Win32k was ported from wine. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
I'm not a developer, so I have no say in the matter, but if you want an outsider's opinion, I would suggest implementing Arwinss for the near-term, so we have better software compatibility. Software compatibility brings publicity, since people will actually be able to do things with ReactOS that they couldn't do before, like run Win32 programs. A lot of the software I test has issues with Win32, and if Arwinss gets them running in the near- term it'll show people the real potential of ReactOS. Some of these people may be programmers, who can then funnel their interest in ReactOS towards contributing to development. Arwinss is a stopgap measure. Regardless of your personal differences in the matter, use Arwinss to gather publicity and near-term compatibility, so development can be focused on other issues, such as DirectX, USB support, or better filesystem support. When the other components are up and running, when we have a functioning ReactOS in beta, hopefully the publicity that will follow ReactOS's progress will have added to the pool of developers. This larger pool of developers will then have the manpower to re-implement a more native Win32 subsystem. While everyone in an open-source project is technically free to go as they please, perhaps the current pool of developers could have a gentleman's agreement to fix the native Win32 when the rest of the Windows components are up and running. Everybody seems to agree that the current Win32 is a monster, so use Arwinss to rally more troops to battle the beast. Even when the native Win32 is fixed, there may be a place for Arwinss where the optional features it offers can be used. Specialized deployments of ReactOS could take advantage of Arwinss, though the main branch of ReactOS would re-implement the native Win32. A corporation that likes the X Server features of Arwinss might decide to sponsor ReactOS, and that assistance could be used to progress the rest of the project as a whole. Don't forget native Win32, but let's see what opportunities Arwinss opens up for ReactOS. Perhaps the choice between Arwinss and native Win32 could be made at install. Arwinss would be the recommended package until native Win32 is fixed. For what it's worth, I'm looking forward to testing my personal list of benchmark software against Arwinss. :) -Joshua Bailey ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
I would agree it would be a nice idea to choose which at install-time, then it would be easy to test both, and would allow any arwinss-haters to get what they want. Sent from my iPod Andrew Faulds (andrewweb) On 20 Jan 2010, at 04:42, Joshua Bailey raptorempe...@yahoo.com wrote: I'm not a developer, so I have no say in the matter, but if you want an outsider's opinion, I would suggest implementing Arwinss for the near-term, so we have better software compatibility. Software compatibility brings publicity, since people will actually be able to do things with ReactOS that they couldn't do before, like run Win32 programs. A lot of the software I test has issues with Win32, and if Arwinss gets them running in the near- term it'll show people the real potential of ReactOS. Some of these people may be programmers, who can then funnel their interest in ReactOS towards contributing to development. Arwinss is a stopgap measure. Regardless of your personal differences in the matter, use Arwinss to gather publicity and near-term compatibility, so development can be focused on other issues, such as DirectX, USB support, or better filesystem support. When the other components are up and running, when we have a functioning ReactOS in beta, hopefully the publicity that will follow ReactOS's progress will have added to the pool of developers. This larger pool of developers will then have the manpower to re- implement a more native Win32 subsystem. While everyone in an open-source project is technically free to go as they please, perhaps the current pool of developers could have a gentleman's agreement to fix the native Win32 when the rest of the Windows components are up and running. Everybody seems to agree that the current Win32 is a monster, so use Arwinss to rally more troops to battle the beast. Even when the native Win32 is fixed, there may be a place for Arwinss where the optional features it offers can be used. Specialized deployments of ReactOS could take advantage of Arwinss, though the main branch of ReactOS would re-implement the native Win32. A corporation that likes the X Server features of Arwinss might decide to sponsor ReactOS, and that assistance could be used to progress the rest of the project as a whole. Don't forget native Win32, but let's see what opportunities Arwinss opens up for ReactOS. Perhaps the choice between Arwinss and native Win32 could be made at install. Arwinss would be the recommended package until native Win32 is fixed. For what it's worth, I'm looking forward to testing my personal list of benchmark software against Arwinss. :) -Joshua Bailey ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
Because there still exists some features of D3D that OpenGL has not or that some manufacturers implement in their D3D drivers but not in their opengl ICD. The funny side of it is that I use wineD3D on my laptop, because intel drivers suck! Jérôme. Kamil Horníček a écrit : What would be the advantage of such an approach? We now use only Wine DX libs anyway and wined3d seems to do its job just fine. This would go directly against the whole arwinss idea = use tested and known to work code from Wine and only spend valuable dev time on parts that are reactos specific. Kamil ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
What would be the advantage of such an approach? We now use only Wine DX libs anyway and wined3d seems to do its job just fine. This would go directly against the whole arwinss idea = use tested and known to work code from Wine and only spend valuable dev time on parts that are reactos specific. Kamil - Original Message - From: Jérôme Gardou jerome.gar...@laposte.net To: ReactOS Development List ros-dev@reactos.org Sent: Sunday, January 17, 2010 2:31 AM Subject: Re: [ros-dev] Arwinss presentation Could this be pushed to write a rosd3d driver? Take all d3d dlls from wine and write a wined3d compatible dll? Also, users could make a choice between wine and ReactOS implementation... Marius Przybylski wrote: What are the disadvantages to using ARWINSS as Win32 subsystem ? Entry level is rather low - What are the requirements for Arwinss developer ? - Marius Przybylski Dnia 16 stycznia 2010 22:44 Aleksey Braginalek...@reactos.org napisał(a): ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
On Jul 30, 2009, at 12:49 AM, James Tabor wrote: If I'm not mistaken, we already imported wine code at the beginning did we not? I'm looking at the commit logs and it does look we started with wine. We need to keep it separated before it is too late. Oh it's already too late. Ah, we missed that one. On Wed, Jul 29, 2009 at 1:10 PM, Gedgedmur...@gmail.com wrote: Current win32 subsystem progress is too slow. We need something now before it's too late. One of the main things that's holing us back and stopping new devs from getting involved is out lack of compatibility and stability. Good reason to keep it separated. That's what being suggested. However Alex said a different opinion, that the rewrite could happen in-place. But apriori that takes more effort, because one needs to take into account compatibility, prevent breakages (Jim knows how hard it is). If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside. Surely this will give you the freedom to get architecture done without worrying about breaking things? Ged. Read all of my previous emails, so I do not have to paint this again James Though still I don't see what a proper win32 subsystem architecture means. I know the crystal clear, well thought through, not changed much over years design of an NT kernel. But with win32 subsystem, there is no such crystal clearness. Timo, James - please, tell me your opinions about that. So far, the only proper things from a real win32 subsystem are the win32k syscall interface (ros still uses its own variant of it, with similar function names, but different parameters, etc - but that's what being fixed) and internal structures documented by Timo (great work indeed). It's fine so far, but having NT API and NDK is not all what's needed to build a good and proper kernel. There is something called internal architecture. What do we have of a proper internal architecture in gdi32, user32 and win32k.sys now in trunk? P.S. no flamewars please, those are fully valid question, fully serious, and no offence to anyone is intended. WBR, Aleksey Bragin. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Stay out of ReactOS! Go ahead and work on ArWinSS, James Man, why so scared? :) Arwinss doesn't even run Firefox2 yet and everyone went crazy. So far Timo provided an extensive answer to my questions, thanks. WBR, Aleksey Bragin. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Oh, c'mon, people. This diagram says nothing. Has anyone of you even a clue of how it would look like for Windows? The only difference to Windows design that can be seen from this diagram is the addition of the NT driver and X11 driver. What it doesn't show is where which parts of the subsystem are located. And that would probably show compatibility problems and bad performace. Regards, Timo Brian schrieb: i cant help but feel that is how it should have been done in the first place by the way the diagram looks ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Absolutely, this is exactly what I had in mind. The project needs a solidly working solution right now, even at some expense of speed (though it's arguable). It is very hard to properly rewrite our existing win32 subsystem without introducing regressions, and by the time this is done, the world may forget Win32 exists. Arwinss gives key advantages to this: 1. It is possible to start a win32 subsystem with the proper, better design without dooming the project for 10 more years (existing win32k started in 1999) of work without any realworld useful result. 2. It is possible too make a new win32 subsystem aiming at future, not at present (e.g. use C++ if that fits better, use more modern architecture if needed, etc). 3. It is possible to gain new developers to do this task because with Arwinss ReactOS is going to get real usage, and come to a new height. Just imagine all good from Wine (compatibility) without all bad parts (Linux/XWindows related). 4. It allows to fix problems in other parts of the system (arwinss already uncovered bugs in csrss for example, more to come). Developing a new win32 susbsystem against bad users will result only in more pain (James knows how fun was it to see desktop class becoming local). WBR, Aleksey Bragin. On Jul 29, 2009, at 3:38 PM, Ged wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it’s our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. From: Timo Kreuzer [mailto:timo.kreu...@web.de] Sent: 29 July 2009 11:33 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture Oh, c'mon, people. This diagram says nothing. Has anyone of you even a clue of how it would look like for Windows? The only difference to Windows design that can be seen from this diagram is the addition of the NT driver and X11 driver. What it doesn't show is where which parts of the subsystem are located. And that would probably show compatibility problems and bad performace. Regards, Timo Brian schrieb: i cant help but feel that is how it should have been done in the first place by the way the diagram looks ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
war is here 3: On Wed, Jul 29, 2009 at 7:30 PM, James Tabor jimtabor.ros...@gmail.comwrote: No, not even, not in the light of day, shall this ever be part of trunk! Separate project maybe, perhaps or will be a new project altogether! Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org. I'm @ wk and had to comment on this, James On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmur...@gmail.com wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it’s our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Current win32 subsystem progress is too slow. We need something now before it's too late. One of the main things that's holing us back and stopping new devs from getting involved is out lack of compatibility and stability. If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside. Surely this will give you the freedom to get architecture done without worrying about breaking things? Ged. -Original Message- From: James Tabor [mailto:jimtabor.ros...@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture No, not even, not in the light of day, shall this ever be part of trunk! Separate project maybe, perhaps or will be a new project altogether! Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org. I'm @ wk and had to comment on this, James On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmur...@gmail.com wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced. On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmur...@gmail.com wrote: Current win32 subsystem progress is too slow. We need something now before it's too late. One of the main things that's holing us back and stopping new devs from getting involved is out lack of compatibility and stability. If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside. Surely this will give you the freedom to get architecture done without worrying about breaking things? Ged. -Original Message- From: James Tabor [mailto:jimtabor.ros...@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture No, not even, not in the light of day, shall this ever be part of trunk! Separate project maybe, perhaps or will be a new project altogether! Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org. I'm @ wk and had to comment on this, James On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmur...@gmail.com wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Personally i like the idea of being able to access remotely using an X Server.. Could this feature be ported to current Win32k implementation after Arwinss is deprecated? On Wed, Jul 29, 2009 at 8:42 PM, King InuYasha ngomp...@gmail.com wrote: Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced. On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmur...@gmail.com wrote: Current win32 subsystem progress is too slow. We need something now before it's too late. One of the main things that's holing us back and stopping new devs from getting involved is out lack of compatibility and stability. If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside. Surely this will give you the freedom to get architecture done without worrying about breaking things? Ged. -Original Message- From: James Tabor [mailto:jimtabor.ros...@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture No, not even, not in the light of day, shall this ever be part of trunk! Separate project maybe, perhaps or will be a new project altogether! Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org. I'm @ wk and had to comment on this, James On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmur...@gmail.com wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Why would we need the X server for remote access if we have terminal services? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Hello, I'm here to tell you about what the not-so-bright user thinks. I have been in contact with them. They say well...ReactOS is Linux, right? Because it's open source. I don't know who, but the world as we see it glued the idea of open-source to Linux. Any OS who is open source is somehow based on Linux. Of course some people know that can't be 100% true. But these people are the users, the developers and the enthusiasts of these projects who are not based on Linux. It doesn't matter how many newsletters you write saying it's not Linux, or how many presentations at events you have, saying it's not Linux but aims to be a completely compatible Windows clone. This is a major security hole for ReactOS. The moment someone says well, now we're based on Wine until we can finish a proper implementation of our cloned-after-Windows subsystems, that's when these users will say well, that's still Linux so I'll take Vista/XP/whatever Windows version, thank you very much. They know what Wine is (although many think it's an emulator) and they know that's Linux. No one can change their minds. Meanwhile, this change sounds very helpful and useful. But this is probably why some developers are so against it. Yes, maybe James Tabor is right - Download ReactOS Wine-based, Download ReactOS Windows-based (but if you write that, everyone will jump and say you copied Windows code after looking at the leaked sources). Release and Debug for each. I'm sorry about this, but it's the way the users were fooled. And these people were Ubuntu users, very happy about it. One of them pointed out that *gasp* YOU HAVE MORE DESKTOPS, JUST LIKE IN LINUX!!! He was, of course, talking about the taskbar, where you can select which desktop you want to use. So, whatever the decision, BE CAREFUL!!! 2009/7/29 Javier Agustìn Fernàndez Arroyo elh...@gmail.com Personally i like the idea of being able to access remotely using an X Server.. Could this feature be ported to current Win32k implementation after Arwinss is deprecated? On Wed, Jul 29, 2009 at 8:42 PM, King InuYasha ngomp...@gmail.com wrote: Makes sense. And once the real subsystems are compatible and stable enough, then the arwinss branch could be relegated to an addon. An addon that could be used on both ReactOS and Windows. It's a stopgap solution, but one that would have uses after it is replaced. On Wed, Jul 29, 2009 at 1:10 PM, Ged gedmur...@gmail.com wrote: Current win32 subsystem progress is too slow. We need something now before it's too late. One of the main things that's holing us back and stopping new devs from getting involved is out lack of compatibility and stability. If we have a drop in replacement which is much more compatible and stable then the current one, then I think it's wise to use that whilst the real implementation is continued alongside. Surely this will give you the freedom to get architecture done without worrying about breaking things? Ged. -Original Message- From: James Tabor [mailto:jimtabor.ros...@gmail.com] Sent: 29 July 2009 18:30 To: ReactOS Development List Subject: Re: [ros-dev] Arwinss architecture No, not even, not in the light of day, shall this ever be part of trunk! Separate project maybe, perhaps or will be a new project altogether! Leave our trunk alone and keep working on ArWinSS where it is or make it's own home on ReactOS.org. I'm @ wk and had to comment on this, James On Wed, Jul 29, 2009 at 6:38 AM, Gedgedmur...@gmail.com wrote: What people should also know is that if this branch ever does make it into trunk it will only be used as a temporary solution until the correct implementation is ready. This is by no means a permanent solution! What it will do is act as a temp replacement which will hold things together and allow work on the real subsystem to accelerate. At the moment the current subsystem must be kept stable as it's our main component and needs to stay regression free whilst rewriting major parts to make it more compatible. Not an easy task! If the Arwinss model can take over for a while it will gives the win32 subsystem developers breathing space to rewrite / hack / break / fight / kill / molest and eventually improve the real implementation without worrying about breaking reactos for everyone else. In the long run this may be a great solution to improve the compatibility and stability of the real reactos win32 subsystem. Ged. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros
Re: [ros-dev] Arwinss architecture
On Wed, Jul 29, 2009 at 3:09 PM, Zachary Gordendrakekaizer...@gmail.com wrote: Why would we need the X server for remote access if we have terminal services? We don't have terminal services though. I mean we should of course, and I should also have a pony. I'm not saying it should go in trunk or not, just pointing out that its kind of a neat feature that has many uses. And besides, if you've ever tried to do rootless RDP to a Linux or Mac host, you would know it makes kittens cry... -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Arwinss architecture
Hello, I will be thoroughly explaining the arwinss architecture, and the very first start is the general flow diagram which could be seen here: http://www.reactos.org/wiki/Arwinss_architecture This page will also get more updates with regard to architecture and design of all modules, but most attention will be paid to win32k.sys internals and native gdi/user driver (so-called winent.drv). With the best regards, Aleksey bragn. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
King InuYasha wrote: Ok, a little more confused now. You said that the idea that Wine code is better than ReactOS code needs to die, but you turn around and basically state that Wine code IS better than ReactOS code. Did you mean that the idea that ReactOS code is better than Wine code? I did Because if that is what you meant, then I agree. Super. Have some cheesecake ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
Please don't make this debate even more confusing by mentioning DirectX. As you could have noticed by now, we are actually using wined3d for DX support now (it's been two years already). The last part ouf our implementation (ddraw) was disabled in trunk few months ago. - Original Message - From: King InuYasha To: ReactOS Development List Sent: Tuesday, July 21, 2009 4:56 PM Subject: Re: [ros-dev] Arwinss On Mon, Jul 20, 2009 at 10:47 AM, KJK::Hyperion hackbu...@reactos.org wrote: Timo Kreuzer wrote: Wine emulates the kernel through a server. Of cause we don't use it, because it has a totally different design. Says who? So far, and only counting official implementations, Win32 has been implemented as: - a shared-memory user mode subsystem (Windows 95, 98) - a RPC user mode subsystem (Windows NT 3) - a kernel mode subsystem (Windows NT 4 and later) - ??? (Windows CE) We have an NT kernel and every kernel developer would eat me alive if I tried to put a single line of wine code into our kernel. It's considered crap there. Wine code has to pass quality reviews and test suites. ReactOS code only has to pass the warmth-and-fuzziness test. Wine can prove their code is right, ReactOS is based on code that feels right The idea that Wine code is better than ReactOS code really needs to die. Compared to theirs, our code is sloppy, highly unprofessional and often inexplicable. We copy the form but tend to completely miss the intent. Wine development is test-driven and entirely based on intent and end results, while our development model is, apparently, to dick around in our spare time pretending we work at Microsoft How do you expect display drivers to work at all? NT display drivers used to run in user mode with the same identical API, and probably the same ABI. I'm sure Aleksey will do just fine More hacks on top of the huge pile of hacks? And how do you deal with missing functionality in wine code? Shove more code in there? Or ignore it, like if wine doesn't need it, we also don't need it? Or again fork the code? I would sell my mother to Carthage for even a fraction of the kind of application support that Wine enjoys, thank you. My only gripe with arwinss is that Aleksey beat me to the first landmark controversial side project ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Ok, a little more confused now. You said that the idea that Wine code is better than ReactOS code needs to die, but you turn around and basically state that Wine code IS better than ReactOS code. Did you mean that the idea that ReactOS code is better than Wine code? Because if that is what you meant, then I agree. The arwinss branch is very interesting. Does this mean that Wine DirectX code can be shared because more Wine code is being used for the core components? Or is ReactX still necessary, even with arwinss? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Arwinss
Hello, I've heard many question about a branch I was working on recently, arwinss, so I'd like to write some explanation (you may skip the boring history part of the message) Arwinss is a rewrite (the most advanced so far out of all previous attempts) of some parts of the Win32 subsystem, namely the USER32 and GDI32 API interfaces, along with the kernel counterpart win32k.sys. The kernel32.dll, csrss, and other parts remain in their present condition, and getting bugfixes if they come in the way of a rewrite. [History and reasoning part starts here] Why rewrite and not fix an existing Win32 subsystem? Timo, James and all our other great developers were and are doing a great work. I put a considerable amount of time in it to fix problems too. But, since our project is a volunteer-driven one, everyone has a real life, real work to do, and is not able to sit 24 hrs researching Windows internal structures, inventing new algorithms, trying out thousands of applications, not to say about graphics drivers. Time is ticking, Win32 is improving, but most annoying bugs are there for years - e.g. vmware installer hang, Firefox move the mouse bug, drawing glitches, concurrency hacks in the code (if (!a) /* someone else was faster than us and already freed it */), probable heap misusage (relying on our heap implementation for desktop heaps) and heap memory corruptions (I kept trying to update rtl/heaps to the newest Wine code - and always failed without any obvious reason), inability to change video mode on the fly, and the list can go on. So I thought, that something should be done with it. I would even want to trade off some speed gain in favor of stability (optimizing is an enjoyable task which could be done later). After teaming up with Stefan, we created an nwin32 branch - a totally stubbed out win23k, user32 and gdi32. They had exactly matched exports, and win32k had exactly same system calls and Windows 2003 SP1's win32k.sys. However, due to really huge amount of work, the branch didn't went farther than trying to boot Windows 2003 with it and see a few stubbed functions being called. Since then I started thinking on an alternative design of a Win32 subsystem. The idea turned out to be very simple, and is based on the following questions: - Why put so much effort into keeping the internal win32k system calls interface the same as in Windows, why put so much effort in converting to internal Windows structures, if we don't have something working first? - Why base on a stoneage Wine's code which James and Christoph occasionally sync, and all my attempts to get more people into this boring task failed? - Why not use achievements of our closest project - Wine? [End of reasoning, fancy stuff starts] The result came by itself: Try to build up a win32 subsystem based as much on Wine code as possible, and using Wine's modular design. Before publicly announcing it, I have spent a month actually trying all that stuff, and surprisingly it went very well, and a nice byproduct: support of remote sessions via X Windows. Proof of concept screenshots are here: http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg Noone has ever done this before: This is Windows 2003 inside VMware, running my custom Win32 subsystem, with an X graphics driver module, communicating with an X Server running in the host OS (Windows XP, XMing X windows server), and with ReactOS's winlogon.exe and msgina.dll (for ease of debugging and source code availability)! Let's go straight to the architecture: GDI32.dll and USER32.dll are ported Wine usermode code, with very few modifications. GDI32 and USER32 depend on two things: Gdi and User driver, and a server. Gdi and User driver is a loadable DLL, which provides an abstraction of a graphics driver in the system through a certain set of APIs. A typical example of such a driver is winex11.drv, which routes all drawing to the X Windows client. However, this is not very useful for a local system which has a Windows NT architecture, where there is no need for remote windows displaying. The server. GDI32 and USER32 rely on the server for managing all global information. In Wine, the server is run as a usermode wineserver.exe process, which communicates with gdi32/user32 via custom RPC, and emulates quite a lof of stuff which Windows NT kernel provides by default. My decision was to convert the RPC protocol from a slow interprocess filedescriptors-based unix-specific invocations to a fast system calls to win32k module. This way, win32k contains small part (~300 kb vs 1.5Mb+) of wineserver's source code, which deals with windows, window classes, atoms, windows stations, desktops and other totally platform/implementation independent stuff. It will be reduced further, because I even ported their own object manager for
Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 8:15 AM, Steven Edwards winehac...@gmail.comwrote: 2009/7/20 Javier Agustìn Fernàndez Arroyo elh...@gmail.com: support of remote sessions via X Windows what the Does it mean some GUI Linux apps would be able to run into ROS with that new Win32 subsystem?? No. It means that if we get things like Microsoft Office working under ReactOS then it will be able to seamlessly display to any client running a X server. Linux, Solaris, Mac OS X, Windows with Xming, etc. The immediate commercial applications should be apparent. Combine ReactOS with a Hypervisor subsystem such as Xen and KVM and you have the makings of a true Windows subsystem. Think VMware Fusion or Parallels Coherency but with remote DISPLAY support, etc. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Would it also mean that an X11 API library could be plugged in so that X based applications can be more easily ported to Windows/ReactOS while still providing the transparency to view on another machine through X11 protocol? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 9:31 AM, King InuYashangomp...@gmail.com wrote: Would it also mean that an X11 API library could be plugged in so that X based applications can be more easily ported to Windows/ReactOS while still providing the transparency to view on another machine through X11 protocol? Such a library already exists. Google for libX11. It is used for the rxvt port in Mingw and Cygwin. It simply maps the X11 api to mostly equivalent Win32 calls. In the ancient past I built a gtk that linked to it. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
Hi, Some people might have already noticed that I have a strong opinion regarding this rewrite. So let me explain my point of view here. Aleksey, thanks for clarification and confirming a lot of what I already thought. I hope you don't feel offended (at least not more than I was, when browsing through your recent commits ;-)) I totally agree that we have a very limited number of devs and it takes quite some time to get the stuff in the win32 subsystem done. Anyway the lets just use wine shortcut won't work. Any developer who has ever done any serious work on our win32 subsystem might actually feel offended by this rewrite. It basically says: Hey, all your stupid attempts to remove the hacks and to make the win32 subsytem work more like Windows and less like crap, were totally a waste of time. You should have instead better written a bunch more hacks around the hacks to make all the wine code work. Well, that's what we did long time ago, when the goal was Get stuff done now, fix bugs later and that's what got us all the problems in the first place. But we are past this stage since quite some time now. No more hacks! that's the current deal. We have invested a great amount of time into testing native api, using the Windows structures, fixing the gdi handle manager, etc. What for? Doing it like windows does, means 100% chance that the approach will work, if properly implemented, it allows better testing and analyzation and it helps to keep developers from doing bs. Doing it like wine or inventing new standards will with a chance of 50% result in great fail, as can be seen over and over again in win32k. Wine emulates the kernel through a server. Of cause we don't use it, because it has a totally different design. We have an NT kernel and every kernel developer would eat me alive if I tried to put a single line of wine code into our kernel. It's considered crap there. Well, Wine also emulates the win32 subsystem though a server. Again the design isn't anywhere near the real win32 design. And yet you want to use it? Be prepared to get eaten alive by a win32 developer when you try to get anything like that into trunk. (I consider it as crap there!) Fixing issues? The idea that this rewrite could instantly fix all the issues, because it works on wine, is a fancy idea. But it won't work. Wine is designed to work on linux/X11 not on NT and that will come back at you sooner or later. Also the fact that it was tested with thousands of apps doesn't mean it works correctly. How do you expect stuff like mode switching to magically start working when there's no wine code that calls a display driver to do the job? How do you expect display drivers to work at all? More hacks on top of the huge pile of hacks? And how do you deal with missing functionality in wine code? Shove more code in there? Or ignore it, like if wine doesn't need it, we also don't need it? Or again fork the code? Optimization later? You cannot simply optimize later. It never works that way. A decent design is a precondition to optimization. Wine code, which is in this case designed as a workaround (hack) can never be optimized. Conclusion: This rewrite does IMO not have any merit. It will at most create an ugly, slow something with a ridiculous design. If it's only some kind of sick joke somewhere between The price is right and the developers edition of How low can you go, and you committed it only to share your fun, then.. well, go ahead, make me laugh, too. If you actually considered merging it, ... Only over my dead body! If you want to use more wine code, install linux and wine. You can even put a new logo on it and sell that if you want money. But keep it out of our core components. Also, instead of complaining about old bugs in the win32 subsystem, you should better take a look at the kernel. Man, there's more than enough work todo. What about cc? What about fastfat? What about 3rd party filesystems? What about implementing MmSecureVirtualMemory? What about usb? What about smp? No, I'm not suggesting to use a linux kernel, because it works stable since ages and has all the stuff we don't have... Finishing with a recursive acronym Wine is not enough! Regards, Timo Aleksey Bragin wrote: Hello, I've heard many question about a branch I was working on recently, arwinss, so I'd like to write some explanation (you may skip the boring history part of the message) Arwinss is a rewrite (the most advanced so far out of all previous attempts) of some parts of the Win32 subsystem, namely the USER32 and GDI32 API interfaces, along with the kernel counterpart win32k.sys. The kernel32.dll, csrss, and other parts remain in their present condition, and getting bugfixes if they come in the way of a rewrite. [History and reasoning part starts here] Why rewrite and not fix an existing Win32 subsystem? Timo, James and all our other great developers were and are doing a great work. I put a considerable amount of time in
Re: [ros-dev] Arwinss
Aleksey Bragin has huge balls of fire. Go ahead, madman ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
Timo Kreuzer wrote: Wine emulates the kernel through a server. Of cause we don't use it, because it has a totally different design. Says who? So far, and only counting official implementations, Win32 has been implemented as: - a shared-memory user mode subsystem (Windows 95, 98) - a RPC user mode subsystem (Windows NT 3) - a kernel mode subsystem (Windows NT 4 and later) - ??? (Windows CE) We have an NT kernel and every kernel developer would eat me alive if I tried to put a single line of wine code into our kernel. It's considered crap there. Wine code has to pass quality reviews and test suites. ReactOS code only has to pass the warmth-and-fuzziness test. Wine can prove their code is right, ReactOS is based on code that feels right The idea that Wine code is better than ReactOS code really needs to die. Compared to theirs, our code is sloppy, highly unprofessional and often inexplicable. We copy the form but tend to completely miss the intent. Wine development is test-driven and entirely based on intent and end results, while our development model is, apparently, to dick around in our spare time pretending we work at Microsoft How do you expect display drivers to work at all? NT display drivers used to run in user mode with the same identical API, and probably the same ABI. I'm sure Aleksey will do just fine More hacks on top of the huge pile of hacks? And how do you deal with missing functionality in wine code? Shove more code in there? Or ignore it, like if wine doesn't need it, we also don't need it? Or again fork the code? I would sell my mother to Carthage for even a fraction of the kind of application support that Wine enjoys, thank you. My only gripe with arwinss is that Aleksey beat me to the first landmark controversial side project ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
Hyperion is riht here; take a look at WINE code then look at ros...WINE appears much more professional than ros code. Good luck aleksey. --Original Message-- From: KJK::Hyperion Sender: ros-dev-boun...@reactos.org To: ReactOS Development List ReplyTo: ReactOS Development List Subject: Re: [ros-dev] Arwinss Sent: Jul 20, 2009 8:47 AM Timo Kreuzer wrote: Wine emulates the kernel through a server. Of cause we don't use it, because it has a totally different design. Says who? So far, and only counting official implementations, Win32 has been implemented as: - a shared-memory user mode subsystem (Windows 95, 98) - a RPC user mode subsystem (Windows NT 3) - a kernel mode subsystem (Windows NT 4 and later) - ??? (Windows CE) We have an NT kernel and every kernel developer would eat me alive if I tried to put a single line of wine code into our kernel. It's considered crap there. Wine code has to pass quality reviews and test suites. ReactOS code only has to pass the warmth-and-fuzziness test. Wine can prove their code is right, ReactOS is based on code that feels right The idea that Wine code is better than ReactOS code really needs to die. Compared to theirs, our code is sloppy, highly unprofessional and often inexplicable. We copy the form but tend to completely miss the intent. Wine development is test-driven and entirely based on intent and end results, while our development model is, apparently, to dick around in our spare time pretending we work at Microsoft How do you expect display drivers to work at all? NT display drivers used to run in user mode with the same identical API, and probably the same ABI. I'm sure Aleksey will do just fine More hacks on top of the huge pile of hacks? And how do you deal with missing functionality in wine code? Shove more code in there? Or ignore it, like if wine doesn't need it, we also don't need it? Or again fork the code? I would sell my mother to Carthage for even a fraction of the kind of application support that Wine enjoys, thank you. My only gripe with arwinss is that Aleksey beat me to the first landmark controversial side project ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Sent on the Sprint® Now Network from my BlackBerry® ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
Just out of curiousity: what wine code and what reactos code were you looking at, that you come to this conclusion? yardkarter...@gmail.com schrieb: Hyperion is riht here; take a look at WINE code then look at ros...WINE appears much more professional than ros code. Good luck aleksey. --Original Message-- From: KJK::Hyperion Sender: ros-dev-boun...@reactos.org To: ReactOS Development List ReplyTo: ReactOS Development List Subject: Re: [ros-dev] Arwinss Sent: Jul 20, 2009 8:47 AM Timo Kreuzer wrote: Wine emulates the kernel through a server. Of cause we don't use it, because it has a totally different design. Says who? So far, and only counting official implementations, Win32 has been implemented as: - a shared-memory user mode subsystem (Windows 95, 98) - a RPC user mode subsystem (Windows NT 3) - a kernel mode subsystem (Windows NT 4 and later) - ??? (Windows CE) We have an NT kernel and every kernel developer would eat me alive if I tried to put a single line of wine code into our kernel. It's considered crap there. Wine code has to pass quality reviews and test suites. ReactOS code only has to pass the warmth-and-fuzziness test. Wine can prove their code is right, ReactOS is based on code that feels right The idea that Wine code is better than ReactOS code really needs to die. Compared to theirs, our code is sloppy, highly unprofessional and often inexplicable. We copy the form but tend to completely miss the intent. Wine development is test-driven and entirely based on intent and end results, while our development model is, apparently, to dick around in our spare time pretending we work at Microsoft How do you expect display drivers to work at all? NT display drivers used to run in user mode with the same identical API, and probably the same ABI. I'm sure Aleksey will do just fine More hacks on top of the huge pile of hacks? And how do you deal with missing functionality in wine code? Shove more code in there? Or ignore it, like if wine doesn't need it, we also don't need it? Or again fork the code? I would sell my mother to Carthage for even a fraction of the kind of application support that Wine enjoys, thank you. My only gripe with arwinss is that Aleksey beat me to the first landmark controversial side project ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Sent on the SprintŽ Now Network from my BlackBerryŽ ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
