I tried this and it seems that ShellExecute doesn't use any environment variables at all:ghisler(Author) wrote:Another idea: Would it help if TC just added the directory from GetSystemWindowsDirectory to its PATH variable? Windows seems to look in the path when launching a program by name only. Or maybe internally set %windir%?
- I added GetSystemWindowsDirectory path to the %path% variable - doesn't help,
- changing %windir% is useless - %windir% always points to the true Windows directory.
%windir always points to the true Windows directory, but ShellExecute doesn't use this variable - it internally calls GetWindowsDirectory function.ghisler(Author) wrote:That's strange, programs launched from TC would inherit it's environment variables, so %windir% should be pointing to the wrong location...Yes, this definitely works.
When EXE is launched on a server machine and it doesn't have IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set, operating system - before passing control to the application - loads tsappcmp.dll application compatibility library for this application. Kernel32.dll looks for tsappcmp.dll and - if loaded - redirects, among others, GetWindowsDirectory calls there - so GetWindowsDirectory returns a "fake" Windows directory.
So TC has tsappcmp.dll loaded and GetWindowsDirectory returns "fake" Windows directory for TC. But when TC launches some application with IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set, OS doesn't load tsappcmp.dll library for that application. When that application calls ShellExecute, ShellExecute internally calls GetWindowsDirectory - it is NOT redirected for that application, so it returns true Windows directory - so ShellExecute can succesfully launch REG files, when called from application with IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set.
So TC could launch a small tool with this flag set, and this tool could successfully open REG files with ShellExecute.