Home / server / Questions / 46980
Accepted
Ian Boyd
Asked: 2009-07-29 06:06:54 +0800 CST

Is there is "Running in terminal session" lie shim?

  • 772

Windows provides a number of shims to workaround bugs and limitations in programs.

Shims can lie to a program about all kinds of things

  • lie about the version of Windows
  • lie about a file operation failing
  • lie about a registry key that it couldn't open

Is there a shim to lie about the software being run from a Terminal Session (e.g. Remote Desktop)?

i have a piece of software that detects if it is running in a Terminal Session and changes its behaviour accordingly. Another piece of software refuses to run because it is says it's simiply not supported.

And like a program that refuses to run on anything higher than Windows 2000, it can run fine - if it just gives itself a chance.

Is there a "terminal session lie" shim?

Imagine the psuedocode that contains:

static class Program
{
   if (System.Windows.Forms.SystemInformation.TerminalServerSession)
   {
       System.Environment.FastFail("We're too lazy to make our software work under TS.");
   }
   ...
}

Other applications change their behaviour under a terminal session:

//Don't enable animations if we're in a TS window, or on battery
Boolean animationsEnabled = 
        (!System.Windows.Forms.SystemInformation.TerminalServerSession)
        &&
        (System.Windows.Forms.SystemInformation.PowerStatus.PowerLineStatus != 
               PowerLineStatus.Offline);

i want Windows to lie to the application, so that it doesn't think it is running in a Terminal Session/Remote Desktop Session.

This is similar to how other program's don't know how to write version check code, and so fail on anything newer than Windows XP:

static class Program
{
   //Make sure we're on Windows 5.0 or later:
   if (!(WinMajorVersion >= 5) && !(WinMinorVersion >= 0))
       FastFail("Requires Windows XP or later");
}

The above code prompty fails on Windows versions 6.0 - which is exactly the reason why version lie shims exist.

windows remote-desktop

3 Answers

  1. Best Answer

    I don't believe this is possible. The particular flag code that your program is probably looking at is the SM_REMOTESESSION flag. As SQLChicken pointed out, you can defeat this for a single user, by trying to grab the console session, which will leave you with SM_REMOTESESSION = 0, but for multiple users, I don't think it can't be done.

    I appreciate this is frustrating, but you will probably have to work with program vendor to resolve this. It's a lot of work correcting software that misbehaves under TS, since it's usually caused by the crappy Windows mentality that all computers are just large screen PDAs and multiple users are out of the question (and networking is really for advanced users). Problems caused by this are not limited to the "Can't be bothered to test" function you describe (something like this:

    #include <windows.h>
#pragma comment(lib, "user32.lib")

BOOL IsRemoteSession(void)
{
   return GetSystemMetrics( SM_REMOTESESSION );
}

    ) but also the use of shared resources and the proper use of graphics (the reason this is actually hard to do right is discussed by Raymond Chen).

    So unless you have some other mechanism to prove that the software works correctly with multiple users, I would be inclined to assume that defeating the SM_REMOTESESSION check would not actually be enough.

    • 5

  2. I'm kind of confused but I'll take a crack at this. In terms of remoting into a server using RDP you can use the console connection so that you can run apps that need that console state. Click on Start-->Run and type in 'mstsc.exe /?' (without single quotes). This will bring up the help switches for whatever version of RDP you're currently running. You can use these switches to launch RDP using the console session. For instance for the version I'm currently running (Windows 7 RC) I would type 'mstsc.exe /v:exampleserver /admin' to connect to the console session for the server named exampleserver. Be aware that there are differences out there in RDP versions because that /admin switch used to be /console. If you want to be sure then connect to your target server and run that /? command and see what it expects for the console connection.

    • 0

  3. Workaround, rather than solution.

    Are you looking to run a single piece of management software, or provide an application to a terminal server?

    If the prior, you could use something such as VNC/LogMeIn to connect to the console -- and the system wouldn't know you were remotely connected.

    The danger in the later is that some applications use shared resources (an application we use has the same named temp files, so multiple users cause corruption) and simply cannot run on a terminal server under multiple instances due to poor design.

    • 0