I've been doing some research into the architecture of Windows Terminal Services lately and it strikes me that it would be entirely possible to develop a pack of drivers and services to present a Windows Terminal Server via the VNC protocol instead of/as well as the RDP (native windows remote desktop protocol) or ICA (god knows what it actually stands for but the citrix protocol).
Essentially, this would mean you could connect to any terminal services-enabled system, login using the graphical prompt, and get your own desktop, which if disconnected from you could reconnect to exactly as it was at any time. It would decouple the user numbers from enforced TS-Client Access licensing since VNC has no inherent support for licensing (and forcing it on the protocol would defeat the purpose). Not that I'm endorsing exceeding licensed limits on clients of course
Using UVNC specifically as a starting codebase would also ensure later availability of direct login credentials (Winlogon), encryption on the wire, and file transfer.
Should the VNC protocol implementation ever exceed any aspect of RDP in functionality, you'd also avoid the requirement to go to a much more expensive product (eg, Citrix) with yet another layer of client licensing on top.
This would NOT enable multiple-desktop functionality on non-TS systems (ie, 2000/XP/Vista) - it relies on the terminal services components to function (TS has to do all the desktop setup stuff - it's a deep-seated part of windows). Under XP Pro/Vista Bus/Ultimate it would basically do exactly the same as RDPing to it does now, just with VNC as the protocol and client.
So... Brainstorming...
The structure of WTS is as follows:
====WINDOWS COMPONENTS===
(stuff that's provided by windows and we needn't reinvent)
Terminal Server service (windows component)
- Acts as listener on TCP port, does associations of sessions to users
Session Manager (windows component)
- does setup/teardown of desktop login sessions, reconnects new connections to existing, disconnected sessions
CSRSS (windows component)
- manages the login session from windows' point of view (fires off the login process, starts the desktop, etc
===VENDOR/PROTOCOL-SPECIFIC COMPONENTS===
(Stuff we need to write)
Winstation Driver
- Does session setup/negotiation, and "de-multiplexes" the session once setup into Video, Keyboard and Mouse channels (and any other channels in the protocol, eg clipboard, file transfer)
Video Driver
- Presents to the terminal services session as an ordinary video device, but processes and hands off video data to be encapsulated into the protocol (VNC in our case) and sent to the client
Input Driver(s)
- Presents to the terminal services session as ordinary keyboard/mouse devices, but actually receives input from the protocol connection (VNC in our case) via the Winstation Driver
Tentative Roadmap
----------------------
A simple NT-Kernel-mode VNC mux/demuxer would need to be written to form the basis/template for a Winstation driver. Perhaps for testing purposes reading 'screen' data from a file, dumping 'input' to a logfile and connecting via named pipes or something.
The UltraVNC Mirror driver would need to be extended into a full video driver, outputting both into a framebuffer (for screen refreshes) and handing off application updates "upstream" (towards the client). Much like normal really. Alternatively, the framebuffer can be dropped with the disadvantage that full screen refreshes require a redraw message to all session apps (slower but less memory). This can be tested in a normal desktop environment. Where possible it should be kept in sync with the existing UVNC driver.
A simple shim combined keyboard/mouse driver would need to be written to receive input events from the client and pass them on as keyboard/mouse events to the session. This can be tested in a normal desktop environment, and might be worthy of passing back upstream to UVNC as an input optimization.
The big step is this:
Either,
porting the WINVNC service to NT-Kernel-mode, or,
reimplementing UVNC's WINVNC service in NT-Kernel-mode
to serve as the Winstation driver.
After this, there should be a working (if barebones) VNC alternative to RDP and ICA as a WTS connection protocol.
Anyway. Let me know what you all think
[mod=494,1225495434]moved from vnc related to feature request[/mod]
