谷歌Chrome和IE8（以及其他）旨在通过在单独的过程中隔离每个标签（网页）来提供更高的可靠性/稳定性（过度简化，我知道）。
这似乎比多线程更重量级，但在一个进程中崩溃的主要好处是不会导致整个应用程序崩溃。
似乎多进程架构长期以来一直用于服务器端应用程序（例如Web服务器），但这些是没有专用GUI的进程。有趣的是，它现在被用于桌面应用程序的用户界面。
如何在Windows Forms .NET应用程序中实现此功能？它甚至可能吗？
Process.Start（）显然是第一个看的地方，但新进程的GUI没有与主机应用程序的GUI紧密集成。它是一个新的独立应用程序，而不是主机应用程序的子控件/窗口，就像Chrome / IE8一样。
（对于任何有兴趣的人，Scott Hanselmann都会为IE8 multi-process architecture here写一篇很好的介绍。）
[更新]
更具体地说：
单独的“子流程”如何直接呈现给“主流程”中的UI？这实际上是发生了什么，或者正如评论中所建议的那样，子流程是否使用IPC来请求主流程为其呈现？
答案 0 :(得分：5)
Google Chrome正在使用命名管道进行进程间通信。
这里有一些有趣的文件： http://dev.chromium.org/developers/design-documents
有关使用“.net”命名管道的更多信息，只需google it。
@Ash： 子进程在单独的Windows“桌面”中运行，这意味着它们无法显示任何内容。 （桌面是一件棘手的事......） 因此，我必须假设子进程渲染的所有内容都必须通过IPC。然后主（？）进程显示它。
我在这里找到了单独的Windows“桌面”的东西： http://dev.chromium.org/developers/design-documents/multi-process-architecture
答案 1 :(得分：3)
在.NET中使用多个进程的更好选择是使用多个AppDomain。这样做的好处是只创建一个实际的Windows进程，但仍然提供了多个区域的额外稳定性（即一个AppDomain中的崩溃只会使那个崩溃，而不是整个应用程序。）
与此相关的成本，因为对象需要跨AppDomain边界序列化。但是，开发可能比多进程模型更容易。
答案 2 :(得分：1)
btw ... dup
参见：Windows Forms application like Google Chrome with multiple processes（Jon Skeet的回答：o）
（我认为这也回答了“更具体”的部分）