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