原文链接：https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36183
（译注：我深知这一篇的翻译质量应该很差，看不下去的话请直接跳过……）
Although Windows is centered around, well, windows, a window itself is not a cheap object. What’s more, the tight memory constraints of systems of 1985 forced various design decisions.
尽管 Windows 是围绕着窗体（windows）设计的，不过窗体并不是便宜大把的对象。此外，1985年硬件配置中紧俏的内存限制催生了很多被迫的设计决定。
Let’s take for example the design of the list box control. In a modern design, you might design the list box control as accepting a list of child windows, each of which represents an entry in the list. A list box with 20,000 items would have 20,000 child windows.
以 Listbox 控件的设计为例。在如今的设计理念中，你可能会将其设计为包含一列子窗体的控件，每个子窗体代表列表中的一个条目。一个拥有20000项条目的 Listbox 就会有20000个子窗体。
That would have been completely laughable in 1985.
这种设计在1985年会让人笑掉大牙。
Recall that Windows was built around a 16-bit processor. Window handles were 16-bit values and internally were just near pointers into a 64K heap. A window object was 88 bytes (I counted), which means that you could squeeze in a maximum of 700 or so before you ran out of memory. What’s more, menus hung out in this same 64K heap, so the actual limit was much lower.
回忆一下，当时 Windows 是围绕16位处理器设计的。窗体句柄是一系列16位的值，在内部则表现为一个 64K 堆中相邻的指针。一个窗体对象要用掉88个字节（我数过了），这就意味着你最多能在内存里塞下700个窗体，再塞就要内存溢出了。另外，菜单也在同一个 64K 堆中，故而实际的上限可能会更低。
Even if the window manager internally used a heap larger than 64K (which Windows 95 did), 20,000 windows comes out to over 1.5MB. Since the 8086 had a maximum address space of 1MB, even if you devoted every single byte of memory to window objects, you’d still not have enough memory.
即便窗体管理器在内部使用的是一个大于 64K 的堆（Windows 95即是如此），20000个窗体也要消耗将近 1.5MB 的空间。由于 8086 处理器的地址空间上限是 1MB，就算你将内存的每一个字节都贡献给窗体对象使用，还是没有足够的内存可以用。
Furthermore, making each list box item a window means that every list box would be a variable-height list box, which carries with it the complexity of managing a container with variable-height items. This goes against two general principles of API design: (1) simple things should be simple, and (2) “pay-for-play”, that if you are doing the simple thing, you shouldn’t have to pay the cost of the complex thing.
除此之外，让每一个 Listbox 的项目都作为一个窗体，意味着每个 Listbox 都会是高度可变的，这就带来了管理包含着可变高度项目的容器的复杂性。如此的设计违背了 API 设计的两项基本原则：（1）简单的事物就应该简单，以及（2）『办多少事花多少钱』，也就是如果事情本身就很简单，便不应当为复杂的事情付出代价。
Filling a list box with actual windows also would have made the “virtual list box” design significantly trickier. With the current design, you can say, “There are a million items” without actually having to create them.
将一个 Listbox 填满事实意义上的窗体，也会将这个『虚拟 Listbox』的设计变得陡然复杂起来。按照其目前的设计，你可以声明『列表中有一百万项』，但不必实际去创建这么多项目。
(This is also why the window space is divided into “client” and “non-client” areas rather than making the non-client area consist of little child windows.)
（这也是为什么窗体控件被分割为『工作区』和『非工作区』，而不是让非工作区也填满了小小的子窗体的缘故。）
To maintain compatibility with 16-bit Windows programs (which still run on Windows XP thanks to the WOW layer), there cannot be more than 65536 window handles in the system, because any more than that would prevent 16-bit programs from being able to talk meaningfully about windows. (Once you create your 65537’th window, there will be two windows with the same 16-bit handle value, thanks to the pigeonhole principle.)
为了维持与16位Windows应用程序的兼容性（鉴于WOW（译注：Windows-On-Windows，在新版Windows上为面向旧版系统设计的应用程序提供有限兼容性的兼容层，此处为32位系统兼容16位应用程序）层，这些程序在 Windows XP 上仍然可用），系统中的窗体句柄不能超过65536个，因为超过这个限制会阻止16位应用程序与系统对窗体进行有意义的沟通。（一旦创建了第65537个窗体，就会出现具有相同句柄值的两个窗体——感谢鸽巢原理（译注：又叫抽屉原理，指如果尝试将n+1个元素放进n个集合中，那么必然有一个集合中包含2个元素）的存在。）
(And yes, 16/32-bit interoperability is still important even today.)
（另外没错，16/32位应用程序的交互操作性，时至今日仍然很重要。）
With a limit of 65536 window handles, your directory with 100,000 files in it would be in serious trouble.
鉴于65535个窗体句柄上限的存在，你那拥有10万个文件的目录（如果按照前面那样嵌套小窗体的设计）就会有大麻烦了。
The cost of a window object has grown over time, as new features get added to the window manager. Today it’s even heftier than the svelte 88 bytes of yesteryear. It is to your advantage not to create more windows than necessary.
随着新功能不断加入窗体管理器，窗体对象的成本也在不断攀升。如今窗体数据的健壮程度已与当年那个苗条的88字节大小不可同日而语，而不要创建多于必要的窗体的责任就落在了你的肩上。
If your application design has you creating thousands of windows for sub-objects, you should consider moving to a windowless model, like Internet Explorer, Word, list boxes, treeview, listview, and even our scrollbar sample program. By going windowless, you shed the system overhead of a full window handle, with all the baggage that comes with it. Since window handles are visible to all processes, there is a lot of overhead associated with centrally managing the window list. If you go windowless, then the only program that can access your content is you. You don’t have to worry about marshalling, cross-process synchronization, Unicode/ANSI translation, external subclassing, hooks… And you can use a gigabyte of memory to keep track of your windowless data if that’s what you want, since your windowless controls don’t affect any other processes. The fact that window handles are accessible to other processes imposes a practical limit on how many of them can be created without impacting the system as a whole.
如果你的程序设计需要你创建成千上万个用于内部对象的窗体，你应当考虑迁移到无窗体的模型，就像 Internet Explorer、Word、Listbox、TreeView、ListView，甚至我们的滚动条示例程序那样。通过使用无窗体设计，你的程序向系统展示的就只有一个完整的窗体句柄，里面包含着所有大大小小的元素。由于窗体句柄是对所有进程可见的，对于集中管理的窗体列表来说负担是很重的。如果采用无窗体设计，那么唯一可以访问窗体中内容的就是你自己。你不必担心 Marshalling、跨进程同步、Unicode/ANSI 转换、外部子类、钩子…… 等等的麻烦事。另外如果你愿意，动用一个G的内存来跟踪你的无窗体模型下的内容也是刻意的，因为你的无窗体模型中的控件不会影响其它进程。由于窗体句柄对其他进程是可见的，也就对可以创建多少个窗体句柄而不会对系统整体产生重大影响这一事实施加了影响。
I believe that WinFX uses the “everything on the screen is an element” model. It is my understanding that they’ve built a windowless framework so you don’t have to. (I’m not sure about this, though, not being a WinFX person myself.)
我相信 WinFX 利用了『屏幕上的一切都是元素』这种模型，我的理解是他们构建了一个无窗体框架，以便你不用再从头造一遍轮子。（尽管对此我并不确定，毕竟我不是相关人士。）
远嚣 Comment