Windows are not cheap objects
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.
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.
That would have been completely laughable in 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.
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.
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.
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.
(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.)
(And yes,
16/32-bit interoperability is still important even today.)
With a limit of 65536 window handles, your directory
with 100,000 files in it would be in serious trouble.
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.
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.
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.)
