Why is it even possible to disable the desktop anyway?

Date:October 21, 2005 / year-entry #315
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20051021-11/?p=33673
Comments:    13
Summary:Some time ago, I mentioned the dangers of disabling the desktop window. But why is it even possible to disable the desktop anyway? This is simply an artifact of the history of philosophy of Windows operating system design. Back in the old days, memory was tight, hard drives were luxuries, the most popular CPU for...

Some time ago, I mentioned the dangers of disabling the desktop window. But why is it even possible to disable the desktop anyway?

This is simply an artifact of the history of philosophy of Windows operating system design.

Back in the old days, memory was tight, hard drives were luxuries, the most popular CPU for the IBM PC didn't have memory protection, and software development was reserved for the rarefied elite who could afford to drop a few thousand dollars on an SDK. This had several consequences:

  • Tight memory means that anything optional had to be left behind.
  • Software developers were trusted not to be stupid.
  • Software developers were trusted not to be malicious.
  • Software developers were trusted to do the right thing.

Certainly there could have been a check in all the places where windows can be disabled to reject attempts to disable the desktop window, but that would have made one window "more special" than others, undermining the "simplicity" of the window manager. Anything optional had to be left behind.

Software developers were trusted not to make the sort of stupid mistakes that led to the desktop being disabled, the heap being corrupted, or any of the other "don't do that" types of mistakes lurking in the shadows Windows programming. If such a serious mistake were to creep in, certainly their testing department would have caught it before the program was released. Software development was hard because nobody said this was going to be easy.

Software developers were trusted to treat their customers with respect. Because, after all, software developers who abuse their customers won't have customers for very long. If a program put itself in the Startup group, then it was doing so not for selfish reasons but rather because the customer actually wanted it.

The window manager was left fairly exposed, granting software developers the power to do things like install hooks, subclass windows that were owned by other processes, and manipulate the contents of the Startup group, with the assumption that software developers would use the power for good, not for evil. Don't bother stopping a program from disabling the desktop window, because maybe that program is doing it for a good reason that we hadn't thought of.

The world of software has changed much since those simpler days. I had a nice chat with my colleague Zeke where we discussed how philosophy has changed over the years. Maybe he'll write a few words on the subject...

Comments (13)
  1. Manip says:
    October 21, 2005 at 10:19 am

    I don’t have a server running here to find out the answer for myself; can that ‘trick’ be used to kill off a terminal server? Connect, run a program as a user that hooks the desktop window and then disables it, the whole machine dies…

  2. Raymond Chen - MSFT says:
    October 21, 2005 at 10:45 am

    It only kills that desktop. Other users’ desktops are unaffected.

  3. Nekto2 says:
    October 21, 2005 at 2:36 pm

    The other thing is still taken for granded is "software is a tool which is in full control of user". That means policy and security are per-user, not per-program+per-user :)

    Now it is not true.

  4. AC says:
    October 21, 2005 at 5:22 pm

    This is not an issue: it "just" brings the system to a halt, and ANY process can do it. (For example, by spawning several "time-critical" priority threads with infinite loops, which will starve everything except "time-critical" processes – and if run as admin, it can change its process priority to "time-critical" and starve even the input devices).

    I fail to see why an application would want to do this: there are better ways to halt the system.

  5. zd says:
    October 22, 2005 at 5:12 am

    You can no longer disable the desktop window now, possibly as of Windows 2000. The desktop window has finally become a "special" window.

  6. offtopic says:
    October 22, 2005 at 9:15 am

    Are Console Windows special windows too? You can’t spy them.

  7. Larry Osterman [MSFT] says:
    October 22, 2005 at 11:43 am

    offtopic, that’s because console windows aren’t "windows". They’re owned by a different subsystem, and don’t receive window messages (ok, the frame around the console window does but that’s it).

  8. ac says:
    October 22, 2005 at 3:35 pm

    the console "window frame" seems to be special aswell. All apps (I have seen) that globally change windows (extra menu options, roll’up, transparency etc.) don’t work on console windows

  9. Jonathan says:
    October 23, 2005 at 4:12 am

    And they don’t get Luna. Also, if you make a console window change a lot ("dir /s" should do the trick), you’ll see that csrss.exe is the process that utilizes the CPU for this.

  10. :: Wendy :: says:
    October 24, 2005 at 12:41 pm

    Reading your original post about ‘trusting’ developers and how that environment has changed prompted a little personal epiphany. Now that I’ve cleared up the mess the epiphany left on the floor i’ll share it with you:

    windows as a system is essentially a ‘commons’ and developers are using the commons resources. This introduces a tension – for each product developer they want to consider what is best for their user… …and provide that. However, windows has limited renewable resources (e.g. memory, start menu real-estate, processing power). If every app developer places their users needs in the forefront they are naturally reducing the resources availably to other App developers. They are in a business environment where they are essentially competing with other developers products.

    This problem is well researched by use of structured games like the ‘prisoners dilemma" http://en.wikipedia.org/wiki/Prisoner‘s_dilemma

    As a Brit i’m more aware of it as ‘the tradgedy of the commons". http://www-personal.umich.edu/~rdeyoung/tragedy.html

    Excerpt form last link:

    imagine the grazing of animals on a common ground. Individuals are motivated to add to their flocks to increase personal wealth. Yet, every animal added to the total degrades the commons a small amount. Although the degradation for each additional animal is small relative to the gain in wealth for the owner, if all owners follow this pattern the commons will ultimately be destroyed. And, being rational actors, each owner ads to their flock

    Analogy – adding a sheep to the folck is like a Dev adding a program to the start menu….

    It’s possible that this kind of research has produced something useful that Microsoft could implement as strategies to support the use of windows resources by developers.

  11. The Old New Thing says:
    February 16, 2006 at 10:00 am

    Like prevent a computer from shutting down.

  12. The Old New Thing says:
    June 13, 2006 at 10:00 am

    It gets worse and worse until it works in the worst way possible.

  13. The Old New Thing says:
    January 17, 2008 at 11:12 am

    It didn’t do quite as much back then.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index