| Date: | October 29, 2004 / year-entry #379 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041029-00/?p=37443 |
| Comments: | 36 |
| Summary: | The taskbar created all sorts of interesting problems, since the work area was not equal to the entire screen dimensions. (Multiple monitors created similar problems.) "Why didn't the gui return the usable workspace as the root window (excluding the taskbar)?" That would have made things even worse. Lots of programs want to cover the entire... |
The taskbar created all sorts of interesting problems, since the work area was not equal to the entire screen dimensions. (Multiple monitors created similar problems.) "Why didn't the gui return the usable workspace as the root window (excluding the taskbar)?" That would have made things even worse. Lots of programs want to cover the entire screen. Games, for example, are very keen on covering the entire screen. Slideshow programs also want to cover the entire screen. (This includes both slideshows for digital pictures as well as business presentations.) Screen savers of course must cover the entire screen. If the desktop window didn't include the taskbar, then those programs would leave a taskbar visible while they did their thing. This is particularly dangerous for screen savers, since a user could just click on the taskbar to switch to another program without going through the screen saver's password lock! And if the taskbar were docked at the top or left edge of the screen, this would have resulted in the desktop window not beginning at coordinates (0,0), which would no doubt have caused widespread havoc. (Alternatively, one could have changed the coordinate system so that (0, 0) was no longer the top left corner of the screen, but that would have broken so many programs it wouldn't have been funny.) [Raymond is currently on vacation; this message was pre-recorded.] |
Comments (36)
Comments are closed. |
If you’re relying on the screen saver for security than your machine is completely unprotected for the 5 or whatever minutes before the screen saver kicks in. Just don’t do that, if you want your machine to be secure you need to lock it, not wait for the screen saver.
You can activate the screen saver from the office shortcut bar. And I doubt the screen saver is designed for serious security anyway, just basic protection from prying eyes. There’s no reason to stop this working just so you can have the desktop area not include the task bar :)
Jerry: I believe you’re missing the point of this article completely.
So why couldn’t games, slideshows and screensavers call a "hide the taskbar" function so that they could use the entire screen?
Granted old applications would not work quite correctly… For old screensavers, windows could even hide the taskbar as part of the code to call the screensaver…
Dito…
Windows Media Player is a particularly bad example of starting under the taskbar (I’m a taskbar-on-top weirdo too.)
I recently did a quick-and-dirty "Outlook style" fading pop-up window, and had to deal with this issue in getting the placement right. It turns out there IS a .NET library function to return the usable workspace. It’s a shame that the Win32 API didn’t sprout this as a library function and tell normal (non-full screen) applications to use it instead.
Adam, it does exist in the Win32 API. SystemParametersInfo(SPI_GETWORKAREA). It would be what the .NET function calls.
Jack – I’m just nitpicking on one of Raymond’s argument for that feature. One shouldn’t encourage the feeling that screen saver password protection is secure, because you can’t use the taskbar to switch to another app. There are plenty of valid reasons why the desktop window spans the whole screen, but the screen saver security is not one of them.
The screen saver should be on its own desktop anyway. Or has that changed with XP?
Stuart: Because games from before Win95 didn’t need to do that, and therefore they shouldn’t need to be updated when win95 came out.
This has gotten me curious, though.
How do programs maximize and not cover the taskbar? Even ancient programs do that fine.
Vorn
And now I think of something I wanted to rant about, related to this.
I’ve been on a Master Of Orion (what, 1993? something like that) kick lately, and I play it on my Mac (with OS X). So MoO sizes its main window to take up the whole screen, except for the menu bar, and a sliver on the right side (where the planet info panel goes) – this puts the bottom underneath the Dock.
The window has resizing disabled.
On any game setting other than "Huge", the actual playable map area is significantly smaller than the window itself, causing awful click-location issues.
Let this be a lesson, folks. Make sure people can resize their windows. :)
Vorn
Jerry – I believe that Raymond’s comment about the security of screen saver password protection applies to Windows 9x only; in Windows NT/2000/XP/2003, the security is much stronger.
If I remember correctly, on NT a password-protected screen saver is launched on a different WinStation and while it runs, neither the user nor the screen saver can interact with the real desktop in any form; that’s why you don’t see "desktop shuffle" screen savers anymore; NT’s security model makes it pretty much impossible for a screen saver to get a bitmap image of the desktop surface.
The only way to exit the screen saver and access the desktop is via the Computer Unlock screen; the screen saver has no control over it. The Unlock screen runs under the SYSTEM account on yet another WinStation and will not switch back to the main WinStation until you provide your Windows password. I think that by default, SYSTEM is the only account that can control WinStations.
Check out Keith Brown’s Programming Windows Security (http://www.amazon.com/exec/obidos/ASIN/0201604426). I don’t have it at hand, but it talks about WinStations.
As a user with the task bar at the top of the screen (auto-hide turned off) I see a lot of poorly behaved programs that launch *under* the taskbar. Becaue the title bar is under the taskbar, it’s impossible to directly move the window using the mouse.
The only way to move them is alt-space, M (for move), move the screen with the arrow keys and hit enter.
Is there a better way to address this issue?
Vorn: because when you maximize a window the window manager takes care of positioning it, not the window itself (even though it could, but regular app, with a regular window wouldn’t), so when you maximize a very old app, that doesn’t know anything about the taskbar the window won’t cover it, because the window manager knows that a maximized window will exclude the taskbar (and any other desktop bars) and positions it correctly.
And for the screen saver – it is better in NT line but still, you shouldn’t realy on it for security. That’s what Lock Workstation is for. NT screen savers should have never had password protection.
Vorn>"How do programs maximize and not cover the taskbar? Even ancient programs do that fine."
When DefWindowProc recevies WM_GETMINMAXINFO, it calculates the proper maximized size and position.
Jerry: NT screen savers should have never had password protection.
They don’t, NT just has an option to automatically lock the workstation when the screensaver is activated.
10/29/2004 11:00 AM Adam Vandenberg
> Windows Media Player is a particularly bad
> example of starting under the taskbar
And Virtual PC 2004, both its console and its windows for guest machines. And a number of dialog boxes for built-in parts of Windows, though I think the number is smaller than it used to be.
You’ll be relieved to know that this problem remains more serious in Linux than in Windows. There was even a case where I couldn’t set window manager options because the window manager was written by someone who never imagined an 800×600 screen, so the options window opened centered with all four edges off-screen and I couldn’t grab anything to try to resize it. Fortunately the cancel button was on-screen.
Ive always found that the most troubling aspect of the Win32 dialog unit concept. One can’t make dialogs that fit exactly in a particular number of pixels.
Dialog boxes scale with the user’s DPI. Windows is intentionally making it hard for you to do the wrong thing.
Windows makes it hard to do one wrong thing, i.e. creating dialogs that don’t scale, but it also makes it hard to avoid doing another wrong thing, i.e. creating dialogs that can’t be resized manually. One of the most painful results of this was the Windows 95 file dialog.
Anyone still using 800×600 deserves what they get :)
I like using dialogs. Theyre a real convinient way to throw together a small "windows forms" type window using just the Win32 API.
The dialog unit thing, while great for popup dialogs, doesnt play nice with kiosk, or embedded / CE type applications where the requirement is to get a dialog that fits the screen. Getting a 240×320 (iirc) pel dialog on a CE device isn’t easy to do in an obviously correct way.
There’s nothing weird about putting the taskbar on the top. It makes perfect sense. Menus should drop down (not erupt upwards), so placing the taskbar at the top makes the Start Menu behave properly.
DrPizza, menus do drop down. The problem is that the top is reserved for apps – if you stuck the taskbar up there, you’d have two levels of menu, which is just confusing.
Apple avoids this by merging the system and app menus – I would imagine that, if MS had done the same, it might be too similar to mac operation for some people’s taste. That, or it would break stuff.
WS_THICKFRAME makes your dialog resizable.
I need to correct myself and apologize. Now that I’m back in my office, I had a chance to check my literature and found that I got quite a few things messed up. Teaches me not to post from memory without verify with my sources first. I apologize for any confusion.
Wherever I talked about "WinStations" it should have been "Desktops within the main WinStation (WinSta0)". Even after this correction, my comment is still not right. NT’s screen savers are indeed a lot more secure than 9x because the workstation becomes locked; I’m not so sure of the role that "Desktops" play on it. Please ignore my comment and review a reliable source before assuming anything about how the security of a locked workstation works.
Resizing dialogs is often very easy. Bind dialog control edge(s) to parent dialog edge(s), and on resize maintain corresponding distance set queried from dialog after initial creation. (This comes out at about 180 lines of code, including a set of macros to make constructing the tables less painful.)
This, I think, will correctly handle the dialog units issue, because by the time the querying (which works in pixels) is done, the dialog’s layout will have been set up as appropriate.
Not suitable for all types of dialog, I must admit, but better than nothing. Such a shame that that is exactly what you get :-|
"set queried", sorry, I mean "queried".
11/1/2004 12:02 AM Raymond Chen
> Dialog boxes scale with the user’s DPI.
Surely the number of users who get their DPI right is even lower than the number of users who do other kinds of abnormal geeky things that we talk about.
Even on notebook PCs where the manufacturer knew what the DPI was (except when the user attaches an external display), Windows doesn’t know and some of us geeks don’t know how to tell Windows and some of us never computed it to tell ourselves either.
> Windows is intentionally making it hard for
> you to do the wrong thing.
Sure, while also intentionally making it hard to do right things, such as making the dialog box fit in the visible area of the screen, making it resizable as necessary, and making scroll bars available when resizing isn’t adequate. OK, those last two items aren’t really true, Windows doesn’t make them too hard, but Windows itself didn’t use those features when necessary. Improved in Windows 2000 and XP, but still missing in some cases.
11/1/2004 4:25 AM Jon Potter
> Anyone still using 800×600 deserves what
> they get :)
I don’t enjoy it, but it fit in a briefcase. I no longer enjoy 1024×768 either but it still fits in a briefcase. (I do see your smiley, but the fact is still the fact.)
Dynamic dialog box resizing requires information that isn’t encoded in the dialog template. E.g., "if the dialog changes size, this control should (a) stay put, (b) move, (c) resize. And if (b) or (c), by how much?" The dialog manager isn’t psychic.
@Tom
"Resizing dialogs is often very easy. … (This comes out at about 180 lines of code)"
@Raymond
"if the dialog changes size, this control should (a) stay put, (b) move, (c) resize. And if (b) or (c), by how much?" The dialog manager isn’t psychic."
Have you had a look at Interface Builder on OS X? When you layout your dialog you attach little springy things to the controls to indicate which one of Raymond’s (a),(b) or (c) to do in the event of a resize.
It makes stuff like a resizeable window containing an RTF view that resizes to fill the available space but maintains a constant margin a zero lines of code job.
It’s not that its desperately hard on Windows but being a lazy dev I’ll probably pass on resizing in Windows but implement it on OS X as its so trivial.
"Have you had a look at Interface Builder on OS X? When you layout your dialog you attach little springy things to the controls to indicate which one of Raymond’s (a),(b) or (c) to do in the event of a resize."
I’m surprised it’s not been added to Windows controls, or at least as a feature in the .NET tools; maybe the shiny new Avalon will do something like this?
A few years ago I was working on a project that required a number of resizable dialogs, and after much hair-pulling in the end I settled on adding custom behaviour to the standard widgets, allowing me to "easily" set absolute or relative positions, anchor points, etc. Unfortunately it was nowhere near production quality — you had to be careful to avoid circular references and stuff as I couldn’t be bothered to check for them myself, and sometimes it would exhibit strange behaviour when certain elements reached critical sizes — and making a nice friendly version is currently number 456 on my huge list of brilliant ideas I have neither the time nor the patience to develop… (Plus All My IP Are Belong To my ex-employer, and I’m sure someone else has beaten me to it anyway.)
Mat – "I’m surprised it’s not been added to Windows controls, or at least as a feature in the .NET tools; "
This is exactly what the Anchor and Dock properties of .Net WinForms controls are for. Play around with them a little bit, it’s very intuitive and easy to use.
"This is exactly what the Anchor and Dock properties of .Net WinForms controls are for. Play around with them a little bit, it’s very intuitive and easy to use."
I’d not noticed them — we’re stuck in the dark days of VB6 here, and although I downloaded the .NET Studio Express beta at home I’ve not played with it much; good to see my complaint is unjustified! :)
If the root window were positioned as the work area, and if this would have restricted programs that want the whole screen, then what would have stopped it from restricting the taskbar too?
Am I misinterpreting something here?
@Raymond
"if the dialog changes size, this control should (a) stay put, (b) move, (c) resize. And if (b) or (c), by how much?" The dialog manager isn’t psychic."
You guys should really look at Borland Delphi, http://www.borland.com/delphi which has been doing this since 1995-96.
Want all (almost) the .NET framework features now in Win32 (but without the 20-22MB overhead), fast? Use Delphi! ;o)
Written by the same guy who architect-ed the .NET framework, Anders Hejlsberg.