Excuse me. What way...?

Hi all!

I post this message, because I would like to read you comments and opinions
about the way to take to implement multiuser support in the Win32 subsystem of
ReactOS. Multiuser support for Win32 is, in fact, named "terminal services".

There are, as you know, two possible ways. Microsoft was at the same crossroad,
when they had to make Win32 in NT 4.0 multiuser.

a) make multiuser compliant csrss.exe+win32k.sys

b) load separate instances of csrss.exe+win32k.sys

B is obviously less expensive, because you do not touch the code in csrss.exe
and in win32k.sys and therefore you need no more debugging than regular single
user Win32. It is a hack, but it sells very well.

But Microsoft is committed to market. ReactOS isn't.

Obviously, as I like challenges (otherwise why would you devote your time to a
project like ReactOS?), and clean design in software, I vote for implementing (a).

Please comment about: 
- easy/hard;
- compatible/incompatible;
- impact on current design;
- huh?



____________________________________________________________
Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. 
Scegli Libero Adsl Flat senza limiti su http://www.libero.it

[Mike Nordell]

ea wrote:

>   a) make multiuser compliant csrss.exe+win32k.sys
>
>  b) load separate instances of csrss.exe+win32k.sys 
While I personally would consider a the cleaner, leaner and more "correct",
it also raises as you noted some challenges.

First and foremost is, how much re-design/refactoring would it require to
make this work? One problem I immediately see is input handling. As input
handling is currently IIRC set up at startup (of win32k), this must be
changed to allow runtime configuration of input devices - at least at winsta
creation time, where each winsta can have different input devices (kbd0,
kbd1, RDP:port, RFB:port, ...). The same obviously goes for output (gfx,
sound, force-feedback joysticks :-),  ...). On the other hand, this has to
be done anyway, only with new instances (option b) it's done at startup,
while using option a it has to be refactored to allow it at winsta creation.

One interesting option that presents itself that I haven't previously
considered, is that this could open the door for using a dual-head (or multi
gfx card) computer for two or more workplaces. Add another monitor, (USB)
kbd and mouse, and you can have another fully working desktop/workplace for
another user without having to buy a whole new (even if cheap, used as a
"thin client") computer. But now I'm drifting away from the subject. :-)

Without having looked at the code involved I can't really guess about the
complexity and how easy/hard a vs. b would be, but as both window stations
and desktops are already (intended to be) secure objects I would go out on a
limb and say that a) might perhaps not so much harder than b) for this
specific class of problems.

As for compatibility... If one limits the descussion by removing ane "fancy"
stuff (even that the idea of remote OpenGL, utilizing its client/server
architecture has already got a foothold in my mind :-) ), and talk only
about plain win32, user, gdi, the possible obstacles I see are related, and
limited, to memory management, limits and system notifications. F.ex. user
and gdi objects heaps and limits, which would possible require some
refactoring to allocate and assign memory/heaps not at startup, but at
winsta creation.

There could of course be some "special thing" about TS-aware apps that I'm
unaware of, that inherently depends on a new csrss instance for each new
logged on user, but whatever that might be I'm blissfully unaware of it.

There could also be something about csrss I'm not aware of, but since one
can already (on a real windows box) create a new desktop, start new
applications as another user using e.g. RunAs without getting new instances
of csrss, I currently don't see how this scenario would be so radically
different from having another user having its own winsta+desktop(s), even is
remote.

There could also be an issue with GDI, that it in Windows is drain-bamaged
in not allowing different desktops (using a single gfx output device) to
have different resolutions/colour-depths. I suspect that point, and other
usually system-wide settings (limited to user and gdi I think), is what
could put a sabot into the machinery for option a.

Yet another possible problem could be with global hooks, that currently may
or may not respect desktop or winsta boundaries.

