FreeWin95

[Emanuele Aliberti]

I just want to warn you are going to build FreeWin95 with WDM support.

-- 
:Emanuele Aliberti

[Jason Filby]

Elaborate?

On 10/9/05, Emanuele Aliberti <ea(a)iol.it> wrote:
>  
>  I just want to warn you are going to build FreeWin95 with WDM support.
>
>  --
>  :Emanuele Aliberti
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Max Well]

I think he wants to say, that we stick to close with Windows.
ReactOS really looks like a clone of Windows NT and doesn't have many
new features.
In my oppinion he is right, maybe we should create something innovative,
that is intuitive and compatible to Windows NT, but doesn't clone the
whole UI.
Maybe we should think of a redesign of the UI, but at the moment I think
the kernel should have a higher priority.

Greets,

David Hinz


Jason Filby schrieb:
>   Elaborate?
>  
>  On 10/9/05, *Emanuele Aliberti* &lt;ea(a)iol.it <mailto:[e-mail]>> wrote:
>  
>      I just want to warn you are going to build FreeWin95 with WDM support.
>  
>      --
>      :Emanuele Aliberti
>  
>      _______________________________________________
>      Ros-dev mailing list
>      Ros-dev(a)reactos.org <mailto:[e-mail]>
>      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

[Jason Filby]

To me it sounds like disagreement with some design choices. We could have a
development team vote, although I always hate when we go on a vote with some
people unhappy about the direction -- debate and a middle way would be
better.

Cheers
Jason

On 10/9/05, Max Well <post.center(a)gmail.com> wrote:
>  
>  I think he wants to say, that we stick to close with Windows.
>  ReactOS really looks like a clone of Windows NT and doesn't have many
>  new features.
>  In my oppinion he is right, maybe we should create something innovative,
>  that is intuitive and compatible to Windows NT, but doesn't clone the
>  whole UI.
>  Maybe we should think of a redesign of the UI, but at the moment I think
>  the kernel should have a higher priority.
>
>  Greets,
>
>  David Hinz
>
>

[Max Well]

I don't think, we should change any direction now or in the near future, 
but I think for release 0.5.0 we should have a redesigned UI.
But that's far away...

Greets,

David Hinz

Jason Filby schrieb:
>   To me it sounds like disagreement with some design
> choices. We could 
>  have a development team vote, although I always hate when we go on a 
>  vote with some people unhappy about the direction -- debate and a middle 
>  way would be better.
>  
>  Cheers
>  Jason
>  
>  On 10/9/05, *Max Well* <post.center(a)gmail.com 
>  <mailto:[e-mail]>> wrote:
>  
>      I think he wants to say, that we stick to close with Windows.
>      ReactOS really looks like a clone of Windows NT and doesn't have many
>      new features.
>      In my oppinion he is right, maybe we should create something
>      innovative,
>      that is intuitive and compatible to Windows NT, but doesn't clone the
>      whole UI.
>      Maybe we should think of a redesign of the UI, but at the moment I think
>      the kernel should have a higher priority.
>  
>      Greets,
>  
>      David Hinz
>  
>

[Max Well]

Well, I already thought of a new UI design and I will try to create a 
preview, but I think the project is in a too early state for crating a 
second UI.

Making it skinnable seems to be a good idea, but it will make the whole 
thing much more difficult.

The most important thing for me is to get away from the classical 
windows look and feel with windows, taskbar and so on.

Greets,

David Hinz

crashfourit schrieb:
>   I think it would be best to have the UI completely
> skinnable, or very 
>  near thereof.  Personally, I'm partial to the LCARS look (Star Trek).  
>  http://www.google.com/search?hl=en&q=lcars&btnG=Google+Search
>  
>  
>  Jason Filby wrote:
>  
> >   To me it sounds like disagreement with some
> > design choices. We could 
> >  have a development team vote, although I always hate when we go on a 
> >  vote with some people unhappy about the direction -- debate and a 
> >  middle way would be better.
> >
> >  Cheers
> >  Jason
> >
> >  On 10/9/05, *Max Well* <post.center(a)gmail.com 
> >  <mailto:[e-mail]>> wrote:
> >
> >      I think he wants to say, that we stick to close with Windows.
> >      ReactOS really looks like a clone of Windows NT and doesn't have many
> >      new features.
> >      In my oppinion he is right, maybe we should create something
> >      innovative,
> >      that is intuitive and compatible to Windows NT, but doesn't clone the
> >      whole UI.
> >      Maybe we should think of a redesign of the UI, but at the moment I
> >      think
> >      the kernel should have a higher priority.
> >
> >      Greets,
> >
> >      David Hinz
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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

[crashfourit]

Yes, Making it completely skinnable would be difficult and require a lot 
of programing, but it will quite possibly widen the market up for ReactOS.

Max Well wrote:

>   Well, I already thought of a new UI design and I will
> try to create a 
>  preview, but I think the project is in a too early state for crating a 
>  second UI.
>
>  Making it skinnable seems to be a good idea, but it will make the 
>  whole thing much more difficult.
>
>  The most important thing for me is to get away from the classical 
>  windows look and feel with windows, taskbar and so on.
>
>  Greets,
>
>  David Hinz
>
>  crashfourit schrieb:
>
> >   I think it would be best to have the UI
> > completely skinnable, or very 
> >  near thereof.  Personally, I'm partial to the LCARS look (Star 
> >  Trek).  http://www.google.com/search?hl=en&q=lcars&btnG=Google+Search
> >
> >
> >  Jason Filby wrote:
> >
> > >   To me it sounds like disagreement with some
> > > design choices. We could 
> > >  have a development team vote, although I always hate when we go on a 
> > >  vote with some people unhappy about the direction -- debate and a 
> > >  middle way would be better.
> > >
> > >  Cheers
> > >  Jason
> > >
> > >  On 10/9/05, *Max Well* <post.center(a)gmail.com 
> > >  <mailto:[e-mail]>> wrote:
> > >
> > >      I think he wants to say, that we stick to close with Windows.
> > >      ReactOS really looks like a clone of Windows NT and doesn't have 
> > >  many
> > >      new features.
> > >      In my oppinion he is right, maybe we should create something
> > >      innovative,
> > >      that is intuitive and compatible to Windows NT, but doesn't 
> > >  clone the
> > >      whole UI.
> > >      Maybe we should think of a redesign of the UI, but at the moment I
> > >      think
> > >      the kernel should have a higher priority.
> > >
> > >      Greets,
> > >
> > >      David Hinz
> > >
> > >
> > >  ------------------------------------------------------------------------ 
> > >
> > >
> > >  _______________________________________________
> > >  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
>

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Max
> Well
>  Sent: 9. oktober 2005 21:30
>  To: ReactOS Development List
>  Cc: Jason Filby
>  Subject: Re: [ros-dev] FreeWin95
>  
>  Well, I already thought of a new UI design and I will try to create a
>  preview, but I think the project is in a too early state for crating a
>  second UI.
>  
>  Making it skinnable seems to be a good idea, but it will make the whole
>  thing much more difficult.
>  
>  The most important thing for me is to get away from the classical
>  windows look and feel with windows, taskbar and so on. 
Such a change will cause companies millions of dollars in training and thus
make adoption of ReactOS much harder. Is it really worth it?

Casper

[Max Well]

I don't think they will have to train their employees, because the first 
priority for such a new UI should be that is intuitive. And if it is 
really intuitive, you don't need to train anybody, neither a newbie, nor 
  an advanced user.

Greets,

David Hinz

Casper Hornstrup schrieb:
> >  -----Original
> > Message-----
> > From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Max
> > Well
> > Sent: 9. oktober 2005 21:30
> > To: ReactOS Development List
> > Cc: Jason Filby
> > Subject: Re: [ros-dev] FreeWin95
> >
> > Well, I already thought of a new UI design and I will try to create a
> > preview, but I think the project is in a too early state for crating a
> > second UI.
> >
> > Making it skinnable seems to be a good idea, but it will make the whole
> > thing much more difficult.
> >
> > The most important thing for me is to get away from the classical
> > windows look and feel with windows, taskbar and so on. 
>  
>  
>  Such a change will cause companies millions of dollars in training and thus
>  make adoption of ReactOS much harder. Is it really worth it?
>  
>  Casper
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[TwoTailedFox]

Surely then, a compromise exists in that truth.

If it can be done, implement Two UI's, selectable on Setup. One is the
"Windows Classic", the other is one that has yet to be designed.

On 10/9/05, Casper Hornstrup <ch(a)csh-consult.dk> wrote:
> >   -----Original
> > Message-----
> >  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Max
> > Well
> >  Sent: 9. oktober 2005 21:30
> >  To: ReactOS Development List
> >  Cc: Jason Filby
> >  Subject: Re: [ros-dev] FreeWin95
> >
> >  Well, I already thought of a new UI design and I will try to create a
> >  preview, but I think the project is in a too early state for crating a
> >  second UI.
> >
> >  Making it skinnable seems to be a good idea, but it will make the whole
> >  thing much more difficult.
> >
> >  The most important thing for me is to get away from the classical
> >  windows look and feel with windows, taskbar and so on. 
>  Such a change will cause companies millions of dollars in training and thus
>  make adoption of ReactOS much harder. Is it really worth it?
>
>  Casper
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
"I had a handle on life, but then it broke"

Little problem:

Our GUI is very slow even without skinning atm, I don't want to know how
slow would it be with skinning...
So I think we must make the GUI very much faster before we can think of
skinning etc.

There are a lot of alternate Shells around, first try these before making
a complete new ;)

[crashfourit]

Thin the first priority (in the UI department) should be to locate all 
those nasty UI bottle necks and remove them.

michael(a)fritscher.net wrote:

>  Little problem:
>
> Our GUI is very slow even without skinning atm, I don't want to know how
> slow would it be with skinning...
> So I think we must make the GUI very much faster before we can think of
> skinning etc.
>
> There are a lot of alternate Shells around, first try these before making
> a complete new ;)
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   
>

[Martin Fuchs]

2005/10/9, michael(a)fritscher.net <michael(a)fritscher.net>et>:
>   Little problem:
>
>  Our GUI is very slow even without skinning atm, I don't want to know how
>  slow would it be with skinning...
>  So I think we must make the GUI very much faster before we can think of
>  skinning etc. 
I think the main reason for the slowness are missing optimizations.
For example the DeferWindows() API is currently not implemented, but
replaced by calls to the synchronous SetWindowPos() API. I don't know
to current kernel/WIN32 code good enough, but expect there are many
other examples like this. What's also missing are accelerated screen
drivers. Things like a generic S3 accelerating driver...

>   There are a lot of alternate Shells around, first try
> these before making
>  a complete new ;) 
Correct. If you want to make a completely other (better) GUI, I would
recommend to take that of those programs, which is closest to that you
are seeking, and build what you need additional on top of this.

Regards,

    Martin

[Casper Hornstrup]

Getting 30 people to agree on everything is utopia.

 

  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Jason
Filby
Sent: 9. oktober 2005 21:02
To: Max Well
Cc: ReactOS Development List; ea(a)reactos.org
Subject: Re: [ros-dev] FreeWin95

 

To me it sounds like disagreement with some design choices. We could have a development
team vote, although I always hate when we go
on a vote with some people unhappy about the direction -- debate and a middle way would be
better. 

Cheers
Jason

On 10/9/05, Max Well <post.center(a)gmail.com> wrote:

I think he wants to say, that we stick to close with Windows.
ReactOS really looks like a clone of Windows NT and doesn't have many
new features.
In my oppinion he is right, maybe we should create something innovative, 
that is intuitive and compatible to Windows NT, but doesn't clone the
whole UI.
Maybe we should think of a redesign of the UI, but at the moment I think
the kernel should have a higher priority.

Greets, 

David Hinz

[James Tabor]

Casper Hornstrup wrote:
>   Getting 30 people to agree on everything is utopia.
>  
>    
I agree!

BTW,
FreeWin95 is out of date. I can not compile ROS with Win98-2.
If there is a vote, I vote Ros as in Win 2k/Xp or better.

Other words, stay the course.

Thanks,
James

[Aleksey Bragin]

All 30 may easily agree with the statement you just wrote :-)

It's like my friend Mark Robbins likes to say - "Remember you're  
unique - just like everyone else!" (sorry forgot who's the author of  
this sentence).


WBR,
Aleksey Bragin.

On Oct 9, 2005, at 11:23 PM, Casper Hornstrup wrote:

>   Getting 30 people to agree on everything is utopia.
>
>
>
>  From: ros-dev-bounces(a)reactos.org [mailto:ros-dev- 
>  bounces(a)reactos.org] On Behalf Of Jason Filby
>  Sent: 9. oktober 2005 21:02
>  To: Max Well
>  Cc: ReactOS Development List; ea(a)reactos.org
>  Subject: Re: [ros-dev] FreeWin95
>
>
>
>  To me it sounds like disagreement with some design choices. We  
>  could have a development team vote, although I always hate when we  
>  go on a vote with some people unhappy about the direction -- debate  
>  and a middle way would be better.
>
>  Cheers
>  Jason

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Max
> Well
>  Sent: 9. oktober 2005 21:00
>  To: Jason Filby; ReactOS Development List
>  Cc: ea(a)reactos.org
>  Subject: Re: [ros-dev] FreeWin95
>  
>  I think he wants to say, that we stick to close with Windows.
>  ReactOS really looks like a clone of Windows NT and doesn't have many
>  new features.
>  In my oppinion he is right, maybe we should create something innovative,
>  that is intuitive and compatible to Windows NT, but doesn't clone the
>  whole UI.
>  Maybe we should think of a redesign of the UI, but at the moment I think
>  the kernel should have a higher priority.
>  
>  Greets,
>  
>  David Hinz 
No one has said you can't be innovative, but you have to be realistic. Inventing
a whole new super-optimized driver model or a new user interface that makes users
more productive isn't easy and requires a lot of resources to do. So what do you
want?
An OS that does more of what people have come to expect from a modern OS or an OS
that does much less of that and something in a completely new way. You can't do both
since ReactOS has limited resources like any other software project.

Casper

[Emanuele Aliberti]

Casper Hornstrup wrote:

>    
>
> >  -----Original Message-----
> > From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Max
> > Well
> > Sent: 9. oktober 2005 21:00
> > To: Jason Filby; ReactOS Development List
> > Cc: ea(a)reactos.org
> > Subject: Re: [ros-dev] FreeWin95
> >
> > I think he wants to say, that we stick to close with Windows.
> > ReactOS really looks like a clone of Windows NT and doesn't have many
> > new features.
> > In my oppinion he is right, maybe we should create something innovative,
> > that is intuitive and compatible to Windows NT, but doesn't clone the
> > whole UI.
> > Maybe we should think of a redesign of the UI, but at the moment I think
> > the kernel should have a higher priority.
> >
> > Greets,
> >
> > David Hinz
> >     
> >  
> No one has said you can't be innovative, but you have to be realistic. Inventing
> a whole new super-optimized driver model or a new user interface that makes users
> more productive isn't easy and requires a lot of resources to do. So what do you
> want?
> An OS that does more of what people have come to expect from a modern OS or an OS
> that does much less of that and something in a completely new way. You can't do both
> since ReactOS has limited resources like any other software project.
>
> Casper
>
>
>
>   
>  
You are perfectly right about resources.

But where is ReactOS innovative?
- drivers: it is binary compatibile with NT 4.0: it clones a Microsoft 
product
- ntoskrnl interfaces: it is binary compatible with NT 4.0, 5.0, 5.1, 
5.2...: it (will) clone a Microsoft product
- UI: it (will) look like Windows 95, 98, NT 4.0, 5.0...: it (will) 
clone a Microsoft product
- libraries: they will match interfaces in NT 4.0, 5.0, 5.1, 5.2...: it 
(will) clone a Microsoft product
- services: ...
But cloning and beeing binary compatible there is the right choice. I 
repeat it: it is good and right. No changes needed: make it work just 
like the other one.

The CSR is the only point in the design of NT where we could add 
something new, or - let me word it better - put back something Microsoft 
removed. Cloning the crippled CSR Microsoft sells now would produce a 
perfect clone of - say - Windows XP. Well, if I want Windows XP now I go 
in a computer shop and buy it. But what if the CSR could run - say - the 
Linux usermode kernel? Linux gets in a snap a multithreaded packet based 
kernel and thousands of free and commercial drivers. Would you then go 
in the shop to buy a Windows XP that can not run Linux? Or would you 
download the latest Fedora ISO that can't run Windows programs? A 
generic CSR is the worst nightmare Microsoft, Sun, Apple etc. dream of 
every night. Every time you invent a more general/universal tool, that 
is a tool that is more abstract than you competitor's, their market 
shrinks and they eventually disappear. Look at film cameras and digital 
cameras, for instance.

What would be the equivalent, in the OS field, for the digital cameras?

Look at Mac OS X: does its design teach us something?

But going back to the resources, what if Microsoft completely changes 
the APIs or if the Microsoft monopoly declines? Could the ReactOs\WinE 
developers keep pace with them or with the new king?

To close my noise, I quote a teacher of mine: "abstraction is the key of 
Computer Science". When you clone you do a 1:1 mapping with no abstraction.

Oh, Casper, about forgetting it! I really like rbuild: it is an 
abstraction of make.

-- 
:Emanuele Aliberti

[Casper Hornstrup]

>   But going back to the resources, what if Microsoft
> completely changes
>  the APIs or if the Microsoft monopoly declines? Could the ReactOs\WinE
>  developers keep pace with them or with the new king? 
They change the APIs all the time. You can try to complete this graph made
by Gé van Geldorp and see if we can keep their pace ;-)

http://www.reactos.nl/pics/date-svn.png

Casper

[James Tabor]

Emanuele Aliberti wrote:

>   
>  Oh, Casper, about forgetting it! I really like rbuild: it is an 
>  abstraction of make.
>   
Yes, that might be correct, but it is 20 sec faster than make too.

Thanks,
James

[Casper Hornstrup]

Correct. FreeWin95 and ReactOS are the same project.

Casper

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
> Emanuele
>  Aliberti
>  Sent: 9. oktober 2005 19:53
>  To: ReactOS Development List
>  Subject: [ros-dev] FreeWin95
>  
>  I just want to warn you are going to build FreeWin95 with WDM support.
>  
>  --
>  :Emanuele Aliberti
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Gunnar Dalsnes]

I dont understand what this "fight" is about. Could you and Alex 
elaborate? I would take part in this discussion too, if i only knew what 
it is about;-)

G.

Emanuele Aliberti wrote:
>   I just want to warn you are going to build FreeWin95
> with WDM support.
>

[Richard Campbell]

This discussion has come up on the list many times in the past (well, as 
far as skinning goes).  Until ROS can run reliably and fast, there is no 
need for skinning support.  When you can successfully run the NVidia 
installer to install your graphics drivers, then upon reboot run a dx9 
or OpenGL based game and play for hours on end, THEN skinning support 
should be considered.  Right now we still have graphical corruption just 
from our CURRENT windows classic look.
Gunnar Dalsnes wrote:

>   I dont understand what this "fight" is
> about. Could you and Alex 
>  elaborate? I would take part in this discussion too, if i only knew 
>  what it is about;-)
>
>  G.
>
>  Emanuele Aliberti wrote:
>
> >   I just want to warn you are going to build
> > FreeWin95 with WDM support.
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[D. Hazelton]

On Monday 10 October 2005 03:23, Richard Campbell wrote:
>   This discussion has come up on the list many times in
> the past
>  (well, as far as skinning goes).  Until ROS can run reliably and
>  fast, there is no need for skinning support.  When you can
>  successfully run the NVidia installer to install your graphics
>  drivers, then upon reboot run a dx9 or OpenGL based game and play
>  for hours on end, THEN skinning support should be considered. 
>  Right now we still have graphical corruption just from our CURRENT
>  windows classic look. 
I cannot disagree with this logic but the fact that XP has moved the 
graphic style from the GDI routines and into a helper DLL cannot be 
overlooked - doubly so if ReactOS is to be intuitive to the generic 
WindowsXP user, who might try installing an XP theme like those 
available with the XP version of the WindowBlinds program.

That case, however, is a long way off - The few people I've mentioned 
ROS to have said "get back to me when it's truly stable and I'll try 
it out". That's not any of my clients, but a few local programmers 
and at least two of the hardware vendors I use.

DRH

[crashfourit]

I have to say; he is correct. We need to do a lot more testing and 
coding before we can do that.

Richard Campbell wrote:

>   This discussion has come up on the list many times in
> the past (well, 
>  as far as skinning goes).  Until ROS can run reliably and fast, there 
>  is no need for skinning support.  When you can successfully run the 
>  NVidia installer to install your graphics drivers, then upon reboot 
>  run a dx9 or OpenGL based game and play for hours on end, THEN 
>  skinning support should be considered.  Right now we still have 
>  graphical corruption just from our CURRENT windows classic look.
>  Gunnar Dalsnes wrote:
>
> >   I dont understand what this "fight" is
> > about. Could you and Alex 
> >  elaborate? I would take part in this discussion too, if i only knew 
> >  what it is about;-)
> >
> >  G.
> >
> >  Emanuele Aliberti wrote:
> >
> > >   I just want to warn you are going to build
> > > FreeWin95 with WDM support.
> > >  
> >  _______________________________________________
> >  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
>

[Nate DeSimone]

I agree as well, I think adding skinning support right now would 
definately be getting ahead of yourselves, how about some working 
networking with firefox and wireless network cards, not to mention a 
system stable enough so I can run my machine for days without reboot?  I 
personally think that solid office productivity and solid networking 
with wireless support is more important right now than getting theming 
working.  I personally think that theming should come AFTER DirectX 9 
and nVidia/ATI graphics drivers are working, that way the theming engine 
than render the entire GUI using hardware acceleration and particle 
effects (aka Mac OS X Quartz Extreme).  Might as well do it right the 
first time than do a crappy job and go back and fix it later.

crashfourit wrote:

>   I have to say; he is correct. We need to do a lot more
> testing and 
>  coding before we can do that.
>
>  Richard Campbell wrote:
>
> >   This discussion has come up on the list many
> > times in the past (well, 
> >  as far as skinning goes).  Until ROS can run reliably and fast, there 
> >  is no need for skinning support.  When you can successfully run the 
> >  NVidia installer to install your graphics drivers, then upon reboot 
> >  run a dx9 or OpenGL based game and play for hours on end, THEN 
> >  skinning support should be considered.  Right now we still have 
> >  graphical corruption just from our CURRENT windows classic look.
> >  Gunnar Dalsnes wrote:
> >
> > >   I dont understand what this "fight" is
> > > about. Could you and Alex 
> > >  elaborate? I would take part in this discussion too, if i only knew 
> > >  what it is about;-)
> > >
> > >  G.
> > >
> > >  Emanuele Aliberti wrote:
> > >
> > > >   I just want to warn you are going to build
> > > > FreeWin95 with WDM support.
> > > >  
> > >  _______________________________________________
> > >  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
>
>

[Phoebe _]

Prettyness/GUI-customizability vs functionality.

Hmm. Real hard choice there.

[Emanuele Aliberti]

Hi Richard,

>   This discussion has come up on the list many times in
> the past (well, 
>  as far as skinning goes).  Until ROS can run reliably and fast, there 
>  is no need for skinning support.  When you can successfully run the 
>  NVidia installer to install your graphics drivers, then upon reboot 
>  run a dx9 or OpenGL based game and play for hours on end, THEN 
>  skinning support should be considered.  Right now we still have 
>  graphical corruption just from our CURRENT windows classic look. 
I am not really talking about the GUI.


-- 
:Emanuele Aliberti

[Emanuele Aliberti]

Hi Gunnar Dalsnes,

>   I dont understand what this "fight" is
> about. Could you and Alex 
>  elaborate? I would take part in this discussion too, if i only knew 
>  what it is about;-)
>
>  G.
>
>  Emanuele Aliberti wrote:
>
> > I just want to warn you are going to build FreeWin95 with WDM support.
> > 
There is no "fight". Just a "disagreement with some design choices",
as 
correctly Jason said. Probably a vote will eventually close it. But, as 
you too ask for, a technical discussion is required, presenting 
arguments pro and contra.

The design choice, in short, is the rôle of the "Client/Server Runtime 
SubSystem" (CSR=CSRSS.EXE+CSRSRV.DLL) in the design of the "O.S. 
Personality" code, that is the emulation code that manages processes of 
the same operating system in user mode, making them belive to run on the 
emulated O.S.

Think about it like the program run by the Architect in Matrix: when you 
double click on Microsoft Word's icon and the process is created, it 
happily belives to run under Windows, it can see the familiar libraries, 
it can call CreateFile and get back a reasonable file. In fact, 
CreateFile calls NtCreateFile and so on. Microsoft Word lives in a fake 
World. ;)

The two opposite directions the CSR can turn for are:
- be a process totally bound to the Windows personality
- be a general purpose process, a facility for any kind of personality

More on demand.

-- 
:Emanuele Aliberti

[Casper Hornstrup]

>   The two opposite directions the CSR can turn for are:
>  - be a general purpose process, a facility for any kind of personality 
What are the arguments against this? I can provide the obvious argument:
more complex implementation.

Casper

[Emanuele Aliberti]

Casper Hornstrup wrote:

> >  The two
> > opposite directions the CSR can turn for are:
> > - be a general purpose process, a facility for any kind of personality
> >     
> >  
> What are the arguments against this? I can provide the obvious argument:
> more complex implementation.
>   
>  
This is a well known side effect of more general (abstract) designs. You 
spend more at the beginning and spend less later when the implementation 
needs redesign.

-- 
:Emanuele Aliberti

[Alex Ionescu]

Emanuele Aliberti wrote:

>   Hi Gunnar Dalsnes,
>
> >   I dont understand what this "fight" is
> > about. Could you and Alex 
> >  elaborate? I would take part in this discussion too, if i only knew 
> >  what it is about;-)
> >
> >  G.
> >
> >  Emanuele Aliberti wrote:
> >
> > > I just want to warn you are going to build FreeWin95 with WDM support.
> > > 
>  There is no "fight". Just a "disagreement with some design choices",
>
>  as correctly Jason said. Probably a vote will eventually close it. 
>  But, as you too ask for, a technical discussion is required, 
>  presenting arguments pro and contra. 
I view this as a "misunderstanding with some design choices", if not 
even a "misunderstanding of NT Subsystem design".

>  
>  The design choice, in short, is the rôle of the "Client/Server Runtime 
>  SubSystem" (CSR=CSRSS.EXE+CSRSRV.DLL) in the design of the "O.S. 
>  Personality" code, that is the emulation code that manages processes 
>  of the same operating system in user mode, making them belive to run 
>  on the emulated O.S. 
The Client/Server Runtime SubSystem, which is unfortunately incorrectly 
named by Microsoft, is actually the Win32 Personality. It manages Win32 
processes in user-mode, and allows them to access kernel features which 
would pollute the native-mode ntdll.dll, would they have been included 
there. Only Win32 processes use csrss and registration is done in 
kernel32. Console windows, another Win32-ism also use csrss. Because NT 
was designed with a set of universal native APIs, this was necessary so 
that routines useful to only one personality wouldn't be exported as 
native APIs. For example, fork() is a POSIX-only API, not Windows 32. 
Therefore, it was not included in ntdll.dll, even though the kernel 
supports it. Instead, it's used by the POSIX subsystem. The same goes 
for Console windows and their APIs, which are usable only in Win32. 
Access to the video hardware is done in kernel-mode, but the functions 
are called through CSRSS.

Now, CSRSS is in a way a Client/Server Subsystem, because it's merely a 
4KB host to CSR Servers, which implement parts of the Win32 behaviour. 
The 3 servers currently used are: basesrv.dll, which handles SxS (Side 
by Side assemblies, a Windows XP feature), VDM (16-bit emulation) and 
stuff like Process/Thread creation, winsrv.dll, which handles some 
graphical things and windowmessage-related functionality (such as 
hardware event dispatching) plus all the Console code (winsrv is 
internally split into 2 CSR Servers). I think a big problem here is that 
ea believes that CSRSS is the place where you would add a POSIX 
subsystem. This isn't the case. CSRSS is reserved for Win32 CSR Servers.

Now, let's move on...what actually loads CSRSS? This is called SMSS, the 
Session Manager SubSystem. The Session Manager handles all the 
subsystems that are installed on an NT Machine. By default, this means 
CSRSS, the Win32 subsystem. If you install SFU 3.5, or are using Windows 
Server 2003 R2, you will also get psxss.exe. On older Windows, you can 
also have os2ss.exe. These are the POSIX and OS/2 subsystems. They have 
nothing to do with CSR at all, and they are actually, in themselves, 
CSRSSes for their own subsystems. This is the naming mistake I was 
talking about; Microsoft should have named csrss as w32ss.exe.

So, SMSS is the first process that will load, and it will then load the 
subsystems, say csrss psxss and os2ss. These subsystems will then load 
server dlls which expose functionality that can be called from user-mode 
processes.

As I'm writing this, my Win2K3 machine is running posix grep and working 
perfectly. It's not touchign CSRSS at all, nor should it have to. CSRSS 
is a win32 subsystem.

>  
>  Think about it like the program run by the Architect in Matrix: when 
>  you double click on Microsoft Word's icon and the process is created, 
>  it happily belives to run under Windows, it can see the familiar 
>  libraries, it can call CreateFile and get back a reasonable file. In 
>  fact, CreateFile calls NtCreateFile and so on. Microsoft Word lives in 
>  a fake World. ;)
>
>  The two opposite directions the CSR can turn for are:
>  - be a process totally bound to the Windows personality 
Which it's -supposed- to be. CSR is W32SS.

>   - be a general purpose process, a facility for any
> kind of personality 
Other personalities don't need CSR! They have PSX and OS2 and VMS and etc...

>  
>  More on demand.
>  
Another issue which ea has brought up is that NT is somehow to 
"connected" to Win32. I beg to differ. I've spent a week working on a 
sample native application. It currently can display running processes, 
drivers, create a new process and create/delete/list files. Here are 
some screenshots:

http://members.tripod.com/WinAlOS/rtlcli.png
http://members.tripod.com/WinAlOS/rtlcli2.png
http://members.tripod.com/WinAlOS/rtlcli3.png

Note that there is no CSR, no win32k.sys loaded. NT is running in its 
rawest form. You need less then 16MB of memory (notice that the 
processes are using <1MB, the rest is up to the drivers, which you can 
disable) and about the same amount of diskspace. This works perfectly in 
Windows 2003 without any need to "separate win32".

Best regards,
Alex Ionescu

[Gunnar Dalsnes]

Alex Ionescu wrote:
>   Emanuele Aliberti wrote:
>  
> >  
> >  The two opposite directions the CSR can turn for are:
> >  - be a process totally bound to the Windows personality 
>  
>  
>  Which it's -supposed- to be. CSR is W32SS.
>  
> >   - be a general purpose process, a facility for
> > any kind of personality 
>  
>  
>  Other personalities don't need CSR! They have PSX and OS2 and VMS and 
>  etc...
>   
Makes sense.

But maybe each subsystem have much in common and EA wants to separate 
this out so it can be reused? Like a common subsystem library? I see no 
problem with this either as long as its not bound to a particular 
subsystem. So if i understand this correctly both your (EA & Alex) 
designs can coexist, as long as its not bound to csrss.

G.

[Alex Ionescu]

Gunnar Dalsnes wrote:

>   Alex Ionescu wrote:
>
> >   Emanuele Aliberti wrote:
> >
> > >  
> > >  The two opposite directions the CSR can turn for are:
> > >  - be a process totally bound to the Windows personality 
> >
> >
> >  Which it's -supposed- to be. CSR is W32SS.
> >
> > >   - be a general purpose process, a facility for
> > > any kind of personality 
> >
> >
> >  Other personalities don't need CSR! They have PSX and OS2 and VMS and 
> >  etc...
> >  
>  Makes sense.
>
>  But maybe each subsystem have much in common and EA wants to separate 
>  this out so it can be reused?  
It's called SMSS. It provides a set of APIs and callbacks for each 
subsystems to use.

>   Like a common subsystem library? 
SMLIB is ours, MS used to have it static but now exposes it through 
Rtl*sm* in ntdll.dll starting in Vista.

>   I see no problem with this either as long as its not
> bound to a 
>  particular subsystem.  
SMSS/SMLIB aren't. All subsystems can (*must*) use them, and also 
provide callbacks to that SMSS can call them with common stuff.

>   So if i understand this correctly both your (EA &
> Alex) designs can 
>  coexist, as long as its not bound to csrss. 

>  
>  G. 
Best regards,
Alex Ionescu

[Emanuele Aliberti]

Alex Ionescu wrote:

>   I view this as a "misunderstanding with some
> design choices", if not 
>  even a "misunderstanding of NT Subsystem design". 
Subsystem design is subtle. Cutler is not an ordinary person. Also the 
subsystem design was conceived in another era, in CS terms. Cutler and 
his group designed it when the OS (beginning-to-ruin) myth was CM Mach 
(at the same time, RMS invented Hurd; recently Apple could sell it 
rebranded as Mac OS X...).

> >  
> >  The design choice, in short, is the rôle of the "Client/Server 
> >  Runtime SubSystem" (CSR=CSRSS.EXE+CSRSRV.DLL) in the design of the 
> >  "O.S. Personality" code, that is the emulation code that manages 
> >  processes of the same operating system in user mode, making them 
> >  belive to run on the emulated O.S. 
>
>  The Client/Server Runtime SubSystem, which is unfortunately 
>  incorrectly named by Microsoft,  
It is funny to note now that what you say here is a thought that spinned 
around in my mind for years in the past. My personal answer was exactly 
yours.

>   is actually the Win32 Personality.  
Later I discovered a theologian and philosopher - W. Ockam 
(1295/1300-1349) - that today most of us (don't) know is the father of 
the KIS(S) principle. Do not invent an hypothesis if it *not needed*. I 
used to say "Those developers at MS are really eccentric! Why did they 
call the Win32 subsystem server CSRSS.EXE? They are really dumb!".

The unnecessary assumption is, of course, that they *incorrectly named* it.

>   It manages Win32 processes in user-mode, and allows
> them to access 
>  kernel features which would pollute the native-mode ntdll.dll, would 
>  they have been included there. Only Win32 processes use csrss and 
>  registration is done in kernel32. Console windows, another Win32-ism 
>  also use csrss.  
This is what we observe today in a live system of the NT family. But, if 
you see a man that wears a black suit, are you sure he's a priest? It 
could be a MiB, or a punk, or simply an old fashioned gentleman.

For instance, everybody here knows that the dynamic library NTDLL.DLL 
exposes the so called "native API", the NT real API. But even you are 
diverted by that sweet assonance and commit the mistake of saying it has 
the native-mode mark. Indeed its subsystem ID is 3.

When I discovered it, I had a shock, a few years ago.

Does it fit in you picture?

>   Because NT was designed with a set of universal native
> APIs, this was 
>  necessary so that routines useful to only one personality wouldn't be 
>  exported as native APIs. For example, fork() is a POSIX-only API, not 
>  Windows 32. Therefore, it was not included in ntdll.dll, even though 
>  the kernel supports it. Instead, it's used by the POSIX subsystem. The 
>  same goes for Console windows and their APIs, which are usable only in 
>  Win32. Access to the video hardware is done in kernel-mode, but the 
>  functions are called through CSRSS.
>  
A very good example, but a less precise description. NtCreateProcess is 
an API that is more abstract than Win32 CreateProcess and than POSIX 
fork/exec. As it is more abstract, the respective less general semantics 
can be implemented using it. As Casper pointed out, more general, more 
abstract, means more complex.

>   Now, CSRSS is in a way a Client/Server Subsystem,
> because it's merely 
>  a 4KB host to CSR Servers, which implement parts of the Win32 
>  behaviour. The 3 servers currently used are: basesrv.dll, which 
>  handles SxS (Side by Side assemblies, a Windows XP feature), VDM 
>  (16-bit emulation) and stuff like Process/Thread creation, winsrv.dll, 
>  which handles some graphical things and windowmessage-related 
>  functionality (such as hardware event dispatching) plus all the 
>  Console code (winsrv is internally split into 2 CSR Servers). I think 
>  a big problem here is that ea believes that CSRSS is the place where 
>  you would add a POSIX subsystem. This isn't the case. CSRSS is 
>  reserved for Win32 CSR Servers. 
Of course, not in the instance where basesrv.dll and winsrv.dll are 
loaded. I think the csrss.exe + csrsrv.dll (the core) were the original 
CSR. Of course the os2ss and psxss MS sold us don't use it. They 
couldn't, because the current CSR core was intentionally "polluted" to 
support only basesrv.dll and winsrv.dll. But it is not our fault.

Also I dont think the Win32 server should run in more than one instance. 
When you look at the process list, in a TS machine, those many csrss.exe 
you see are (but one) μSessions of the Win32 server (the mother is the 
one with lowest PID). Imagine Linus' face if you propose to load a new 
instance of the Linux kernel each time you login... well it is exactly 
what happens when you connect from a TS client (win32k.sys is loaded 
again). I don't know how you define that way of programming: perhaps, in 
a sentence, "Does it compile? Let's sell it!". Well, two.

>  
>  Now, let's move on...what actually loads CSRSS? This is called SMSS, 
>  the Session Manager SubSystem. The Session Manager handles all the 
>  subsystems that are installed on an NT Machine. By default, this means 
>  CSRSS, the Win32 subsystem. If you install SFU 3.5, or are using 
>  Windows Server 2003 R2, you will also get psxss.exe. 
The original PSXSS.EXE was, as you know, a nice trick. MS had to show 
that NT was POSIX 1003.1 compliant, to get DOD contracts. But, of 
course, it should do it fast and could not show "too much". This decency 
shows how they got two prizes with one shot. PSX is not a vertical 
subsystem, but a side subsystem, or a second-level personality. In fact 
it requires the Win32 subsystem running to work. The first prize is that 
you show NT is a POSIX system. The second prize is that you can not drop 
Win32 to run your POSIX system. Market and market, not computer science.

This recalls me that recently MS was sentenced, because it is impossible 
to remove IE from Windows. A recurring trick.

>   On older Windows, you can also have os2ss.exe. These
> are the POSIX and 
>  OS/2 subsystems. 
Once again, let's look back. OS/2 was the original user mode API Cutler 
was sked by MS to make available on top of the NT core. As Windows 3.0 
was a worldwide success and the alliance with IBM broke, they had to 
switch to Win32. As there was a common ancestor, do you think they 
rewrote the CSR from ground up? It is more likely that they freezed the 
CSR used by OS/2 and, after a lazy copy & paste, extended it ("polluted 
it") to build what we today say it should be named w32ss.exe.

>   They have nothing to do with CSR at all, and they are
> actually, in 
>  themselves, CSRSSes for their own subsystems. 
This is by design, an evil design... ;) Would have MS shown how easy is 
writing your own subsystem in a moment when they had to face IBM OS/2 
rival API? My friends, close every gate, every window, every hole and 
harmour the Win32 server!

>   This is the naming mistake I was talking about;
> Microsoft should have 
>  named csrss as w32ss.exe. 
Ockam! ;)

