[ros-dev] Excuse me. What way...?
ea at iol.it
Sun Feb 20 16:01:51 CET 2005
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
In your opinion, is that possible by implementing (in csrss *and* in
win32k) an internal "session" object to keep per session data? Is it
>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
I don't know how RunAs is implemented: with a security token change or a
>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
IMHO, the only scalability issue is in csrss for consoles, but consoles
are a resource only system administrators and developers use.
>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.
More information about the Ros-dev