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.