>  
>  So, SMSS is the first process that will load, and it will then load 
>  the subsystems, say csrss psxss and os2ss. These subsystems will then 
>  load server dlls which expose functionality that can be called from 
>  user-mode processes.
>  
SM is a super server. But then, if it is so super, why does it humble 
itself in defining DOS devices, in loading a process of one of its 
controlled children (I refer to WINLOGON.EXE)... If that is not 
"pollution", maybe a nuclear bomb exploded somewhere in the vicinity. :(

>   As I'm writing this, my Win2K3 machine is running
> posix grep and 
>  working perfectly. It's not touchign CSRSS at all, nor should it have 
>  to. CSRSS is a win32 subsystem.
>  
CSRSS.EXE+CSRSRV.DLL, as they load BASESRV.DLL and WINSRV.DLL, *are* the 
Win32 personality subsystem server.

> >  
> >  Think about it like the program run by the Architect in Matrix: when 
> >  you double click on Microsoft Word's icon and the process is created, 
> >  it happily belives to run under Windows, it can see the familiar 
> >  libraries, it can call CreateFile and get back a reasonable file. In 
> >  fact, CreateFile calls NtCreateFile and so on. Microsoft Word lives 
> >  in a fake World. ;)
> >
> >  The two opposite directions the CSR can turn for are:
> >  - be a process totally bound to the Windows personality 
>
>  Which it's -supposed- to be. CSR is W32SS. 
If we clone Windows NT, this is correct. But dumping is illegal.

>  
> >   - be a general purpose process, a facility for
> > any kind of personality 
>
>  Other personalities don't need CSR! They have PSX and OS2 and VMS and 
>  etc... 
The pieces of code MS sold us match this definition. I ask myself: is 
this a technical limitation, or imposed by market staff?

As Gunnar saw, probably there is a common set of facilities you need 
every time you write a personality server. I would like to write it once 
for them all (If I could, but you showed you are much more skilled than 
me!). Casper, as already noted, pointed out it is a complex piece of 
code to write. You are required to write the equivalent of the abstract 
NtCreateProcess, to be called by the Windows personality server and by 
the POSIX personality server and by the OS/2 server and by the...

My question is: is it worth writing such a live run-time code? (DLLs are 
"dead code", because they live un the context of the process that loads 
them; vice versa, a subsystem is a "live DLL", because it lives before 
the process that will use it; if you like biology, there is the same 
difference between a virus and a bacterium).

>  
> >  
> >  More on demand.
> >  
>  Another issue which ea has brought up is that NT is somehow to 
>  "connected" to Win32. 
Well, Alex, I repeatedly used the adjective "polluted", which does not 
mean "connected". I meant they put helper pieces of code, here and 
there, to make the Win32 server's life easier. If you want a more 
technical equivalent of "polluted", read it "less general, less 
abstract". Casper is definitely right!

>   I beg to differ. I've spent a week working on a
> sample native 
>  application. It currently can display running processes, drivers, 
>  create a new process and create/delete/list files. Here are some 
>  screenshots:
>
>  http://members.tripod.com/WinAlOS/rtlcli.png
>  http://members.tripod.com/WinAlOS/rtlcli2.png
>  http://members.tripod.com/WinAlOS/rtlcli3.png
>
>  Note that there is no CSR, no win32k.sys loaded. NT is running in its 
>  rawest form. You need less then 16MB of memory (notice that the 
>  processes are using <1MB, the rest is up to the drivers, which you can 
>  disable) and about the same amount of diskspace. This works perfectly 
>  in Windows 2003 without any need to "separate win32". 
I actually didn't understand if Russinovich was paid by MS to show that, 
or if he actually could get there alone, the real NT hacker! Because, if 
you look at what that really means, you get a strange feeling.

First, the rumors that pollution (Win32/Win64 infiltration) is gone to a 
point where the old NT-designed core is less stable, are immediatley 
silenced. Russinovich, indipendently (and with the naive "Oooh" by some 
MS engineers...), showed it!

Second, in a hidden and really smart way, you promote the equivalence 
CSR=Windows: "Note that there is no CSR, no win32k.sys loaded.". Bill is 
a genius! I love him.

With best regards,

-- 
:Emanuele Aliberti

[Alex Ionescu]

Emanuele Aliberti wrote:

>   Alex Ionescu wrote:
>
> >   I view this as a "misunderstanding with some
> > design choices", if not 
> >  even a "misunderstanding of NT Subsystem design". 
>
>  Subsystem design is subtle. Cutler is not an ordinary person. Also the 
>  subsystem design was conceived in another era, in CS terms. Cutler and 
>  his group designed it when the OS (beginning-to-ruin) myth was CM Mach 
>  (at the same time, RMS invented Hurd; recently Apple could sell it 
>  rebranded as Mac OS X...). 
Mark Lucovsky wrote the subsystem design (smss, csrss), not Cutler, just 
a by the way.

>  
> > >  
> > >  The design choice, in short, is the rôle of the "Client/Server 
> > >  Runtime SubSystem" (CSR=CSRSS.EXE+CSRSRV.DLL) in the design of the 
> > >  "O.S. Personality" code, that is the emulation code that manages 
> > >  processes of the same operating system in user mode, making them 
> > >  belive to run on the emulated O.S. 
> >
> >
> >  The Client/Server Runtime SubSystem, which is unfortunately 
> >  incorrectly named by Microsoft,  
>
>  It is funny to note now that what you say here is a thought that 
>  spinned around in my mind for years in the past. My personal answer 
>  was exactly yours.
>
> >   is actually the Win32 Personality.  
>
>  Later I discovered a theologian and philosopher - W. Ockam 
>  (1295/1300-1349) - that today most of us (don't) know is the father of 
>  the KIS(S) principle. Do not invent an hypothesis if it *not needed*. 
>  I used to say "Those developers at MS are really eccentric! Why did 
>  they call the Win32 subsystem server CSRSS.EXE? They are really dumb!".
>
>  The unnecessary assumption is, of course, that they *incorrectly 
>  named* it. 
(Note for others: The KISS principle is "Keep it simple, stupid" or 
sometimes "Keep it simple and stupid")

If you really want to argue using Ockam's Razor (note for others: 
Ockam's razor basically says that the simplest assumption is usually the 
correct one), then I'm afraid I'm the one winning this argument. My 
assumption is that CSRSS has always been built to service Win32's needs. 
This has much evidence, as you've added and agreed with me, mostly 
importantly:
- The fact that other subsystems have their own *ss.exe
- The fact that CSRSS is specially "polluted" for Win32

Your assumption, as far as I could understand, is that CSR was 
"originally supposed to be somethign else" and was later "polluted". 
Now, what makes more sense and seems the easiest assumption, by using 
Ockam's Razor:
- CSR is what all evidence to it points, a Win32 subsystem runtime 
manager. (Alex)
- CSR is everything but what it currently seems to be. CSR was actually 
designed to be something totally different. It was later polluted and 
became what it is now.(Emanuele)

Ockam would agree with theory #1, and your assumption would become the 
unnecessary one.

>  
> >   It manages Win32 processes in user-mode, and
> > allows them to access 
> >  kernel features which would pollute the native-mode ntdll.dll, would 
> >  they have been included there. Only Win32 processes use csrss and 
> >  registration is done in kernel32. Console windows, another Win32-ism 
> >  also use csrss.  
>
>  This is what we observe today in a live system of the NT family. But, 
>  if you see a man that wears a black suit, are you sure he's a priest? 
>  It could be a MiB, or a punk, or simply an old fashioned gentleman. 
If he also wears a cross, he could be a punk or priest. Ockam's Razor 
would dictate the simplest assumption to be the true one. Therefore, he 
is a priest.

>  
>  For instance, everybody here knows that the dynamic library NTDLL.DLL 
>  exposes the so called "native API", the NT real API. But even you are 
>  diverted by that sweet assonance and commit the mistake of saying it 
>  has the native-mode mark. Indeed its subsystem ID is 3.
>
>  When I discovered it, I had a shock, a few years ago.
>
>  Does it fit in you picture? 
(Note to others: 3 is IMAGE_SUBSYSTEM_WINDOWS_CUI)

I've always found it strange that ntdll.dll has the CUI subsystem, and 
not IMAGE_SUBSYSTEM_NATIVE.

Of course, the most plausible reasons for this are that due to some 
kernel/loader semantics, it's simply easier to use this flag for X, Y 
reasons. Even simpler, perhaps it's just the default used for building 
other DLLs. You can note that basesrv.dll and winsrv.dll also have the 
same flag set, even though they are not CUI DLLs. I'm not going to go in 
some theory that "Oh God, oh God, ntdll has the Win32 Console flag set, 
it must be a hidden console DLL!".

>  
> >   Because NT was designed with a set of universal
> > native APIs, this was 
> >  necessary so that routines useful to only one personality wouldn't be 
> >  exported as native APIs. For example, fork() is a POSIX-only API, not 
> >  Windows 32. Therefore, it was not included in ntdll.dll, even though 
> >  the kernel supports it. Instead, it's used by the POSIX subsystem. 
> >  The same goes for Console windows and their APIs, which are usable 
> >  only in Win32. Access to the video hardware is done in kernel-mode, 
> >  but the functions are called through CSRSS.
> >  
>  A very good example, but a less precise description. NtCreateProcess 
>  is an API that is more abstract than Win32 CreateProcess and than 
>  POSIX fork/exec. As it is more abstract, the respective less general 
>  semantics can be implemented using it. As Casper pointed out, more 
>  general, more abstract, means more complex. 
Which is why the Native API isn't the default API, because programming 
with it would be much more complicated. Win32 is a good thing in that 
regard.

>  
> >   Now, CSRSS is in a way a Client/Server Subsystem,
> > because it's merely 
> >  a 4KB host to CSR Servers, which implement parts of the Win32 
> >  behaviour. The 3 servers currently used are: basesrv.dll, which 
> >  handles SxS (Side by Side assemblies, a Windows XP feature), VDM 
> >  (16-bit emulation) and stuff like Process/Thread creation, 
> >  winsrv.dll, which handles some graphical things and 
> >  windowmessage-related functionality (such as hardware event 
> >  dispatching) plus all the Console code (winsrv is internally split 
> >  into 2 CSR Servers). I think a big problem here is that ea believes 
> >  that CSRSS is the place where you would add a POSIX subsystem. This 
> >  isn't the case. CSRSS is reserved for Win32 CSR Servers. 
>
>  Of course, not in the instance where basesrv.dll and winsrv.dll are 
>  loaded.  
Not in ANY instance!

>   I think the csrss.exe + csrsrv.dll (the core) were the
> original CSR.  
Assumption assumption! csrsrv.dll is merely the real implementation of 
CSRSS, and provides a common API for all the CSR servers (base and 
winsrv). You are *convinced* that CSR+csrsrv.dll were designed to allow 
other subsystems to be implemented as DLLs. No, no, no! It was *never* 
that way. You mention the proof yourself: csrsrv.dll does things like 
setting up the Win32 Base Name Objects directories and other 
win32-specific things!

>   Of course the os2ss and psxss MS sold us don't use
> it. 
I don't think they "sell" them; psxss is free, and os2ss was part of 
Windows. And the reason they don't use it is because they're -not 
supposed to-!

>   They couldn't, because the current CSR core was
> intentionally 
>  "polluted" to support only basesrv.dll and winsrv.dll. But it is not 
>  our fault. 
Another assumption. How about assuming that CSR was intentionally 
CREATED for Win32.

>  
>  Also I dont think the Win32 server should run in more than one instance. 
All subsystems run in more then one instance if multiple Session IDs are 
used. This is by the very own design of "Sessions" in NT. Sessions are 
completely seperate entities. They run their own set of programs, have 
their own desktops, windowstations, windows, etc. Even their -memory- is 
seperated. Memory in one session is usually seperated from memory in 
another session. Even the Paged and Nonpaged Pools are seperated! It 
makes perfect sense that even subsystems are seperated. Plus, this is a 
feature that I personally LOVE. It allows me to debug csrss.exe on a 
-live- system, simply by connecting to another session. Without this 
wonderful design, such abilities would be lost. Also, assume csrss.exe 
crashes in one session. The others sessions are still ok. There are a 
myriad of reasons why having an isolated environment for each session is 
a good thing. It's why windows terminal services are probably one of the 
best features of NT.

>   When you look at the process list, in a TS machine,
> those many 
>  csrss.exe you see are (but one) μSessions of the Win32 server (the 
>  mother is the one with lowest PID). Imagine Linus' face if you propose 
>  to load a new instance of the Linux kernel each time you login... 
I really wouldn't associate csrss.exe with the Linux kernel. If this was 
a high-school debate I could easily attack you personally because you 
just made that comparison ;)

>   well it is exactly what happens when you connect from
> a TS client 
>  (win32k.sys is loaded again).  
Win32k is made to load into every session by DESIGN, and it comes with a 
share of benefits. Did you also know that other drivers can be made 
session-specific as well?

>   I don't know how you define that way of
> programming: perhaps, in a 
>  sentence, "Does it compile? Let's sell it!". Well, two. 
I think you define it as "secure, isolated, scalable design". Which is 
quite different from Linux's monolithic, unscalable design.

>  
> >  
> >  Now, let's move on...what actually loads CSRSS? This is called SMSS, 
> >  the Session Manager SubSystem. The Session Manager handles all the 
> >  subsystems that are installed on an NT Machine. By default, this 
> >  means CSRSS, the Win32 subsystem. If you install SFU 3.5, or are 
> >  using Windows Server 2003 R2, you will also get psxss.exe. 
>
>  The original PSXSS.EXE was, as you know, a nice trick. MS had to show 
>  that NT was POSIX 1003.1 compliant, to get DOD contracts. 
Possibly true, although it sounds like a conspiracy theory. I'm sure a 
big part of POSIX compliance was also compatibility, and also to prove 
that NT is a solid design. Remember that NT was originally built for 
non-x86 CPUs only because Cutler thought it was the best way to catch 
bugs and make a solid OS. Subsystems were a design choice in NT for a 
long time.

>   But, of course, it should do it fast and could not
> show "too much". 
>  This decency shows how they got two prizes with one shot. PSX is not a 
>  vertical subsystem, but a side subsystem, or a second-level 
>  personality. In fact it requires the Win32 subsystem running to work.  
Ah, finally we get to a point where I'll agree you with you on 
pollution! Yes, POSIX only works with Win32 loaded. But can we easily 
work around this later on, when we have a POSIX subystem? Sure! Does it 
have anything to do with CSR? NO!

>   The first prize is that you show NT is a POSIX system.
> The second 
>  prize is that you can not drop Win32 to run your POSIX system. Market 
>  and market, not computer science. 
Yes, Microsoft was probably afraid of allowing NT to run in POSIX-only 
mode, but we can pull it off much later once that's needed.

>  
>  This recalls me that recently MS was sentenced, because it is 
>  impossible to remove IE from Windows. A recurring trick. 
Well, when NT was first publically shipped its job was to run Win32 
applications. Allowing Win32 to be removed might've caused many 
technical/support headaches apart from the marketing stuff. I wouldn't 
jump to conspiracy theories right away. The design of NT is much 
different from the shell/ie.

>  
> >   On older Windows, you can also have os2ss.exe.
> > These are the POSIX 
> >  and OS/2 subsystems. 
>
>  Once again, let's look back. OS/2 was the original user mode API 
>  Cutler was sked by MS to make available on top of the NT core. As 
>  Windows 3.0 was a worldwide success and the alliance with IBM broke, 
>  they had to switch to Win32. As there was a common ancestor, do you 
>  think they rewrote the CSR from ground up? It is more likely that they 
>  freezed the CSR used by OS/2 and, after a lazy copy & paste, extended 
>  it ("polluted it") to build what we today say it should be named 
>  w32ss.exe. 
I think I see what you mean, yes, CSR back in those days was probably 
the OS/2 subsystem. How is that better though? It still wasn't a GENERIC 
subsystem loader (SMSS is that). They merely took out the OS/2 
"pollution" and added win32 "pollution". Then they added the OS/2 
"pollution" back into what became os2ss.exe. In that sense, CSR was 
always "polluted" by whatever the subsystem it was holding was supposed 
to be. Now it's a win32 subsystem, and has been that way for 15 years.

>  
> >   They have nothing to do with CSR at all, and they
> > are actually, in 
> >  themselves, CSRSSes for their own subsystems. 
>
>  This is by design, an evil design... ;) Would have MS shown how easy 
>  is writing your own subsystem in a moment when they had to face IBM 
>  OS/2 rival API? My friends, close every gate, every window, every hole 
>  and harmour the Win32 server! 
Slippery slope fallacy/conspiracy theory. It was simply the design that 
every subsystem woudl have its own "CSR EXE" followed by server DLLs.

>  
> >   This is the naming mistake I was talking about;
> > Microsoft should have 
> >  named csrss as w32ss.exe. 
>
>  Ockam! ;) 
Not really, if viewed from the historical perspective, it makes sense 
why it was never renamed as such. Assuming that CSR was something else 
then the original OS/2 subsystem for a very short while is much more flawed.

>  
> >  
> >  So, SMSS is the first process that will load, and it will then load 
> >  the subsystems, say csrss psxss and os2ss. These subsystems will then 
> >  load server dlls which expose functionality that can be called from 
> >  user-mode processes.
> >  
>  SM is a super server. But then, if it is so super, why does it humble 
>  itself in defining DOS devices 
This was moved to CSRSS.

>   , in loading a process of one of its controlled
> children (I refer to 
>  WINLOGON.EXE)... If that is not "pollution", maybe a nuclear bomb 
>  exploded somewhere in the vicinity. :( 
And this is the second point I agree with you, the second design mistake 
of NT. Smss's "initial command" is to run winlogon, and that really 
creates a problem where win32 becomes -required-. However, instead of 
thinking this was some marketing ploy, I think that NT was getting close 
to shipping, and doing it this way was a much easier solution for the 
prime goal: Win32. So yes, it's a bad design decision:

BTW: It has a "bug", in that if you define an "inital debugger", the 
initial command will be replaced by "initial debugger.exe winlogon", so 
that winlogon can be launched with a debugger. Stick your 
native/posix/whatever program as the initial debugger, and ignore the 
winlogon command line, and you've beaten the flaw ;) The string is 
configurable in the registry, IIRC. Once again, this is something we can 
do better in ReactOS after the windows stuff works normally.

>  
> >   As I'm writing this, my Win2K3 machine is
> > running posix grep and 
> >  working perfectly. It's not touchign CSRSS at all, nor should it have 
> >  to. CSRSS is a win32 subsystem.
> >  
>  CSRSS.EXE+CSRSRV.DLL, as they load BASESRV.DLL and WINSRV.DLL, *are* 
>  the Win32 personality subsystem server. 
That's what I meant.

>  
> > >  
> > >  Think about it like the program run by the Architect in Matrix: when 
> > >  you double click on Microsoft Word's icon and the process is 
> > >  created, it happily belives to run under Windows, it can see the 
> > >  familiar libraries, it can call CreateFile and get back a reasonable 
> > >  file. In fact, CreateFile calls NtCreateFile and so on. Microsoft 
> > >  Word lives in a fake World. ;)
> > >
> > >  The two opposite directions the CSR can turn for are:
> > >  - be a process totally bound to the Windows personality 
> >
> >
> >  Which it's -supposed- to be. CSR is W32SS. 
>
>  If we clone Windows NT, this is correct.  
ReactOS is a Windows NT clone.

>   But dumping is illegal.
>
> >  
> > >   - be a general purpose process, a facility for
> > > any kind of personality 
> >
> >
> >  Other personalities don't need CSR! They have PSX and OS2 and VMS and 
> >  etc... 
>
>  The pieces of code MS sold us match this definition. I ask myself: is 
>  this a technical limitation, or imposed by market staff? 
How about a design choice? One which makes a lot of sense to me.

>  
>  As Gunnar saw, probably there is a common set of facilities you need 
>  every time you write a personality server. I would like to write it 
>  once for them all (If I could, but you showed you are much more 
>  skilled than me!).  
The common set of facilities are exposed by SMSS callbacks and a smlib! 
I've written about that in a previous email.

>   Casper, as already noted, pointed out it is a complex
> piece of code to 
>  write. You are required to write the equivalent of the abstract 
>  NtCreateProcess, to be called by the Windows personality server and by 
>  the POSIX personality server and by the OS/2 server and by the... 
One of these abstract callbacks is SbCreateProcess. I plan to implement 
the Sb callbacks and SMSS later this year. (Nice bit of trivia: 
SbApiPort and SmApiPort are quite different! One relates to SMSS (Sm) 
itself, the other handles the common subsystem (Sb) functionality which 
you seem to want).

>  
>  My question is: is it worth writing such a live run-time code? (DLLs 
>  are "dead code", because they live un the context of the process that 
>  loads them; vice versa, a subsystem is a "live DLL", because it lives 
>  before the process that will use it; if you like biology, there is the 
>  same difference between a virus and a bacterium).
>
> >  
> > >  
> > >  More on demand.
> > >  
> >  Another issue which ea has brought up is that NT is somehow to 
> >  "connected" to Win32. 
>
>  Well, Alex, I repeatedly used the adjective "polluted", which does not 
>  mean "connected". I meant they put helper pieces of code, here and 
>  there, to make the Win32 server's life easier. If you want a more 
>  technical equivalent of "polluted", read it "less general, less 
>  abstract". Casper is definitely right! 
Polluted, connected, I still disagree. There is almost nothing in NT 
which makes Win32's life easier, apart from some win32k.sys stuff. Yes, 
there are certaintly some things which help out win32, but that's 
because NT is PRIMARLY DESIGNED to be a Win32 OS. By definition, so must 
ReactOS, at least until 1.0 when our goal, to clone Windows NT, is 
reached. After that, we are free to explore other areas, if 
compatibility can remain intact.

>  
> >   I beg to differ. I've spent a week working on
> > a sample native 
> >  application. It currently can display running processes, drivers, 
> >  create a new process and create/delete/list files. Here are some 
> >  screenshots:
> >
> >  http://members.tripod.com/WinAlOS/rtlcli.png
> >  http://members.tripod.com/WinAlOS/rtlcli2.png
> >  http://members.tripod.com/WinAlOS/rtlcli3.png
> >
> >  Note that there is no CSR, no win32k.sys loaded. NT is running in its 
> >  rawest form. You need less then 16MB of memory (notice that the 
> >  processes are using <1MB, the rest is up to the drivers, which you 
> >  can disable) and about the same amount of diskspace. This works 
> >  perfectly in Windows 2003 without any need to "separate win32". 
>
>  I actually didn't understand if Russinovich was paid by MS to show that,  
I feel a bit insulted. What does Russniovich have to do with anything? 
The screenshots above show a program which I alone have worked on, and 
that no other "NT hacker" has attempted in doing before.

>   or if he actually could get there alone, the real NT
> hacker! Because, 
>  if you look at what that really means, you get a strange feeling. 
I have no idea what you're talking about. There are many more 
knowledgable people in NT then Mark. They just don't get the media/MS 
attention he does. If he's the "real" NT hacker then what are Skwing, 
Filip, KJK::Hyperion, yourself and I?

>  
>  First, the rumors that pollution (Win32/Win64 infiltration) is gone to 
>  a point where the old NT-designed core is less stable, are immediatley 
>  silenced. Russinovich, indipendently (and with the naive "Oooh" by 
>  some MS engineers...), showed it! 
Actually, I think I just did by writing that program. I once again don't 
see what the -hell- Russinovich has to do with me. And no, MS didn't pay 
me to write that program.

>  
>  Second, in a hidden and really smart way, you promote the equivalence 
>  CSR=Windows: "Note that there is no CSR, no win32k.sys loaded.".  
Yeah, CSR+Win32k.sys == Windows.

>   Bill is a genius! I love him. 
Bill is an idiot, but a very good businessman. Cutler and Mark are 
geniuses, and if it wasn't for, especially, Cutler's angry attitude and 
specific design goals for NT, win32 would probably be in ntoskrnl.exe

