Err. You're actually correct there, provided the app follows the rules. MFC wizard-generated multi-SDI applications don't, interestingly.

One potential problem is that Win32 message loops have thread-affinity, and Win32 windows have thread-affinity (it's this way by default as a Win16 backwards compatibility thing), meaning that it's possible for the modal message loop to mess up the other windows in the thread anyway.

Similarly, if a process doesn't make good use of background threads or asynchronous operations, it'll block the UI thread, whether there's a modal window open or not (assuming a single UI thread, which is the model for most Win32 applications).

Thus, one-process per top-level window is my preferred way to implement this. You get sandboxing; you get more address space (assuming 32-bit), and you don't have to waste too much memory, because Windows shares pages when it can. You shouldn't even need to worry about using the clipboard between processes, because Windows data objects have that covered. Although, ironically, it seems that Excel's mildly broken here, too.