There could also, possibly, be some kind of scalability, WM message handling
speed etc problems having a single instance handle this all, over letting a
separate instance handle each user, that could possibly lead to one user on
the machine doing something that could create "hiccups" for another user. I
don't _know_ if any such problems are present, but considering user32 is
inherently designed as a single-user desktop, I wouldn't bet against it
either.


But to to sum up, if option a) turns out to be feasible I'd prefer it any
day over the hackish MS-style option of starting a new csrss+win32k for
every "remote" desktop user.


/Mike
P.S. If it was up to me, and I had unlimited time and resources, I'd take it
even further by reviving the pre-NT4 way of doing things, for remote user,
but still have only one instance handle all remote connections. It's not
like the speed MS gained in NT4 by putting user and gdi in kmode could ever
make a noticable difference if running remote any way, and IMO it only
complicate development, debugging and other things of both the ROS
infrastructure and the drivers required for this, for remote connections.

[ea]

Mike Nordell wrote:

> >  a) make
> > multiuser compliant csrss.exe+win32k.sys
> >
> > b) load separate instances of csrss.exe+win32k.sys
> >     
> >  
> While I personally would consider a the cleaner, leaner and more "correct",
> it also raises as you noted some challenges.
>
> First and foremost is, how much re-design/refactoring would it require to
> make this work? One problem I immediately see is input handling. As input
> handling is currently IIRC set up at startup (of win32k), this must be
> changed to allow runtime configuration of input devices - at least at winsta
> creation time, where each winsta can have different input devices (kbd0,
> kbd1, RDP:port, RFB:port, ...). The same obviously goes for output (gfx,
> sound, force-feedback joysticks :-),  ...). On the other hand, this has to
> be done anyway, only with new instances (option b) it's done at startup,
> while using option a it has to be refactored to allow it at winsta creation.
>   
>  
Probably, after finishing the current work on the SM, I'll touch the CSR 
to make it session aware, at least for what I can understand. This is 
why I asked for comments here.
Yes, both ways require rethinking some internals of csrss+win32k. 
Currently I/O is wired in csrss: devices should be parameters when 
creating a window station and/or a desktop. Would this break compatibility?

>  One interesting option that presents itself that I
> haven't previously
> considered, is that this could open the door for using a dual-head (or multi
> gfx card) computer for two or more workplaces. Add another monitor, (USB)
> kbd and mouse, and you can have another fully working desktop/workplace for
> another user without having to buy a whole new (even if cheap, used as a
> "thin client") computer. But now I'm drifting away from the subject. :-)
>   
>  
Actually I miss the ability to switch consoles with ctrl+alt+Fx like in 
Linux and SCO Openserver (others?) and having multiple displays is very 
useful in many situations.

>  Without having looked at the code involved I can't
> really guess about the
> complexity and how easy/hard a vs. b would be, but as both window stations
> and desktops are already (intended to be) secure objects I would go out on a
> limb and say that a) might perhaps not so much harder than b) for this
> specific class of problems.
>
>   
>  
I know something about CSR but win32k is an obscure land for me. Still 
waiting for comments on developers working on it.

>  As for compatibility... If one limits the descussion by
> removing ane "fancy"
> stuff (even that the idea of remote OpenGL, utilizing its client/server
> architecture has already got a foothold in my mind :-) ), and talk only
> about plain win32, user, gdi, the possible obstacles I see are related, and
> limited, to memory management, limits and system notifications. F.ex. user
> and gdi objects heaps and limits, which would possible require some
> refactoring to allocate and assign memory/heaps not at startup, but at
> winsta creation.
>
>   
>  
In your opinion, is that possible by implementing (in csrss *and* in 
win32k) an internal "session" object to keep per session data? Is it 
sufficient?

>  There could of course be some "special thing"
> about TS-aware apps that I'm
> unaware of, that inherently depends on a new csrss instance for each new
> logged on user, but whatever that might be I'm blissfully unaware of it.
>
>   
>  
Typically tracking per session properties. This can be done running 
indipendent instances of a single session process or managing internally 
those properties in a single process. But is that enough?