>  
>  With best regards,
>  
Best regards,
Alex Ionescu

[Phillip Susi]

Alex Ionescu wrote:

>  
>  (Note for others: The KISS principle is "Keep it simple, stupid" or 
>  sometimes "Keep it simple and stupid")
>
>  If you really want to argue using Ockam's Razor (note for others: 
>  Ockam's razor basically says that the simplest assumption is usually 
>  the correct one), then I'm afraid I'm the one winning this argument. 
>  My assumption is that CSRSS has always been built to service Win32's 
>  needs. This has much evidence, as you've added and agreed with me, 
>  mostly importantly:
>  - The fact that other subsystems have their own *ss.exe
>  - The fact that CSRSS is specially "polluted" for Win32
>
>  Your assumption, as far as I could understand, is that CSR was 
>  "originally supposed to be somethign else" and was later "polluted".
>
>  Now, what makes more sense and seems the easiest assumption, by using 
>  Ockam's Razor:
>  - CSR is what all evidence to it points, a Win32 subsystem runtime 
>  manager. (Alex)
>  - CSR is everything but what it currently seems to be. CSR was 
>  actually designed to be something totally different. It was later 
>  polluted and became what it is now.(Emanuele)
>
>  Ockam would agree with theory #1, and your assumption would become the 
>  unnecessary one.
>  
I don't see why it matters whether csrss was originally intended to be 
more generic, or win32 specific.  You can argue about that until the 
cows come home, without much purpose.  If the real quesion is should 
ReactOS's csrss be generic or win32 specific, then I think the obvious 
answer is that it should probably be just like windows is, unless there 
is a good technical reason, not a philisophical one, to deviate.  It 
seems that MS implemented the posix and os2 subsystems as seperate 
processes, so what would we gain by not doing as they did?

>   (Note to others: 3 is IMAGE_SUBSYSTEM_WINDOWS_CUI)
>
>  I've always found it strange that ntdll.dll has the CUI subsystem, and 
>  not IMAGE_SUBSYSTEM_NATIVE.
>
>  Of course, the most plausible reasons for this are that due to some 
>  kernel/loader semantics, it's simply easier to use this flag for X, Y 
>  reasons. Even simpler, perhaps it's just the default used for building 
>  other DLLs. You can note that basesrv.dll and winsrv.dll also have the 
>  same flag set, even though they are not CUI DLLs. I'm not going to go 
>  in some theory that "Oh God, oh God, ntdll has the Win32 Console flag 
>  set, it must be a hidden console DLL!".
>  
Funny you should mention that.  As far as I know, the subsystem 
identifier means nothing to dlls.  The only thing I know of that it has 
any impact on is that win32's CreateProcess() will only load executables 
marked as either win32 gui or cui.  Because it doesn't seem to have any 
actual impact, I don't see why one should spend much time worrying about 
it. 

>  
>  All subsystems run in more then one instance if multiple Session IDs 
>  are used. This is by the very own design of "Sessions" in NT. Sessions 
>  are completely seperate entities. They run their own set of programs, 
>  have their own desktops, windowstations, windows, etc. Even their 
>  -memory- is seperated. Memory in one session is usually seperated from 
>  memory in another session. Even the Paged and Nonpaged Pools are 
>  seperated! It makes perfect sense that even subsystems are seperated. 
>  Plus, this is a feature that I personally LOVE. It allows me to debug 
>  csrss.exe on a -live- system, simply by connecting to another session. 
>  Without this wonderful design, such abilities would be lost. Also, 
>  assume csrss.exe crashes in one session. The others sessions are still 
>  ok. There are a myriad of reasons why having an isolated environment 
>  for each session is a good thing. It's why windows terminal services 
>  are probably one of the best features of NT.
>  
IMHO, the session support they added to win2k is an abomination.  I 
remember when I first read about winstations in NT 3.51 and figured that 
must be there so they can support multiple heads and remote login 
sessions.  The winstation encapsulates a display device and input 
device(s) so it seems perfectly logical to create a windowstation for 
each physical or virtual set of human I/O devices in the system.  
Kludging the kernel to be able to load multiple instances of win32k.sys 
made my skin crawl the first time I read they were going to do that in 
win2k.  I still don't know why they would do such a thing. 

I've allways had the opinion that ReactOS should do it the right way, 
and make use of the winstation support rather than load win32k.sys 
multiple times.  Running multiple instances of csrss seems fine, it's a 
user mode process after all, but win32k.sys should not be. 

>  
>  Win32k is made to load into every session by DESIGN, and it comes with 
>  a share of benefits. Did you also know that other drivers can be made 
>  session-specific as well?
>  
And again, I think that is a horrible design, and that it provides no 
benefits.  The kernel runs the entire system.  It exists in every 
process, and in no process.  That is how things should be, and 'session 
space' seems a horrible kludge created because someone figured it would 
be easier to load win32k.sys multiple times than to fix any bugs in it 
that prevented it from properly connecting to multiple I/O devices and 
routing them to the correct windowstation. 

>   I think you define it as "secure, isolated,
> scalable design". Which is 
>  quite different from Linux's monolithic, unscalable design. 

Ok now really, this is falling off into religion.  Linux is just as 
modular/monolithic as NT.  NT is not MACH as much as it was originally 
hailed to be.  And with good reason. 

> >  
> >  The original PSXSS.EXE was, as you know, a nice trick. MS had to show 
> >  that NT was POSIX 1003.1 compliant, to get DOD contracts. 
>
>  Possibly true, although it sounds like a conspiracy theory. I'm sure a 
>  big part of POSIX compliance was also compatibility, and also to prove 
>  that NT is a solid design. Remember that NT was originally built for 
>  non-x86 CPUs only because Cutler thought it was the best way to catch 
>  bugs and make a solid OS. Subsystems were a design choice in NT for a 
>  long time.
>  
Yes, NT was originally designed with subsystems in mind.  It seems 
likely that this was either because Cutler thought it to be a better 
design, or MS didn't know whether they were going to make NT use an OS/2 
interface, or something else, or probably both of these.  Either way, MS 
has never really supported the posix subsystem, so it seems that they 
only created it for compliance with the DOD ( which they did require ). 

>  
>  Ah, finally we get to a point where I'll agree you with you on 
>  pollution! Yes, POSIX only works with Win32 loaded. But can we easily 
>  work around this later on, when we have a POSIX subystem? Sure! Does 
>  it have anything to do with CSR? NO! 

I agree.  The reason microsoft's posix subsystem requires win32 is 
because the posix subsystem needed a means of conducting I/O with the 
user, and the win32 subsystem already provided that, so they didn't have 
to invent such a means for the posix subsystem, and both subsystems 
could not control the I/O devices at once, and win32 was decided the 
"main" subsystem.  The same arguments apply to ReactOS.  If you really 
wanted to be able to run without win32, then you could extend the posix 
subsystem to use its own code to manipulate the display and read the 
input devices, but the first goal should be to get it to run with win32 
doing those things, and seperate it later if you really, really want 
to.  Our target base however, expects ReactOS to run win32 apps, and 
those who want to run posix apps will most likely be quite happy to be 
able to run them allongside win32 apps.  This requires that the posix 
subsystem communicate with the win32 subsystem, not be completely 
isolated. 

>  
>  Well, when NT was first publically shipped its job was to run Win32 
>  applications. Allowing Win32 to be removed might've caused many 
>  technical/support headaches apart from the marketing stuff. I wouldn't 
>  jump to conspiracy theories right away. The design of NT is much 
>  different from the shell/ie. 

Not to mention that they did not disallow disabling the win32 subsystem, 
they just saw no reason to fully develop the posix subsystem to be 
capable of living without win32. 

>  
>  Polluted, connected, I still disagree. There is almost nothing in NT 
>  which makes Win32's life easier, apart from some win32k.sys stuff. 
>  Yes, there are certaintly some things which help out win32, but that's 
>  because NT is PRIMARLY DESIGNED to be a Win32 OS. By definition, so 
>  must ReactOS, at least until 1.0 when our goal, to clone Windows NT, 
>  is reached. After that, we are free to explore other areas, if 
>  compatibility can remain intact.
>  
Agreed.

[Alex Ionescu]

Phillip Susi wrote:

>   Alex Ionescu wrote:
>
> >  
> >  (Note for others: The KISS principle is "Keep it simple, stupid" or 
> >  sometimes "Keep it simple and stupid")
> >
> >  If you really want to argue using Ockam's Razor (note for others: 
> >  Ockam's razor basically says that the simplest assumption is usually 
> >  the correct one), then I'm afraid I'm the one winning this argument. 
> >  My assumption is that CSRSS has always been built to service Win32's 
> >  needs. This has much evidence, as you've added and agreed with me, 
> >  mostly importantly:
> >  - The fact that other subsystems have their own *ss.exe
> >  - The fact that CSRSS is specially "polluted" for Win32
> >
> >  Your assumption, as far as I could understand, is that CSR was 
> >  "originally supposed to be somethign else" and was later "polluted".
> >
> >  Now, what makes more sense and seems the easiest assumption, by using 
> >  Ockam's Razor:
> >  - CSR is what all evidence to it points, a Win32 subsystem runtime 
> >  manager. (Alex)
> >  - CSR is everything but what it currently seems to be. CSR was 
> >  actually designed to be something totally different. It was later 
> >  polluted and became what it is now.(Emanuele)
> >
> >  Ockam would agree with theory #1, and your assumption would become 
> >  the unnecessary one.
> >  
>  I don't see why it matters whether csrss was originally intended to be 
>  more generic, or win32 specific.  You can argue about that until the 
>  cows come home, without much purpose.  If the real quesion is should 
>  ReactOS's csrss be generic or win32 specific, then I think the obvious 
>  answer is that it should probably be just like windows is, unless 
>  there is a good technical reason, not a philisophical one, to 
>  deviate.  It seems that MS implemented the posix and os2 subsystems as 
>  seperate processes, so what would we gain by not doing as they did? 
Nothing. Deviating from NT design is a bad thing.

>  
> >   (Note to others: 3 is
> > IMAGE_SUBSYSTEM_WINDOWS_CUI)
> >
> >  I've always found it strange that ntdll.dll has the CUI subsystem, 
> >  and not IMAGE_SUBSYSTEM_NATIVE.
> >
> >  Of course, the most plausible reasons for this are that due to some 
> >  kernel/loader semantics, it's simply easier to use this flag for X, Y 
> >  reasons. Even simpler, perhaps it's just the default used for 
> >  building other DLLs. You can note that basesrv.dll and winsrv.dll 
> >  also have the same flag set, even though they are not CUI DLLs. I'm 
> >  not going to go in some theory that "Oh God, oh God, ntdll has the 
> >  Win32 Console flag set, it must be a hidden console DLL!".
> >  
>  Funny you should mention that.  As far as I know, the subsystem 
>  identifier means nothing to dlls.  The only thing I know of that it 
>  has any impact on is that win32's CreateProcess() will only load 
>  executables marked as either win32 gui or cui.  Because it doesn't 
>  seem to have any actual impact, I don't see why one should spend much 
>  time worrying about it. 
That was my point. Since Win32 exes need to load ntdll, that's why it's 
marked as such.

> >  
> >  All subsystems run in more then one instance if multiple Session IDs 
> >  are used. This is by the very own design of "Sessions" in NT. 
> >  Sessions are completely seperate entities. They run their own set of 
> >  programs, have their own desktops, windowstations, windows, etc. Even 
> >  their -memory- is seperated. Memory in one session is usually 
> >  seperated from memory in another session. Even the Paged and Nonpaged 
> >  Pools are seperated! It makes perfect sense that even subsystems are 
> >  seperated. Plus, this is a feature that I personally LOVE. It allows 
> >  me to debug csrss.exe on a -live- system, simply by connecting to 
> >  another session. Without this wonderful design, such abilities would 
> >  be lost. Also, assume csrss.exe crashes in one session. The others 
> >  sessions are still ok. There are a myriad of reasons why having an 
> >  isolated environment for each session is a good thing. It's why 
> >  windows terminal services are probably one of the best features of NT.
> >  
>  IMHO, the session support they added to win2k is an abomination.  I 
>  remember when I first read about winstations in NT 3.51 and figured 
>  that must be there so they can support multiple heads and remote login 
>  sessions.  The winstation encapsulates a display device and input 
>  device(s) so it seems perfectly logical to create a windowstation for 
>  each physical or virtual set of human I/O devices in the system.  
>  Kludging the kernel to be able to load multiple instances of 
>  win32k.sys made my skin crawl the first time I read they were going to 
>  do that in win2k.  I still don't know why they would do such a thing.
>  I've allways had the opinion that ReactOS should do it the right way, 
>  and make use of the winstation support rather than load win32k.sys 
>  multiple times.  Running multiple instances of csrss seems fine, it's 
>  a user mode process after all, but win32k.sys should not be. 
Note that not all of win32k is actually loaded again. Some parts of it 
are only visible in certain sessions and isolated from each others. I 
don't see why it's a bad thing.

