Why isn’t the original window order always preserved when you undo a Show Desktop?


A commenter asked why the original window order is not always preserved when you undo a Show Desktop.

The answer is "Because the alternative is worse."

Guaranteeing that the window order is restored can result in Explorer hanging.

When the windows are restored when you undo a Show Desktop, Explorer goes through and asks each window that it had minimized to restore itself. If each window is quick to respond, then the windows are restored and the order is preserved.

However, if there is a window that is slow to respond (or even hung), then it loses its chance and Explorer moves on to the next window in the list. That way, a hung window doesn't cause Explorer to hang, too. But it does mean that the windows restore out of order.

Comments (52)
  1. Anonymous says:

    Isn’t that what Ghost windows are for? Just because an application which draws a window is hung doesn’t mean that the desktop should stop treating the window as a valid object.

  2. Anonymous says:

    This does NOT exuse you. That was you (I mean Microsoft) who made it ever possible:

    – for window to hang

    – for hung window not to be able to restore quickly

    – for explorer.exe to hang when trying to restore a hung window

    So it’s not an exuse at all. It was just that you said: "Well, this sucks, but that because we’ve made a sucking window manager where we just cannot make it work any better, and so we are not going to"

    (This message is not supposed to be offensive, I do respect you.)

  3. Anonymous says:

    Ilya, it will always be possible for an app to hang. Even if you use callbacks (executing on a separate thread for each one) instead of message queue it will still be possible for an app not to respond. There’s nothing you can do about that in any window manager.

  4. Anonymous says:

    but surely a window hanging doesn’t stop Explorer placing the window in the correct z-order and hence being ‘in order’. Sounds to me like suckage in the implementation.

  5. Anonymous says:

    Ilya,

    Is it your assertion that all Windows apps that hang or can’t restore their windows quickly are solely due to Microsoft’s coding errors? Or that all other window managers other than Windows somehow prevent all applications running under then from hanging or restoring their windows slowly?

  6. Anonymous says:

    Jerry,

    I’m sure lots of people will hold up the X Window System as a counter-example to your claim, so I guess I’ll do it first. (unless someone beats me to it!)

    The window manager in X is a separate process which talks to the X server. The application doesn’t really know a whole lot about it except when it gets messages that the window has been resized and whatnot. If you "restore" a hanged window in X, the window will restore but the canvas will not be repainted, so you’ll probably end up with a bordered window with no contents until the application is ready to process the X version of the WM_PAINT message. The Window border will go on responding to the user, though, allowing him or her to resize the window, minimize it again or to "kill" it (terminate the connection between the app and the display — a forced quit.), assuming the Window Manager has such a function.

  7. Anonymous says:

    Recall that the original window manager was based on a co-operative multitasking model. This influenced much of the design.

  8. Anonymous says:

    Explorer doesn’t place windows in Z-order. You are perhaps used to X, where a "window manager" process is responsible for moving and managing windows. This is not how Windows works. Windows in Windows place themselves, or rather, running processes place the windows they own.

    Explorer restores windows by sending them messages, telling them to restore themselves. If, for some reason, the window takes a while to get around to it (say because it was doing something else at the time), well, it may restore out of order.

  9. Anonymous says:

    So, another question left dangling from the earlier thread (from Jerry P.): why does Explorer keep deciding to switch off the status bar and is there any way of making it truly permanent?

  10. Anonymous says:

    The status bar is managed by IE. I keep trying to redirect questions about it to the IE team but people keep asking me for some reason. Here’s the answer again: I don’t know. The IE folks say that it’s fixed in SP2. Why not ask them what the reason was?

    http://blogs.msdn.com/tonyschr/archive/2004/06/15/156787.aspx

  11. Anonymous says:

    PEOPLE

    I’m not talking about preventing APPLICATIONS from hanging. I’m taling about WINDOWS.

    Operating system CAN paint a window even when the app is hung. Application is to paing only the client area, not the border. So it’s window manager’s job to restore z-order and windows’ borders.

    That’s what it should do when recovering from Show Desktop mode.

  12. Anonymous says:

    The Windows window manager leave even nonclient painting (borders) to the application (via the WM_NCPAINT message). So the window manager can’t draw the borders because it doesn’t know what kind of borders the app is going to draw. Similarly, when the window manager changes a window’s z-order, the window gets a change to intercept the request (WM_WINDOWPOSCHANGING) and accept, reject, or modify it. So changing a window’s z-order requires the app to respond to the "is this z-order okay with you?" message.

    Yes, it is possible to design window managers that avoid these problems. Recall that the Windows window manager was designed in the early 1980’s for machines with less than 1MB of memory, running on top of a co-operatively multi-tasked kernel. There was no such thing as a program trying to send a message to a nonresponsive window. (Think about it.)

  13. Anonymous says:

    Huh. Interesting. That’s something I always wondered about. Maybe I only notice when the windows rearrange themselves in a non-intuitive way, or maybe the programs I use most often just tend to be slow at responding, but I was convinced before reading your article that the window manager minimized the windows in such a way as to maximize the number of alt-tabs necessary to bring the frontmost applications up again.

    However, having just now performed an extremely unscientific test on the applications I have open, I notice that I was wrong and that after a show desktop command their alt-tab order is merely the reverse of their location on the taskbar. With the exception of Visual Studio .NET, which for some reason is always first. :)

    Is the alt-tab order different than the window order in this case?

  14. Anonymous says:

    Hm it seems I’ve reached the point where people are asking questions I’ve already answered. Perhaps that means it’s time to stop.

    http://weblogs.asp.net/oldnewthing/archive/2003/10/20/55367.aspx

  15. Anonymous says:

    Pardon my Macintosh arrogance, but have you ever seen this?

    http://www.apple.com/macosx/features/expose/

    I used Expose today when one of the running applications locked up, and it worked perfectly — I was able to glance at all the open windows. Somehow this doesn’t make the entire machine lock up. [wink]

  16. Anonymous says:

    That shows what sort of things you can do when you do a redesign of the window manager, as Carbon was. Windows hasn’t redesigned the window manager in twenty years – for compatibility reasons.

  17. Anonymous says:
    • for window to hang

      Not sure what you really mean here but I’m going to assume you mean a "program looks like it is frozen". Unless your window is backed by a bitmap instead of being drawn on the fly in response to paint messages, windows can always look like they’re hanged. Being backed by a bitmap wastes a huge amount of memory though and if you had some logic to resize the window, the only reasonable thing would be to scale the bitmap until the app can process the paint message. If you’ve ever programmed a direct3d program using the default resize message processing it does just that and it looks like ass.

      – for hung window not to be able to restore quickly

      Whenever the z-order, position, or size gets changed, two messages are sent, the first one is a request to move/resize/etc to the new value (the program can also adjust the value to something it likes better). If that message is accepted, a message to notify the window that it has been moved/resized/etc.

      Windows has some logic to take over some messages if it detects your app is frozen like being able to minimize a window, draw something reasonable (the windows borders and filled in with a solid color), and activate a menu when you right click on it’s button in the taskbar. It’s a fine line what kind of messages to handle because what the app thinks and what windows thinks can get out of sync if you’re not careful.

      – for explorer.exe to hang when trying to restore a hung window

      explorer.exe doesn’t hang, that’s the point.

      It’s not just explorer that messes up the z-order, if you try any of those expose clones for windows, they will mess it up too on their show desktop implementation (but at least they will get modal dialogs and the winamp window out of the way).

  18. Anonymous says:

    Actually, Raymond, the original Windows window manager was designed for machines with 256K (as in Kilobytes) of RAM – that was the minimum hardware requirement for Win 1.0.

    And it had to run (IIRC) 15 different gwbasic applications simultaneously on it.

    Think about it. :)

  19. Anonymous says:

    This is a little cheeky, but since I missed the linked entry (it’s in a category I don’t subscribe to, I guess) I’m going to be a little off-topic.

    In that other entry you tried to use Wingdings and Marlett to show the Windows logo and what I assume is the minimize icon, and a couple of people commented that it hadn’t worked. Aside from the obvious lack of these fonts, there is another less-obvious reason why this won’t work in most browsers.

    HTML 4 is based around Unicode. When you say ÿ, this means "show the character at unicode codepoint 255", which is defined as an umlauted "Y". Wingdings, being a symbol font, doesn’t map onto unicode, as you can see if you select it in the Windows NT version of Character Map; for this font, it won’t allow you to view by unicode subrange. The TrueType Font property page extension shows this too, on the Unicode and Code Pages tab: it doesn’t have any characters attached to unicode code points.

    A strictly compliant browser (which, of course, Internet Explorer is not) will see the request for unicode character 255 and note that this character is not available in the currently-selected font (Wingdings) and go off hunting for it in the preferred font for that unicode range, which is of course Latin.

    Internet Explorer seems to have all of this in there somewhere, since it’s capable of noticing that a particular mathmatical operator isn’t available in my stock Arial and will go hunting for it and find it in Arial Unicode MS. However, I guess there’s a special case in there which stops this mechanism from working for non-unicode fonts, instead reverting to the Windows-specific codepage.

    I can imagine why this was done: old versions of Microsoft Word encouraged users to insert things like this by changing the font and typing a character. That was a reasonable hack at the time since Unicode wasn’t around yet. Of course, when Word saves to HTML it can’t translate these to Unicode because most of the Wingdings glyphs don’t have any suitable codepoints in Unicode.

    As a Microsoft developer writing a site about Microsoft products, I can’t fault you for writing to Microsoft’s browser, but I thought I’d take the opportunity to mention this anyway, for the benefit of others who *aren’t* writing about Microsoft.

    A more correct solution would be for Microsoft to assign Wingdings glyphs to suitable Unicode code points, — many would be at home in the Symbols and Dingbats range — but things like the Windows logo would only fit into Private Use Characters which are unsuitable for web use, of course.

    Sorry again for replying to your closed discussion in this one. I won’t do it again! ;)

  20. Anonymous says:

    First, I think the gfx shell (explorer) in WinXP (and maybe just SP2, I’m not sure) will still repaint default window borded for an app that’s not responding quickly enough. If you’ve ever combined few hundred binary posts in OE you’ll know ;)

    Second, my issue was with explorer not remembering the folder view for folders that were not using the default. It might have included the status bar. That does seem to be fixed in WinXP SP2, now my control panel always uses Large Icons even when my default folder view is List. I must say that the IE team did fairly good work for SP2, of course all this should’ve been done years ago, with the release of IE6 SP1 and the team should have been working on fixing standards breaking bugs (and better standard support overall).

    And third – NT based windows use the same window manager that was in 3.x and 9x line? Eeeeewwww.

    Oh and fourth – explorer should not be changing the z-order when showing/hiding desktop. Only when the user switches windows.

  21. Anonymous says:

    I sympathise with the Windows arguement here given the backward compatability issues.

    In trying to see the whole picture, I’m trying to think of a scenario where restoring the windows in a specific order is important and am failing. What’s the big deal?

  22. Anonymous says:

    Raymond:

    | Windows hasn’t redesigned the window manager

    | in twenty years – for compatibility reasons.

    I don’t know much about anything, but from these posts the window manager in Windows seems to just basically send messages to each window and they can do what they want with them; the windows manager doesn’t really care too much.

    If this is the case (I may be wrong and it may not be, but if it is) then why should there be ANY compatibility problems if the window manager suddenly decides IT wants to take over some actual control. Maybe it can even handle the non-client redrawing itself :)

    All it’d have to do is NOT send certain message, but instead carry out the tasks itself. This shouldn’t affect the window/program adversely, should it?

    Well I dunno, but to me it seems like MS is just a little lazy. To be completely honest I don’t care about windows being jumbled up, all it is is one click on the taskbar (of a few alt + tabs). I just thought I’d input my piece, and see exactly how wrong I am! :)

  23. Anonymous says:

    This is my I started reading your blog, and the more I read the more impressed I am with what Microsoft does to keep programs working from release to release.

    It’s easy to not care about this sort of thing (witness Linux and X many times over), and hard to make it work, but Microsoft does it so flawlessly you almost never notice it.

    I’m pleased to see that this slight of hand isn’t easy, it proves Microsoft’s dedication to the rest of the programing world.

    –Tyler

  24. Anonymous says:

    Raymond,

    Have you ever considered writing an article on why Microsoft decided to boot the operating system when the power is turned on? I would just love to see people whine about how doing such a thing is silly and (insert favorite OS) didn’t make the same mistake.

    :)

  25. Anonymous says:

    "All it’d have to do is NOT send certain message, but instead carry out the tasks itself."

    But what if a program was *expecting* a message? Now it’s broken because it doesn’t get a message it was relying on.

  26. Anonymous says:

    This is my I started reading your blog, and the more I read the more impressed I am

    > with what Microsoft does to keep programs working from release to release.

    > It’s easy to not care about this sort of thing (witness Linux and X many times over), and hard to make it work, but Microsoft

    > does it so flawlessly you almost never notice it.

    > I’m pleased to see that this slight of hand isn’t easy,

    > it proves Microsoft’s dedication to the rest of the programing world.

    I’ll have to disagree with you here, sometimes you just have to throw out all the old stuff and start anew. Technology has changed, there’s more insight in a certain problem, requirements are different.

    Microsoft missed a great opportunity to do thing right with Win95, they missed it again with win2k. Here’s a big OS upgrade, lot’s of stuff changed under the hood, people expect stuff to break, it’s a great time to clean up your code.

    The window manager (or lack thereof) is a great example, You’re stuck with a design that was written for 1985 specs, almost 30 years old by now, it’s designed for a single-user, stand-alone system and the design is based on a lot of assumptions that aren’t true anymore, it’s not a good idea to use those specs for a multi-user, networking OS like e.g. win2k, really. (Shatter attack anyone ?).

    The current windows versions are held together with sticks, strings and ducktape.

    Last night I spent hours battling with Windows File Protection while upgrading some apps on a production win2k AS server after-hours.

    Instead of providing a band-aid like WFP, shouldn’t you have fixed the reason something like WFP is needed ?

  27. Anonymous says:

    <i>Instead of providing a band-aid like WFP, shouldn’t you have fixed the reason something like WFP is needed ?</i>

    eh? you mean, like never allowing any app to write to the system32 directory at all, under any circumstances? That’s the fix you’re talking about – but then, those apps you were upgrading would never have successfully installed in the first place.

    The big problem though, is that if MS changed the design and stopped things like your apps running, you’d be complaining just as much that windows had broken your code.

    As for the window mananger – why is it a big deal? Its not broken at all, its just that the design is to allow applications to manage their own windows, instead of having a manager manage the frame that the application draws inside. That’s just a different design choice – not a bad one, and you could think up many reasons where the X-style window manager is flawed compared to the windows-style one (eg. when an app hangs, I can kill the window, but the app continues to run…)

  28. Anonymous says:

    if you want some examples of why taking over messages like WM_NCPAINT, WM_NCCALCSIZE, WM_NCHITTEST, WM_WINDOWPOSCHANGING etc, just look at Winamp or Trillian. If windows took away sending of non-client messages and instead drew the default regardless, both apps would break horibly.

    When the windows source code was leaked, various postings appeared with comments taken from the source like "do this here to make xyz app work" (or similar messages). This shows just how committed microsoft is to keeping various apps working.

  29. Anonymous says:

    eh? you mean, like never allowing any app to write to the system32 directory at all, under any circumstances? That’s the fix you’re talking about – but then, those apps you were upgrading would never have successfully installed in the first place.

    Why not maintain a strong MS tradition and borrow a page from unix? Implement something like app jails where the app can party on sys32 all it likes without affecting others because all of its file updates are stored in a separate place.

    This would likely require a patch to support, unless you allow users to define a jail by name for install, then associate it with the running app.

  30. Anonymous says:

    Before you play the "it’s old and computers were too slow then to be reasonable" remember that Unix dates back to 1970, and the X Windows System was started in 1984, with X11 released around 1988 or so, and both have much saner behavior. And from my experience both are just as backwards compatible as windows is without the crazy hacks.

  31. Anonymous says:

    They also had the advantage of processors that supported memory protection and pre-emptive multitasking, as well as the presence of a network. The IBM PC had none of this. (Microsoft’s Unixlike system Xenix did however.)

  32. Anonymous says:

    "Here’s a big OS upgrade, lot’s of stuff changed under the hood, people expect stuff to break,"

    _Maybe_ developers expect stuff to break, but certainly none of the users expect stuff to break. Despite Microsoft’s best efforts to make Windows more than just an OS, it’s fundamentally just the thing they have to have on their computer to get the value out of the software they actually want to run. If you buy that assumption, then the value of Windows it pretty much completely tied to the applications it can run. Thus, I find it hard to believe that breaking compatibility with significant chunks of those apps is a smart thing to do.

    IMHO, The best compromise, the approach Windows has largely taken, is to move the platform forward, maintain compatibility with legacy apps, and minimize the access they have to the rest of the system. Thus, while I can still run Visicalc on XP SP2, it’s not exactly a security risk.

    "They also had the advantage of processors that supported memory protection and pre-emptive multitasking, as well as the presence of a network. "

    Memory protection isn’t an essential component of good software architecture. Also, even the 8088 supports premptive multitasking. Minix multitasked on an 8088, DesqView would multitask DOS applications, and I spent the better part of five years working on an embedded platform that preemptively multitasked on an 80188. Further back, folks were doing preemptive multitasking on 8080’s and Z80’s with the likes of MP/M.

  33. Anonymous says:

    You can write UNIX-alikes that will run on Commodore 64s. http://lng.sourceforge.net/

    X11 was originally written on 1 MIPS VAX machines if I recall, with not much more power than an 8086 PC.

    MS often decided for quick hacks over the "right-thing" design wise. Understandable, but don’t try to gloss it over with "back then computers were too slow". Use the proper argument "we wanted to maximize stockholder value at the expense of maintainability and future user experience".

  34. Anonymous says:

    I remember being quite impressed on my old 286 system when I installed Windows 3.0 and I could have several DOS applications running and task switch between them. Of course, since this was a 286 it wasn’t really multitasking, but at the time I’d only had experience with DOS so it sure looked like multitasking to me.

    I remember that when pressing Alt+Tab in a DOS application (or did it need an extra qualifier from DOS? I can’t remember) the window switcher would be a character-mode thing with the window name centered on the top row of the screen, presumably because it was much faster to do that than to switch back to Windows land.

    Looking back on it now it seems like nothing, but getting it all working on a 286 (and, of course, earlier chips in the same family) was quite a feat.

    People have made linux run in single user mode on a 286 in retrospect, but that’s working backwards from new technology, which is much easier than working forwards.

  35. Anonymous says:

    Wow, I never knew people would get irritated when their windows didnt pop up exactly the same way they minimized…

    get a life guys!

  36. Anonymous says:

    Jerry, (re: 9/9/2004 4:54 PM)

    Now that Windows isn’t cooperatively multitasking anymore there’s a way to send messages to applications and detect if the app doesn’t respond within a certain period, and Windows 2000 and XP make use of this to prevent hanged applications from getting "stuck".

    For example, as you noted if an application doesn’t respond to WM_NCPAINT (actually, probably one of the other similar NC messages) Windows seems to automatically call the defaultwindowproc on it so that *something* renders. You can see this if Winamp hangs as Windows will draw the default border over the edges of the window.

    This is also used for the messages regarding the close gadget, though. If you click it once and there’s no response and then you click it again, Windows assumes the application is hanged and offers to terminate it for you. I suspect (although can’t confirm) that there’s more going on here than a message timeout, since things like displaying model dialog boxes (which prevent the message handler from returning immediately) also seem to count as responses.

    Modern Windows also seems to be able to force changes to the window Z-order when it becomes important to do so, and sometimes allows you to move around hanged windows (in x and y) even though they aren’t redrawing.

    However, as Raymond has noted there’s only so much you can do behind an application’s back before you break it. If you force a restore without the application’s "permission" it won’t do things it needs to do to get ready to restore, so then it’ll probably get a WM_PAINT message to draw its normal state but won’t be ready to do so because it never saw the restore/resize message.

    In order to do this properly, I suppose Windows would have to remember that it force-resized the window so that it can make sure that the application still gets the right messages in the right order when it is ready to pump its message queue.

    Such is the cost of backwards compatibility.

  37. Anonymous says:

    Wow, I never knew people would get irritated when their windows didnt pop up exactly the same way they minimized…

    It’s not that people here get irritated about. People here seem to get irritaded by the amount of excessive bending over for backwards compability Microsoft has done.

    Almost all the discussion here follow the same steps:

    – Raymond posts about something odd Windows does and show it’s for a good reason (backwards compability)

    – People start complaining it’s absurd, insane, he should let the applications break when they are wrong, and Linux doesn’t do it that way (even when Linux not doing it that way isn’t relevant to the discussion at all)

    – Raymond answers explaining why maintaining backwards compability is very important, and it couldn’t be done in a better way while still maintaining backwards compability

    – After a few days, the discussion ends

    No matter how small the backwards compability is, someone will find a fault with it. Of course, if Microsoft did the opposite, people would complain "you shouldn’t let the applications break" and "why didn’t you do X" where X is some sort of compability layer.

  38. Anonymous says:

    Vince, X doesn’t have saner behaviour than Windows, just different. It’s still very easy to write an app that hangs X dead; as a matter of fact some of my students did just that the other day and it was far too easy for me to consider X to be friendly for beginner programmers (or any programmer not intimately related to the inner workings of X).

    But maybe that’s the intention of X’s design?

  39. Anonymous says:

    Did X11 have to be DOS-compatible?

    "Wanted" to maximize shareholder value? It’s not a matter of "want". A company has a legal **obligation** to maximize shareholder value.

  40. Anonymous says:

    > A company has a legal **obligation** to maximize shareholder value.

    Among other obligations. There’s also the question of whether to maximize this quarter’s returns at the expense of future growth. Single-mindedly maximizing quarterly returns is a great way to kill a company.

  41. Anonymous says:

    "eh? you mean, like never allowing any app to write to the system32 directory at all, under any circumstances? That’s the fix you’re talking about – but then, those apps you were upgrading would never have successfully installed in the first place."

    This app was NOT overwriting stuff in the system32 dir but in it’s own install dir.

    "Thus, I find it hard to believe that breaking compatibility with significant chunks of those apps is a smart thing to do."

    Not doing the Right Thing™ design-wise, to avoid breaking some apps is a short-term solution, in the long run the user is better of with the better designed OS. A solid design leads to a stable, maintainable program, if you apply band aid upon band aid, the design becomes garbled, stuff start to get unpredictable (Call X sometimes behaves like in way A, and sometimes it’s in ‘band aid’ mode and behaves in way B) and you’ll end up with an unmaintainable, unstable, quirky mess.

  42. Anonymous says:

    "Did X11 have to be DOS-compatible?"

    No matter what the answer to that question was initially, it ended up being compatible. DesqView/X ran X11 under DOS+a 386 extender, much like Windows/386, etc.

    DV/X could actually do some pretty cool stuff. Since it could display DOS/Windows apps in X11 windows, it was possible to use it to remotely display DOS and Windows apps on other X Windows consoles. Somebody on a Sun workstation could remotely run a DOS or Windows app on a machine running DV/X and have it display on their Sun’s display.

  43. Anonymous says:

    "People have made linux run in single user mode on a 286 in retrospect, but that’s working backwards from new technology, which is much easier than working forwards. "

    That’s an odd statement, considering that Minix, Torvald’s original inspiriation for Linux, multitasked on an 8088-class machine. That was (obviously) before Linux ran on the 386, and well before Linux was backported to the 286.

    It’s also worth pointing out that the PDP-7 on which Unix was originally developed had an 80K address space, very limited memory protection, and could support multiple users as it blazed along at 1MHz.

  44. Anonymous says:

    Andreas Magnusson: Did your students report the X11 crash to the maintainer? Best way to get it fixed.

    I’d never say in all ways X is superior. It’s just interesting to see the different design philosophies. Personally I think having a separate process, the window manager, control the windows is a lot saner than having the indvidual processes do it. Mainly because if a process is poorly coded or hangs it makes the OS look unresponsive or broken, not just the app.

    I like coming to this site, and I usually try to hold my tongue, mainly because I do realize the readership here doesn’t want to hear about how great the alternatives are.

    I just am shocked sometimes that a company with top programmers and seemingly infinite money sometimes seems to make such poor design decisions. Backwards compatibility is a noble goal, but you shouldn’t let it become a crutch.

    I do hope MS software improves, because maybe it will decrease the amount of hours a year I am unwillingly obligated to support friends/family computers who despite MS’s best efforts have backwards compatibility, security, and non-intuitive interface issues.

    I wish there was some sort of "favors called from computer-knowledgable friend" on total cost of ownership reports.

  45. Anonymous says:

    Vince: He didn’t say it crashed. He said it hang.

    Which means the student programs probably did a "grab" (probably a server grab or a mouse grab).

    A server grab means you own the server (i.e. only you can draw), which looks a lot like a hang.

    A mouse grab means you are the only one who receives mouse events (you also have a keyboard grab, which does the same thing to the keyboard). It can also look like a hang.

    There are special keys to release grabs (disabled by default — see the AllowDeactivateGrabs and AllowClosedownGrabs options on XFree86).

    Sorry for continuing an offtopic thread.

  46. Anonymous says:

    Actually (to clear up the discussion about my students), they wrote a Java-app that had an infinte loop in the update-method (called to repaint the window).

    I also think that in this case the app kept feeding X with requests to repaint the window.

    I must admit I haven’t tried to reproduce this under Windows so I don’t know if it would hang Windows dead or just take up 99% of the CPU (and thus be killable by TaskManager).

  47. Anonymous says:

    Andreas,

    I suspect in Windows the app would appear to be hanged although the window is repainting, which is unusual but possible … I’ve actually done things like this by mistake before in my early days of Windows programming, such as mishandling WM_PAINT and having Windows keep resending it, which actually causes a worse situation because Windows sees the app responding to messages but the message queue is being flooded with paint messages so the application doesn’t appear to be hanged but instead just runs very sluggishly, dragging around the screen in jolty fashion – Windows doesn’t take over like it normally would because the app looks to Windows like it is still running okay.

    Under Windows 2000 and XP in the situation your students found themselves in, the app will not be responding to messages so two clicks on the close gadget should trigger Windows’ "Application is not responding" message and allow you to end the task.

    A problem with the X Window System design, of course, is that in most cases the display server is a single process and if you get that busy doing something it looks like the whole system is locked but if you were to log in to a non-console TTY (say, an SSH session from another host) you’d find that the system was still running fine underneath and you could kill the offending process from there, but of course that’s hardly a good solution.

    I remember seeing an interesting X Window System server for Windows a while back, actually. What made it interesting was that for each application connection it would fork off a child process responsible for handling that connection only. This was possible because it ran "rootless" and created Windows windows, so a master process to manage the ultimate display wasn’t necessary. (or rather, it was necessary but provided by Windows itself) I think it did still use the parent process for IPC but that was to handle things like the clipboard and not painting and interaction issues.

    It’s clear that both designs have their pros and cons. Nothing’s perfect.

  48. Anonymous says:

    "…were to log in to a non-console TTY …"

    Yes, that’s what we did and killed the X server, or rather the sys-admins did, since the X server is running as root (or something with a higher level than ordinary users anyway) and the class is at a major university here in Sweden, so security is important.

    My post was not a complaint about linux, but rather about the design of X (which leads to situations like that) since another poster held it in such high regard.

  49. Anonymous says:

    "(Shatter attack anyone ?). "

    What about them?

    Window messages aren’t trusted input. Shatter attacks are no more fundamental than an application crashing because you pass too much on the command line or because you send too much through a socket. They’re all problems of trusting untrustworthy input, and all fixable (in essentially the same way) as soon as one realizes this.

  50. Anonymous says:

    I already wrote why 16-bit apps are still important.

    But certainly you want your Windows 2000 apps to keep running, don’t you? They rely on the same window manager feature that the old 16-bit apps do.

  51. Anonymous says:

    Pardon my arrogance here, but I find it quite amusing that there’s only Windows that can’t restore things in the right order. My Linux desktop can hapilly restore in the right order (even if one of more of the windows has crashed), and the iBook’s desktop does it nicely too, although I’ve no experience of a crashed app in MacOS X yet ;)

    Perhaps it’s time Windows had a new window manager that doesn’t rely on a program to be actually working for it to make it do things, like resize, restore, minimise windows etc.

    As for the backwards compatibility issue, does windows *really* need it any more? Why are you still supporting DOS programs? If I want to use a DOS program, I won’t try and mungs XP round to try and run it, I’ll dig out the old 486 and run it on that.. Similar for Win95/98 apps.. I’m fairly sure if you stopped with the backwards compatibility thing, Windows would work a fair bit better than it does at the moment.. And I might have half a reason to actually use my Windows box rather than it sitting there donig nothing whilst I use the mac and linux boxes.

    </rant>

Comments are closed.