AutoHotkey Community

This thread may not belong perfectly in the Bug Reports section, but it seems to be the closest fit. See if you agree.

I have concerns about the recent addition of the "TS awareness" flag to AutoHotkey.exe (and to compiled scripts) in that it disables some extremely useful behaviors on servers running Terminal Services (I refer here to "Application Server" mode). I'll be more specific below, but besides potentially breaking many existing scripts for the TS/Citrix crowd (to which I belong, let it be said up front ), it forces authors of future AHK programs that may be run in Terminal Services sessions to code in a so-called "profile-aware" fashion (see below), often an unnecessary complication. Note that nothing previously prevented AHK programmers from writing TS-aware/profile-aware applications, but they're now forced into it (for no obvious benefit, by the way -- the MS claim that non-TS-aware applications load or run more slowy under TS is essentially a crock as far as human perception is concerned.)

To explain what I'm babbling about, I first need to describe the two principal useful behaviors that Windows applies to executables running in a TS session (both of which disappear if the executable has the "TS aware" flag set). A TS session is at any one time in one of two modes: "Install Mode", only available to administrators (who use it for short periods of time mostly while installing applications), and "Execute Mode", the "normal" state of all sessions.

In a session that's in "Install Mode",
(1) any registry write to HKCU\Software\... is centrally "shadowed" (i.e. also written) to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\... (informally known as the TS "shadow keys"), and
(2) any use of the GetWindowsDirectory API call to locate the Windows directory (or use of Read/WritePrivateProfileString to read/write a .ini file specified by name but without a path) is directed to the "true" Windows directory (typically C:\Windows).

In a session that's in "Execute Mode",
(1) any registry read from HKCU\Software\... that would otherwise fail (because the requested key or value does not exist) instead causes the corresponding key to first be copied from the "shadow keys" area (assuming of course that it does exist there) to the user's Registry hive and then provided to the requesting program (which is never made aware of the sneaky under-the-covers activity), and
(2) the GetWindowsDirectory and Read/WritePrivateProfileString calls are now directed not to the "true" Windows directory but rather to each user's "private" Windows directory (typically %HomeDrive%%HomePath%Windows), with any missing .ini files copied as needed (and again transparently) from the true Windows directory.

The basic idea and net effect of these behaviors (which by the way were invented by Citrix and sold to Microsoft as part of the development deal that led to Terminal Services on NT4 and beyond) is that (1) a single user (an administrator, using Install Mode) can install an application once, and multiple users (using "Execute Mode") can later successfully run that application despite not having installed it themselves, even if the application expects to find HKCU\Software\... entries that were supposed to have been created by its setup program, and (2) each user can individually set program configuration options, even if the settings are stored in a .ini file in the Windows directory (since each user reads and modifies his or her private copy of the file following the one-time replication of the central copy).

It must also be noted (as I slowly get to my point) that many TS/Citrix administrators make use of (and rely on) these "Execute Mode" spoofing behaviors to propagate standard application settings to all users by "manually" writing entries to the TS shadow keys or to .ini files in the central Windows directory, even when the application's own setup program did not write anything to those areas. Such applications are sometimes referred to as "profile-aware" apps, i.e. apps that do not rely on their setup program to provide an initial set of default user settings under HKCU\Software (which normally only affects the installing user's profile) but rather take the responsibility of providing initial user settings the first time each user launches the app (so each user profile eventually gets populated, not just the installing user's). AutoHotkey having the "TS aware" flag (a) forces the programmer to write in profile-aware fashion (and may break previous non-profile-aware programs if ever recompiled), and (b) removes from the administrator the ability to centrally provide standard initial application options, because the contents of the TS shadow keys will now be ignored and only central (common, non-private) .ini files will be accessed (which means that any change by one user will affect all users).

Here's a specific example of AHK code that will behave differently in standard "Execute Mode" sessions now that the "TS aware" flag is set:
Under previous AHK versions, both the first two writes (the Test1 and Test2 values) would be written not in fact to TSTest.ini in %windir% (aka %SystemRoot%) but rather to TSTest.ini in the user's private Windows directory -- depending on system configuration, it might be something like H:\Windows (assuming H: is mapped to the user's home directory) or "C:\Documents and Settings\username\Windows". This behavior is often used when writing application "wrappers" with AutoHotkey, to pre-set certain dynamically obtained information into (the user's private copy of) an application's .ini file prior to launching the app. Under the latest versions of AutoHotkey, the first two writes would be directed to a common TSTest.ini in the "true" %SystemRoot% (e.g. C:\Windows), and would incidentally probably fail because of insufficient user permissions. [If you're wondering about the third IniWrite in the above sample code, I included it to point out a difference between how AutoHotkey and AutoIt v2.x handle a .ini file specified without a path: AutoHotkey forces writes to the file in the working directory %A_WorkingDir% while AutoIt v2.x appears to pass the unmodified filespec to WritePrivateProfileString, which writes to the Windows directory -- common or private, depending on whether the TS session is in Install or Execute mode, respectively].

Lastly (I promise), I should point out that, even without the "TS Awareness" flag set in its executable, an application that for whatever reason does not wish some or all of the Execute Mode "spoofing behaviors" to take place under Terminal Services can turn them off in very granular fashion using a set of executable-specific flags written to an appropriately named subkey of HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications.

Well, that's my pitch against the TS awareness flag. I apologize for the length of the post.

Jacques.

Thanks for the detailed info. I'd changed the flag to try to help with the problems over at http://www.autohotkey.com/forum/viewtop ... 9&start=15

But it seems unlikely the flag helps with any of that. So unless anyone gives a good reason not to change it back, I will do so.

Thanks, Chris. I appreciate the quick response and willingness to put things back as they were. [I was already planning to try to figure out where that flag is found in an exe's header for the purpose of hacking it back off -- which I may do anyway in case a particular program might some day benefit in som way from having it on].

I'll have a look at the thread you mention as soon as I get a chance to see if I can help with whatever the issue is.

Jacques.

Due to a mistake, only in today's 1.0.46.09 was the Terminal Server Awareness flag actually turned back off. So things should be back to how they were in all versions prior to 1.0.46.06.