Regular application has no problems with showing its GUI to user. An application starts and its forms becomes visible. It looks very simple and natural, like the scheme below:
In fact there are some important details that were not visible on this scheme. First of all there are things such as Desktop. Only one desktop is visible for user at the same time but is is possible to have many desktops. Desktops can be switched so one desktop becomes visible to user while previous desktop hides:
Desktop switching occurs, for example, when you press Win+L to switch to another user without logging off previously logged on user:
Another example is RDP monitor. When user logs on remotely with RDP it receives its own desktop. In the case of Windows workstation version the logon screen is shown on the main (local) display. If local user logs on then RDP connection closes. In the case of Windows server with terminal services turned on many RDP users are allowed and everyone of them has its own desktop:
Multiple visible and invisible desktops compose a first problem for "interactive service". While regular application shows its GUI on default desktop that is visible to the logged on user the service application have to care about desktop choice itself:
Here the problem begins. The diagram shown above can not be implemented directly. The thing is that every desktop belongs to one or another Window Station and process can interact with one Window Station only:
In addition one thread of process can interact with one desktop only:
Unfortunately it means that service application can not show forms or tray icons to several users at the same time.
Ok, what about one user, the locally logged on user? How was it possible to create interactive service before Vista? Let's continue...
Copyright:
