Arwinss architecture

[Aleksey Bragin]

	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.

[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 <aleksey(a)reactos.org> 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[King InuYasha]

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 <elhoir(a)gmail.com>

>   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 <aleksey(a)reactos.org>wrote;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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Brian]

i cant help but feel that is how it should have been done in the first place
by the way the diagram looks



-- 
brian

[Timo Kreuzer]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

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:[e-mail]] 
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

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:[e-mail]]
>  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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

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<gedmurphy(a)gmail.com> wrote:
>   What people should also know is that if this branch
> ever does make it into
>  trunk it will only be used as a temporary solution until the correct
>  implementation is ready. This is by no means a permanent solution!
>
>  What it will do is act as a temp replacement which will hold things together
>  and allow work on the real subsystem to accelerate.
>
>
>
>  At the moment the current subsystem must be kept stable as it’s our main
>  component and needs to stay regression free whilst rewriting major parts to
>  make it more compatible. Not an easy task!
>
>  If the Arwinss model can take over for a while it will gives the win32
>  subsystem developers breathing space to rewrite / hack / break / fight /
>  kill / molest and eventually improve the real implementation without
>  worrying about breaking reactos for everyone else.
>
>
>
>  In the long run this may be a great solution to improve the compatibility
>  and stability of the real reactos win32 subsystem.
>
>
>
>  Ged.
>
>
>

[Javier Agustìn Fernàndez Arroyo]

war is here 3:>

On Wed, Jul 29, 2009 at 7:30 PM, James Tabor <jimtabor.rosdev(a)gmail.com>wrote;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<gedmurphy(a)gmail.com> wrote:
> >   What people should also know is that if this
> > branch ever does make it 
>  into
> >   trunk it will only be used as a temporary
> > solution until the correct
> >  implementation is ready. This is by no means a permanent solution!
> >
> >  What it will do is act as a temp replacement which will hold things 
>  together
> >   and allow work on the real subsystem to
> > accelerate.
> >
> >
> >
> >  At the moment the current subsystem must be kept stable as it’s our main
> >  component and needs to stay regression free whilst rewriting major parts 
>  to
> >   make it more compatible. Not an easy task!
> >
> >  If the Arwinss model can take over for a while it will gives the win32
> >  subsystem developers breathing space to rewrite / hack / break / fight /
> >  kill / molest and eventually improve the real implementation without
> >  worrying about breaking reactos for everyone else.
> >
> >
> >
> >  In the long run this may be a great solution to improve the compatibility
> >  and stability of the real reactos win32 subsystem.
> >
> >
> >
> >  Ged.
> >
> >
> >  
>   _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Ged]

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:[e-mail]] 
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<gedmurphy(a)gmail.com> wrote:
>   What people should also know is that if this branch
> ever does make it into
>  trunk it will only be used as a temporary solution until the correct
>  implementation is ready. This is by no means a permanent solution!
>
>  What it will do is act as a temp replacement which will hold things 
together
>   and allow work on the real subsystem to accelerate.
>
>
>
>  At the moment the current subsystem must be kept stable as it's our main
>  component and needs to stay regression free whilst rewriting major parts 
to
>   make it more compatible. Not an easy task!
>
>  If the Arwinss model can take over for a while it will gives the win32
>  subsystem developers breathing space to rewrite / hack / break / fight /
>  kill / molest and eventually improve the real implementation without
>  worrying about breaking reactos for everyone else.
>
>
>
>  In the long run this may be a great solution to improve the compatibility
>  and stability of the real reactos win32 subsystem.
>
>
>
>  Ged.
>
>
>  
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[King InuYasha]

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 <gedmurphy(a)gmail.com> wrote:

