Logging on a user
in [Win32 API]
|
Prev: GetFileTime on usb driver return 0 and does not fail
Next: To avoid call WSAStartup function in every class of DLL
From: Sebastian G. on 4 May 2008 10:32 Alex wrote: > Stefan Kuhr wrote: >> Exactly. > > Thanks > >> It is a WindowStation that is associated with a process that is ... >> well.... ummhh, interactive. It can be operated by a human being using >> keyboard and mouse and has a display surface attached. If someone else >> has a better definition I'd be glad to hear it, so far this is probably >> a trivial one and the only one I can come up with. >> >> Technically speaking, you can differentiate interactive versus >> non-interactiv ewindowstations by calling GetUserObjectInformation with >> the UOI_FLAGS parameter. This will return a USEROBJECTFLAGS struct and >> you can examine the dwFlags struct member. If it has the WSF_VISIBLE >> flag set, it is interactive. > > Thanks for the explanation, so one of the major differences (the only?) > seems to be that an application cannot switch to desktops of window > stations other than Winsta0, correct? A privileged application can. An unprivileged application can't even switch to other desktops. I already explained the difference: Application can send Window messages to all applications on the same desktop, and to consenting application on different desktops in the same WindowStation, but not to different WindowStation. This and that non-virtual devices can only be assigned to one WindowStation. > Okay, so while desktops of non-interactive window stations cant actually > access the system's input/output devices it technically still can > process input and provide also "virtual" output (virtual as in not > displayed but still internally rendered) - or will the creation of > windows fail as well? Seems to work quite well, since this is how Terminal Server is implemented. > Related to this I am having a similar question, what happens if an > application creates more than one window station? unprivileged application: access denied privileged application: you get a new non-interactive window station, and you have to switch between those for pulling off various actions privileged application on Terminal server: access denied, or system crash > So far I have the > impression it can always be only associated with one window station at a > time, right? You can still access other WindowStations via a handle. > So this would mean it would always have to switch to the > desired window station prior of accessing its desktops, wouldnt it? Depends on what you want to do. > I guess the same would apply to individual desktops. Depends on what you want to do, though sending messages to different desktops doesn't require switching.
From: Stefan Kuhr on 4 May 2008 15:16 Hello Alex, Alex wrote: > Stefan Kuhr wrote: >> > <snip> > Thanks for the explanation, so one of the major differences (the only?) > seems to be that an application cannot switch to desktops of window > stations other than Winsta0, correct? > In addition to what Sebastian wrote, which is all corect AFAI can see, as a response to this posting of yours, I even did that in a commercial product, which switched a service's windowstation from a noninteractive one running under a distinct user account to the one of the interactively logged in user (simply ignoring the fact that there can be many of them) temporarily and then back to the original one, while doing there temporarily administrative stuff that required interactivity. While I do not recommend this to anyone I had to do this under the constraints that I wasn't allowed to change anything with the setup of services in the product, let alone introduce a new dedicated service in the product, that would have allowed to do things much easier and much more elegant. At least, the mechanism still works for pre-Vista OS versions today and I never received any complaint or customer issue :-) and we are talking about a product that has millions of client licenses in numerous enterprise environments. So in general, switching windowstations actually works, if your process is privileged enough to do that. > > Okay, so while desktops of non-interactive window stations cant actually > access the system's input/output devices it technically still can > process input and provide also "virtual" output (virtual as in not > displayed but still internally rendered) - or will the creation of > windows fail as well? How should COM in the apartment model work for services if they couldn't even create windows in noninteractive winstas? Cheers, -- S
From: Stefan Kuhr on 4 May 2008 15:26 Hi Sebastian, Sebastian G. wrote: > Stefan Kuhr wrote: > > >> It is a WindowStation that is associated with a process that is ... >> well.... ummhh, interactive. It can be operated by a human being using >> keyboard and mouse and has a display surface attached. If someone else >> has a better definition I'd be glad to hear it, so far this is >> probably a trivial one and the only one I can come up with. > > > Actually it's just a type of object, which acts as a container for > desktops and can be associated with devices. In Windows' limited > architecture, only one WindowStation can map to the physical graphic > card, mouse and keyboard. You can still map WindowStation to interactive > users through Terminal Services. This for sure is a much better definition than the prosaic version of mine. Maybe we could refine it like so: "only one WindowStation can map to the physical graphic card, mouse and keyboard at the same time". What do you think would make "Windows' limited architecture" look less limited? > >> Technically speaking, you can differentiate interactive versus >> non-interactiv ewindowstations by calling GetUserObjectInformation >> with the UOI_FLAGS parameter. This will return a USEROBJECTFLAGS >> struct and you can examine the dwFlags struct member. If it has the >> WSF_VISIBLE flag set, it is interactive. > > > Which raises the question: Wouldn't this also be the case for > WindowStation associated to TS users on TS? > Try it :-) > > > But as long as they don't run on the same desktop as well, there's no > way to get a handle to the application window or its desktop for sending > a message. That is, to do communication, you need consent from potential > receiver, and the handle has to be acquired through some other IPC > mechanism. Isolation based upon WindowStation is just stronger in that > sense that even accidential consent (confused debuty problem) won't lead > to any undesired IPC through Window messages. Yep. This more or less explains what you wrote before: "This still doesn't explain any *need* for separate WindowStation for services." -- Stefan
From: Sebastian G. on 4 May 2008 15:59 Stefan Kuhr wrote: > What do you think would make "Windows' limited architecture" look less > limited? Allowing multiple devices to be divided among multiple interactive workstations, especially for displays. >>> Technically speaking, you can differentiate interactive versus >>> non-interactiv ewindowstations by calling GetUserObjectInformation >>> with the UOI_FLAGS parameter. This will return a USEROBJECTFLAGS >>> struct and you can examine the dwFlags struct member. If it has the >>> WSF_VISIBLE flag set, it is interactive. >> >> Which raises the question: Wouldn't this also be the case for >> WindowStation associated to TS users on TS? >> > > Try it :-) I got Windows 2003 R2 Enterprise Edition through MSDNAA, but this doesn't give me any TS license.
From: Pavel A. on 4 May 2008 19:21
"Sebastian G." <seppi(a)seppig.de> wrote in message news:686itfF2qk4toU2(a)mid.dfncis.de... > Stefan Kuhr wrote: > > >> What do you think would make "Windows' limited architecture" look less >> limited? > > > Allowing multiple devices to be divided among multiple interactive > workstations, especially for displays. > So it isn't possible to use 2 monitors in a TS session? --PA |