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

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