>  There could also be something about csrss I'm not
> aware of, but since one
> can already (on a real windows box) create a new desktop, start new
> applications as another user using e.g. RunAs without getting new instances
> of csrss, I currently don't see how this scenario would be so radically
> different from having another user having its own winsta+desktop(s), even is
> remote.
>   
>  
I don't know how RunAs is implemented: with a security token change or a 
session change?

>  There could also be an issue with GDI, that it in
> Windows is drain-bamaged
> in not allowing different desktops (using a single gfx output device) to
> have different resolutions/colour-depths. I suspect that point, and other
> usually system-wide settings (limited to user and gdi I think), is what
> could put a sabot into the machinery for option a.
>  
Applications can not cross desktop bondaries. Actually having different color
depths and resolutions is a matter of implementing it.

>  Yet another possible problem could be with global
> hooks, that currently may
> or may not respect desktop or winsta boundaries.
>
> There could also, possibly, be some kind of scalability, WM message handling
> speed etc problems having a single instance handle this all, over letting a
> separate instance handle each user, that could possibly lead to one user on
> the machine doing something that could create "hiccups" for another user. I
> don't _know_ if any such problems are present, but considering user32 is
> inherently designed as a single-user desktop, I wouldn't bet against it
> either.
>
>   
>  
IMHO, the only scalability issue is in csrss for consoles, but consoles 
are a resource only system administrators and developers use.

>  /Mike
> P.S. If it was up to me, and I had unlimited time and resources, I'd take it
> even further by reviving the pre-NT4 way of doing things, for remote user,
> but still have only one instance handle all remote connections. It's not
> like the speed MS gained in NT4 by putting user and gdi in kmode could ever
> make a noticable difference if running remote any way, and IMO it only
> complicate development, debugging and other things of both the ROS
> infrastructure and the drivers required for this, for remote connections.
>
>   
>  
I too like the old design, but it didn't perform well on the console.
If we go for a multiuser (multisession) csrss, it could be possible to 
use win32k.sys for console attached window stations and a usermode proxy 
for remote ones.

[Magnus Olsen]

Hi
I think B) will need alot of memmory and cpu power when it comes more that 1
user.
A) will need less memmory and smaller cpu power ageinsts B)
I would like see ros take small cpu power and memmory as posiblty


----- Original Message ----- 
From: <ea(a)iol.it>
To: "ros-dev" <ros-dev(a)reactos.com>
Sent: Friday, February 18, 2005 2:08 AM
Subject: [ros-dev] Excuse me. What way...?


>   Hi all!
>
>  I post this message, because I would like to read you comments and 
opinions
>   about the way to take to implement multiuser support
> in the Win32 
subsystem of
>   ReactOS. Multiuser support for Win32 is, in fact,
> named "terminal 
services".
>  
>  There are, as you know, two possible ways. Microsoft was at the same 
crossroad,
>   when they had to make Win32 in NT 4.0 multiuser.
>
>  a) make multiuser compliant csrss.exe+win32k.sys
>
>  b) load separate instances of csrss.exe+win32k.sys
>
>  B is obviously less expensive, because you do not touch the code in 
csrss.exe
>   and in win32k.sys and therefore you need no more
> debugging than regular 
single
>   user Win32. It is a hack, but it sells very well.
>
>  But Microsoft is committed to market. ReactOS isn't.
>
>  Obviously, as I like challenges (otherwise why would you devote your time 
to a
>   project like ReactOS?), and clean design in software,
> I vote for 
implementing (a).
>  
>  Please comment about:
>  - easy/hard;
>  - compatible/incompatible;
>  - impact on current design;
>  - huh?
>
>
>
>  ____________________________________________________________
>  Navighi a 2 MEGA e i primi 3 mesi sono GRATIS.
>  Scegli Libero Adsl Flat senza limiti su http://www.libero.it
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev