| Date: | March 15, 2005 / year-entry #65 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050315-00/?p=36183 |
| Comments: | 73 |
| Summary: | 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... |
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.) |
Comments (73)
Comments are closed. |
Does anyone know offhand what the size of a window object in CE is?
Great post. I miss the days of ‘lean’ development. Software is getting fat and lazy.
Does not having a window handle mean that you have to implement your own accessiblity features such as supporting a screen reader. I don’t have issues with that myself, but I sometimes use the Narrarator to make my computer talk for my kids.
As a developer, is this a tradeoff that needs to be considered when going windowless?
Here’s a question: Why are all window handles visible to all processes? Why not force you to set a flag bit that says "make this window handle visible to other processes", or, in the alternative, allow for a flag that says "this window handle is private"?
Wouldn’t this fix lots of security problems, where a flaw in any application makes it easy to spy on the data of every application? Only problem I see is screen-readers, as Matt pointed out.
It would seem this is what WinFX is moving toward, but re-implementing the whole thing at the same time.
James: Marking a window as "private" doesn’t help the window manager any – it still has to keep track of it. It is keeping track of the window at all that is expensive.
I don’t see why you’re bringing up the security aspect of window handles. I was writing about the memory cost.
Far too often I respond to posts in developer forums and on articles regarding this issue – like when someone uses several Control class derivatives (Windows Forms) or worse – a UserControl derivative – to form a checkered board with each square being a control.
I’ll have to remember this point and simply link to you.
Can you explain why controls (buttons, drop downs, etc.) were OS windows in the first place? It seemed like a lot extra effort for programmers (me) to build GUI applications where every control is a window.
Why weren’t "windowless controls" the default implementation, with Window handles being reserved for "actual windows" on the screen?
64,
This article isn’t talking about Win64. Plus, sooner or later the backward compatibility must be dropped. The cost of keeping 16 bit compatible with the 32 bit platform is acceptable. However, keeping 16 on 64 makes the cost change hands.
Besides, 32 bit will be around for a nice long time for those of you who just don’t want to get off your butts and write your code to conform to what it needs to be…or give you time to ween yourselves off your DOS games.
James
You thought windowed controls were hard to write – windowless cotrols are even harder.
For comparison, GEM 1.x (1985) had a 50-byte window structure, and allowed 8 windows in total, including the desktop. It should come as no surprise that in GEM, controls such as buttons and text boxes were not windows.
James, 64: the reason that 16-bit apps aren’t supported on x64 running in long (64-bit) mode is pretty simple. Virtual-8086 mode cannot be enabled in this mode. V86 mode is required for 16-bit support – I don’t think it works if you just set the code segment’s compatibility mode to 32-bit and the default operand size to 16 bits.
Whether achievable or not, it would have required a rewrite of 16-bit support, since 32-bit Windows uses V86 mode. It’s not worth it at this stage given that very few people regularly run 16-bit programs.
Luckily for we who care, GNU/Linuxes are cheap objects, as well as being Free!
They’re only free if your time has no value.
On the Amiga, all "controls" (called Gadgets) were window-less. Each window (the Amiga only had top-level windows, there was no child window concept) had its own linked list of Gadgets which the UI manager (Intuition) knew about and would take care of for you. You simply called a function to add the list of gadgets to the window and Intuition would handle the user interaction for you automatically, only passing mouse events and the like through that did not involve a gadget.
Yeah, MacOS Classic (1.0-9.2.2) worked the same way as Amiga. "Windows" were only actual windows on the screen while everything else were "controls." If the OS told your application that an event occured inside one of your windows, you were responsible for handling your own controls. (Of course, the API provided tons of functions to make this easy to do.)
Of course, these OSes were designed with a one megabyte system was almost unheard of… MacOS 1.0 shipped on a 128k machine, and that was a pretty high-end machine at the time.
No 16 bit apps? I’ve got a ton of command-line utilities I’ve written in Turbo C 2. Put me on the list of people who won’t be moving to 64-bit anytime soon. I have no desire to port those utilities to 32-bit.
As a developer this situation is amusingly paradoxical. If I wish to create an application that has so many control windows that it would overflow a 16 bit window handle I have to NOT use windows. So the Win16 app has nothing to enumerate anyway, and "compatibility" (app, not OS) is not achieved.
Hypothetically – All we really need is a WS_EX flag to CreateWindow that, for WS_CHILD windows, indicates an apps readiness to have a full 32 bit window handle returned. The window manager, (hypothetically remember), would never allow 16bit apps to see the 32 bit hwnds. Now the situation is the same. The 16bit app still can’t see my windows, but they look all themed and work real nice on XP without a lot of work from me :)
The system should not be encouraging a program to create 60,000 windows.
I don’t think Avalon really solves the huge scaling problem. It’s controls are still objects in a hierarchy. If you had 20,000 listbox items, you’d have at least 20,000 objects with a lot of duplicated state (font, color, position etc). In practice, probably a lot more since you’d like each item to be a composite of others (icon, text, checkbox etc).
So eventually, with Avalon, you’ll have to write your own hit testing and control stuff. Again.
Jon Potter,
Were gadgets really supported at the Intuition level? I didn’t spend much time developing GUI apps on the Amiga, but I thought all that came along in Kickstart/Workbench 2.0 with the gadtools.library, or something like that.
Then again, maybe I’m just getting my terminology mixed up. It’s been a while…
Jock, you’re right, but those are no longer OS level objects, they’re local to your app. I think the whole issue comes from the fact that Microsoft is encouraging everyone to create windows for eveyrthing, even for things that are not user interface, simply because they like to have their developers drag and drop code and you can’t exactly drag and drop something that is not a window. That’s why we have applications that have form windows that handle modem communications and so on.
And I wish IE actually went the windowless way instead of that hybrid model it uses today.
Jerry Pisk wrote:
—————————-
I think the whole issue comes from the fact that Microsoft is encouraging everyone to create windows for eveyrthing, even for things that are not user interface, simply because they like to have their developers drag and drop code and you can’t exactly drag and drop something that is not a window. That’s why we have applications that have form windows that handle modem communications and so on.
—————————-
Erm… I’m not sure what platform you’re talking about, or what development tools you’re using, but it certainly doesn’t sound like C++/Win32 to me.
Or do you think that dialog editors are equivalent to "drag and drop code"?
Actually, scratch that. I’m even more interested in whether or not you’ve actually ever developed using an IDE, or if you’re a Vi jockey who likes to pretend to be superior.
One nice(?) thing about creating child windows is that you can do cheap tricks to customize the interface by sending hide and size messages to windows in other applications. Sure, that’s not a very nice thing to do, but I’ve found it useful in the past for fixing little niggly things that really bug me.
Unfortunately, I don’t have a current example because right now all of my applications are serving me pretty well.
Simon,
I suspect he’s thinking of Visual Basic. I seem to remember that in older versions it was common to create little invisible windows in a form to create non-UI objects. It was, of course, cleaner to use the WithEvents thing to declare it in code, but that didn’t seem to stop people dragging and dropping the "Winsock Control" onto a form and accessing it like an ActiveX control.
I understand that since Visual Studio .NET such objects now float about in a little area at the bottom of the GUI designer, which seems like a good workaround to allow visual editing while not creating useless child windows.
Guh. Were designed *when* a one megabyte system was almost unheard of. Not with, when.
Ben Cooke: "Were gadgets really supported at the Intuition level? I didn’t spend much time developing GUI apps on the Amiga, but I thought all that came along in Kickstart/Workbench 2.0 with the gadtools.library, or something like that."
Yep. The basic gadgets equivalent to those in USER under Windows were all supported by Intuition right from Amiga OS 1.0. Version 2.0 added gadtools.library as you said which provided a few more complex gadgets (similar to the Windows common controls) and a basic OO system (BOOPSI) but the underlying OS support was there from the start and never really changed.
(This is all from memory as it’s been over 6 years since I programmed an Amiga so forgive me if I’m a bit off :)
Gah! It *would* have been really nice if the core functionality of windowed controls had been exposed in a windowless fashion from user32.dll
I trust that far more than some muppets ActiveX "windowless" control. It would have been nice to be able to write lightweight windowless gadgets with the correct functionality, but I guess thats just wishful thinking.
Ben: "Unfortunately, I don’t have a current example because right now all of my applications are serving me pretty well."
This is about dialogs, not controls, but I had the problem that OpenOffice.org remembers the positions of its dialogs, which brought me great pain when I switched the positions of my multiple screens. Suddenly these remembered positions were completely off-screen, and since the dialogs were modal, the app appeared to have crashed.
I may be naive, but i´ve yet to see an application that can fit 60000 window objects on to a single screen. Same for the directory with 100000 files. Make that lazy, and you have (allmost) no problem???
Patrick Schriner: "I may be naive, but i´ve yet to see an application that can fit 60000 window objects on to a single screen."
Imagine a webbrowser or a spreadsheet application, displaying a 20 column wide table with 3000 rows. 1 window for each cell.
Borland VCL (Delphi, C-Builder) has two kinds of controls: WinControls and Graphic (windowless) controls. Both derived from same class and graphic controls cannot receive focus, only mouse input. They paint themselves to the parent WinControl (they can be placed to the WinControls only). And they receive windows messages, parent controls take care about delivering messages. Some standard controls like image, label, speed button derived from graphic controls.
John Potter, you are remembering correctly :)
Anyways, telling people not to make windows for their controls amounts to telling people to make their own hit-box testing and whatever you need to implement controls on your own, doesn’t it?
ps. John Potter of Directory Opus fame?
As I noted in the article, I already gave an example of windowless controls: Each item in the scrollbar sample is windowless. They aren’t accessible yet – that’s on my list of future topics.
I know that under the current system and set of libraries writing windowless controls is much more difficult than writing window based controls. However, I think that if the initial decision had been to make controls windowless, then libraries would have been written with windowless controls in mind. (with all of the hit test code, etc, saving us from the trouble of dealing with that so much in the current libraries.)
Is there something I’m missing that makes windowless controls inherently more complicated than windowed controls, given proper library support for windowless controls?
(@ Chris Becke)
That would have to be cheaper, even from a system perspective, because you aren’t tracking wndClass, message queue’s and the like for each control, plus you don’t have to worry about parent notification and other such cross talk that comes from having 30 "windows" in one UI window.
Having created windowless controls for a visual editor, I can testify that windowless programming is a *BIG* pain. That said, I would have liked it if there were an easer way to draw controls. At least in pure managed code there isn’t a good way to easily implement themed support. What would have been nice is to have lightweight button classes that had all the state properties of buttons and rendered them nicely to a Graphics object.
I ended up just using un-themed ControlPaint drawing, and I’ll switch it over to themed painting when the v2 framework comes out. I’ve heard they have renderers which would be similar to my lighweight buttons. I’m hoping…
"… given proper library support…" – That’s rather tautological – if there were any problems you could blame it on the library for not handling it "properly".
Call me obsessed, call me off-topic, but these posts still don’t explain why I can’t open more than 60-70 Internet Explorer windows or why the limitations mentioned in http://support.microsoft.com/default.aspx?kbid=126962 (quoted by Mr. Chen in a previous post) exist in Windows XP.
I have some freaking 700 MB of RAM free and I can’t open any more programs. I want to be able to use my machine the way I want…
One of the best thing about Windows is that everything is a Window, no special case for widgets.
As stated above, windowless controls are very difficult to get right, I am currently working with a windowless library of our our own. You loose a lot of things the OS does a lot of thing for free for windows, hittesting, clipping, tab handling, focus, capture, premade controls such as the Edit, etc. The problem I run into with real windows is the speed, there is a flood of messages when creating and manipulating windows that makes them feel much more sluggish than our windowless controls. Also, the windows are individually double-buffered whereas if you do everything in your own windowless lib you can double-buffer everything together and aleviate flickering. One still ends up having to create real windows for things such as edit controls, or opengl windows, so it’s never truely satisfying unless you invest many man month to create a complete windowless lib. Harder to train new developpers to use internal toolkits as well, and no help from tools such as spy++, boundchecker.
Don’t give me that. Windows is fairly scalable on the server. Once you take the darned swap file down, SQL Server or ASP.NET perform quite well. Why can’t scalability be brought to the Window Manager as well?
Also, keep in mind that some dude decided to write his own OS more than a decade ago. It’s givind Microsoft bad dreams at night these days…
Ovidiu: The memory for UI objects comes out of the so-called desktop heap. You typically run out of desktop heap long before running into any other limits (like the 65535-window limit). That’s why windows are not cheap objects.
Thanks for the reply, Raymond. I sort of understood that from the KB article mentioned above.
The really pesky question still remains: Why can’t the desktop heap scale? What if I put 4 GB of RAM on my desktop? (I can see myself going to 2 GB in the near future, for instance, and I’m sure I’ll make the next step later). Will Windows still use a several MB desktop heap by default?
Remember – the desktop heap is global (it has to be since window handles are available to all procsses). Make it too big and there won’t be room for other global stuff. It’s all a balancing act. See the previous discussion about the /3GB switch for examples.
Maybe I’m going in the wrong direction, but how does this differ from other global objects you might have in Windows, like file handles, mutexes, sempahores and so on? Sure, windows are managed in a different component of the OS, and the situation is quite a bit more complex because of having to work with window stations, desktops and so on (for instance, if you run a process with RunAs, you can change the keyboard layout with the keyboard shortcut but not from the systray icon – the window manager at work, not allowing windows in different security contexts to access each other). What is it in there that makes the balancing act harder for the desktop heap? The 64K limit on window handles inside a process seems reasonable even these days, and even limiting the overall memory consumption is a good thing, I’m convinced of that. I just don’t like it being harcoded, regardless of the features of the physical machine.
Anyway, thank you for your time :)
Beyond the normal object overhead, a semaphore is just a dword; an event is just a bit! But windows are much heavier – message queues, property lists, invalid regions, child windows, window classes, keyboard layouts, IME context, virtual keyboard state, double-click state, caret state… Obviously if something is big you can’t have as many of them as something that is small.
But if he has the memory resources then that’s not the limitation, the architecture is. I think the answer to his question is probably, "In our experience and based on customer usage we haven’t seen a need to implement that capability". If there were enough demand for what Ovidiu wants to do then it would probably be implemented, right? It’s not like you need to automatically allocate the memory, but if there’s enough RAM why not let global constructs grow larger?
RAM is irrelevant. The issue is address space, which is 4GB regardless of how much RAM you have.
Ovidiu: On Win2kPro, with a mere 384M of RAM, I can open 376 IE windows before things start to go bad. That’s with no other open (active) apps.
If I play with taskmgr I can often sneak a 377th window in, but then Things Start To Go Bad. Things like not being able to open taskmgr anymore, or even shut down my computer.
The limits were within about 20 windows of when I tried it on my machine with 1G of memory. I assumed it was a desktop UI issue (and the different number was due to background apps or services).
On the other hand, how often do you need 60 IE windows open? I start to freak out when I have 15 windows open. Even while browsing, 20 windows is ample for me (and I use Opera in MDI mode).
Raymond Chen wrote:
"The system should not be encouraging a program to create 60,000 windows."
But really – why not?
Sure, the window object has grown over time. And is now something more than 88 bytes. System RAM however has grown far faster. I think that real window objects are relativly cheap – especially so considering all the built in goodness you DO get. A lot of thought and careful design has gone into them – they *work*. By contrast, any custom framework for managing windowless controlls – what reason is there to expect that they will be substantially cheaper than windowed controls?
In rare instances maybe. But frankly, most programmers are lazy dogs who do the minimum required but will insist on rewriting non OS provided services from scratch anyway so NOT having an OS that allows them to do stupid things (like bog their app down with 60’000 windows) just works out to incent the production of hundreds of not-quite-the-same implementations of some or other grid control – none of which react to themeing and changes to system default colors quite the same way.
Perhaps the best topic for a set of articles would/should be: "How to write windowless widgets right, right now, without waiting for Avalon/WinFX/Whatever, that react to XP theming and system appearance settings properly". Which looks just too big a task to realistically expect anyone to do in their free time.
4 GB address space / 88 bytes per window = 4.8 million windows :)
It’s a lot more than 88 bytes now, especially after you add in the hangers-on (which I didn’t count). And of course this assumes you don’t want to leave any address space anyhthing else!
merle how many instances of notepad were you able to open? IE is pretty resource intensive especially with all the plugins and core dependencies.
3/16/2005 12:44 PM Merle
> Even while browsing, 20 windows is ample for
> me
I agree, even when opening and comparing various results from Google searches, I usually don’t have 20 IE windows. (And fortunately I can have 20. Windows 98 corrupted itself badly after about 5. 4 if OE was open at the same time.)
However, I might have 15 VB6 instances open at the same time. Open one, make changes that I think are necessary in a source file, open the other 14 to check if anything has obviously been broken or not, then compile them one-by-one. Of course if the source file needs further changes then I have to close 14 of the VB projects, change the source file in 1, and then open the other 14 again. For some reason it does seem easier to switch from one to another and look at whatever I need to look at, instead of keeping just 1 open and frequently closing the current one and opening up another just to take another look at the other.
What impact do windowless controls have on automated testing tools?
One of the apps our product works with uses a custom GUI library (VxWare or something) and all the GUI testers see it as one big window. You have to ensure everything is pixel perfect during playback or the tests don’t work because the testing tools can only go by mouse x/y not by window handle or name.
Ovidiu:
Then may I suggest that you write your own OS?
That way you can use your machine any way you want, because you’ll get to define all of the tradeoffs in the way the OS is defined. And there *are* tradeoffs.
David Taylor – nothing if they support the IAccessibility interface.
I measured 30-35 IE instances on Win2003 loading a simple page like http://di.se/ (what one of my customers typically access). That’s 30 instances of IE before I use any other applications…
I don’t quite see why Raymond thinks IE is a good example of good resource management. To me it illustrates clearly why the default desktop heap size of 3MB is ridiculously small!
—
Rune
Something related to this discussion:
http://www.winterdom.com/dev/ui/wnd.html
This is a guy trying to reverse engineer the internal window structure :) (although its a moot point since Longhorn will change the whole thing no doubt :)
Rune: Now imagine how much worse it would be if IE used actual window handles.
Hi, one of the things I could never understand (when using windowless controls from VB6) is why none of the bugs with them ever seemed to get fixed. I reported the following one in the beta of VB6 and again at every service pack where I got the opportunity to comment. Yet they never got fixed.
Take two windowless text boxes, drop them on a form. Put code in the "GotFocus" event for each textbox to select all the text in the text box. Run the program. Whichever textbox has the focus when the program starts has its text disappear. If you tab out, it reappears.
This is the sort of thing I can’t work around easily.
Why didn’t this sort of thing ever get fixed?
Thanks,
Greg
paulr: it did not seem to make much difference what app it was. IE with all those silly toolbars off, opening "about:blank", isn’t bad, and all instances share a large memory footprint.
I remember testing cmd.exe vs notepad.exe, and I could get the same number. I’m not *positive* I tested IE up into the 300+ window range, but do know I’ve opened 100 (for load testing).
more on the windowless/windowed saga:
the advantage of windowed everything is that you can subclass/superclass and modify the default behaviour. Can you do that with windowless (?)
not to mention that to get a windowless "window" on a dialog with ATL you need a real host window (CAxWindow). Lame or what?
gawd knows what avalon will do with all that…
I cannot believe Raymond Chen is having to tell people the difference between RAM and address space. But since he is, that leads me to this next question:
Are many of you here to learn, or just bash Windows/Microsoft??
James
Raymond: The question isn’t really whether IE could be worse or not, but rather if the current approach is sufficient.
Current generation LCD monitors typically offer 1280×1024 resolution and most of us have limited ourselves to two such panels. However, you can buy 1920×1200 panels and with PCI Express you’ll have workstations capable of any (practical) number of such monitors.
30-35 instances of IE will in setups like that seem like a very limited number of instances. I can already feel the pain with my dual monitor setup.
Clearly a solution needs to be worked out, so my question is: Have MS atleast increased the default desktop heap size for the 64-bit versions of Windows?
Now, the really bad part about this is: I can’t seem to find any performance counters which gives me an indication of how much desktop heap size Windows has left. Thus I’m left with "if weird UI problem surfaces — try increasing desktop heap size and reboot" which is hardly the way to go. :( (A reboot to fix a small UI issue? Surely someone at MS are doing something very wrong?)
—
Rune (finally back from four weeks of vacation)
Oh, and I’d just like to add: That is 30-35 instances of IE showing a rather simple web page. More elaborate web pages may require additional resources, thus further reducing the number of instances that are possible. Also keep in mind that most users will want to run other applications besides just IE… (btw Merle: testing IE using about:blank is hardly useful?)
—
Rune
A simpler life.
PingBack from http://blog.stevienova.com/2008/02/05/it-and-development-best-practice-just-because-you-can-doesnt-mean-you-should/
PingBack from http://wallism.wordpress.com/2008/12/07/memory-leak-in-my-net-application/