From: Neil on
The "SESSIONNAME" environment variable is consistent on Terminal
Services. If it's RDP..., you are remotely connected. If you connect
locally, is 'Console'.

I think I might have done something to enumerate sessions, once... if
you don't have the answers you need, say, and I'll see if I can find
it.
From: Neil on
OK, not a TCL answer, but what I did in the past was look at the
output of Tasklist.exe. All of the running tasks are listed with their
session name and number. Just like the SESSIONNAME variable, any of
the session-names that start with 'RDP' are running remotely... If you
don't want to look at all processes, I *believe* you can just look for
csrss.exe, which I think should exist once in every client session.

I just looked on a Citrix server, and the SESSIONNAME environement
variable is ICA-tcp#60 where, of course, 60 will be the session name.
I don't have access to run something like tasklist, but I assume the
session names will be consistent. I would expect that TCL's task-
enumeration capabilities would include the session names, as well.

Incidentally, I've never seen Alexandre's KIT variable on any
machines. I would guess it's app-specific.
From: Michael Schumacher on
Harald Oehlmann wrote:

> Special Windows question a bit off-topic but maybee, someone knows.
>
> ( Background: Citrix or WTS (Windows Terminal Services) allow multiple
> users from distant computers to get a windows environment (->remote
> session) each. If they start programs, they are physically started on
> the server computer. This is similar to the help stuff in windows,
> where the current screen is displayed remotely. Here, we have multiple
> independent screens )
>
> Q1) May a TCL/Tk program detect if it is started within a remote
> session ?
>
> Q2) May a TCL/Tk program detect if it is started on a system with
> remote sessions ?

There used to be a "winfo interps" command in Tk which returned a list
of all Tk apps running on the querying system (and bound to a given
display, if specified). However, whether or not this works for Citrix
is something I can't tell for sure. Could you please try it and give
us a short report of your findings?


mike

From: Harald Oehlmann on
>> Q1) May a TCL/Tk program detect if it is started within a remote
>> session ?

>> Q2) May a TCL/Tk program detect if it is started on a system with
>> remote sessions ?

> There used to be a "winfo interps" command in Tk which returned a list
> of all Tk apps running on the querying system (and bound to a given
> display, if specified).  However, whether or not this works for Citrix
> is something I can't tell for sure.  Could you please try it and give
> us a short report of your findings?

Thank you all for the answers!!!

Unfortunately, I am asking so dump, because I have no access to such a
system and the software just should do it. So sorry, no test with
"winfo interps" by me.

Anyway, the environment variable "SESSIONNAME" seams to be very easy
to use for Q1

When rereading Q2, I want to reformulate it:

Q2) May a TCL/Tk program detect if it is started on a system with
remote sessions capabilities (citrix server, windows server with
wts) ?

Thank you,
Harald
From: Andreas Leitgeb on
Harald Oehlmann <wortkarg2(a)yahoo.de> wrote:
>>> Q1) May a TCL/Tk program detect if it is started within a remote
>>> session ?

Likely not - at least not reliably. It could start locally, and later
someone might connect to the desktop with an rdp-client.

My believe is, that all these remote-GUI protocols were defined such,
that all the remote-ness is transparent to the application running
inside.

I may be wrong, of course.

Perhaps ask in a windows-forum first, and for the answers you
get there, there might be some tcl-way (using twapi, or exec'ing
some system program that responds to stdout...)


PS: I think "winfo interps" will not help you there - I think
Mike misunderstood your question - or I do.
winfo interps will just show you, which further Tk-apps are
running on the same desktop - regardless whether local or remote.

PPS: I haven't got a terminal-server available, either for trying.