Back in the day, I used to love having a PC equipped with a VGA graphics card and an additional Hercules graphics card attached to a green-screen monitor. When debugging applications, the app could run on the main screen and the debugger could run on the green-screen. This was particularly beneficial in the early days of Windows when debuggers were text-mode apps which forced the screen to toggle between text screen and Windows GUI as you stepped through code. Some older graphics cards and monitors used to take several seconds per switch to re-sync making single stepping through code a VERY painful experience.

And then, along came debuggers that could run within console windows or were native Widows apps and the need to switch between text-only and graphical screen resolutions suddenly went away. However, I always missed having my debugger & source on one screen and the app being debugged on another.

As the price of graphics cards and screens continued to drop, and as PC's and Windows' ability to support multiple screens improved, I eventually acquired a second screen letting me run the debugger on one screen while the app rendered on the other.

But as I started to work on multiple machines at the same time, I then hit another dilemma ... how do I retain my multi-screen environment when I have to switch between several physical boxes?

Alas, KVM's are just not a solution - they're unpredictable at best, horribly unreliable at worst and didn't smoothly support multi-monitor scenarios.

Then, a few years ago, Citrix, Microsoft and others introduced Terminal Services (TS) capabilities to Windows and other OS'. TS essentially streams all the User Experience (UXP) commands that would normally be directed to a machine's graphics, audio, printer, keyboard, etc. drivers to a remote PC running a Terminal Services Client (TSC). The TSC app would then translate these commands to render the same UXP on the local machine so that to all intents and purposes, the user could believe that they were actually sat at and operating the remote machine.

Whilst TS can be a massive boon to many enterprise scenarios enabling administrators to consolidate many thousands of user's PC's apps and environment into one server infrastructure. However, TS capabilities are not just limited to enterprise environments.

Thankfully, Microsoft opted to include a TS client (MSTSC) within Windows client OS' which meant that instead of having to buy a KVM and a ton of cables, I could instead control multiple machines from one client PC using MSTSC application (also known as Remote Desktop).

Whilst MSTSC was great in that I could now have my local desktop on one screen and other machine's desktops on other screens, all controlled from the same keyboard and mouse with no fiddly screen-switching to perform, I sometimes wanted to view a remote machine's desktop spanned across two screens.

Vista has now made this not only possible, but easy and simple!

To start MSTSC, it's often best to use the command line because there are a few options available which (for some reason) aren't exposed through the Tools  | Options dialog.

For example, to connect to a remote machine called RichDev01, you could type (or create a shortcut for) the following:

MSTSC \\RichLaptop01

When executed, you'll then be shown the remote machine's desktop. For example, here's my laptop's desktop (where I am writing this post), accessed from an MSTSC instance running on my dev box:

On a multi-monitor machine, I am also able to access the local machine's desktop (on the left) AND the remote machine's desktop (on the right) simultaneously:

Whilst this is great (so I can keep up with my email while my dev box builds, for example), I sometimes want to be able to access the remote machine's desktop as if it was attached to the two screens.

Thankfully, this was a feature added to Vista (and enhanced in Vista SP1)! Below is a screen capture of my laptop's desktop, viewed across my dev machine's two screens:

How do you do this? Simple - you call MSTSC with the /SPAN command-line option; for example:

MSTSC \\RichLaptop01 /SPAN

It turns out that spanning your target desktop via an MSTSC session has a valuable hidden feature: When you maximize an app on the remote desktop, it will expand to fill the entire space available to it, rather than the current screen! Just what you need when parsing complex logs or comparing files etc!

Anyone out there with more than two screens that can test out if a remote machine's desktop can be spanned across more than two screens?