[dspillett]

It wasn't usually a performance problem because before you hit that point you hit a more simple resource problem: up to and including Windows 95¹, GDI had significant 16-bit internals (at least partly, I assume, for compatibility with older apps), and there was a limit of 16,384 HWNDs and so that 16,384 active objects of any type that needed a HWND. This could be a noticeable limit if running a number of certain apps at once anyway, but some apps had a habit of "leaking" handles making it more common to run into.

IIRC this limit never applied to the NT family (NT, 2000, XP, …).

--

[1] I can't remember if this was resolved at all in the 98 releases, I imagine not

[grumpyprole]

I remember running into this quite often. Apps would fail to draw completely and malfunction.

[Narishma]

Do you know why they made those handles public instead of private to each app?

[dspillett]

In the early days there was little need, nothing big enough to need that many would fit in the rest of the machine anyway.

Also they were global so apps could communicate - the message queue was based on sending things to window handles, and the more advanced IPC methods like DDE and so forth were built on that. It is also how anything that interested with the task list or interacted with the desktop (adding decorations to windows etc.) functioned. This doesn't work if local handles can conflict with those in the other app.

The amount of things that depended on HWNDs working this way is probably a significant part of why large chunks of GDI remained 16-bit in Windows95 despite things like the limit of 16,384 handles being an issue you could run into relatively easily by that point - too many existing apps & tools would have broken otherwise and limited people's desire to upgrade from 3.x.

So a combination of "no point introducing extra complexity, at least early on", "the global pool is actually useful", and "once it was done that way, it was very hard to refactor without breaking compatibility with much of the existing application base".

I think the compatibility layers on later versions did start separating the apps more, once breaking things was less of an issue (new versions existed that were directly compatible with newer APIs) so segregating the apps for stability reasons won out over being quite as backward compatible.

[lmz]

Windows can be interacted with cross process e.g. send an event to a window owned by another process, have a child window owned by another process etc.