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. 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 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
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 presentation
why? Sent from my iPod Andrew Faulds (andrewweb) On 21 Jan 2010, at 18:50, Alwyn Tan wrote: I blame andrewweb. On Wed, Jan 20, 2010 at 10:31 AM, Aleksey Bragin 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=Arwinss&diff=27579&oldid=27578 > It was news to me too I wrote that after seeing this: http://www.reactos.org/wiki/index.php? title=Arwinss&diff=27396&oldid=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
I blame andrewweb. On Wed, Jan 20, 2010 at 10:31 AM, Aleksey Bragin 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=Arwinss&diff=27579&oldid=27578 > > It was news to me too > I wrote that after seeing this: > http://www.reactos.org/wiki/index.php? > title=Arwinss&diff=27396&oldid=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
Re: [ros-dev] Arwinss presentation
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=Arwinss&diff=27579&oldid=27578 > It was news to me too I wrote that after seeing this: http://www.reactos.org/wiki/index.php? title=Arwinss&diff=27396&oldid=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
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=Arwinss&diff=27579&oldid=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
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 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
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
Good catch! On Tue, Jan 19, 2010 at 7:05 PM, Steven Edwards wrote: > On Tue, Jan 19, 2010 at 6:11 PM, James Tabor > 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
On Tue, Jan 19, 2010 at 6:11 PM, James Tabor 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
performance, and probably compatibility On Wed, Jan 20, 2010 at 1:18 AM, Sir Gallantmon 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 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~! >> >> On Tue, Jan 19, 2010 at 3:54 PM, Sir Gallantmon >> 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
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 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~! > > On Tue, Jan 19, 2010 at 3:54 PM, Sir Gallantmon > 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
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 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
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
On Tue, Jan 19, 2010 at 3:19 PM, Ged Murphy wrote: > > > On Tue, Jan 19, 2010 at 8:23 PM, Colin Finck 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 > > 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... ___ 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 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
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 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 3:23 PM, Colin Finck 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
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
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
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
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
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
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" To: "ReactOS Development List" 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 Bragin >> 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 presentation
Great work Aleksey! I'm completely convinced by your presentation. Now a usable ReactOS becomes highly viable. I will be working on the kernel, but I heartly support the move to Arwinss. Jose Catena DIGIWAVES S.L. -Original Message- From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On Behalf Of Aleksey Bragin Sent: Saturday, 16 January, 2010 22:45 To: ReactOS Development List Subject: [ros-dev] Arwinss presentation ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 Bragin napisał(a): > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
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 Bragin napisał(a): > All, > today I would like to officially announce the (sub)project I was > working on for the last half a year, and make a call to developers to > participate. > > ReactOS has been around for about 11 years, and it's been growing > each year since then. The demand for an open source Windows- > compatible operating system is huge: geek, servers, netbooks, > accounting, point of sales, CAD... The list could go on and on. > > Time goes by, new versions of Windows operating systems are being > released. ReactOS usability still has not reached any significant > value. Not to say ReactOS didn't even officially enter the Beta > stage. Separately, there are many achievements: audio support > appeared, bootloader is able to boot real Windows, some Windows > binary drivers could be loaded and work in ReactOS, networking is > being improved every day, the kernel is being actively worked on too. > But all of that does not really matter for the end user. For a user > it's important that a web-browser loads websites, instant messenger > client connects and works, [Microsoft/Open] Office shows documents, > email client gets new messages. > > This bare usability is what's still missing, and if ti continues to > be like this, I am afraid our project won't be of much use in another > 10 years. Certainly, I became very concerned and started analyzing > situation. Being opensource project without major commercial > sponsors, there are certain limitations as to what could be done to > improve the situation, so mainly it's a matter of picking right > priorities and properly managing (motivating) existing human resources. > > The part of ReactOS which plays major role in compatibility and > usability is Win32 subsystem. Right now, it's a huge monster which > requires a lot more human resources than we have now. It's very hard > and time consuming to reach even Windows 2000 level of compatibility > with current amount of participating developers, and high entry level. > > I came up with something which could solve this problem: Arwinss. To > better explain what it is, I made a special presentation (URL to > slides in PDF format is in the end of this email). Please imagine > myself talking through it as I didn't perform/record it. > > Now, after you read through the presentation, I would like to make a > proposal to all developers (even newcomers, who never worked on > ReactOS before). Let's make an Arwinss week, or Arwinss month. Every > developer could definitely find a few hours during a week to hack > Arwinss. Entry level is rather low, there are some basic docs about > Arwinss in the wiki, and I am happy to consult about details. > > If I could make this new subsystem out of nothing (out of Wine and > ReactOS) almost alone (Kamil and Smiley help is very valued and > appreciated!) within a few months, imagine what we could do all > together? > > With the best regards, > Aleksey Bragin. > > The presentation: (links to further information are in the > presentation too) > http://www.reactos.org/media/docs/2010/arwinss.pdf > > > ___ > 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
That's a long email :) I second the call out for help too, please devs, could we focus for at least a month to try fix the remaining issues in arwinss and see what comes out ? I've been testing arwinss and I think it's got a huge potential to be a working OS. I think that all devs that work and have worked in current win32k have done a great job, but we are running out of time, with so little resources there are little choices to make, keep this way taking a lot of time to reach our goal (it'll be too late probably), or optimize what we have to get there faster. This is the humble opinion of a simple fan, tester, patcher, translator of ros (registered since 2003 but following the project since 2002 in fact) in the hope of getting some inspiration from all the team. Please try to make this a constructive discussion, the only intention here is to have a working ReactOS faster. Thank you all in advance. Gabriel. _ Non sei a casa? Prova il nuovo Web Messenger http://www.messenger.it/web/default.aspx___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
What you guys need is some way to convince the ARM Ninjas that rewriting the memory manager won't make the ARM port easier -- but that rewriting win32k/gdi32/user32 will! Best regards, Alex Ionescu On Thu, Jul 30, 2009 at 1:32 PM, Samuel serapion wrote: > I love you. > > > On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer wrote: > >> King InuYasha schrieb: >> > Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the >> > implementation that some people are saying is "right" is more in line >> with >> > the NT4-WinXP. >> You obviously have no clue what you're talking about. >> arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 >> architecture. >> Also Vista/Win7 architecture is following XP/2003 architecture much more >> than NT3. >> >> > In the strictest sense of the definition, both arwinss and >> > the current default implementation styles are "correct." Both >> > implementations work and allow Windows NT drivers to work with it, so >> that's >> > not the problem. It also adds in RDP-esque support through X, which is >> > pretty cool too. >> > I guess some of these people don't like Wine code. The problem with that >> is >> > that without Wine code, ReactOS would probably take ten times as long to >> > actually get to a usable state. >> That's just bs. >> The win32 subsystem has a bunch of bugs yes, but don't expect them to go >> away by using more wine code. >> >> > Using Wine code for win32k seems to cross >> > some sort of line for them. I heard some of them saying the Wine code >> for >> > win32k is "ugly." >> When you talk about "them" and "these people" you talk about us, don't >> you? It's win32k devs you talk about, right? If you can do the coding >> for us, ... >> >> > What does ugliness have to do with it? Being able to share >> > more with Wine saves a lot of hard work from ReactOS devs. They can >> focus >> > more on bringing the NT kernel up to scratch, rather than spending more >> time >> > with the Win32k code. >> And this is exactly what is *not* happening. Aleksey currentlty spends >> his time with this win32k rewrite instead of something useful, like >> fixing the kernel or fixing the real win32k or fixing fat or usb or >> porting reactos to mips. >> >> > They could even work on adding in other subsystems, if >> > they wanted to. >> > >> Yes everyone is free to code what he likes, it just won't lead us >> anywhere. >> >> Sorry for sounding rude, but I just hate when people with no >> understanding about the topic are spreading misinformation. >> >> Thanks, >> Timo >> >> >> >> ___ >> 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
I love you. On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer wrote: > King InuYasha schrieb: > > Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the > > implementation that some people are saying is "right" is more in line > with > > the NT4-WinXP. > You obviously have no clue what you're talking about. > arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 > architecture. > Also Vista/Win7 architecture is following XP/2003 architecture much more > than NT3. > > > In the strictest sense of the definition, both arwinss and > > the current default implementation styles are "correct." Both > > implementations work and allow Windows NT drivers to work with it, so > that's > > not the problem. It also adds in RDP-esque support through X, which is > > pretty cool too. > > I guess some of these people don't like Wine code. The problem with that > is > > that without Wine code, ReactOS would probably take ten times as long to > > actually get to a usable state. > That's just bs. > The win32 subsystem has a bunch of bugs yes, but don't expect them to go > away by using more wine code. > > > Using Wine code for win32k seems to cross > > some sort of line for them. I heard some of them saying the Wine code for > > win32k is "ugly." > When you talk about "them" and "these people" you talk about us, don't > you? It's win32k devs you talk about, right? If you can do the coding > for us, ... > > > What does ugliness have to do with it? Being able to share > > more with Wine saves a lot of hard work from ReactOS devs. They can focus > > more on bringing the NT kernel up to scratch, rather than spending more > time > > with the Win32k code. > And this is exactly what is *not* happening. Aleksey currentlty spends > his time with this win32k rewrite instead of something useful, like > fixing the kernel or fixing the real win32k or fixing fat or usb or > porting reactos to mips. > > > They could even work on adding in other subsystems, if > > they wanted to. > > > Yes everyone is free to code what he likes, it just won't lead us anywhere. > > Sorry for sounding rude, but I just hate when people with no > understanding about the topic are spreading misinformation. > > Thanks, > Timo > > > > ___ > 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
How much time do you need to make existing trunk's win32 subsystem to have at least Wine's compatibility and usability level? I'm speaking of gdi32/user32/win32k mostly, don't account other parts for now. On Jul 30, 2009, at 8:03 PM, James Tabor wrote: > LOL! > > On Thu, Jul 30, 2009 at 10:37 AM, Aleksey > Bragin wrote: >>> 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. > I'm getting PM'ed out the ass! I'm not the one scared, you scared > everyone else! The impression is, we are replacing our win32k system > with something else. > >> >> So far Timo provided an extensive answer to my questions, thanks. >> >> >> WBR, >> Aleksey Bragin. >> > Read my email closer, you have your class assignment, no less than 10 > pages too... papers are due in December so you have more than > enough time. > James ___ 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 8:03 PM, James Tabor wrote: > LOL! > > On Thu, Jul 30, 2009 at 10:37 AM, Aleksey > Bragin wrote: >>> 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. > I'm getting PM'ed out the ass! I'm not the one scared, you scared > everyone else! The impression is, we are replacing our win32k system > with something else. Obviously we aren't! It just can't happen without approval of other developers, so don't panic. Everything is under control. WBR, Aleksey Bragin. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
LOL! On Thu, Jul 30, 2009 at 10:37 AM, Aleksey Bragin wrote: >> 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. I'm getting PM'ed out the ass! I'm not the one scared, you scared everyone else! The impression is, we are replacing our win32k system with something else. > > So far Timo provided an extensive answer to my questions, thanks. > > > WBR, > Aleksey Bragin. > Read my email closer, you have your class assignment, no less than 10 pages too... papers are due in December so you have more than enough time. James ___ 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
2009/7/30 Timo Kreuzer : > Aleksey Bragin schrieb: > > 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, Ged 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). > > > Ripping our win32k out from trunk will not help with it's development. Do > you think we will get more developers that say "yay there's 2 win32 > subsystems, that's exactly what I was looking for"? Ripping it apart won't > help. And if there's something that can break trunk, we can do it in a > temprary branch and merge it back as soon as it's ready and tested. Proper > testing is obligatory. But how do you expect probems to be detected when you > don't even have that code in trunk? How do you expect people will fix bugs > in it when the code is somewhere outside trunk? Please stop telling it's an > advantage for win32k devs, cause it's not. > > Also: I still don't see where you want to get more stability and > compatibility with that new subsystem. We have some bugs yes, but the major > buggers are still in the kernel. How often does win32k crash and how often > does the kernel crash. Don't blame win32k for everything, instead put your > own house in order first. > > > 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. > > > There's a lot more. The structures and syscall interfaces are just the > bottom. You can use the syscall interfaces for native api testing to make > sure you know what is the kernel's part is and what is gdi/user's part. Then > you can use the structures together with WinDbg and memory dumps and back > traces to do very detailed analysis of the inner workings of functions > without disassembling anything. It tells you where objects are allcoated > from, where objects come from and where they point to. Looking at the symbol > names tells you a great detail of the inner workings, too. I have added > backtraces from font drivers to the wiki. That probably tells you more about > the internal font driver architecture than all books. Combine all these > methods and you get a lot more detailed knowledge about the inner > architecture. The rest is reasoning and extrapolation. > > Now let's look at design compared to windows (XP/2003) > There's the gdi handle manager, which is is now working almost identical to > the Windows one. There's shared locks and references that work like on > Windows (not everywhere but getting there). There are still problems but > it's already quite good. It allows us to use the gdi handle viewer tool in > reactos. It also allows loading reactos gdi32 in windows (although it fails > for most things) > There's brushes. The interface between the usermode brushes and the kernel > brushobj and DCs and XLATEOBJs is quite complicated. Just slapping something > together that kinda does it's job for now and improving on it later is what > has been done in our win32k in earlier times. Everone just adds his 5 lines > of fix upon the existing code instead of fixing the implementation > architecture. But that leeds to code that gets more and more bloated and > complicated and slow. I've spend some time fixing it and it should be much > more Windows like now. As a side effect we now have support for DC pen/brush > and for the first time allows display drivers to use their own brushes > instead of failing miserably. > Let's loo
Re: [ros-dev] Arwinss architecture
Hi! On Thu, Jul 30, 2009 at 7:51 AM, King InuYasha wrote: > Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the > implementation that some people are saying is "right" is more in line with > the NT4-WinXP. In the strictest sense of the definition, both arwinss and > the current default implementation styles are "correct." Both > implementations work and allow Windows NT drivers to work with it, so that's > not the problem. It also adds in RDP-esque support through X, which is > pretty cool too. Nothing close at all~ We have a list of books for you to read, media/doc/books.txt, but that list looks very short, someone removed some book about win32k in there. > I guess some of these people don't like Wine code. The problem with that is > that without Wine code, ReactOS would probably take ten times as long to > actually get to a usable state. Using Wine code for win32k seems to cross > some sort of line for them. I heard some of them saying the Wine code for > win32k is "ugly." What does ugliness have to do with it? Being able to share > more with Wine saves a lot of hard work from ReactOS devs. They can focus > more on bringing the NT kernel up to scratch, rather than spending more time > with the Win32k code. They could even work on adding in other subsystems, if > they wanted to. > > Do some research with our project, go back and read our emails and correlate them with our commit logs to get a more precise picture on what happen and why and where. Understanding our history will help you understand where we are today. Thanks, James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Hi, On Thu, Jul 30, 2009 at 3:25 AM, Aleksey Bragin wrote: > > 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, Ged 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). > > LOL, which Alex, the one I know, knows the rewrite already started back in 2006. Yes I know about breakage, and I wish someone will bring up the fact about the whole rewrite work I started and how it moved the project past a level of a hacky POS. Including the other developers that had time to KILL working on win32k. I guess in this instance we can not complain about coding styles or bad grammar. >>> 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. > Paint is already drying, if you haven't noticed. > 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. I'm to busy working on real problems right now to sit here a write a book for you when you should have been reading all the commit logs in the first place. FYI, I'm fixing windowing class issues, if you did not notice. Small fixes have been known to fix big problems. Read the logs. In away, I'm still a part time body builder, but now days it's for heath reasons. If you start lifting heavy weights with arms and legs first with out building up your back, what is going to happen when you start deadlifting? You are going to blow your back out! Stay out of ReactOS! Go ahead and work on ArWinSS, James ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
King InuYasha schrieb: > Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the > implementation that some people are saying is "right" is more in line with > the NT4-WinXP. You obviously have no clue what you're talking about. arwinss has no more in common with NT3 or Vista/7 than with NT4/XP/2003 architecture. Also Vista/Win7 architecture is following XP/2003 architecture much more than NT3. > In the strictest sense of the definition, both arwinss and > the current default implementation styles are "correct." Both > implementations work and allow Windows NT drivers to work with it, so that's > not the problem. It also adds in RDP-esque support through X, which is > pretty cool too. > I guess some of these people don't like Wine code. The problem with that is > that without Wine code, ReactOS would probably take ten times as long to > actually get to a usable state. That's just bs. The win32 subsystem has a bunch of bugs yes, but don't expect them to go away by using more wine code. > Using Wine code for win32k seems to cross > some sort of line for them. I heard some of them saying the Wine code for > win32k is "ugly." When you talk about "them" and "these people" you talk about us, don't you? It's win32k devs you talk about, right? If you can do the coding for us, ... > What does ugliness have to do with it? Being able to share > more with Wine saves a lot of hard work from ReactOS devs. They can focus > more on bringing the NT kernel up to scratch, rather than spending more time > with the Win32k code. And this is exactly what is *not* happening. Aleksey currentlty spends his time with this win32k rewrite instead of something useful, like fixing the kernel or fixing the real win32k or fixing fat or usb or porting reactos to mips. > They could even work on adding in other subsystems, if > they wanted to. > Yes everyone is free to code what he likes, it just won't lead us anywhere. Sorry for sounding rude, but I just hate when people with no understanding about the topic are spreading misinformation. Thanks, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
Aleksey Bragin schrieb: > 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, Ged 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). > Ripping our win32k out from trunk will not help with it's development. Do you think we will get more developers that say "yay there's 2 win32 subsystems, that's exactly what I was looking for"? Ripping it apart won't help. And if there's something that can break trunk, we can do it in a temprary branch and merge it back as soon as it's ready and tested. Proper testing is obligatory. But how do you expect probems to be detected when you don't even have that code in trunk? How do you expect people will fix bugs in it when the code is somewhere outside trunk? Please stop telling it's an advantage for win32k devs, cause it's not. Also: I still don't see where you want to get more stability and compatibility with that new subsystem. We have some bugs yes, but the major buggers are still in the kernel. How often does win32k crash and how often does the kernel crash. Don't blame win32k for everything, instead put your own house in order first. > 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. > There's a lot more. The structures and syscall interfaces are just the bottom. You can use the syscall interfaces for native api testing to make sure you know what is the kernel's part is and what is gdi/user's part. Then you can use the structures together with WinDbg and memory dumps and back traces to do very detailed analysis of the inner workings of functions without disassembling anything. It tells you where objects are allcoated from, where objects come from and where they point to. Looking at the symbol names tells you a great detail of the inner workings, too. I have added backtraces from font drivers to the wiki. That probably tells you more about the internal font driver architecture than all books. Combine all these methods and you get a lot more detailed knowledge about the inner architecture. The rest is reasoning and extrapolation. Now let's look at design compared to windows (XP/2003) There's the gdi handle manager, which is is now working almost identical to the Windows one. There's shared locks and references that work like on Windows (not everywhere but getting there). There are still problems but it's already quite good. It allows us to use the gdi handle viewer tool in reactos. It also allows loading reactos gdi32 in windows (although it fails for most things) There's brushes. The interface between the usermode brushes and the kernel brushobj and DCs and XLATEOBJs is quite complicated. Just slapping something together that kinda does it's job for now and improving on it later is what has been done in our win32k in earlier times. Everone just adds his 5 lines of fix upon the existing code instead of fixing the implementation architecture. But that leeds to code that gets more and more bloated and complicated and slow. I've spend some time fixing it and it should be much more Windows like now. As a side effect we now have support for DC pen/brush and for the first time allows display drivers to use their own brushes instead of failing miserably. Let's look at the Window structures. We use a combination
Re: [ros-dev] Arwinss architecture
Arwinss resembles the NT3/Vista/7 architecture for Win32k, while the implementation that some people are saying is "right" is more in line with the NT4-WinXP. In the strictest sense of the definition, both arwinss and the current default implementation styles are "correct." Both implementations work and allow Windows NT drivers to work with it, so that's not the problem. It also adds in RDP-esque support through X, which is pretty cool too. I guess some of these people don't like Wine code. The problem with that is that without Wine code, ReactOS would probably take ten times as long to actually get to a usable state. Using Wine code for win32k seems to cross some sort of line for them. I heard some of them saying the Wine code for win32k is "ugly." What does ugliness have to do with it? Being able to share more with Wine saves a lot of hard work from ReactOS devs. They can focus more on bringing the NT kernel up to scratch, rather than spending more time with the Win32k code. They could even work on adding in other subsystems, if they wanted to. On Thu, Jul 30, 2009 at 3:25 AM, Aleksey Bragin wrote: > > 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, Ged 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 > ___ 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, Ged 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
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, Ged 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. > 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
On Wed, Jul 29, 2009 at 3:09 PM, Zachary Gorden 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
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 > 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 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 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, 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 fo
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
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 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 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, 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. >> > >> > >> > >> >> ___ >> 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
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 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, 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. > > > > > > > > ___ > 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
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, 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. > > > ___ 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 wrote: > 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, 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. > > > > > > > > ___ > 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
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, 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. > > > ___ 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
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
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
i cant help but feel that is how it should have been done in the first place by the way the diagram looks -- brian ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
This architecture makes it possible to do headless instances of Windows. ReactOS might actually make some headway with this architecture. People that have to use Windows for their server platform would probably appreciate being able to run Windows totally headless and remotely connecting and using their regular tools as if they were sitting right at the server console. 2009/7/28 Javier Agustìn Fernàndez Arroyo > Loks awesome > Hope you are right, and ROS will be actually *better* than Windows! > > > On Tue, Jul 28, 2009 at 8:41 PM, Aleksey Bragin wrote: > >>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 >> > > > ___ > 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
Loks awesome Hope you are right, and ROS will be actually *better* than Windows! On Tue, Jul 28, 2009 at 8:41 PM, Aleksey Bragin wrote: >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 > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
On Tue, Jul 21, 2009 at 11:59 AM, KJK::Hyperion wrote: > 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 There are many different views on 'better' There can be: a is a more technically correct design than b b is more compatible than a b is easier to read than a a is written lang $foo while b is written in lang $bar I am sure we could go on... Needless to say I don't believe using wineserver in win32k is more 'correct' for ReactOS's goals. If our goal is to be fully compatible with Windows its a (general relatively) short term short solution to the end user problems but not to the overall design goal. The correct thing it would seem is IF and this is a big IF, it does prove to function better than our existing win32k/user32/gdi32 then to use it and quickly move one piece of our existing win32k.sys and friends back in at a time to isolate and fix problems while keeping the same level of compatibly and not allowing regressions in wine tests and applications. Also it would be nice to carry forward the new feature we gain which is the remote X display support. If it gets more people to use ReactOS and brings in more users and developers there is a case for being pragmatic. -- 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
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 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
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
On Mon, Jul 20, 2009 at 10:47 AM, KJK::Hyperion 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
Re: [ros-dev] Arwinss
yardkarter...@gmail.com wrote: > I'll look at the code when I get access to my PC and > pull up examples Don't ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
It's been awhile since I've looked at the ros code; mostly involved with wine on os x now. I'll look at the code when I get access to my PC and pull up examples if nobody beats me to it. Although I have a feeling someone will beat me since I won't be home for a week. Sent on the Sprint® Now Network from my BlackBerry® -Original Message- From: Timo Kreuzer Date: Mon, 20 Jul 2009 21:19:41 To: ; ReactOS Development List Subject: 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
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
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
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
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
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 >
Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 10:09 AM, Steven Edwards wrote: > 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. Sorry I mean't libW11 -- 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
On Mon, Jul 20, 2009 at 9:31 AM, King InuYasha 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
On Mon, Jul 20, 2009 at 8:15 AM, Steven Edwards wrote: > 2009/7/20 Javier Agustìn Fernàndez Arroyo : > > "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
2009/7/20 Javier Agustìn Fernàndez Arroyo : > "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
Re: [ros-dev] Arwinss
"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??
On Mon, Jul 20, 2009 at 12:16 PM, 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 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