> >  
> >  Win32k is made to load into every session by DESIGN, and it comes 
> >  with a share of benefits. Did you also know that other drivers can be 
> >  made session-specific as well?
> >  
>  And again, I think that is a horrible design, and that it provides no 
>  benefits.  The kernel runs the entire system.  It exists in every 
>  process, and in no process.  That is how things should be, and 
>  'session space' seems a horrible kludge created because someone 
>  figured it would be easier to load win32k.sys multiple times than to 
>  fix any bugs in it that prevented it from properly connecting to 
>  multiple I/O devices and routing them to the correct windowstation. 
That might be true, but I still like the isolation it provides. But by 
the way, the kernel changes that were needed for session spaces and 
loading win32k multiple times are extremly complex and "fixing win32k" 
would've probably been much easier, so I doubt this was the reason.

> >   I think you
> > define it as "secure, isolated, scalable design". Which 
> >  is quite different from Linux's monolithic, unscalable design. 
>
>
>  Ok now really, this is falling off into religion.  Linux is just as 
>  modular/monolithic as NT.   
Ah c'mon, I hope you don't mean that. That's the typical mistake people 
make when a monolithic kernel can load modules. That doesn't make Linux 
modular.

>   NT is not MACH as much as it was originally hailed to
> be.  And with 
>  good reason.
>
> > >  
> > >  The original PSXSS.EXE was, as you know, a nice trick. MS had to 
> > >  show that NT was POSIX 1003.1 compliant, to get DOD contracts. 
> >
> >
> >  Possibly true, although it sounds like a conspiracy theory. I'm sure 
> >  a big part of POSIX compliance was also compatibility, and also to 
> >  prove that NT is a solid design. Remember that NT was originally 
> >  built for non-x86 CPUs only because Cutler thought it was the best 
> >  way to catch bugs and make a solid OS. Subsystems were a design 
> >  choice in NT for a long time.
> >  
>  Yes, NT was originally designed with subsystems in mind.  It seems 
>  likely that this was either because Cutler thought it to be a better 
>  design, or MS didn't know whether they were going to make NT use an 
>  OS/2 interface, or something else, or probably both of these.  Either 
>  way, MS has never really supported the posix subsystem, so it seems 
>  that they only created it for compliance with the DOD ( which they did 
>  require ). 
Considering they've been actively improving it, and now in R2 we've been 
working to make it even more powerful and compatible, and that in Vista 
it will be part of the OS, I think it's a bit more then just DOD 
compliance at this point.

> >  
> >  Ah, finally we get to a point where I'll agree you with you on 
> >  pollution! Yes, POSIX only works with Win32 loaded. But can we easily 
> >  work around this later on, when we have a POSIX subystem? Sure! Does 
> >  it have anything to do with CSR? NO! 
>
>
>  I agree.  The reason microsoft's posix subsystem requires win32 is 
>  because the posix subsystem needed a means of conducting I/O with the 
>  user, and the win32 subsystem already provided that, so they didn't 
>  have to invent such a means for the posix subsystem, and both 
>  subsystems could not control the I/O devices at once, and win32 was 
>  decided the "main" subsystem.  The same arguments apply to ReactOS.  
>  If you really wanted to be able to run without win32, then you could 
>  extend the posix subsystem to use its own code to manipulate the 
>  display and read the input devices, but the first goal should be to 
>  get it to run with win32 doing those things, and seperate it later if 
>  you really, really want to.  Our target base however, expects ReactOS 
>  to run win32 apps, and those who want to run posix apps will most 
>  likely be quite happy to be able to run them allongside win32 apps.  
>  This requires that the posix subsystem communicate with the win32 
>  subsystem, not be completely isolated. 
I totally agree. The main thing to realize, as you've said, is that 
ReactOS is an -NT clone-. Steven and I and others are preparing a talk 
to be delivered to universities which want to give an OS course based on 
Windows, so that ReactOS's code base can be used as an example and 
learning base for the actual NT kernel. If we do everything differently, 
and I'm not talking about small internal algorithms, this is a big 
design decision, then such possibilites will vanish.

> >  
> >  Well, when NT was first publically shipped its job was to run Win32 
> >  applications. Allowing Win32 to be removed might've caused many 
> >  technical/support headaches apart from the marketing stuff. I 
> >  wouldn't jump to conspiracy theories right away. The design of NT is 
> >  much different from the shell/ie. 
>
>
>  Not to mention that they did not disallow disabling the win32 
>  subsystem, they just saw no reason to fully develop the posix 
>  subsystem to be capable of living without win32.
>
> >  
> >  Polluted, connected, I still disagree. There is almost nothing in NT 
> >  which makes Win32's life easier, apart from some win32k.sys stuff. 
> >  Yes, there are certaintly some things which help out win32, but 
> >  that's because NT is PRIMARLY DESIGNED to be a Win32 OS. By 
> >  definition, so must ReactOS, at least until 1.0 when our goal, to 
> >  clone Windows NT, is reached. After that, we are free to explore 
> >  other areas, if compatibility can remain intact.
> >  
>  Agreed.
>  _______________________________________________  
Best regards,
Alex Ionescu

[Thomas Weidenmueller]

Alex Ionescu wrote:
>   Considering they've been actively improving it,
> and now in R2 we've been
>  working to make it even more powerful and compatible, and that in Vista
>  it will be part of the OS, I think it's a bit more then just DOD
>  compliance at this point. 
you've been working on it? it always sounds like if you were part of
their team :P just kidding...

- Thomas

[Emanuele Aliberti]

Alex Ionescu wrote:

>   I totally agree. The main thing to realize, as
> you've said, is that 
>  ReactOS is an -NT clone-. Steven and I and others are preparing a talk 
>  to be delivered to universities which want to give an OS course based 
>  on Windows, so that ReactOS's code base can be used as an example and 
>  learning base for the actual NT kernel. If we do everything 
>  differently, and I'm not talking about small internal algorithms, this 
>  is a big design decision, then such possibilites will vanish. 
This is a good reason for cloning NT.

-- 
:Emanuele Aliberti

[Phillip Susi]

Alex Ionescu wrote:
>   
>  
>  That was my point. Since Win32 exes need to load ntdll, that's why it's 
>  marked as such.
>   
What I was trying to say is that ntdll could easily be marked for the 
native subsystem and it would change nothing.  AFAIK, LoadLibrary() does 
not check the subsystem tag, so win32 apps could still load ntdll just 
fine.  It is only CreateProcess() that checks the subsystem type, so 
that it can correctly launch executables marked for OS2 or POSIX.

>   
>  
>  Note that not all of win32k is actually loaded again. Some parts of it 
>  are only visible in certain sessions and isolated from each others. I 
>  don't see why it's a bad thing.
>   
AFAIK, it IS simply loaded again.  Obviously the read only sections like 
.text will share physical pages in the same way that user mode code is 
shared between processes at the physical page level.  I'm sure that some 
parts of the .data segment don't really need to be session specific, so 
it is a waste to duplicate that data.  As for isolation, what good does 
it do to give each their own complete .data segment?  It isn't like if 
one session crashes, it won't bring down the others.  It is still kernel 
mode code afterall, and as such, it should not be perverted to behave 
more like user mode modules.


>   That might be true, but I still like the isolation it
> provides. But by 
>  the way, the kernel changes that were needed for session spaces and 
>  loading win32k multiple times are extremly complex and "fixing win32k" 
>  would've probably been much easier, so I doubt this was the reason. 
I would think so too, but the fact remains that win32k already appeared 
to have window stations in place specifically for the purpose of 
supporting multiple consoles ( be they physical or virtual ), so I can 
see no good reason to go through the trouble of hacking up the kernel to 
be able to load a driver multiple times.  Unless you know of a good 
reason, then ReactOS should not make that same mistake.

One good technical reason NOT to use session space is that the pages 
therein can't be marked with the global page bit, so they must be 
flushed from the TLB on every context switch.  Then the page tables 
themselves take up more memory, though a relatively small amount.

>   Ah c'mon, I hope you don't mean that.
> That's the typical mistake people 
>  make when a monolithic kernel can load modules. That doesn't make Linux 
>  modular.
>   
Then what does?  The definition of modular means the system is broken up 
into multiple pieces which can be mixed and matched as desired.  Both 
systems meet that definition.  Unless you are using a definition like 
microkernel purists use, whereby only the most basic primatives should 
be in the kernel and everything else, including device drivers, should 
be user space.  Of course, such purists consider both to be monolithic.

>   
>  Considering they've been actively improving it, and now in R2 we've been 
>  working to make it even more powerful and compatible, and that in Vista 
>  it will be part of the OS, I think it's a bit more then just DOD 
>  compliance at this point.
>   
They have been actively improving it?  I have not seen any improvement 
ever.  I remember back in NT 3.50 out of the box, NT only was posix.1 
compliant to meet the DOD requirements.  If you wanted to run any kind 
of real posix code, you needed to buy some third party software, whose 
name now escapes me.  I am not aware of any improvements to the posix 
subsystem since then.

If you are refering to Services For Unix, that isn't a posix subsystem, 
it's just a bunch of utilities to network with unix systems, like an NFS 
client/server and a telnet server.  It seems they have been working on 
that lately, but not a posix subsystem.

[Alex Ionescu]

Phillip Susi wrote:

>   Alex Ionescu wrote:
>
> >  
> >
> >  That was my point. Since Win32 exes need to load ntdll, that's why 
> >  it's marked as such.
> >  
>  What I was trying to say is that ntdll could easily be marked for the 
>  native subsystem and it would change nothing.  AFAIK, LoadLibrary() 
>  does not check the subsystem tag, so win32 apps could still load ntdll 
>  just fine.  It is only CreateProcess() that checks the subsystem type, 
>  so that it can correctly launch executables marked for OS2 or POSIX. 

>  
> >  
> >
> >  Note that not all of win32k is actually loaded again. Some parts of 
> >  it are only visible in certain sessions and isolated from each 
> >  others. I don't see why it's a bad thing.
> >  
>  AFAIK, it IS simply loaded again.  Obviously the read only sections 
>  like .text will share physical pages in the same way that user mode 
>  code is shared between processes at the physical page level.  I'm sure 
>  that some parts of the .data segment don't really need to be session 
>  specific, so it is a waste to duplicate that data.   
Not all parts are.

>   As for isolation, what good does it do to give each
> their own complete 
>  .data segment?  It isn't like if one session crashes, it won't bring 
>  down the others.  It is still kernel mode code afterall, and as such, 
>  it should not be perverted to behave more like user mode modules. 

>  
>
> >   That might be true, but I still like the
> > isolation it provides. But 
> >  by the way, the kernel changes that were needed for session spaces 
> >  and loading win32k multiple times are extremly complex and "fixing 
> >  win32k" would've probably been much easier, so I doubt this was the 
> >  reason. 
>
>  I would think so too, but the fact remains that win32k already 
>  appeared to have window stations in place specifically for the purpose 
>  of supporting multiple consoles ( be they physical or virtual ), so I 
>  can see no good reason to go through the trouble of hacking up the 
>  kernel to be able to load a driver multiple times.  Unless you know of 
>  a good reason, then ReactOS should not make that same mistake. 
Multiple-driver capability could be considered a feature and used for 
other purposes later. While making win32k load multiple times might be a 
"mistake", having the ability to do would, in my opinion, result in a 
much better driver (just like it did for MS:, win32k became a lot more 
portable, unloadable, etc).

>  
>  One good technical reason NOT to use session space is that the pages 
>  therein can't be marked with the global page bit, so they must be 
>  flushed from the TLB on every context switch.  Then the page tables 
>  themselves take up more memory, though a relatively small amount.
>
> >   Ah c'mon, I hope you don't mean that.
> > That's the typical mistake 
> >  people make when a monolithic kernel can load modules. That doesn't 
> >  make Linux modular.
> >  
>  Then what does?  The definition of modular means the system is broken 
>  up into multiple pieces which can be mixed and matched as desired.  
>  Both systems meet that definition.  Unless you are using a definition 
>  like microkernel purists use, whereby only the most basic primatives 
>  should be in the kernel and everything else, including device drivers, 
>  should be user space.  Of course, such purists consider both to be 
>  monolithic. 
Modular doesn't mean microkernel. Linux is not a microkernel, it's a 
monolothic kernel. Nor is NT, which is why it's called a Hybrid 
Microkernel, which is still a subclass of microkernels.