>   Current win32 subsystem progress is too slow. We need
> something now before
>  it's too late.
>  One of the main things that's holing us back and stopping new devs from
>  getting involved is out lack of compatibility and stability.
>
>  If we have a drop in replacement which is much more compatible and stable
>  then the current one, then I think it's wise to use that whilst the real
>  implementation is continued alongside.
>
>  Surely this will give you the freedom to get architecture done without
>  worrying about breaking things?
>
>  Ged.
>
>  -----Original Message-----
>  From: James Tabor [mailto:[e-mail]]
>  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<gedmurphy(a)gmail.com> wrote:
> >   What people should also know is that if this
> > branch ever does make it 
>  into
> >   trunk it will only be used as a temporary
> > solution until the correct
> >  implementation is ready. This is by no means a permanent solution!
> >
> >  What it will do is act as a temp replacement which will hold things 
>  together
> >   and allow work on the real subsystem to
> > accelerate.
> >
> >
> >
> >  At the moment the current subsystem must be kept stable as it's our main
> >  component and needs to stay regression free whilst rewriting major parts 
>  to
> >   make it more compatible. Not an easy task!
> >
> >  If the Arwinss model can take over for a while it will gives the win32
> >  subsystem developers breathing space to rewrite / hack / break / fight /
> >  kill / molest and eventually improve the real implementation without
> >  worrying about breaking reactos for everyone else.
> >
> >
> >
> >  In the long run this may be a great solution to improve the compatibility
> >  and stability of the real reactos win32 subsystem.
> >
> >
> >
> >  Ged.
> >
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[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 <ngompa13(a)gmail.com> wrote:

>   Makes sense. And once the real subsystems are
> compatible and stable enough,
>  then the arwinss branch could be relegated to an addon. An addon that could
>  be used on both ReactOS and Windows. It's a stopgap solution, but one that
>  would have uses after it is replaced.
>
>
>  On Wed, Jul 29, 2009 at 1:10 PM, Ged <gedmurphy(a)gmail.com> wrote:
>
> >   Current win32 subsystem progress is too slow. We
> > need something now before
> >  it's too late.
> >  One of the main things that's holing us back and stopping new devs from
> >  getting involved is out lack of compatibility and stability.
> >
> >  If we have a drop in replacement which is much more compatible and stable
> >  then the current one, then I think it's wise to use that whilst the real
> >  implementation is continued alongside.
> >
> >  Surely this will give you the freedom to get architecture done without
> >  worrying about breaking things?
> >
> >  Ged.
> >
> >  -----Original Message-----
> >  From: James Tabor [mailto:[e-mail]]
> >  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<gedmurphy(a)gmail.com> wrote:
> > >   What people should also know is that if this
> > > branch ever does make it 
> >  into
> > >   trunk it will only be used as a temporary
> > > solution until the correct
> > >  implementation is ready. This is by no means a permanent solution!
> > >
> > >  What it will do is act as a temp replacement which will hold things 
> >  together
> > >   and allow work on the real subsystem to
> > > accelerate.
> > >
> > >
> > >
> > >  At the moment the current subsystem must be kept stable as it's our main
> > >  component and needs to stay regression free whilst rewriting major parts 
> >  to
> > >   make it more compatible. Not an easy task!
> > >
> > >  If the Arwinss model can take over for a while it will gives the win32
> > >  subsystem developers breathing space to rewrite / hack / break / fight /
> > >  kill / molest and eventually improve the real implementation without
> > >  worrying about breaking reactos for everyone else.
> > >
> > >
> > >
> > >  In the long run this may be a great solution to improve the 
> >  compatibility
> > >   and stability of the real reactos win32
> > > subsystem.
> > >
> > >
> > >
> > >  Ged.
> > >
> > >
> > >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Zachary Gorden]

Why would we need the X server for remote access if we have terminal
services?

[Steven Edwards]

On Wed, Jul 29, 2009 at 3:09 PM, Zachary Gorden<drakekaizer666(a)gmail.com> wrote:
>   Why would we need the X server for remote access if we
> have terminal
>  services? 
We don't have terminal services though. I mean we should of course,
and I should also have a pony. I'm not saying it should go in trunk or
not, just pointing out that its kind of a neat feature that has many
uses. And besides, if you've ever tried to do rootless RDP to a Linux
or Mac host, you would know it makes kittens cry...

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Alexandru Lovin]

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 <elhoir(a)gmail.com>

