Why does the taskbar default to the bottom of the screen?

Date:September 12, 2003 / year-entry #58
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20030912-00/?p=42543
Comments:    13
Summary:The original taskbar didn't look at all like what you see today. It defaulted to the top of the screen.

It didn't always.

The original taskbar didn't look at all like what you see today. It defaulted to the top of the screen and looked something like this.

This is definitely not what it actually looked like. It has been so long I forgot precisely what it looked like (I didn't realize there was going to be a quiz ten years later), but this captures the basic flavor, at least for the purpose of this discussion.

The point is that the bar took the form, not of buttons, but of tabs. Each tab corresponded to a running window, which melded into the tab. You switched window by clicking the corresponding tab.

You can see vestiges of this style in the TCS_BUTTONS style in the tab control. When we switched to the button-look for the taskbar, we still had a lot of switching code based on the tabs metaphor, and it was less work to add a button-look to the tab control than it was to rewrite all the switching code.

The tabbed look was abandoned for various reasons, one of which was what everybody else has already noticed: If you put the taskbar at the top of the screen, lots of windows end up sliding under it, because they assumed that the usable area of the screen began at (0,0). Other windows would "creep" up the screen because they used GetWindowPlacement to save their window position (which returns workspace coordinates, where (0,0) is the first usable pixel) but use SetWindowPos to restore it (which uses screen coordinates, where (0,0) is the upper left pixel of the primary monitor).

There were too many apps that kept sliding under the top-docked taskbar so we had to abandon that idea and move it to the bottom.

It's somewhat disheartening to observe that now, eight years later, apps still mess up their coordinate systems and keep sliding under a top-docked or left-docked taskbar.


Comments (13)
  1. dom says:

    heh,

    I have for a long time docked my taskbar to the top.

    A co-worker noticed this and had a bit of a fit: I pointed out that it was entirely logical; at least then the Start menu drops DOWN like all other menus, instead of UP!

    Our boss resolved the issue by proclaiming, "Never trust anybody who docks their taskbar at the top."

    Now I dock it on the left, it’s far more efficient in screen real-estate when lots of apps are open.

  2. Dewayne Christensen says:

    …apps still mess up…and keep sliding under…

    Can you say IL DASM?

  3. John Cavnar-Johnson says:

    I recently switched to docking my taskbar at the top. There are sooo many apps that misbehave (ehem, even Microsoft apps). I’ve gotten really good at Alt-spacebar, down arrow, down arrow…

  4. DavidK says:

    Does XP force apps to behave better with a top-docked taskbar? I was worried one of the apps I wrote would fall into the trap, but it behaves fine under XP; I haven’t tested it under anything else yet.

  5. DavidK says:

    Ah, good for me, I AM using SetWindowPlacement :)

  6. runtime says:

    If bad apps drew themselves at (0,0), then why not move the coordinate system? Have (0,0) began the the lower left corner of the taskbar. So logical coordinate (0,0) would be drawn at physical pixel (0,20) or whatever. Since no app should draw using negative "off screen" coordinates, they would not be allowed to draw over the taskbar.

    But Fitt’s Law tells us that having the taskbar at the top would still be a bad idea because the app menu bars would not be at the edge of the screen (where they can easily be clicked). Of course, I just glanced at the top of my Windows XP desktop and see that the File menu is still not at the top of the screen because of the enormous window title bar. :-(

  7. Raymond Chen says:

    Changing the coordinate system would have broken soooo many apps: Any app that wanted to cover the entire screen (screensavers, games, PowerPoint) would end up leaving the taskbar exposed.

  8. Ryan Eibling says:

    I’ve docked my taskbar at the top for years, and I don’t know if it has anything to do with Windows XP but very few apps slide under it anymore. Aside from some example code from the ‘net, the only app I can remember doing it in the past year or two was Mame.

  9. dmitri says:

    what a load of hogwash, the reason it’s on the bottom is so MS can point to one more thing that makes Windows different from the MacOS. and it worked, it helped them in their court cases.

    don’t try to re-write history Raymond. i can’t believe no else has made this comment yet.

  10. I find it quite amusing that "it was less work to add a button-look to the tab control than it was to rewrite all the switching code".
    This is virtually the very definition of "hacking" over doing development properly – instead of changing your code to use the correct API (buttons), you hack into the API (tab control) and force it into an entirely alien "button" concept.
    Yes yes I know that sometimes you do hacks to get quick results, but this is the company with (even then) almost unlimited resources to do things right, and who obviously never minded letting things slip.
    Cheers

  11. matthew says:

    there is a piece of shareware called shove-it that will solve this problem

  12. Raymond Chen says:

    Commenting on this article has been closed.

  13. GetWindowPlacement.

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