Avoiding Multiple Instances of an Application

One of the interesting points that was raised by one correspondent, Daniel Lohmann is that the term "multiple instance" was not well-defined in an earlier version of this essay. He points out that "multiple instance" can mean different things in the  multiuser environment of NT. He points out that it is possible to use API calls such as LogonUser, CreateProcessAsUser, CreateDesktop and SwitchDesktop, and therefore it is possible to have multiple users and multiple desktop sessions running under different accounts.

Therefore, there are several issues about why one would not want multiple instances of an application. He categorized them as

1. Avoiding multiple instances started in the same user session, no matter how many desktops that user session has, but allowing multiple instances to run concurrently for different user sessions.
2. Avoiding multiple instances started in the same desktop, but allowing multiple instances to run as long as each one is in a separate desktop.
3. Avoiding multiple instances started for the same user account, no matter how many desktops or sessions running under this account exist, but allowing multiple instances to run concurrently for sessions running under a different user account.
4. Avoiding multiple instances started on the same machine. This means that no matter how many desktops are used by an arbitrary number of users, there can be at most one instance of the program running.

He observes that many programmers actually mean (a), and sometimes mean (b) or (c). The technique outlined in the earlier version of this essay always interpreted the question as (d). Note that in the case of Win9x/Millenium, only (d) exists, since there is only one user session and one desktop per machine.

Thus, as you read the essay below, be aware that we are answering only (d) using this technique. Afterwards, I will present his proposed solutions for being able to extend this technique to include (a)-(c). He observes that certain "service-oriented" applications that fit into the class of (d) are often better done as System Services. The service may be started on-demand or at system startup, but all users and all desktops share the same common service.