>   Personally i like the idea of being able to access
> remotely using an X
>  Server.. Could this feature be ported to current Win32k implementation after
>  Arwinss is deprecated?
>
>
>  On Wed, Jul 29, 2009 at 8:42 PM, King InuYasha <ngompa13(a)gmail.com> wrote:
>
> >   Makes sense. And once the real subsystems are
> > compatible and stable
> >  enough, then the arwinss branch could be relegated to an addon. An addon
> >  that could be used on both ReactOS and Windows. It's a stopgap solution, but
> >  one that would have uses after it is replaced.
> >
> >
> >  On Wed, Jul 29, 2009 at 1:10 PM, Ged <gedmurphy(a)gmail.com> wrote:
> >
> > >   Current win32 subsystem progress is too slow. We
> > > need something now
> > >  before
> > >  it's too late.
> > >  One of the main things that's holing us back and stopping new devs from
> > >  getting involved is out lack of compatibility and stability.
> > >
> > >  If we have a drop in replacement which is much more compatible and stable
> > >  then the current one, then I think it's wise to use that whilst the real
> > >  implementation is continued alongside.
> > >
> > >  Surely this will give you the freedom to get architecture done without
> > >  worrying about breaking things?
> > >
> > >  Ged.
> > >
> > >  -----Original Message-----
> > >  From: James Tabor [mailto:[e-mail]]
> > >  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<gedmurphy(a)gmail.com> wrote:
> > > >   What people should also know is that if this
> > > > branch ever does make it 
> > >  into
> > > >   trunk it will only be used as a temporary
> > > > solution until the correct
> > > >  implementation is ready. This is by no means a permanent solution!
> > > >
> > > >  What it will do is act as a temp replacement which will hold things 
> > >  together
> > > >   and allow work on the real subsystem to
> > > > accelerate.
> > > >
> > > >
> > > >
> > > >  At the moment the current subsystem must be kept stable as it's our 
> > >  main
> > > >   component and needs to stay regression free
> > > > whilst rewriting major 
> > >  parts
> > >  to
> > > >   make it more compatible. Not an easy task!
> > > >
> > > >  If the Arwinss model can take over for a while it will gives the win32
> > > >  subsystem developers breathing space to rewrite / hack / break / fight 
> > >  /
> > > >   kill / molest and eventually improve the real
> > > > implementation without
> > > >  worrying about breaking reactos for everyone else.
> > > >
> > > >
> > > >
> > > >  In the long run this may be a great solution to improve the 
> > >  compatibility
> > > >   and stability of the real reactos win32
> > > > subsystem.
> > > >
> > > >
> > > >
> > > >  Ged.
> > > >
> > > >
> > > >  
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


-- 
Alex Lovin - www.erasereality.3x.ro

[James Tabor]

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<gedmurphy(a)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.

>   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

[Aleksey Bragin]

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<gedmurphy(a)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.

[King InuYasha]

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 <aleksey(a)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<gedmurphy(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Timo Kreuzer]

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

[Samuel serapion]

I love you.

On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer <timo.kreuzer(a)web.de> 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alex Ionescu]

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 <samdwise51(a)gmail.com>wrote;wrote:

>   I love you.
>
>
>  On Thu, Jul 30, 2009 at 10:00 AM, Timo Kreuzer <timo.kreuzer(a)web.de>wrote;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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[James Tabor]

Hi!

On Thu, Jul 30, 2009 at 7:51 AM, King InuYasha<ngompa13(a)gmail.com> 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

[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<gedmurphy(a)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).
>     
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 of a kernel
structure and a usermode structure. This result of "let's do it our own
way" is leading to null pointer dereferences, memory leaks and whatever.
Jim currently makes good progress in this area so that I expect this
mess to be cleaned up soon. This will be a premise to do proper fixing
of the Winpos code that is very buggy.
Let's look at the sysparams: Our earlier implementation was huge,
bloated, incomplete and it would have been simply impossible to fix it.
So I spent quite some time in analyzing how it works on windows and
rewriting it. It turned out that we were storing certain variables in
absurd locations. It's still not 100% right, but I'm quite certain that
the current design is good enough to work out in the future.

What is the advantage of this?
Doing it "your own way", ignoring everything you know about the Win32
subsystem, hacking hacks upon hacks, reusing large portions of 3rd party
code without understanding the inner workings might actually get you
some working subsystem in the short run (although this still remains to
be seen). But it will most likely also result in duplicated work later.
At some point you'll notice: Ohh crap, this all doesn't work out like it
should. Why that? Rewrite #7!

On the other hand, using all pieces of knowledge about how it works on
Windows will help to make sure that the code will work correctly even
later with parts and details you didn't yet take care of. As soon as you
know how something works on Windows especially how things are
interrelated, you're free to change whatever detail is
neccessary/useful. But you shouldn't think you're smarter than all the
ms devs if you don't understand how that stuff works on windows.

Regards,
Timo

[James Tabor]

2009/7/30 Timo Kreuzer <timo.kreuzer(a)web.de>de>:
>   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<gedmurphy(a)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).
>
>
>  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 of a kernel
>  structure and a usermode structure. This result of "let's do it our own
> way"
>  is leading to null pointer dereferences, memory leaks and whatever. Jim
>  currently makes good progress in this area so that I expect this mess to be
>  cleaned up soon. This will be a premise to do proper fixing of the Winpos
>  code that is very buggy. 
FYI, SMWP has started, once I get menu/item converted
after class/windows.

>   Let's look at the sysparams: Our earlier
> implementation was huge, bloated,
>  incomplete and it would have been simply impossible to fix it. So I spent
>  quite some time in analyzing how it works on windows and rewriting it. It
>  turned out that we were storing certain variables in absurd locations. It's
>  still not 100% right, but I'm quite certain that the current design is good
>  enough to work out in the future.
>
>  What is the advantage of this?
>  Doing it "your own way", ignoring everything you know about the Win32
>  subsystem, hacking hacks upon hacks, reusing large portions of 3rd party
>  code without understanding the inner workings might actually get you some
>  working subsystem in the short run (although this still remains to be seen).
>  But it will most likely also result in duplicated work later. At some point
>  you'll notice: Ohh crap, this all doesn't work out like it should. Why that?
>  Rewrite #7!
>
>  On the other hand, using all pieces of knowledge about how it works on
>  Windows will help to make sure that the code will work correctly even later
>  with parts and details you didn't yet take care of. As soon as you know how
>  something works on Windows especially how things are interrelated, you're
>  free to change whatever detail is neccessary/useful. But you shouldn't think
>  you're smarter than all the ms devs if you don't understand how that stuff
>  works on windows.
>
>  Regards,
>  Timo
>
>  
I agree!
If anyone (Also the Orig Devs) bothered to do the proper research and
read the books published and some are available online, you will "GET
IT". I wrote this into the code so anyone with good programming skills
can pick this up. Read my code it's there and it's getting better
since we started placing comments in there. Reason, some do not know
how to read music.

The only way a nebie can get their feet wet is to dig into the code
and read. Hooking a wire to your head at night will not help you "GET
IT".

Class work:
Kernel space and User space, why? Compare the number of callbacks,
advantages and disadvantages, why ReactOS is faster in this relation.
James

[James Tabor]

Hi,

On Thu, Jul 30, 2009 at 3:25 AM, Aleksey Bragin<aleksey(a)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<gedmurphy(a)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).
>
>  
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

[Aleksey Bragin]

>   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.

[James Tabor]

LOL!

On Thu, Jul 30, 2009 at 10:37 AM, Aleksey Bragin<aleksey(a)reactos.org> 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

[Aleksey Bragin]

On Jul 30, 2009, at 8:03 PM, James Tabor wrote:

>   LOL!
>
>  On Thu, Jul 30, 2009 at 10:37 AM, Aleksey  
>  Bragin<aleksey(a)reactos.org> 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.

[Aleksey Bragin]

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<aleksey(a)reactos.org> 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