>  
> >  
> >  Considering they've been actively improving it, and now in R2 we've 
> >  been working to make it even more powerful and compatible, and that 
> >  in Vista it will be part of the OS, I think it's a bit more then just 
> >  DOD compliance at this point.
> >  
>  They have been actively improving it?  I have not seen any improvement 
>  ever.  I remember back in NT 3.50 out of the box, NT only was posix.1 
>  compliant to meet the DOD requirements.  If you wanted to run any kind 
>  of real posix code, you needed to buy some third party software, whose 
>  name now escapes me.  I am not aware of any improvements to the posix 
>  subsystem since then.
>
>  If you are refering to Services For Unix, that isn't a posix 
>  subsystem, it's just a bunch of utilities to network with unix 
>  systems, like an NFS client/server and a telnet server.  It seems they 
>  have been working on that lately, but not a posix subsystem. 
Erm, the posix subsystem has been removed since Windows 2000. Had SFU 
not been including one all along, then all those utlities would've never 
worked...so yes, SFU -does- include psxss. That part is called SUA 
(Subsystem for Unix Applications). One of the big improvemnts is that it 
now supports 64-bit.

Best regards,
Alex Ionescu

[Phillip Susi]

I was under the impression that the SFU programs were all win32 
subsystem, they just provided network access to unix services, and 
therefore, there was no posix subsystem.

Are you saying that SFU ships PE images tagged for the posix subsystem 
instead of win32 cui?

Alex Ionescu wrote:
>   
>  Erm, the posix subsystem has been removed since Windows 2000. Had SFU 
>  not been including one all along, then all those utlities would've never 
>  worked...so yes, SFU -does- include psxss. That part is called SUA 
>  (Subsystem for Unix Applications). One of the big improvemnts is that it 
>  now supports 64-bit.
>  
>  Best regards,
>  Alex Ionescu 


The kernel still only has a single namespace.  The session specific 
namespaces are implemented as object manager directories other than 
\DosDevices, and kernel32.dll simply prefixes the correct path for the 
current session instead of \DosDevices.  You can force it to use 
\DosDevices instead of the session directory by prefixing the names you 
pass it with Global\.


Robert Köpferl wrote:
>   The one reason I gave me as answer was that on a
> TS-environment, 
>  everyone has it's own DOSDevices-namespace.
>  
>  and I think there are even more parts of the object manager namespace 
>  duplicated and separated. But will this need several csrss?
>  Neiter that nor win32k. It needs a hack to the win32 API
>  
>  OR
>  Start csrss with another alternative \DosDevices OM-Path as start 
>  parameter to make the whole win32 api behave different. GetDriveLetters 
>  etc.

[Alex Ionescu]

Phillip Susi wrote:

>   I was under the impression that the SFU programs were
> all win32 
>  subsystem, they just provided network access to unix services, and 
>  therefore, there was no posix subsystem.
>
>  Are you saying that SFU ships PE images tagged for the posix subsystem 
>  instead of win32 cui? 
Yep.

>  
>  Alex Ionescu wrote:
>
> >  
> >  Erm, the posix subsystem has been removed since Windows 2000. Had SFU 
> >  not been including one all along, then all those utlities would've 
> >  never worked...so yes, SFU -does- include psxss. That part is called 
> >  SUA (Subsystem for Unix Applications). One of the big improvemnts is 
> >  that it now supports 64-bit.
> >
> >  Best regards,
> >  Alex Ionescu 
>
>
>
>  The kernel still only has a single namespace.  The session specific 
>  namespaces are implemented as object manager directories other than 
>  \DosDevices, and kernel32.dll simply prefixes the correct path for the 
>  current session instead of \DosDevices.  You can force it to use 
>  \DosDevices instead of the session directory by prefixing the names 
>  you pass it with Global\.
>
>
>  Robert Köpferl wrote:
>
> >   The one reason I gave me as answer was that on a
> > TS-environment, 
> >  everyone has it's own DOSDevices-namespace.
> >
> >  and I think there are even more parts of the object manager namespace 
> >  duplicated and separated. But will this need several csrss?
> >  Neiter that nor win32k. It needs a hack to the win32 API
> >
> >  OR
> >  Start csrss with another alternative \DosDevices OM-Path as start 
> >  parameter to make the whole win32 api behave different. 
> >  GetDriveLetters etc. 
>
>  
Best regards,
Alex Ionescu

[Robert Köpferl]

Phillip Susi wrote:

>   
>  I would think so too, but the fact remains that win32k already appeared 
>  to have window stations in place specifically for the purpose of 
>  supporting multiple consoles ( be they physical or virtual ), so I can 
>  see no good reason to go through the trouble of hacking up the kernel to 
>  be able to load a driver multiple times.  Unless you know of a good 
>  reason, then ReactOS should not make that same mistake.
>  
>  One good technical reason NOT to use session space is that the pages 
>  therein can't be marked with the global page bit, so they must be 
>  flushed from the TLB on every context switch.  Then the page tables 
>  themselves take up more memory, though a relatively small amount.
>   
The one reason I gave me as answer was that on a TS-environment, 
everyone has it's own DOSDevices-namespace.

and I think there are even more parts of the object manager namespace 
duplicated and separated. But will this need several csrss?
Neiter that nor win32k. It needs a hack to the win32 API

OR
Start csrss with another alternative \DosDevices OM-Path as start 
parameter to make the whole win32 api behave different. GetDriveLetters etc.

[KJKHyperion]

Alex Ionescu wrote:

>   If you really want to argue using Ockam's Razor
> (note for others: 
>  Ockam's razor basically says that the simplest assumption is usually 
>  the correct one), then I'm afraid I'm the one winning this argument. 
oh, FFS (note for others: "For Fuck's Sake"), just grow up already

Emanuele: let's discuss your CSRSS.EXE fetishism this time. You know 
what's my position about subsystems, let's let the others know too. To 
keep it simple, I'll use a bullet list:
 - the concept of "subsystem server" just complicates the taxonomy of 
Windows processes unnecessarily. I'd like to think to ReactOS only 
having two kinds of processes: services and non-services (three: the 
SCM, in a category on its own). All of the other ad-hoc semantics 
(start-up sequence, user session lifetime, connection to the display, 
etc.) can be implemented either with service semantics or with a custom 
logic specific to a certain service. Keyword: SIMPLICITY
 - personalities as services? meh. Personalities should be the closest 
possible to utility libraries, you should be allowed to mix them (mixing 
Win32 and POSIX is very necessary to implement a BeOS personality, for 
instance, and POSIX itself needs to at least be aware of Win32 if we 
want it to be actually useful), and please let's stop the insanity: 
POSIX was designed to be implemented in kernel mode, and there's nothing 
shocking or horrific about running POSIX in a kernel (I mean, lots of 
systems do, none has crashed and burned. Even QNX - signals and the 
lowest-level forms of IPC are implemented in the microkernel). Keyword: 
FLEXIBILITY
 - Win32 consoles. Yuck. Let's see: I/O and signaling in user mode, user 
interface in a system process, could it be any more wrong than this? why 
yes, it _is_: in Win32 its handles share a namespace with NT handles, 
despite having perversely differing semantics. What a disaster. Keyword: 
ORTHOGONALITY

[Emanuele Aliberti]

Alex Ionescu wrote:

> >   I actually
> > didn't understand if Russinovich was paid by MS to show that,  
>
>  I feel a bit insulted. What does Russniovich have to do with anything? 
>  The screenshots above show a program which I alone have worked on, and 
>  that no other "NT hacker" has attempted in doing before. 
Sorry, I took it for what Russinovich showed in his blog (killing the SM 
and LSA):

Sunday, July 24, 2005
Running Windows with No Services

http://www.sysinternals.com/Blog/

Actually, P. Dabak published the code of a native application that did 
keyboard I/O

Prasad Dabak   28 Feb 2000 10:00

Newsgroup: comp.os.ms-windows.programmer.nt.kernel-mode
From: Prasad Dabak <prasadNOprS...(a)cybermedia.co.in.invalid>
Date: 2000/02/28
Subject: Re: Keyboard input in Windows NT native application



-- 
:Emanuele Aliberti

[Alex Ionescu]

Emanuele Aliberti wrote:

>   Alex Ionescu wrote:
>
> > >   I
> > > actually didn't understand if Russinovich was paid by MS to show 
> > >  that,  
> >
> >
> >  I feel a bit insulted. What does Russniovich have to do with 
> >  anything? The screenshots above show a program which I alone have 
> >  worked on, and that no other "NT hacker" has attempted in doing before. 
>
>  Sorry, I took it for what Russinovich showed in his blog (killing the 
>  SM and LSA):
>
>  Sunday, July 24, 2005
>  Running Windows with No Services
>
>  http://www.sysinternals.com/Blog/ 
Ah... nice blog article. Too bad he stole it from a post I made on the 
private Microsoft newsgroups about 2 years earlier (Yes,this is an 
assumption, but I had posted the exact same screenshot and explenation a 
full two years earlier on a newgroup I know he has access to!).

>  
>  Actually, P. Dabak published the code of a native application that did 
>  keyboard I/O
>
>  Prasad Dabak   28 Feb 2000 10:00
>
>  Newsgroup: comp.os.ms-windows.programmer.nt.kernel-mode
>  From: Prasad Dabak <prasadNOprS...(a)cybermedia.co.in.invalid>
>  Date: 2000/02/28
>  Subject: Re: Keyboard input in Windows NT native application 
The code doesn't work on Win 2003 anymore, although it was a good read. 
The hard part is scancode->character conversion, as well as proper 
display output, including "backspace" (which requires buffering the 
line-data and using some simple algos to emulate backspace.

Best regards,
Alex Ionescu

[Robert Köpferl]

>   Another issue which ea has brought up is that NT is
> somehow to 
>  "connected" to Win32. I beg to differ. I've spent a week working on a 
>  sample native application. It currently can display running processes, 
>  drivers, create a new process and create/delete/list files. Here are 
>  some screenshots:
>  
>  http://members.tripod.com/WinAlOS/rtlcli.png
>  http://members.tripod.com/WinAlOS/rtlcli2.png
>  http://members.tripod.com/WinAlOS/rtlcli3.png
>  
>  Note that there is no CSR, no win32k.sys loaded. NT is running in its 
>  rawest form. You need less then 16MB of memory (notice that the 
>  processes are using <1MB, the rest is up to the drivers, which you can 
>  disable) and about the same amount of diskspace. This works perfectly in 
>  Windows 2003 without any need to "separate win32". 
Highly interesting. I'm just fascinated from that native app or the 
screenshots and what they show.

And many many quetions arise in my brain.

One is: Why are you talking so much of 2k3 in the latest time?
Is there some real big design change occoured?
Can it live without csrss while priror versions couln't?
That would be courious to me because MS pollutes and webs more and more 
together but separating each part cleanly.

[Alex Ionescu]

Robert Köpferl wrote:

>  
>
>
> >   Another issue which ea has brought up is that NT
> > is somehow to 
> >  "connected" to Win32. I beg to differ. I've spent a week working on a 
> >  sample native application. It currently can display running 
> >  processes, drivers, create a new process and create/delete/list 
> >  files. Here are some screenshots:
> >
> >  http://members.tripod.com/WinAlOS/rtlcli.png
> >  http://members.tripod.com/WinAlOS/rtlcli2.png
> >  http://members.tripod.com/WinAlOS/rtlcli3.png
> >
> >  Note that there is no CSR, no win32k.sys loaded. NT is running in its 
> >  rawest form. You need less then 16MB of memory (notice that the 
> >  processes are using <1MB, the rest is up to the drivers, which you 
> >  can disable) and about the same amount of diskspace. This works 
> >  perfectly in Windows 2003 without any need to "separate win32". 
>
>  Highly interesting. I'm just fascinated from that native app or the 
>  screenshots and what they show.
>
>  And many many quetions arise in my brain.
>
>  One is: Why are you talking so much of 2k3 in the latest time? 
Because it's the best OS Microsoft has ever written.

>   Is there some real big design change occoured? 
There were some big changes in IO/PnP regarding asyncronous device 
loading (almost all of the PnP code is now async, working on thread 
queues which process requests), and a lot of the kernel changed and 
became less polluted. Many algorithms were rewritten from scratch for 
better speed, such as the Heap manager.. the scheduler was completely 
redesigned too, as well as several parts of the dispatcher... and a lot 
more changes that aren't coming to my head now.

>   Can it live without csrss while priror versions
> couln't? 
They all can. It's just that Win2k3 boots much faster so I chose it in 
qemu. However a lot of csrss became deprecated in 2k3, and even more in 
Vista. (some stuff in it was NT 3 stuff that really needed to die...)

>   That would be courious to me because MS pollutes and
> webs more and 
>  more together but separating each part cleanly. 
Well, 2k3 DOES "pollute" ntdll with the Etw* stuff, which I think 
shouldn't be there.

Best regards,
Alex Ionescu