4

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.

3 Answers 3

5

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.

6
  • Isn't the zeroth session reserved for services on Vista? Jul 28, 2009 at 15:22
  • maybe :) Jul 28, 2009 at 16:46
  • Thanks for in-depth explanation. My answer came from a sysadmin POV and this question seems more from a dev POV. Is this more appropriate for StackOverflow than ServerFault?
    – SQLChicken
    Jul 28, 2009 at 17:24
  • i added to code to try to drive home the realization that it is the software that needs to be lied to. It has nothing to do with features of TS to display remote applications, or the RDP protocol. The application is written, and now i'm looking for a shim that can be applied to the domain so that the software will work when people remote to their machines.
    – Ian Boyd
    Jul 28, 2009 at 20:12
  • @Colin: i don't believe it is possible to connect to the "console session" on Windows Vista. At the very least i can say that if you remote to a desktop machine, it knows you are running in a terminal session (and the given pseudo-code will detect it)
    – Ian Boyd
    Jul 28, 2009 at 20:14
0

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.

2
  • i guess you just have no idea what i'm talking about. :) Once you're connected to the desktop on a machine, you can now use Explorer to browse around and double-click to run a program. Some programs detect that you're running from inside a TerminalSession/RemoteDesktopWindow
    – Ian Boyd
    Jul 28, 2009 at 14:18
  • I think you're talking on different levels. RDP is the protocol for Remote Desktop / Terminal Services. The correct way of detecting a Remote Desktop sesssion (as a programmer) is to check SM_REMOTESESSION. By connecting to console session, you are effectively 'taking over' the main session as it were, and SM_REMOTESESSION is still 0, and the program won't be able to tell you are using Remote Desktop. Only works for single user of course. More details here: msdn.microsoft.com/en-us/library/aa380798%28VS.85%29.aspx Jul 28, 2009 at 14:34
0

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.

1
  • i'm looking to run a piece of software in the enterprise.
    – Ian Boyd
    Jul 28, 2009 at 14:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .