准备工作
我们需要一个具体的例子，一个实验工程myApp2，其主窗体如下：
其中，包含了3个元素：一个button，一个蓝色的panel1，以及一个黄色的panel2，所有控件元素其它属性都是默认的。在这一个实验之中，您还需要在myApp2之中添加如下两个对象：
很显然，myApps编译之后，运行时会出现如下窗口：
所有64-bit WinForm应用都是浏览器
2025年12月25日，我们在"博客园"发布了
"所有64 位WinForm 应用都是Chromium 浏览器"。
该篇文章，明确的表达了如下观点：
原生代码编译的终点，是Web生态的起点
这意味着------您完全没必要修改代码，也无需改变已经完成编译的应用，您仅需要确保原生代码顺利编译、可以正常运行，您就可以直接为编译之后的WinForm应用写无限数量Web应用。
.NET UI对象与Chromium Tab Group的绑定
.NET UI对象泛指WinForm窗体、User Control以及WPF控件。一个设计时插入到WinForm窗体的.NET UI对象，在运行时成为一个"Chromium Tab Group "之中某一个"Chromium Tab "的一部分，我们称之为该.NET UI对象与"Chromium标签组"建立了绑定关系。如下图我们看到的"设计时"黄色的panel2：
运行时，panel2成为"Chromium Tab"的一部分：
WinForm窗体之中的DHTML
我们知道：
1、 每一款WinForm应用，会存在一组"WinForm"窗体；
2、 每一个WinForm窗体，都会包含一组"控件"；
3、 每一个控件，都会有"Dock"属性。
在一个WinForm窗体之中，如果存在Dock属性为
"DockFill "或者"DockNone"
的一组控件，我们将WinForm窗体之中的这个"控件组"，称为WinForm窗体的"动态内容组"。我们的结论是，对一个WinForm窗体：
1、 "动态内容组"之中的每一个控件，都可以动态绑定一个"Chromium标签组"，不必设计时嵌入CEF、WebView2，而是运行时绑定"浏览器标签组"；
2、 一旦其中的一个控件建立了与"Chromium标签组"的绑定关系，那么，"动态内容组"之中的其余控件将与Chromium标签组解除绑定。
3、 一个控件与"Chromium标签组"之间的捆绑关系，意味着该控件与一组Web页面建立了互操作关系。在这一组页面之中，可以利用DHTML技术控制"动态内容组"之中控件窗口矩形的无限数量的"环绕布局"。
我们先看一看具体的控件绑定**"Chromium标签组"**场景，如下图所示：
（Creator Runtime并不是通过设计时插入CEF、WebView2之类技术支持页面，而是运行时借助于Dock属性完成web页面的动态绑定）
在这一个"绑定"场景之中，黄色的panel2，成为浏览器标签之中的成员，并且与Web页面共同分享同一个"Chromium Tab "。与此同时，panel1 、panel2 的窗口矩形外围，都出现了myApp主窗体设计时，没有包含的"环绕内容"。这些环绕布局，都是通过"Chromium 标签组"之中的Web页面，利用DHTML技术实现的。
借助于DHTML以及Javascript技术，我们可以利用panel2与"Chromium标签组"的绑定关系，在panel1、panel2的外围，创建丰富的"内容层"：
（想想看，如果您的客户需要运行时，在您开发的窗体右侧动态插入一组元素。您会怎么处理？）
Creator Runtime
Creator Runtime 是一款"有身无脑 "的Chromium浏览器 ：没有等价于"Chrome.exe "的主进程可执行文件，所以它只能等待被其它64位应用以"浏览进程的方式唤醒 "，进而提供创建Renderer等子进程的能力。一个关键的问题是：谁可以承担其缺失的"大脑(Chrome.exe) "，进而成为其"主进程（浏览进程）"角色？答案是------任何一款64位WinForm应用。
对编译后的64位WinForm应用 ，Creator Runtime 的责任是完成"有脑无身 "与"有身无脑"的结合：
1、 将WinForm应用，视为一款"有脑无身 "的现代浏览器。通常情况下，WinForm应用处于默认的状态，无法创建Renderer、GPU等"子进程"，进而不具备现代浏览器的"多进程架构"
2、 通过"文件级组合 "操作，让WinForm应用获得"Chromium浏览进程身份"，拥有创建Renderer、GPU等子进程能力，进而成为完整Chromium浏览器。
您可以访问：Creator下载Creator Runtime安装包。安装Creator之后，会在Windows桌面之上创建一个"快捷方式"：CreatorAppLoader，这一个快捷方式会创建如下一个窗口：
如果将一款WinForm应用的可执行文件AppName .exe，拖入如上窗口之中，会完成：
1、 将Creator安装文件夹之中的"proxy.exe "复制为"AppName.exe 所在文件夹的AppNameProxy.exe"；
2、 创建初始化Web页面"AppName.app.html"；
3、 创建一个新的"快捷方式"用来启动"AppName.exe"。
"Proxy.exe "是一个EV签名 、尺寸不足160k的启动器（Loader），提供完整的源代码。如果您打算编译自己的版本，那么，您需要自己完成"EV签名 "，进而符合"安全 、防病毒"软件的审核。如果您熟悉Chromium Project的源代码，可以研究我们即将发布的源代码，进而分析Proxy.exe的工作原理，
AppNameProxy.exe 启动AppName.exe 之后，会自毁退出，不参与AppName.exe 实际运行。在运行时，AppName.exe 会完成标准Chromium浏览器的初始化流程，进而获得了Chromium Project规定的全部能力。那么，AppName.exe 会不会失去什么？这一点无需担心，由于AppNameProxy.exe先启动AppName.exe ，所以，AppName.exe完整功能得以保留，Chromium的完整流程也会正常的展开。其结果是，您编译的AppName.exe，正常的占据了Chrome.exe的位置。
Creator Runtime解决什么问题？
编译之后的WinForm应用创建现代浏览器窗口
对独立的WinForm应用而言，Creator Runtime解决了该应用可以创建任意数量与"Chrome同宗同源的浏览器窗口 "问题。这意味着，WinForm应用可以如同Chrome、Edge一样，浏览互联网，同时还可以创建任意数量的"超级Chromium浏览器窗口 "------一类支持"原生桌面窗口组合"的Chromium Browser Window：
那么，这些独立"浏览器窗口 "意味着什么？答案是：一旦您的应用与"Creator Runtime"成功的"对接"，那么，您的应用在技术架构上，就处于"Chrome"相同的Level，Chrome拥有的一切能力，您的应用都会拥有。
编写面向应用的Web页面
在应用维度方面，你的应用可以支持任意数量"Native-Web "组件形成的"混合扩展Web页面"，这意味着：
1、 标准Web页面元素；
2、 应用本身包含的对象（应用内部的WinForm、UserControl、WPF等对象）；
3、 大量的、符合工业标准的WinForm组件、WPF组件、UserControl；
都成为Web页面之中的html元素，开发者可以在页面之中充分运用JavaScript技术：
1、 将这些超级html元素结合在一起形成表现力强大的浏览器窗口、WinForm窗体；
2、 处理这些对象的原生事件，形成有价值的Web互操作。
以下一组截图显示的就是".NET User Control、WinForm窗体等.NET UI"与标准html元素混合编写的"扩展Web页面"：
毫无疑问，"Native-Web混合扩展Web页面 "，会为WinForm应用提供无穷无尽的基于Web技术动态生成的"应用内容"，进而充分的利用Web技术的弹性以及JavaScript脚本的灵活性，形成强大的"应用内容生态"。这是一个前所未有的应用"升维 、增值"模式。
Dock属性与"Chromium标签组绑定"
在本文开始阶段，我们给出了WinForm窗体之中的"动态内容组"概念，一个前所未有的视角出现了------"动态内容组"之中的每一个**"控件"**：
|------------------------------------------------------------------------------------------|
| 可以"动态绑定一个Chromium标签组"，进而与一组Web页面建立了直接互操作关系，这与编译前在特定窗体之中嵌入CEF、WebView2等技术，形成了完全不同的模式。 |
如下图所示，我们看到了黄色的panel2"绑定一组扩展Web"的实际场景：
在一个WinForm窗体之中，如果某一个**"控件绑定了Chromium标签组** "，那么，其中的Web页面的"Web DOM"作用域会"外溢"，进而使得WinForm窗体之中"动态内容组"之中的其它"控件"的外围，出现任意数量的"动态、环绕内容层 "，这就是如上图之中，您看到的蓝色的panel1外围，出现了"新的内容结构"。每一个"动态内容层"，都是"扩展Web页面之中的html元素"，开发者可以基于html的规则，利用JavaScript脚本，充分的控制这些动态内容结构，进而使得WinForm窗体成为超级强大的"DHTML"载体。
我们以myApp2为例。现在，启动Creator Runtime 的"CreatorAppLoader"：
并将刚刚创建的myApp2编译的"myApp2.exe"拖入上述窗口，你会获得应该新的"快捷方式 "，并且为您的应用创建应该"初始化Web页面myApp2.app.html "。按照这一个"快捷方式"启动myApp2，您就可以看见panel1外围的"环绕内容结构 "，您不仅会看到最外层的"标签"，还可以看到"Common AIGC for Desktop Application "标签之内的"Chromium标签组"，如下图所示：
关于"main_form_client"
一旦"CreatorAppLoader "为您的myApp2.exe生成了默认的"myApp2.app.html "，页面之中会有一个mainWindow元素，这一个元素有一个"子元素main_form_client"。这一个元素对应的是您主窗体之中，第一个Dock属性为DockFill或者DockNone的控件。
在具体的应用之中，您应该将这一个"html标签"的名字（main_form_client），修改为具体的、您需要绑定"Chromium标签组"的控件的"控件名"。如果您不清楚设计时"控件名"，可以借助于.NET Framework提供的"ildasm"工具查看：
"panel2"能否绑定"Chromium标签栏"？
如果您认为"标签栏 "应该显示在"黄色的panel2"外围，关闭myApp2的主窗体，打开"myApp2.app.html "，找到<mainWindow >页面标签，并将"main_form_client "修改为"panel2 "，重新双击"快捷方式"即可看到：
现在，我们可以归纳一下：一个完成编译的应用之中，如果您选择一个窗口作为"浏览器窗口"，您需要在窗体之中选择一个Dock属性为"DockFill"或者"DockNone"的控件，用于绑定"Chromium标签组"，其标签栏的结构参考默认生成的".app.html"初始化页面。您的窗体设计时如有控件panel3，或者其它控件，例如一个名字为"xyz"的控件，当其Dock属性为"DockFill"或者"DockNone"，您可以按照如上的方法，将mainWindow元素的子元素panel2的名字修改为"panel3"或者"xyz"，将"浏览器标签栏"与WinForm窗体之中的panel3或者xyz控件"绑定"。
从静态WinForm窗体到"动态窗体"
现在，新的问题来了：如果您将标签栏 绑定在panel2，那么，panel1会不会就不能"动态布局了"？ 我们可以在"mainWindow"元素之内，将子元素"panel2"复制一次，并重命名为"panel1"，如下图：
需要注意的是：现在，mainWindow之中，panel1、panel2仅仅是"名字不同"。那么，重新双击"快捷方式"，我们会看到什么？结果如下：
这当然不是我们希望的。我们回到页面"myApp2.app.html"，重新看"mainWindow"的结果，我们发现，panel1、panel2元素之中，都存在caption属性为"Common AIGC for Desktop Application"的元素，我们分别将这些"caption"属性后面添加序号，并且将panel1之中这一个xobj元素的"url"属性删除，同时增加"objid='nucleus'"属性，如下图：
重新双击"快捷方式"启动myApp2，您差不多可以预期：运行时，"蓝色的panel1"，当然在周围出现了"动态环绕布局"：
以上的实验表明，xobj的"objid='nucleus' "属性启动panel1控件是否显示，而xobj的url属性，决定了"标签栏"的位置。
通过myApp2这一个实验例子，我们可以获得如下直观的信息：
1、 每一个WinForm窗体之中的Dock属性为"DockFill"或者"DockNone"的控件，都在Web页面之中，对应一个包含xobj元素"树"的Web页面元素，xobj对象树的结构，决定了这一类控件外围的"环绕内容层"；
2、 很显然，对"动态内容组"之中的每一个"控件"（Dock属性为"DockFill"或者"DockNone"的控件），环绕内容层的数量，与"xobj元素对象树"形成直接的对应关系，这一点可以在运行时，动态的基于场景，让控件的外围环绕结构，产生针对性的变化；
您可以通过阅读"问世间，exe是何物？直教AI沉默、Web寡言（4）"，进一步了解xobj元素的递归结构，进而，您会看到WinForm窗体的"DHTML"特征。
在后续的文章之中，我们会系统的揭示WinForm应用之中的DHTML技术。