[ros-dev] Excuse me. What way...?

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