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 <alek...@reactos.org> 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<gedmur...@gmail.com> wrote: > >> Current win32 subsystem progress is too slow. We need something > >> now before > >> it's too late. > >> One of the main things that's holing us back and stopping new devs > >> from > >> getting involved is out lack of compatibility and stability. > >> > > 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
