I have a grievance with some programs that host many separate instances (main windows) hosted by a single process.
On the plus side, you can get some good perf wins from this. One process can host many windows. (I think of this as the evolution of MDI, although that's not quite accurate). The code should be read-only pages and should be shared either way by the OS. However, sharing the process also gives you a chance to share data, threads, and process startup.
On the down side, when one instance hangs or crashes, everything goes down. And if any other programs are hosting this app, then those program may hang too. The big mitigation is "Task Manager : End Process" to kill the hanging app, but Window often struggles to kill a hung process.
From the end-users perspective, it becomes a performance vs. reliability tradeoff.
Consider a real example:
Word shares a single process. You can verify this by seeing one instance of "WinWord.exe" in the task manager even when you've got many Word windows open. Or you can use Spy++. You can see other evidence of this:
- the "Window" menu lists all open word documents.
- changing settings in one instance affect other instances. For example, changing the current color on the "Font Color" button in one instance shows up in all instances.
Obviously, that sharing could still be done if each instance of Word had its own process since processes can communicate with each other; but it likely suggests the data is shared in a single-process.
Now when one instance of Word hangs, all instances hang. Furthermore, Outlook may host Word as an email editor. This means that when Word hangs, Outlook empirically hangs. Since I've been living in Word lately, I'll commonly have literally 15 instances of Word or emails open, I've started noticing this.
The bottom line:
If you are going to host many instances of an app within one process, be very careful about using shared state, including common threads, locks, and other synchronization.