8 ms·

90s apps used these Windows handle controls and it was not a performance problem. On computers 100 slower than today and with 1000 times less memory. BTW, the

90s apps used these Windows handle controls and it was not a performance problem. On computers 100 slower than today and with 1000 times less memory. BTW, the current Windows Task Manager still shows the total HANDLE count on the CPU page. They were not used in apps with complex UIs because native controls were hard to skin and didn't work very well when their size was very small (as complex UIs tend to need)

adzm 3y ago
Note the HANDLE count is kernel objects; windows and graphics objects will show as USER and GDI respectively. Each of these has its own heap and limits.
Someone 3y ago
> 90s apps used these Windows handle controls and it was not a performance problem. That depends on the overhead per window. Microsoft Windows could use nested windows because it had separate Graphics objects to store such things as the current drawing pen, its position and the current font to use for drawing (https://learn.microsoft.com/en-us/windows/win32/api/gdiplusgraphics/nl-gdiplusgraphics-graphics https://learn.microsoft.com/en-us/windows/win32/api/gdiplusg...) In comparison, on the classic Mac every window had a GrafPort that defined a boundary region, a clipping region, the current pen position, size, drawing pattern, etc. The Mac could have such heavy-weight window objects because it didn’t nest windows. Instead, each window had a single list of controls that were much lighter-weight. my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. (its documentation is ‘less than stellar’, but it appears GrafPort still exists: https://developer.apple.com/documentation/applicationservices/grafport https://developer.apple.com/documentation/applicationservice...)
- skissane 3y ago
  > (its documentation is ‘less than stellar’, but it appears GrafPort still exists: GrafPort is part of QuickDraw, almost all of which was removed in 64-bit macOS. (A handful of QuickDraw functions survive, but they can't actually be used to do drawing, just to manipulate Point/Region/etc data structures.) From what I understand, this struct/typedef remains in the headers to help with compiling legacy code–but all the APIs which take it as an argument have been removed, so it is essentially a useless vestige.
- nxobject 3y ago
  I think the tradeoff with the Toolbox is that positioning controls with relative coordinates, and updating views when scrolling etc, is a huge PITA since you have to do it in application code – for example, I'm not aware of many classic Toolbox applications that had bottom window status bars before that required relative positioning. A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.) On the point of GrafPort still existing – Carbon was insanely backwards source compatible until QuickDraw was deprecated in the transition to 64-bit! [1] Conservatively-written 80s Toolbox code would work with some switching around of headers, and shimming getting/setting members of structs with functions. [1] https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbon-and-building-Classic-Mac-OS-apps-in-OS-X https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbo...
  - Someone 3y ago
    > for example, I'm not aware of many classic Toolbox applications that had bottom window status bar I think that’s more either because they yet had to be invented or because giving up 16 or so pixels on a screen (the menu bar was 20 pixels high, IIRC) that’s only 342 pixels high wasn’t desirable. > A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.) I think MacPaint can be forgiven for that. It was a miracle that it ran on a Mac with 128kB RAM. An application on that machine had about 28kB free for a program. MacPaint allowed you to edit a 50kB bitmap, double-buffering the screen to avoid flicker, with full undo. (And yes, paging to floppy disk isn’t fast. It did work, though)
- bitwize 3y ago
  > my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. I like to sum up the difference between Mac and Windows thusly. Probably glossing over a bunch of stuff but still: * Steve Jobs toured Xerox and came away with an idea, and a fairly shallow one -- the windowed, mouse-driven, document-centric interface. This is what he then had his team implement in the Lisa and Mac. As implementations go, it was really good and it looked good, but it was really procedural Pascal code beneath. (You had to handle window moving and resizing yourself in early Mac OS. There were library functions to help, but you had to code all that into your application's main loop.) * Microsoft, at right about the same time, was hiring guys out of Xerox PARC itself -- guys like Charles Simonyi -- and they brought with them a whole passel of ideas, not just concerning interfaces but also software design, things like objects and message-passing. That's why Windows could do things like handle the move and resize drag actions, and then just post WM_MOVE or WM_RESIZE to the target window. Windows were objects -- members of classes, even, and could receive messages. Granted, Windows couldn't run in 128K -- and Jobs would pivot completely with NeXT and deliver an object-oriented desktop based on Smalltalk grafted onto C (Objective-C), but initially it seems Apple were trying to build a cheaper, more user friendly Xerox Star and Microsoft were trying to get as much of the Smalltalk environment as would fit in a PC without requiring devs to learn a new language.
  - twoodfin 3y ago
    FWIW, Steve agreed with your assessment. One of my favorite Jobs quotes: I had three or four people who kept bugging me that I ought to get my rear over to Xerox PARC and see what they were doing. And so I finally did. I went over there. And they were very kind and they showed me what they were working on. And they showed me really three things, but I was so blinded by the first one that I didn’t even really see the other two. One of the things they showed me was object-oriented programming. They showed me that, but I didn’t even see that. The other one they showed me was really a network computer system. They had over a hundred Alto computers, all network using email, et cetera, et cetera. I didn’t even see that. I was so blinded by the first thing they showed me, which was the graphical user interface. I thought it was the best thing I’d ever seen in my life. One way to describe NeXT is Steve returning to the two things he missed @ Xerox.
dspillett 3y ago
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
- Narishma 3y ago
  Do you know why they made those handles public instead of private to each app?
  - lmz 3y ago
    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.
  - dspillett 3y ago
    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.
stouset 3y ago
> They were not used in apps with complex UIs because native controls were hard to skin Every time I’m forced to use Windows I’m blow away by the clownishness of every application deciding to skin its own custom windowing controls. This started happening some time around XP, I think?
- amluto 3y ago
  I remember Borland shipping a toolkit with horrible built-in skins well before Windows XP. I even vaguely recall MS jumping on this bandwagon with some MFC styles.
  - barrkel 3y ago
    There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc. That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible.
    - lproven 3y ago
      Hang on hang on... > There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc. This I remember well. It was a hallmark. > That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible. Say what now?!
      - barrkel 3y ago
        The VCL has a window managed by TApplication and it's the window which shows up in the task bar, but it's not the application's main window, which is generally a TForm descendant. When you minimize the main window (certainly on Windows 7 and before - I'm not sure about what happens these days) it would just vanish, while a tiny little animation not related to the main window would briefly show disappearing into the task bar button. The application's window message queue was used for things like coordinating background thread actions with the UI thread and other general purpose stuff - I don't remember the details and it's been a long time since I read the VCL source.
bitwize 3y ago
> 90s apps used these Windows handle controls and it was not a performance problem. For a while there, at least on Windows 3.1 and before, possibly some Windows 9x versions -- you had a GDI heap and USER heap of 64k each (one 16-bit x86 segment). If you allocated too many HANDLEs, you could blow one of these heaps. So it still made sense to be judicious about how many windows you created. Most Web browsers and word processors, for instance, drew their documents in the client area and did not use subwindows to position text elements.

adzm 3y ago

Note the HANDLE count is kernel objects; windows and graphics objects will show as USER and GDI respectively. Each of these has its own heap and limits.

Someone 3y ago

> 90s apps used these Windows handle controls and it was not a performance problem. That depends on the overhead per window. Microsoft Windows could use nested windows because it had separate Graphics objects to store such things as the current drawing pen, its position and the current font to use for drawing (https://learn.microsoft.com/en-us/windows/win32/api/gdiplusgraphics/nl-gdiplusgraphics-graphics https://learn.microsoft.com/en-us/windows/win32/api/gdiplusg...) In comparison, on the classic Mac every window had a GrafPort that defined a boundary region, a clipping region, the current pen position, size, drawing pattern, etc. The Mac could have such heavy-weight window objects because it didn’t nest windows. Instead, each window had a single list of controls that were much lighter-weight. my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. (its documentation is ‘less than stellar’, but it appears GrafPort still exists: https://developer.apple.com/documentation/applicationservices/grafport https://developer.apple.com/documentation/applicationservice...)

skissane 3y ago
> (its documentation is ‘less than stellar’, but it appears GrafPort still exists: GrafPort is part of QuickDraw, almost all of which was removed in 64-bit macOS. (A handful of QuickDraw functions survive, but they can't actually be used to do drawing, just to manipulate Point/Region/etc data structures.) From what I understand, this struct/typedef remains in the headers to help with compiling legacy code–but all the APIs which take it as an argument have been removed, so it is essentially a useless vestige.
nxobject 3y ago
I think the tradeoff with the Toolbox is that positioning controls with relative coordinates, and updating views when scrolling etc, is a huge PITA since you have to do it in application code – for example, I'm not aware of many classic Toolbox applications that had bottom window status bars before that required relative positioning. A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.) On the point of GrafPort still existing – Carbon was insanely backwards source compatible until QuickDraw was deprecated in the transition to 64-bit! [1] Conservatively-written 80s Toolbox code would work with some switching around of headers, and shimming getting/setting members of structs with functions. [1] https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbon-and-building-Classic-Mac-OS-apps-in-OS-X https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbo...
- Someone 3y ago
  > for example, I'm not aware of many classic Toolbox applications that had bottom window status bar I think that’s more either because they yet had to be invented or because giving up 16 or so pixels on a screen (the menu bar was 20 pixels high, IIRC) that’s only 342 pixels high wasn’t desirable. > A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.) I think MacPaint can be forgiven for that. It was a miracle that it ran on a Mac with 128kB RAM. An application on that machine had about 28kB free for a program. MacPaint allowed you to edit a 50kB bitmap, double-buffering the screen to avoid flicker, with full undo. (And yes, paging to floppy disk isn’t fast. It did work, though)
bitwize 3y ago
> my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. I like to sum up the difference between Mac and Windows thusly. Probably glossing over a bunch of stuff but still: * Steve Jobs toured Xerox and came away with an idea, and a fairly shallow one -- the windowed, mouse-driven, document-centric interface. This is what he then had his team implement in the Lisa and Mac. As implementations go, it was really good and it looked good, but it was really procedural Pascal code beneath. (You had to handle window moving and resizing yourself in early Mac OS. There were library functions to help, but you had to code all that into your application's main loop.) * Microsoft, at right about the same time, was hiring guys out of Xerox PARC itself -- guys like Charles Simonyi -- and they brought with them a whole passel of ideas, not just concerning interfaces but also software design, things like objects and message-passing. That's why Windows could do things like handle the move and resize drag actions, and then just post WM_MOVE or WM_RESIZE to the target window. Windows were objects -- members of classes, even, and could receive messages. Granted, Windows couldn't run in 128K -- and Jobs would pivot completely with NeXT and deliver an object-oriented desktop based on Smalltalk grafted onto C (Objective-C), but initially it seems Apple were trying to build a cheaper, more user friendly Xerox Star and Microsoft were trying to get as much of the Smalltalk environment as would fit in a PC without requiring devs to learn a new language.
- twoodfin 3y ago
  FWIW, Steve agreed with your assessment. One of my favorite Jobs quotes: I had three or four people who kept bugging me that I ought to get my rear over to Xerox PARC and see what they were doing. And so I finally did. I went over there. And they were very kind and they showed me what they were working on. And they showed me really three things, but I was so blinded by the first one that I didn’t even really see the other two. One of the things they showed me was object-oriented programming. They showed me that, but I didn’t even see that. The other one they showed me was really a network computer system. They had over a hundred Alto computers, all network using email, et cetera, et cetera. I didn’t even see that. I was so blinded by the first thing they showed me, which was the graphical user interface. I thought it was the best thing I’d ever seen in my life. One way to describe NeXT is Steve returning to the two things he missed @ Xerox.

dspillett 3y ago

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

Narishma 3y ago
Do you know why they made those handles public instead of private to each app?
- lmz 3y ago
  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.
- dspillett 3y ago
  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.

stouset 3y ago

> They were not used in apps with complex UIs because native controls were hard to skin Every time I’m forced to use Windows I’m blow away by the clownishness of every application deciding to skin its own custom windowing controls. This started happening some time around XP, I think?

amluto 3y ago
I remember Borland shipping a toolkit with horrible built-in skins well before Windows XP. I even vaguely recall MS jumping on this bandwagon with some MFC styles.
- barrkel 3y ago
  There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc. That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible.
  - lproven 3y ago
    Hang on hang on... > There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc. This I remember well. It was a hallmark. > That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible. Say what now?!
    - barrkel 3y ago
      The VCL has a window managed by TApplication and it's the window which shows up in the task bar, but it's not the application's main window, which is generally a TForm descendant. When you minimize the main window (certainly on Windows 7 and before - I'm not sure about what happens these days) it would just vanish, while a tiny little animation not related to the main window would briefly show disappearing into the task bar button. The application's window message queue was used for things like coordinating background thread actions with the UI thread and other general purpose stuff - I don't remember the details and it's been a long time since I read the VCL source.

bitwize 3y ago

> 90s apps used these Windows handle controls and it was not a performance problem. For a while there, at least on Windows 3.1 and before, possibly some Windows 9x versions -- you had a GDI heap and USER heap of 64k each (one 16-bit x86 segment). If you allocated too many HANDLEs, you could blow one of these heaps. So it still made sense to be judicious about how many windows you created. Most Web browsers and word processors, for instance, drew their documents in the client area and did not use subwindows to position text elements.