Any reason Session ID = 1 instead of 0 on Vista?

  • Thread starter Thread starter Joseph Geretz
  • Start date Start date
J

Joseph Geretz

For as long as I can remember, Session ID for a console session has been 0.
We use this value to identify when our software is running from the console,
or running from within a TS or Citrix session. For a variety of reasons, we
need to know.

Anyway, I'm finding that Vista assigns Session ID of 1 to the console
session. Any reason for this, or just for the purposes of ensuring minimal
backward compatibility?

Thanks,

- Joe Geretz -
 
Joseph said:
For as long as I can remember, Session ID for a console session has
been 0. We use this value to identify when our software is running
from the console, or running from within a TS or Citrix session. For
a variety of reasons, we need to know.

Anyway, I'm finding that Vista assigns Session ID of 1 to the console
session. Any reason for this, or just for the purposes of ensuring
minimal backward compatibility?
Click to expand...

It's done for a reason. If you read the old new thing blog at
http://msdn.microsoft.com/oldnewthing you'll see that whatever other
numerous faults we can assign to Microsoft, going around changing important
system parameters just for a giggle to see how many apps they can break in
one day isn't really one of them.

http://www.realvnc.com/pipermail/vnc-list/2006-December/056565.html might be
of interest to you also.
 
In message <[email protected]> "Joseph Geretz"
For as long as I can remember, Session ID for a console session has been 0.
We use this value to identify when our software is running from the console,
or running from within a TS or Citrix session. For a variety of reasons, we
need to know.

Anyway, I'm finding that Vista assigns Session ID of 1 to the console
session. Any reason for this, or just for the purposes of ensuring minimal
backward compatibility?
Click to expand...

It's part of the process isolation changes in Vista -- Previously, it
was often possible for an app running under Session ID 0 to directly
communicate with services and potentially trick the service into doing
something inappropriate.

Moreover, this change is required for switch user to work.
 
Anyway, I'm finding that Vista assigns Session ID of 1 to the console
Not quite correct. A console session can be any session other than 0. As for
why the did that...

Short answer: This was done to isolate services from interactive
applications and prevent services from being hacked by end users.

Longer answer:
http://www.microsoft.com/whdc/system/vista/services.mspx

I don't think identifying console sessions versus terminal server sessions
is really a good plan. With Fast User Switching (which works in a domain in
Vista) any session that is local can actually be a terminal services session.
If you have to do it maybe the better option is to look for the session that
hosts smss.exe or csrss.exe, or one of the other services? I don't know of an
API that lets you identify the origin of a session.

It's done for a reason. If you read the old new thing blog at
http://msdn.microsoft.com/oldnewthing you'll see that whatever other
numerous faults we can assign to Microsoft, going around changing important
system parameters just for a giggle to see how many apps they can break in
one day isn't really one of them.
Click to expand...

Robert, that link doesn't work.
 
I don't think identifying console sessions versus terminal server sessions
is really a good plan.
Click to expand...

We need to identify the workstation that the user is on (i.e. the physical
device with the keyboard and mouse attached). With a workstation (whether or
not fast user switching is in play) it's going to be the workstation the
application is actually running on. With a Terminal Server, it's a different
device altogether, it's the client PC, not the machine which is hosting the
application process. (I'm not at work and so I don't recall offhand the
different function calls for the different scenarios.)

This is the major reason we need to differentiate. On the other hand, if you
know of an API call such as GetUserWorkstation which does this transparently
for us then we wouldn't need to worry about it ourselves explicitly.

Thanks,

- Joseph Geretz -
 
Joseph Geretz said:
For as long as I can remember, Session ID for a console session has been
0. We use this value to identify when our software is running from the
console, or running from within a TS or Citrix session. For a variety of
reasons, we need to know.
Click to expand...

That sounds dangerously like "we need to do it because we've always needed
to do it, and now that we can't do it, rather than revisit whether we really
need to do it, we need to find a different way to do it".

You may have a valid reason, but I just have to ask the question - for
natural curiosity, if nothing else - why do you feel that you need to
differentiate between running your software at the workstation and running
your software via a terminal link?

Alun.
~~~~
 
This is the major reason we need to differentiate. On the other hand, if you
know of an API call such as GetUserWorkstation which does this transparently
for us then we wouldn't need to worry about it ourselves explicitly.
Click to expand...

Sorry, I don't know whether such an API exists. There are APIs for
OpenWindowStation which may help, but that's all I know. I'd suggest trolling
the SDK and see what you find. I'd also be curious to know whether you find
anything.
 
Jesper said:
Sorry, I don't know whether such an API exists. There are APIs for
OpenWindowStation which may help, but that's all I know. I'd suggest
trolling
the SDK and see what you find. I'd also be curious to know whether you
find
anything.
Click to expand...

You could check for the existence of the environment variable "CLIENTNAME",
which will tell you in Citrix and TS sessions what computer was used to
connect in (contrast this with COMPUTERNAME. It generally won't be available
in a session tied to the console - but it might be created, there's nothing
preventing it - a user might say "set clientname=jim" for random reasons.

For TS alone, you could call WTSGetActiveSessionId and compare it to the
result from WTSQuerySessionInformation, as specified in the spec for
WTSQuerySessionInformation. I don't know whether this will work for Citrix
(but I wouldn't be surprised if it does).

Alun.
~~~~
 
Hi Alun,
natural curiosity, if nothing else - why do you feel that you need to
differentiate between running your software at the workstation and running
your software via a terminal link?
Click to expand...

We need to identify the workstation that the user is on. Since this
information is derived differently depending on whether the process is
running on a workstation or within a Terminal Session, we need to know.

Also, we've identified certain features within our code which run
differently on TS than on a workstation. These are few and far between,
however we need to distinguish between these different environments in order
to avoid problems.

BTW, I am able to do this. With a little bit of recoding to account for how
the rules of the game have changed for Vista, I can accommodate both Vista
and pre-Vista conditions.

- Joseph Geretz -
 
Back
Top