Welcome to MSDN Blogs Sign in | Join | Help

Because programmers were trusted to do the right thing, part 2

Some time ago, I discussed briefly the philosophy of API design that prevailed in the early days. One of the places this manifested itself was in the area of power management. As originally designed, power management was a cooperative affair (as was nearly everything in Windows in the early days). When the user attempted to put the computer into a low power state, the system sent a WM_POWER message to each program, allowing it to prepare for the suspend operation, say, closing network resources or flushing caches, or even reject the suspend attempt outright.

Programmers were trusted to do the right thing. Rejecting the suspend attempt should be done based on user confirmation. For example, a program might put up the message, "You have unsaved changes to the database record. Save the changes before suspending?" with the replies Yes, No or Cancel. Selecting "Yes" would save the changes, selecting "No" would leave the changes unsaved, and selecting "Cancel" would cancel the suspend operation. Programs were discouraged from rejecting the suspend operation without receiving confirmation from the user, although this was not enforced because a program might have a legitimate need to fail the suspend silently. What would that legitimate need be? Who knows, but maybe there is one out there, and Windows was being flexible enough to allow for that possibility.

As Huat Chye Lim pointed out over on the Windows Mobile PC Team Blog, the result of this was that everybody considered themselves to be one of these "exceptional" cases that didn't need to get user confirmation before rejecting a suspend request. Ultimately, the result was that for many users, the suspend command simply never worked. Programmers were trusted to do the right thing, and they abused that trust.

Those who were at the 2005 PDC and attended FUN319 Windows Vista: Developing Power-Aware Applications learned that Windows Vista is addressing the issue by simply not trusting programs any more. Programs will no longer able to reject suspend requests or even to delay the suspend for more than a few seconds. That's what happens when you don't play friendly: The person with the ball simply doesn't won't let you play any more.

Published Thursday, February 16, 2006 7:00 AM by oldnewthing
Filed under:

Comments

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 10:08 AM by ..
Wow! Can't wait till the day my laptop will standby when flashing some rom or doing some delicate work. Here we have many program set to always deny standby because for our work the laptop must be always on (even when closed) and checking the settings on every pc is impratical.

Thanks to the person with the ball, who, as always, is imposing his view on every other like most dictators.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 10:35 AM by Marty Thompson
What's the difference it suspends(in Vista) or runs out of power(your way)?  Either way you're in danger.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 10:49 AM by Pazu
If there is possibility to disable the suspend-mode - what is a problem ?? Flashing of ROM - always risky - if there is no suspend and you do it on batteries, you can of course expect the worst ! So what next ? Nothing ? Good. Finally somebody in MSFT realised that OS has to imperative, othervise there is no security and stability.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 10:57 AM by BryanK
Because XP (at least on the few laptops we have) will still suspend, even if the machine is plugged into AC and the battery is in use.  You never flash a ROM while on battery anyway (or at least, you shouldn't).

On a sort-of-related note: Anyone know why XP no longer allows programs to shut the machine down but *NOT* power it off?  We have several services running on our shop-floor machines that require this capability.  For instance, one is a watchdog card service.  When the watchdog doesn't get reset, the service (if it's still able to run) does a clean machine shutdown and tells the watchdog card to toggle the reset line on the motherboard after a fixed delay (something like 30 seconds).  The watchdog plugs into the reset switch header on the motherboard, and connects these contacts after the delay elapses.  But if the machine doesn't stay powered on, the reset contact doesn't do anything.  And if the machine doesn't shut down at all, then the FS is in danger of getting screwed up.

So does anyone know why this capability got removed?  (MSDN even got updated, at least the online version.  The VS .Net 2003 version still says that InitiateSystemShutdownEx's bRebootAfterShutdown parameter will shut down but not power off if it's set to FALSE ("Windows XP and earlier: A message is displayed indicating it is safe to power down"); the online version says that it will "safely power down" the system when it's set to FALSE.)

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:28 AM by Alun Jones
A lot of this would be helped if Microsoft made available (in documentation, not in fleeting presentations at PDC) statements on the philosophy of certain elements of the API.

I learned a long time ago that once you understood the philosophy behind an API, you found yourself programming with it, rather than against it, and programs are written far faster, smaller, and with less hassle.  So, why is it that we have to divine the philosophy from trial and error?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:30 AM by Randolpho
Can't delay or suspend more than a few seconds...

But you do still get a power event notice, right? If so, I think this is a wise way to go.

You at least still know there's a power event occuring, and have a few seconds to do whatever you need to do in order to handle it. If you chose to ignore it, and you get shutdown mid-process, you (the programmer) messed up and deserve to be berated by an irate user.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:33 AM by SuperKoko
Why not requesting for the user advice when a window returns PWR_FAIL on WM_POWER message?
Something like:
"The state of program <executable-file-name> may be altered when passing into low power mode. Are you sure you want to pass in low power?"

Both behaviours :
rejecting blindlessly the WM_POWER operation without user's advice, for a program.

Or

Rejecting blindlessly program advice & user advice, for Windows.

Appear to be bad.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:50 AM by James Schend
Microsoft's greatest enemy is and has always been the 3rd party developers writing for their OSes.  Notice how Apple never has any problems like this... I don't know exactly what it is that Apple is doing right, but it might be a good idea to copy it and raise the quality of Windows software.

I'm really sick of not being able to run as administrator because of broken third party software, and having sleep disabled on my computer would just make me mad as hell.

The other part of this equation is why do Windows users stand for it?  I think it's just ignorance... there's no way to tell which programs will crap all over your system until you've already bought and installed it.  Windows should have some kind of notification system, informing the developer (and user) of which Windows API rules they're breaking and tallying a final score for them.  "Move the mouse cursor without user interaction?  -100 points."  Something like that.  Additionally, Microsoft should provide a testing environment (perhaps using VirtualPC) which could automatically test for things like 'windows directory not in the default loaction' or 'really restrictive file permissions' and tell the programmer what part of his program failed, and what to do to fix it.

But the most important thing is to make the developers *want* to fix it.  Normally when I point out stuff like, "you shouldn't hard-code the path c:\Windows because that will break on some systems", the response is usually, "who cares?  I'll fix it when it happens."  You need to convince programmers that doing things the right way is always easier in the long run, and usually easier in the short run also.

Enough ranting.  I'm just sick of the quality of the software out there.  The very fact that IBM can produce a product as terrible as Lotus Notes, and then sell it for *more money* than Exchange/Outlook... that means something is VERY WRONG with the free market as it relates to the computing industry.

# :rolleyes:

Thursday, February 16, 2006 11:54 AM by Maurits
Oh... my... God.

How arrogant is this?

Give the user the option.  Let the program say it wants to cancel the suspend, and have WINDOWS pop up a box:

[?] Cancel Suspend?
<such-and-such program> wants to cancel the suspend.  Cancel the suspend?

[ Yes ] [ No ]
[ ] Remember my choice for this program

where the "remember" input is a checkbox.

Oh, and provide a means on the Power Options control panel to clear the "remember" memory.

If the guy with the ball won't let anyone play, the neighborhood kids are likely to go get their own ball.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:54 AM by josh
Well, if it's suspending because you closed your laptop, eg, all the user prompting in the world won't help.  You're not gonna see any of it.

Of course you could have a timeout to some default behavior...

# timeout = "No"

Thursday, February 16, 2006 11:56 AM by Maurits
If the user doesn't press "Yes" within a preset time, "No" should be the default action (similar to the "End Now" button when shutting down)

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:59 AM by oldnewthing
James Schend: It's called the Application Verifier. Check it out.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:02 PM by N. Coffey
I think SuperKoko has the right idea, above.  Don't explicitly trust the programs, but at least take their advice.  I'd pick a friendlier wording, though.

"The program 'AppName' may need attention before going into sleep mode.  Please be sure any open files are saved, or exit the program if necessary.  Sleep mode will continue anyway in [x] seconds."

Stuff in a "Sleep Anyway" button and a "Cancel Sleep" button (yeah, forget "ok" and "cancel"), and the hardest part becomes figuring out a good value for [x]. This allows programs to request attention, while still allowing sleep to continue (albeit slightly delayed) without further user intervention.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:08 PM by Doug McClean
Why does the newer version of Office (I think it is Office XP?) stop you from shutting down windows when "an office application is open"? It got a notification that I want to shut down, clearly, to put up the dialog. Couldn't it respond by saving my work and closing?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:19 PM by Matt Sayler
The issue of "trust" here reminds me a lot of the idea of cooperative multitasking.  We trust you to cede your control to the OS at decent intervals..

In general, the way to deal with these issues seems to be work ok/give preference to apps that behave nicely, but be prepared to bring down the big stick on ones that don't.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:27 PM by Not Amused Again
James Schend: Nice one. Do you know why the damn programs have to ask before allowing things to go into suspend mode? It's because MS's freakin networking code is freakin *broken*. Open files are supposed to be reconnected after a suspend, and *they are not*, leading to losses in any open files. (Not that saving the files then allowing the suspend to continue works either, as the wonderful opportunistic file locking junk seems to predictably barf after suspends.)

MS's worst enemy has always been their own programmers.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:28 PM by krisztian pinter
very smart. replace a poor behaviour with a wrong one. if there really is a program that can not finalize itself in the given time, you actually punish the user for a wrong decision (e.g. forgetting about an ongoing task, like CD burning)

the right solution would be to give the program only two options: either accept, or demand a reject and supplying an explanation message. if windows receives a reject demand, it shows a dialog, and includes the explanation, then let the user to decide what to do.

if you do so, user have full control without being punished for mistakes.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:29 PM by Michael
This is good stuff.  My biggest complaint about computers is the constant second guessing . . . you said reboot, are you really sure?  Do you really want to put the computer to sleep?  Of course I do, I clicked the bloody button.

I just want a computer that when I tell it to hibernate, it actually hibernates.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:32 PM by Anonymous Coward
The auto update functionality in XP is annoying.  It likes to reboot your computer no matter what.  This is extremely annoying if you happen to be away from your computer for a while, and come back to find out it has rebooted throwing away whatever you had going.  (Things like command line history are valuable to me, in addition to open documents etc).

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:38 PM by oldnewthing
When you enabled automatic updates, you were asked whether you wanted reboots to be automatic or not. Say "no".

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:42 PM by Thomas
Oddly enough, a while back I wrote a little utility in C to give me more control over things like this. It basically listens for the WM_POWER message, and then either cancels it, allows it, or prompts the user (defaulting to allow after 15 seconds) as to what to do, dependign on what the user chose earlier. It also does the same thing for shutdown, so I can happily stop those installers that assume a restart is always required, regardless of what actually went on in the install or what the user's doing. Are there any plans to allow special-purpose utilities like that to still work as normal, or will this affect everything?

(on another note: the linked ppt (FUN319) has a typo on slide 45. It looks like the ES_SYSTEM_REQUIRED and ES_CONTINUOUS flags have been swapped)

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:47 PM by Darren Stone
When a user shuts their laptop lid, the machine must suspend immediately.  Period.  No prompting or any other ridiculousness.

If a program is doing a risky operation, such as burning a ROM, it should ensure that the power profile is adequate before proceeding (e.g. ensuring that the machine doesn't shutdown automatically from inactivity).

It's simple.  And it's surprising that in 2006 the premier PC OS can't handle this correctly.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:49 PM by oldnewthing
"... then let the user to decide what to do."

This assumes there's a user there to answer the question. The laptop lid is closed. The user's workstation is locked or switched-away-from.

Even if you manage to get the message into the user's face, you get the "I already told you" problem. User initiates suspend. Application says, "You are watching a movie. Do you want to suspend anyway?" You say "No". The system then says, "Hey, this program cancelled the suspend. Do you want to suspend anyway?" User says, "Stupid computer. I already told you."

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 12:53 PM by Maurits
Responses inline...

> "... then let the user to decide what to do."

> This assumes there's a user there to answer the question. The laptop lid is closed. The user's workstation is locked or switched-away-from.

Timeouts fix this problem.  Default action should be to sleep as requested.

> Even if you manage to get the message into the user's face, you get the "I already told you" problem. User initiates suspend. Application says, "You are watching a movie. Do you want to suspend anyway?" You say "No". The system then says, "Hey, this program cancelled the suspend. Do you want to suspend anyway?" User says, "Stupid computer. I already told you.

The idea is to REPLACE the application dialog with the Windows dialog, not show both.  This entails allowing the app to send back a string containing the reason it would like the suspend to be cancelled.

Anyway, that's only an issue in the event that the user WANTS to cancel the suspend.  The Vista behavior you describe wouldn't allow them to cancel the suspend at all.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 1:06 PM by Gabe
Am I correct to assume that this behavior is only with user-requested suspends?

If I request a suspend while watching a movie, then I obviously am aware of it. If I'm watching a movie with my laptop connected to my TV or doing a presentation, I don't want to have to leave the lid open just to prevent the automatic suspend.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 1:07 PM by Anonymous Coward
Raymond said:

"When you enabled automatic updates, you were asked whether you wanted reboots to be automatic or not. Say "no"."

I am using XP Pro and there is no "automatic reboots" option.  In fact the word reboot doesn't appear anywhere on the page (I am using the "Automatic Updates" widget in the Control Panel).

There are 4 options:

- Automatic (recommended)
- Download, but don't install
- Notify, but don't download
- Off

None of those say anything about reboots.  The 2nd one will in theory solve the problem, but then I have to work out which updates require a reboot and which don't.

All I am asking is to stop automatically overriding me and losing *MY* information.  I will reboot *my* computer when I am ready.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 1:12 PM by oldnewthing
"work out which updates require a reboot and which don't."

All updates can potentially require a reboot if a file being updated is in use. So just assume that they always require a reboot.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 1:13 PM by vince
> When you enabled automatic updates,
> you were asked whether you wanted
> reboots to be automatic or not. Say
> "no".

Maybe, but if you made the mistake of saying "yes" windows won't let you cancel the impending shutdown, only delay it every X minutes by clicking delay.

A co-worker today had a presnetation trashed because auto-update managed to reboot his machine while he was being introduced.  He had clicked "later" earlier, but apparently this means "reboot later" not the proper action of "I'll reboot when _I_ know I can.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 1:19 PM by oldnewthing
You really need to reboot. Until you do, you're in this frankenstate and things may start crashing.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 2:16 PM by Austin
Raymond,
The force-reboot-no-matter-what-I-choose is an absolutely horrid design decision.  It assumes that I can't make a rational decision for myself.  I'm glad some programmer at 2000 miles away from me knows what's best for my computer and my time (reboots can sometimes take awhile, if I've got programs running that have a large amount of data that needs to be saved).  

I've lost data because of this, before I realized what an asinine decision MS made (No means no, k?).  And while I still have Automatic Updates enabled, now I download the specific update from the web, and I get full control over what happens next.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 2:24 PM by Jonathan_S
>None of those say anything about reboots.  The 2nd one will in theory solve the problem, but then I have to work out which updates require a reboot and which don't.

That is one thing I really like about the updater for Apple's OS-X.  It always shows, before you start installing the update, whether that update will require a reboot or not.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 2:49 PM by Vorn
OS X also needs only one restart to update everything; the same is true of Linux, in the rare occasion you need to restart at all: the entire kernel can get replaced and a reboot is not required.

Vorn

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 2:51 PM by 8
What about device drivers that need to do stuff (for example, unload themselves) when suspending? Since Vista is probably going to run a lot slower then XP, will "a few seconds" be enough, considering the hard disk will be a small one and the data very fragmented?

Reminds me of a funny problem with Windows 98. Try playing an MP3 file with ActiveMovie, and then try to suspend. You'll get a fatal exception 0D. Something with DirectSound still going on regardless of wether the sound driver still exists, I guess.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 2:59 PM by Anonymous Coward
You know, if you really want the machine to go down on suspend, just catch WM_POWER and kill the DCOM server.

I've noticed multiple behaviors with Auto Update, but never click later -> reboot. Sometimes, five minutes after clicking "Later," you get a "I'm going to reboot within a minute unless you tell me not to" dialog with a timer. Timer reaches zero? You get a reboot.

Personally, I usually get annoyed after two cycles and let it reboot.

The funny thing in all this: people *always* complain about lack of flexibility in Windows. Here, MSFT provided flexibility, 3rd party programs break it, and people blame it on the OS.

I can't hibernate my Shuttle desktop that runs XP, but none of the power stuff on my Sony Vaio laptop works in Linux. *shrug* And I used to have an iMac that crashed so hard while OS/X was doing a system update that I had to format the drive and start from scratch.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:32 PM by Sean W.
In regards to the "Reboot Now" vs. "Reboot Later" buttons, why not just have another button that says "Reboot Tomorrow," that puts it off for, say, twelve or sixteen hours?  This achieves the same goal of forcing the user to reboot, but it gives the user time to get his work done without being bothered.  I have a reboot dialog that's been bothering me all day today, and every twenty minutes or so, like clockwork, I just keep hitting "Reboot Later," when what I really want is just for it to wait for me to be done for the day.

Heck, I've been known to shut down the relevant processes in the Task Manager just so I can keep working, and I'm sure *that's* a lot less healthy for the system than the Frankenstate solution.

Graaah!  Stupid dialog box popped up again while I was writing this message.  Somebody gimme a gun and point me at the programmer who coded this wretched monstrosity...

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:37 PM by oldnewthing
Because you REALLY need to reboot soon. Your system is in an unstable state and needs to reboot to restabilize.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:53 PM by Sean W.
Al Cooper, About Face (first edition), page 178.  "Don't stop the proceedings with idiocy."  And page 179.  "You might think that 'idiocy' is too harsh a word, but it isn't...  The typical error message box is unnecessary.  It either tells the user something that he doesn't care about or demands that he fix some situation that the program could usually fix just as well."

Frankly, I don't care about the supposed state of the system.  The machine ran fine before that message appeared; and just as significant, it continues to run fine no matter how many times (or hours or days days) I click "Reboot Later."  From the user's perspective, this little dialog box is excise, plain and simple.  It tells the user that the system isn't capable of handling its daily needs without immediate attention, like a young child who needs to use a bathroom before he wets himself.  From a user-interaction perspective, this dialog box --- or perhaps the underlying model that generates the need for it --- is an unforgivable mistake.

The automatic updates system needs to be altered to fit the needs of the user --- and not the other way around.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:55 PM by Nar
>>Because you REALLY need to reboot soon
>>Your system is in an unstable state
>>and needs to reboot to restabilize.

In most Linux distros you can unlink and replace the binaries of running programs, add new versions of libraries, etc. and whenever you eventually quit the old ones the update will be complete. Why can't Windows do that?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:58 PM by Nar
I forgot to mention that the programs being updated have to be designed to be updated like that, but for your own updates you could go out of your way to make a better user experience.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 3:58 PM by oldnewthing
It only seems to run fine. You're actually running with mismatched binaries. Maybe there's only a 1% chance of data corruption but when that 1% hits you you're going to be complaining "If Windows knew that things were bad, why didn't it tell me?"

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:04 PM by oldnewthing
Nar: That works as long as all the libraries the program needs are already loaded. If a program loads a library dynamically, then it will get the new one instead of the old one, and now you have a mismatch. How does Linux address this?

Even if all the Windows components supported on-the-fly updates, you're still screwed if you're running Word or Lotus or anything else that isn't part of Windows. Say Lotus uses a component that got updated, but only used half of it at the time you installed the update. When you go to insert a picture, it loads the other half, and now it's running a mishmash of old and new.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:16 PM by Sean W.
> It only seems to run fine. You're actually
> running with mismatched binaries.

To which I say:  So what?  What you're telling me is that not only does the implementation not know how to update the system as a single atomic action, it has to bother the user with loud complaints about its failures as well.

A viable alternative implementation is to download the binaries, and determine immediately whether any of them require a reboot.  If they do, you pop up the dialog to remind the user that reboots are required to update the system, and give him the opportunity to ignore it (at his risk, obviously).  On reboot, as part of shutdown, you apply the first half of the patches, and as part of startup, you apply the other half.  From the user's perspective, he's bothered with this question no more than he cares to be, and there are no negative consequences to saying "Reboot Later" because nothing has changed.

The way it's implemented now presents a user experience like having the maintenance staff of an office building come in to replace your desk; and when they find you're still using the old one, they give you the option of coming back in 20 minutes or replacing it right now.  And the fact is that any maintenance staff that did that all day to, say, president of the company would likely be fired on the spot after the second or third time they bothered him --- and with good cause.

An alternative implementation model exists, and it's more compatible with the user's experience.  Moreover, it's not that much harder to implement than the current model.  So the dialog box can be shown to be irrelevant, and therefore it solidly earns the title of "idiocy."

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:20 PM by Frederik Slijkerman
Ok, how about this? When auto-update encounters a locked file, it rolls back the entire update, and writes it to a temp folder instead. Then it sets a flag so it knows that this should be installed at the next reboot, and tells the user that a reboot is required in order to install this update. No frankenstate, no mishmash.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:26 PM by oldnewthing
Sean W: If you want that model, then use the "Download, but don't install" option to automatic updates.

Frederik: But what if the file can't be rolled back because during the interim, somebody started using it? The frankenstate remains.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:33 PM by Myron A. Semack
FYI, the automatic-rebooting after applying security updates was added with Windows XP Serivce Pack 2.  This change was made because too many people were applying the updates and not rebooting, which leaves your system still at risk for any nasty worms that are spreading.

If the auto-reboot upsets you, you can disable it.  However, (as Mr. Chen is pointing out) you run the risk of system instability by not rebooting immedaitely afterwards.  Not rebooting is a BAD THING, but if you want to keep the gun pointed at your foot, have fun.

The registry keys for controlling this behavior are documented:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2maint.mspx

It is unfortunate that the rebooting is inconvenient for some users.  However, it is a tradeoff between usability and security.  Which is more valuable to you?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:36 PM by Andy C
"The 2nd one will in theory solve the problem, but then I have to work out which updates require a reboot and which don't. "

It's not on the GUI, however you can get the behaviour you want by using the "No auto-reboot with logged on users" Group Policy setting.

"The idea is to REPLACE the application dialog with the Windows dialog, not show both. "

How can you do that without rewriting all the old applications?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:41 PM by Anom
>> Because you REALLY need to reboot soon. Your system is in an unstable state and needs to reboot to restabilize.

Simple. The system should not apply updates until ready. Use whatever data structure to install them 90% but not completely, that is not going into "frakenstate".

The way it works now is very brain damaged and having Mr. "Pay your taxes" defend it, is ridicolous.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:43 PM by Maurits
> How can you do that without rewriting all the old applications?

1. Microsoft designs the new power messaging behavior
2. Microsoft publishes the new power messaging behavior
3. Microsoft releases betas to application developers
4. Application developers rewrite / patch / ignore according to taste
5. Microsoft releases operating system
6. Users install new versions / patch existing versions / live with told-you-twice according to taste and decisions of application developers

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:49 PM by oldnewthing
Maurits: Yup, that's how the changes to power management were handled in Windows 95. Look at all the applications that were updated accordingly! (Repeat exercise with Remote Desktop, Hierarchical Storage Management, ClearType, Roaming User Profiles, ...)

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:51 PM by Abc
"You really need to reboot. Until you do, you're in this frankenstate and things may start crashing."

So the question is, why is "Automatic" the default (and recommended) option in Windows Update?  Why is the default action set to the one that puts the clueless user into some weird "fankenstate" that is fraught with danger?  If updating DLLs while programs are running is dangerous, why give the user an option to do so?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:52 PM by Abc
"You really need to reboot. Until you do, you're in this frankenstate and things may start crashing."

So the question is, why is "Automatic" the default (and recommended) option in Windows Update?  Why is the default action set to the one that puts the clueless user into some weird "fankenstate" that is fraught with danger?  If updating DLLs while programs are running is dangerous, why give the user an option to do so?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:52 PM by Sean W.
Since I don't have any new updates to test with, it'll be hard to compare:  But I've set this machine to update using "Let me choose when to install them" as you suggested.  That said, I remember I used to have this thing set to do exactly that, and it would never remind me at all that anything needed to be done:  No messages, no notices, nothing more than an icon in the system tray that's easily overlooked among a dozen others.  So I'll give you the benefit of the doubt on this setting:  But if it doesn't tell the user at all that anything needs to be done, and doesn't do anything automatic at all, that's just as bad as the over-notification of the other setting.

A steady fallback system akin to how TCP/IP uses fallbacks would make more sense for most users than either of the two existing models:  Download the updates, and prepare to install them, and offer "Reboot Now" and "Reboot Later" as options.  For each successive time "Reboot Later" is clicked, double the amount of time you wait until the next notice, up to 24 hours.  Most users won't object to being reminded once a day that they have to do something semi-important; but most users *will* object to being reminded every 20 minutes on the same thing.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 4:53 PM by Ian Tyrrell
Maurits, you are assuming two things here:
1) That the company that produced the application in the first place still exists AND
2) That companies running the application will install an updated version. I know many won't do it, and won't patch it unless a business-critical error occurs (and then they get annoyed at the application developer).

I work programming business systems management programs, and many of the businesses that use them won't update just because we put out a patch (even if it is critical). They will only update if something stops working for them.

They might update their version of windows though. But then again, they might not. What happens then if they install your new application version, but are still running an older version of windows that doesn't support this new power management scheme?

(Not trying to be harsh, but they are important issues. Also I had some program that wouldn't let me hibernate my laptop, and I didn't discover it till I'd shut the lid and put the laptop in a bag and pulled it out several hours later to find it was incredibly hot, out of battery, and I'd lost my work (which I'd saved, but I still lost my place in the document). If I tell the computer to hibernate/shut down, it better do it. When _I_ say to.

Oh, and I hate dialog boxes, no-one reads them anyway.

# who needs a patch?

Thursday, February 16, 2006 5:07 PM by Maurits
> Maurits, you are assuming two things here

Nah, there was an "ignore" option in my previous comment.

I'm trying to save the ability for apps to cancel a suspend here, and I'm getting shot down with "but the users might have to see a dialog box twice."

Which is a bit like removing the fire escape because the color doesn't match the building.

Oh, and *ahem*: http://img513.imageshack.us/my.php?image=deletingashortcut1sd.jpg

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:12 PM by boxmonkey
I'd rather take my chances than be forced to drop everything I'm doing and reboot. It an update is really going to make a system unstable though, why not design the updates so that they don't replace any files until the reboot is performed? System is not in an unstable state even if I put off rebooting for a week. Yeah, I don't get the updates immediately, but at least I'll get them as soon as I reboot.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:15 PM by Ian Tyrrell
Ouchies, that's a whole lot of dialogs...

Fair enough re: ignoring. I missed that bit.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:15 PM by oldnewthing
Anom: I'm not defending the current model. I'm just pointing out that the proposed "solutions" are worse.

I would have designed it differently.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:15 PM by BryanK
> Nar: That works as long as all the libraries
> the program needs are already loaded. If a
> program loads a library dynamically, then it
> will get the new one instead of the old one,
> and now you have a mismatch. How does Linux
> address this?

It doesn't, but it doesn't usually have to, either.  Most programs don't link to other libraries at runtime.  Of the ones that do, they only do it on startup, not while they're running, because they use the dlopen() as a test for what addons or plugins or optional dependencies are installed.

For instance, there is no COM CreateObject API that will load the required DLL when it's called; there's only dlopen() / dlsym() / dlclose() (pretty much exactly equivalent to LoadLibrary, GetProcAddress, and FreeLibrary).  If you need to load an additional .so file to support your COM infrastructure (like FF does), then you do it at startup and leave it loaded.

When all programs do that, you can unlink (and therefore replace) any file at any time.  And when the process starts again, it'll get the new version.  (This is what Nar meant about "the programs have to be designed to do this".)  It's not a 100% simple fix, but it does work much better than Windows having to restart every time I patch anything.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:21 PM by Bjorn
Honestly, it seems the way to get rid of the C:\WINDOWS crowd is to abolish C:\WINDOWS. Ditto C:\Docume~1, C:\Progra~1, and the like. At install time (including OEM image install time), add a random extension to these directories, so we get C:\WINDOWS.A40, C:\USERS.J$E, and so on. The per-system variation will mean no one can get away with hardcoding the paths.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:44 PM by ChrisE
Regarding the hardcoded C:\WINDOWS\ insanity, I'm guessing that's why Windows 2000 installs to <drive>:\WINNT by default, but the later NT-based OSes (XP, 2003, etc.) install to \WINDOWS\?  I wonder how many applications were broken by the behavior in WinNT/Win2K.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:48 PM by Dean Harding
I forget which version it was (it might be 2003), but I've seen Windows applying updates when you actually shut down the computer. So instead of applying updates, then asking to reboot, it happens the other way around - it asks to reboot, then applies the updates. So you're never left in the "Frankenstate".

You can still be persistent: "I REALLY have to reboot to apply these updates" (because it should apply them ASAP) but at least there's no chance of screwing the system up by not updating all at once.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:54 PM by Dean Harding
BryanK: It still doesn't fix the problem though. If you have two program which communicate via some sort of IPC, and open the second one after the update, then if they used a common library for communication, you'd get a mismatch.

And if you're asking applications to play nicely with the system, then you haven't been programming Windows for long... the apps which DON'T play nicely surely outweight the ones that do everything right.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 5:57 PM by oldnewthing
"I forget which version it was (it might be 2003) [that installs updates when you shut down]"

Windows XP Service Pack 2 added this feature (which is how I would've done it). I believe you get it when you specify "Download but do not install immediately".

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 6:22 PM by oldnewthing
"Why is the automatic updates the default if it leaves you in the frankenstate?"

You only get into that state if you interfere with the automatic update and postpone the reboot. The default is to install automatically and reboot. That way, you are always up to date.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 6:43 PM by Steve
oldnewthing: "Because you REALLY need to reboot soon. Your system is in an unstable state and needs to reboot to restabilize."

If the update leaves the system in such an unstable state, then the updater should not run unless all other programs are closed. The auto-updater in XP doesn't work that way. On the contrary, it encourages the user to keep working while the update is installed.

Unless this unstable state materializes the moment the update finishes, we have a contradiction. Either the system is still stable after the update finishes or it is already unstable while the update is installed and the user is being encouraged to keep working.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:13 PM by :: Wendy ::
most people that I know systematically close all their windows and programs before they 'shutdown' their computer - i do.  during this process I notice if some 'process' that I value (burning a CD) is still happening.  When i say SHUTDOWN that's what I want,  the times it doesnt happen are when some process i dont recognise is not 'ending' so I zap the bugger with that 'end process now' dialog thingy that pops-up because I have no idea what it is or why i would want it or how long it will take if it will ever end - its gotta be something dodgy because i closed everything legitimately before hitting shutdown.

If i wanted my PC on all the time I'd never hit shutdown or get someone clever to arrange clever-setting-type-things for me.

As it is I have to sit and watch the thing shutdown (Bluhhhh!)when all is quiet and all lights are off I can leave or shut the lid and put it in its very cute carry-case.  BUT if forget sometimes,  because I trust my PC to do what i want when I've said SHUTDOWN 2 times already

Those pesky program is not responding thingys that stop shutdown have drained my battry several times.  ZAP them!!!!!

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:21 PM by J
Maurits, I don't get the point of you linking to that 7-step file delete thing.  Are you implying that since there's circumstances where Windows annoys you with 7 dialogs, then it's ok for Windows to annoy you with 2 dialogs to suspend the PC?  

Couldn't it just be that the 7-step dialog is the wrong way to do it, and you should never bug the user multiple times about the same issue?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:46 PM by Miral
"You only get into that state if you interfere with the automatic update and postpone the reboot. The default is to install automatically and reboot. That way, you are always up to date."

And missing lots of unsaved data, or web pages that you haven't read, or have read and were meaning to bookmark but hadn't yet.

No sane person would ever willingly allow their computer to spontaneously reboot whenever it felt like it.  Which is why the only sensible thing to do with the current implementation (IMO) is to set it to "download, but install only when I tell you to", and then stubbornly resist the icon in the corner until I'm actually ready to reboot.  Which tends to be about three months later (I hibernate a lot).

Better an unpatched system than a frankenstate or spontaneously rebooting one.

# guilty

Thursday, February 16, 2006 7:53 PM by Maurits
Guilty as charged :)

Yes, the 7-step dialog is wrong.
Yes, a single dialog is better than two dialogs.

But the choice is between two scenarios:

A) The operating system suspends without offering applications a chance to appeal to the user

and

B) The operating system allows applications a chance to appeal to the user to cancel a suspend;
* new and patched applications may appeal by having Windows show a single dialog;
* legacy applications may appeal by either
-- having Windows show a single dialog (these are the "naughty" apps that try to cancel the suspend without checking with the user or
-- showing a dialog themselves, then (if the user tries to cancel the suspend) Windows will show another dialog confirming (these are the "nice" apps that ask the user before trying to cancel the suspend)

I think B) is by far the lesser of two evils.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:55 PM by Peter
Perhaps I'm missing something -- but I just wrote a program that does a SendMessage (hWnd, 72=WM_POWER, 1=PRW_SUSPENDREQUEST, 0) to every window on my system (yes, I like playing with fire) -- each and every window came back right away with a '0' which, according to the docs, is not legit (they are supposed to respond with 1=PWR_OK or (-1)=PWR_FAIL.

Other than whacking horribly at my system, what have I done wrong?

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:56 PM by James Schend
1. Microsoft designs the new power messaging behavior
2. Microsoft publishes the new power messaging behavior
3. Microsoft releases betas to application developers
4. Application developers rewrite / patch / ignore according to taste
5. Microsoft releases operating system
6. Users install new versions / patch existing versions / live with told-you-twice according to taste and decisions of application developers

That would be great is number 4 ever happened, but it doesn't.

How long did it take Lotus Notes to properly support running on multi-user Windows installs?  There was a version of it (3, 4?) for NT 4, but it didn't actually *support* it until 6.5, which didn't come out until Windows XP was already out.

Do you know how many web apps force me to disable XP SP2's pop-up blocker because, despite having access to the betas and knowing it was coming, they never bothered to design their site to cope with blocked pop-ups?

That's the exact crap that makes me complain about how plain *terrible* most software is.  Microsoft only releases an OS every, what, 4-5 years?  And *still* application developers have trouble keeping up!  (Meanwhile, Apple's releasing a new OS X every 18 months or so, and OS X applications never have a problem coping with those releases or taking advantage of the new features added by Apple.)

It's the year 2006.  How come there isn't a single IM program on Windows that uses text-to-speech to speak IMs out loud, but there are a half-dozen on OS X?  (And don't tell me it's a useless feature; I love it.)  How come there are still applications that allow text input but *don't* have spell-checkers?  Does Microsoft know that a huge number of people use web clients for their email or things like, hm, this comment field?  I'd bet it's 75% of users or more... so why doesn't IE have a spell-checker?

Grah.  It just drives me nuts.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 7:56 PM by Miral
This is very belated, but:

"Do you know why the damn programs have to ask before allowing things to go into suspend mode? It's because MS's freakin networking code is freakin *broken*. Open files are supposed to be reconnected after a suspend, and *they are not*, leading to losses in any open files."

It's worse than that.  Open files on a network drive randomly drop out all the time, and never reconnect.  Apps need to never assume that just because they opened a file it'll stay that way -- it could vanish out from under them at any time.  And it's not just networked files.

One of my big peeves recently is with a VM program.  I had a VM running with a CD mounted from an image on a network server.  The network connection dropped out for a few seconds, and then I get a warning dialog saying "crap, i can't read the file" with retry/cancel -- but the retry only retried the read, it didn't reopen the file.  Meaning that even once the network was back it still failed.  And Cancel shut down the entire VM.  And I wasn't even *using* the CD at the time it happened.  Grr.

# spell checker

Thursday, February 16, 2006 8:01 PM by Maurits
> why doesn't IE have a spell-checker?

http://www.iespell.com/

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 8:02 PM by Miral
Peter:

(quoted from MSDN):
Note  The WM_POWER message is obsolete. It is provided only for compatibility with 16-bit Windows-based applications. Win32-based applications should use the WM_POWERBROADCAST message.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 8:04 PM by Jamie Anderson
Re: WM_POWER and Vista

I agree that the "shut down anyway" approach is wrong. There may be software out there that correctly says that it cannot be suspended. However, something needs to be done so that users can deal with programs (and programmers) with big egos.

I like the idea of a dialog box saying something like:

"The program 'xyzzy.exe' has indicated that the system should not be suspended. Do you want to suspend anyway?

The system will suspend automatically in ## seconds.

[ ] Remember my answer for this application."

The timer should count down from a sufficiently large value (30 or 60 seconds). This solution (a) allows rogue applications to be ignored, (b) allows correct applications to prevent shutdown, and (c) minimizes duplicate dialogs.


Re: automatic updates

I seem to remember that more recent versions of XP and 2003 allowed for hot-patching of in-use DLLs. So, shouldn't the following happen when updating:
* Updater tries to write the new DLL.
* Write fails (sharing violation).
* Updater suspends execution of all applications using the DLL. (It may have to wait for threads to exit the DLL code.)
* Updater renames the in-use DLL.
* Updater writes the new version of the DLL.
* Updater resumes any applications that were suspended.


Using this method, the code is updated nicely and without thread execution contentions. The next time the system reboots, it simply has to remove the renamed copies of the old DLLs.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 8:26 PM by Peter
>Peter:

>(quoted from MSDN):
>Note  The WM_POWER message is obsolete. It is >provided only for compatibility with 16-bit >Windows-based applications. Win32-based >applications should use the WM_POWERBROADCAST >message.

Hey, I'm just using the WM_POWER that Raymond himself is using.  What's odd, though, is that all programs are returning the wrong thing -- even all of the true-blue Microsoft ones.  You'd expect that Dos shells and IE would return the 'correct' values even for bad items.

However, when I try the same thing with WM_POWERBROADCAST (536=0x218) with a APMQUERYSUSPEND (0), I get 1's back for almost everything (yay!) and ZEROS back from three programs.  The doc, of course, say to return either TRUE (1) or BRAODCAST_QUERY_DENY which is 0x424d5144.

(This means, of course, that Raymond is pretty well right -- "nobody" is following the WM_POWER spec, and some people are doing the WM_POWERBROADCAST wrong)

Personally, I think Microsoft is doing the right thing here.  Suspend means suspend right now; anything else is wrong.  If some apps are broken (for whatever reason), then let them be replaced with working programs.

Peter

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 9:11 PM by tsrblke
Regarding the automatic updates.  MS made a simple assumption and that's that people would choose a time when they aren't likely to be using their computer (i.e. 3 AM).  Simply put the next assumption would be that people will save and exit their thngs before they leave their PC for extended periods of time.  Do I always do this: No.  But I will say this: the last time my power went out overnight and I lost some data, I learned quickly.  Is the power outage a result of bad programming? No.
So to be quite blunt, before you leave your computer for extended periods of time, you should save and exit.  This is just a good practice.  While this assumption maybe horribly wrong on MS's part, it is based on a least something viable.
And before you go off about "extended rendering times" and "compiling takes all night."  Remember, this Autoupdate was built to be as simple as possible for the user whose using Word and IE only on their computer, and so they are unaffected by these things.
(Yes, I make blatent generalizations and ad hoc assumptions in this post.  But face it, it's decently grounded at its core.)

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 9:37 PM by Miral
Default behaviour for all programs is to respond 0 to messages that they don't care about.  So that's to be expected.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:17 PM by Norman Diamond
Thursday, February 16, 2006 10:08 AM by ..
> Can't wait till the day my laptop will
> standby when flashing some rom

Me too.  Fortunately the closest problem I had to this was when Windows XP decided to suspend itself during an FTP download.  Thank you for reminding me how lucky I was, and much worse it could have been.

Thursday, February 16, 2006 12:38 PM by oldnewthing
> When you enabled automatic updates, you were
> asked whether you wanted reboots to be
> automatic or not. Say "no".

I'll gladly say "no", but, in which universe was I asked this question?

Thursday, February 16, 2006 12:47 PM by Darren Stone
> When a user shuts their laptop lid, the
> machine must suspend immediately.  Period.

Wrong.  If the user has set an option to behave that way period then it should behave that way period.

When Windows is running and lets me set what action to do, I set it to do no action, because I close the lid to turn off the backlight (and/or prevent the cat from stepping on the keyboard) while letting programs continue to run.

When Windows isn't running, usually I avoid closing the lid, though sometimes I have to hope that BIOS settings were lucky.  This is particularly relevant in the machine where I'm installing the checked build of Vista Beta 1.  Even though some part of Windows is running to some degree while installation is proceeding, control panel settings are not available.  About 3 months after I started installation, part of the plastic case burned a little bit because the backlight had been on for 3 months straight.  This is during the time when the installer says "Do not restart your computer during this time" and I don't think the installer has enabled hibernation so I didn't want to gamble on what would happen when the lid closed.  But after seeing what happened, I finally did have to gamble, and closed the lid.  Fortunately the backlight turned off but the rest of the machine continued running, just as I hoped.  Around 5 times a week I open it to check it and the installer is still going, with MSCORSVW.EXE being the biggest user.

Now, what to think when part of the plastic case burns because the backlight has been on for 3 months.  My intuition says I should take this up with Fujitsu (which I intend to do after Vista finishes installing, if I live that long).  But certain famous people say that everyone blames Microsoft no matter what, and I'm not sure if I want to disappoint them.

# re: Because programmers were trusted to do the right thing, part 2

Thursday, February 16, 2006 11:43 PM by James Day
Likely reaction from one database server: when power down notice is received, do a deliberate "crash" of the server, then a recovery of (RAM in computer less one gigabyte) of  data when the service is restarted after the reboot.

I'm not really sure that deferring say 16GB of random reads and writes in 16k chunks to system restart is desirable behavior, even though it is the behavior you need when you're facing power loss in the immediate future.

Does Microsoft desire some other behavior? At the moment, this is the one I'm going to recommend for a server with a few million Windows users.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 12:22 AM by LarryOsterman
Btw: W.r.t. the comments about why Windows closes files over the network on connection loss.

The answer is very "Raymond-ish".  "Because the alternative is worse".

I'll write up more about it tomorrow in my blog (it's late), but the simple reason is the answer to the question: "What happened to the contents of the file during the time the connection was lost?"

# Why KMDF does not have a callback for IRP_MN_QUERY_POWER/SystemPowerState

Friday, February 17, 2006 1:57 AM by A Hole In My Head
I was going to blog about this after I had some KMDF entries under my belt, but Raymond Chen got things...

# Office 2K was one of the abusers of power

Friday, February 17, 2006 2:21 AM by Steve Loughran
Raymond,

Its easy to critique all those third party apps, but office 2000 abused WM_POWER too. If you tried to suspend/hibernate win2k with a network file open, office 2k would refuse to suspend, even when the file was in the offline filestore. It was trying to be clever, but not clever enough.

I have a systray applet that triggers suspend/hibernate/shutdown without giving apps a lookin. This leaves me only vulnerable to drivers.

One problem there is the OS; if a driver refuses there is no attempt to retry, just a dialog box.  A dialog box you see later, when you pull a hot laptop out of your bag to find the battery nearly flat.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 2:59 AM by .
On the

>When a user shuts their laptop lid, the
> machine must suspend immediately.  Period.

We often do short but critical works (involving television) with laptops, sometimes off power (the job often last less than 1 hour).
We have a backup laptop, usually closed below the one we work on. Should anything happen to the main one, we close the lid of the main, swap them, open the lid of the backup and expect it to be ready (not suspended) even after 45 min of inactivity with lid closed.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 3:55 AM by Stephen Jones
The user is allowed to choose what happens when the laptop lid closes. Often he will want to chose 'do nothing', because for example he has another monitor, keyboard and mouse.

Now, perhaps Raymond can tell us if the monitor will switch off automatically in this case when the lid is closed? Unfortunately I am not able to squeeze underneath and have a peep :)

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 7:05 AM by AC
Oh yeah. When will people learn: applications should be the lowest class citizens in the system.

When I say "shutdown", I don't mean "can you please shut down?", I mean "I'm cutting the power in 30 seconds, make the most out of it because it is really going down no matter what".

A better example: the stupid "safe removal" behaviour (is it called this way in English?). I say "remove this USB drive". Windows says "no I can't". Ok, bad luck, but trust me, I have the last word on this. I have met people who have a retarded program which locks any drive; therefore "safe removal" never works. Not that it matters, they won't bother with it anymore and just remove the drive.

A much better behaviour would be to invalidate all the handles and at least unmount the filesystem cleanly. The "invalidate all the handles" thing is going to happen anyway, so...

If computers still had a classical power switch (or people knew that you can press 5 seconds to force shutdown), you'd be surprised how few would cope with the "it takes more than 1 second to switch off" bullshit.

Apart from those two things, this can be extended to other stuff such as locked files that you can't rename, move or delete. I want a "kill all handles of this file" button in the failure dialog.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 7:55 AM by SuperKoko
Peter:
For the windows returning 0 to WM_POWER, I am almost sure that it is not their fault.
It is probably due to DefWindowProc, returning zero, instead of a correct default value (I am not absolutely sure since I did'nt tested it right now, but you can test).

And, theorically, a programmer who don't handle a message (because he is not even aware of it... we cannot expect that every programmer know the hundreds of message, whose number increases at each release of Windows).

So, I am almost sure that this behaviour is due to a bug in DefWindowProc, which should be reported & fixed.

Also, It would have been nice (but now it is too late), if there existed a value (zero for example) that could be returned for any "unhandled" message, and if there were a convention for return values, similar to the one used by COM.

For example:
0  : unknown/unrecognised/unhandled message.
<0 : failure code
>0 : success code

Perhaps, -1 could be a better choice for the "universal unhandled code", hence, allowing messages to return a positive integer meaning something (for example a count), and still maintaining a coherent convention.

For example, using TRUE/FALSE for some messages and zero/non-zero for others is quite evil, because 1==TRUE==success for messages using boolean, and 0==success for many messages returning more complex values.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 8:26 AM by BryanK
Dean:

"It still doesn't fix the problem though. If you have two program which communicate via some sort of IPC, and open the second one after the update, then if they used a common library for communication, you'd get a mismatch."

Yes.  And yet, I don't think this ever happens.  That may be because IPC libraries are careful enough to include "version X" fields in their data structures, or it may be because of other things, I'm not sure.

(Perhaps it's because the programmers know the entire system.  See below.)

"And if you're asking applications to play nicely with the system, then you haven't been programming Windows for long... the apps which DON'T play nicely surely outweight the ones that do everything right."

I have been programming Windows (and cursing its stupidity) for maybe 7 years or so, actually.  Now maybe that isn't what you mean by "long", but it's been a while.  As for "the apps which DON'T play nicely surely outweigh the ones that do everything right" -- it's funny how Windows is the only OS where I see this.  As others have mentioned, it doesn't happen on OSX.  It doesn't happen on Linux.  It doesn't happen on BSD.  It probably doesn't happen on proprietary Unix-en, though I've never seen any of those to know for sure.

I think the reason is (partly) related to the fact that it seems like there are hundreds of millions of people programming for Windows that don't have a clue how to program, and/or who don't know the "philosophy" of the OS (so even if they do know how to program, they do the wrong thing with the various APIs).

The philosophy of Unix, OTOH, is fairly well known among its programmers, and the ones that don't know (because they're just starting, or whatever) have 2 things to help them learn: tons of code available that does the right thing already (since many of the applications are open-source, and many more facilities have pre-made libraries already built), and relatively better documentation (manpages for every C library function, manpages for most add-on library functions, lots of online tutorials for various common-but-hard concepts (select, X11, etc.), etc.).

And this documentation never changes, because there's an even higher commitment to backwards compatibility at certain levels (the meaning of flags passed to old system calls NEVER changes, for instance; reference my comment #3 above, regarding InitiateSystemShutdownEx -- I wonder why this wasn't flagged by the various back-compat people at Microsoft?)

# Interesting Finds

Friday, February 17, 2006 8:41 AM by Jason Haley

# Interesting Finds

Friday, February 17, 2006 8:45 AM by Jason Haley

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 9:38 AM by Matt
re 'So to be quite blunt, before you leave your computer for extended periods '

Anyone who leaves there computer on for extended periods of time [doing nothing] should be fined.

It's irresponsible to waste energy and pump out greenhouse gasses like that.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:04 AM by Moi
> perhaps Raymond can tell us if the monitor will switch off automatically in this case when the lid is closed?

I understand, Stephen, that they each laptop will come with its own little Elf, like the one that comes with each fridge, and he will switch off the monitor.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:07 AM by KiwiBlue
"Anyone who leaves there computer on for extended periods of time [doing nothing] should be fined."

Yeah, and what about those sheep left for extended periods of time doing nothing but emitting greenhouse gasses?? :D

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:12 AM by James Summerlin
I am getting a kick out of those of you who are saying what MS should and shouldn't be doing.  There are two things happening here:

1.  The change in Vista will break or hurt your program in some way and you don't like it because you were caught cheating or are trying to be cool by thinking your program is THE number one program the user has on his/her computer.

2.  Not a single one of you has spent the resources MS has in researching this problem.  You are just guessing at what you think needs to be done or what would suite you and not the user base at large.

James

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:20 AM by David Walker
"When you enabled automatic updates, you were asked whether you wanted reboots to be automatic or not. Say "no". "

Um, that's completely false.  

You are asked if you want to INSTALL updates automatically, but not if you want the machine to reboot after the install.  (OK, you could claim that the reboot is implied.  Sometimes I tell Automatic Updates to install an update, but I choose to reboot later.  It keeps reminding me, and eventually I let it reboot.)

We once had our server set to install updates at the default time of 3:00 AM, and lo and behold, one afternoon at 4:15 PM it decided to install some automatic updates AND reboot.  Bleah.  Now the server is set to download but not install updates.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:24 AM by David Walker
I see I am not the only one with that comment "there's no reboot option".

What's confusing is that when there's an automatic update notification, the GUI gives you an Express or Custom choice, and only the Custom choice says a reboot may be required.  

It implies that the Express choice won't need a reboot.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:28 AM by David Walker
And, this whole "Reboot is required" thing clearly points out that the Automatic Updates settings dialog in Control Panel should say "install and reboot", not just "install".

One choice should say "Download updates, but let me choose when to install them and reboot the system."

Another choice saying "Automatically download recommended updates for my computer and install them and reboot the system [Every day] at [3:00 AM]"

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 10:31 AM by Dewi Morgan
Suspend:
When I say "shutdown/sleep" I mean "Take your time, don't lose my data."

When I say "Force shutdown/sleep", or hold in my power button for five seconds, I mean "I understand there may be data loss, but the shutdown is more important than the data in the open applications of which I am aware."

If I close my laptop lid, or the screen saver has been on for N minutes, or I hit the "power" button on my keyboard by accident, these are not, and should never default to being, the same as holding in my power button for five seconds.

For this reason, I invariably perform a keyectomy on keyboards which have sleep/power buttons, since win2k does not permit these to be disabled or remapped, does not permit apps to prompt when they are hit, and just doesn't sleep well at all.

Updater:
"You can get safe update behaviour if you click on unrelated-advanced-option A, but not if you click unrelated-default-option B" is russian roulette at its worst: you default to shooting users.

Files to be updated should be checked to see if they can be updated. If not, the relevant update should set up installation files in the tmp dir, display an "I need to (reboot/close application X) in order to update, may I do so?" and the files should be updated in the reboot or once the application is closed. That's what I always assumed it was doing.

The idea that windows itself was playing update-roulette with my data never occurred to me, or, I suspect, any other windows user, because that's not how any other updater on earth behaves.

Unlike most of Raymond's blogs, where he demonstrated that certain windows behaviours are reasonable, this time it is clear that both these behaviours are not just bad, kludgy, or inefficient: they're evil.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 11:18 AM by Ashod Nakashian
Yet another example of NOT getting it right.

When will MS realize that the USER should choose behavior, NOT WHOEVER HAPPENS TO HAVE TO BALL!

Why not make it an option? Why isn't most things an option that the user configures? Don't you trust the user to configure to his/her needs? You know better?

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 12:24 PM by J
Ashod Nakashian:

Think about it for a second from a program perspective.  Let's say that MS lets you, the user, decide the behavior during suspends.  You can either have the computer suspend immediately, or you can let applications abort the suspend.

Don't you see that if you're writing a program, you had better assume that the user is ALWAYS going to force the computer to suspend?  If you rely on the user always letting your program abort the suspend, then your program is BROKEN.

MS absolutely got it right in this situation.

# /me passes Raymond the fire extinguisher

Friday, February 17, 2006 12:55 PM by Maurits
Wow, 100 comments in one day.  Is that a record for this blog?

# Why does the NT redirector close file handles when the network connection breaks?

Friday, February 17, 2006 1:09 PM by Larry Osterman's WebLog
Yesterday, Raymond posted an article about power suspend and it's behavior in XP and Vista.&amp;nbsp; It...

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 4:24 PM by Gabe
In the case of automatic reboots, I think there would have to be a flag indicating the urgency of the reboot shipped with the update. Something like "You are vulnerable to attack until the next reboot" would be indicated so that the user would know whether their work or the pending reboot is more important.

People seem to forget that the reboot isn't necessary just because the system is in an inconsistent state, but because the system is vulnerable to attack. Most patches nowadays are for security reasons, and any security update that requires a reboot is going to leave the system vulnerable until it happens.

# @J

Friday, February 17, 2006 6:14 PM by Maurits
> If you rely on the user always letting your program abort the suspend, then your program is BROKEN.

Um, nonsense.  The program knows what the consequences of a suspend are, at any point in time.  If these are particularly dire, the program has an OBLIGATION to alert the user.

Imagine suspending in the middle of a write to a document on a network drive, for example.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 6:31 PM by Dean Harding
Ashod: that's the whole point! USERS are telling Windows to suspend, but PROGRAMS are saying "no, I don't want to do that" - now Windows is taking the side of the USERS and saying "sorry, program, but you don't get a choice in the matter - I've been told to suspend, so I'm going to suspend."

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 6:42 PM by Isaac Lin

As for "the apps which DON'T play nicely surely outweigh the ones that do everything right" -- it's funny how Windows is the only OS where I see this.  As others have mentioned, it doesn't happen on OSX.  It doesn't happen on Linux.  It doesn't happen on BSD.  It probably doesn't happen on proprietary Unix-en, though I've never seen any of those to know for sure.


On the contrary -- much Unix code uses ancient pre-POSIX APIs, and I've seen plenty of code that fails to handle signal handling and multi-threading correctly.

# sometimes

Friday, February 17, 2006 7:50 PM by Maurits
> USERS are telling Windows to suspend

Well... sometimes.

Consider the following scenario.

Jane is sitting in her office working away on her laptop one cold but sunny day.  She's typing away on a large Word document which is open from a network drive.

Her neighbor Bill plugs in his portable heater and blows the circuit breaker that they share.  He goes off to find a Facilities guy.

Jane happened to be looking out the window for inspiration (as is her wont) and didn't notice the screen suddenly dim.  She turns back to her Word document.

She carries on typing for a while, then decides to take a break for coffee.

She doesn't worry about losing any data... after a nasty experience in her past, she configured Word to save automatically every fifteen minutes.

Which it does, a few minutes later.  Due to a twist of fate, the "suspend" timeout coincides with the middle of the Word autosave.  The network file is only partially written to... corrupting her massive Word document... losing hours of work.

Now I'll ask you.  Did Jane tell Windows to suspend?

Notice I left out the part of the story when Jane comes back and sits at her desk.  I'll let you fill that part in.

Another critical question is, what *should* have happened?  The default would have been to suspend anyway.  Only if Jane had gone out of her way to set "Let Word cancel suspends" would the document have been saved.

# re: Because programmers were trusted to do the right thing, part 2

Friday, February 17, 2006 11:19 PM by Puckdropper
Maurits,

The best way to prevent that is to save a copy of the file first, then overwrite the original.  If your save goes bad on you, you can at least open the original without as much loss.  I don't know how Word does it, but that's one of the safest ways to do it.

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 18, 2006 12:51 AM by LarryOsterman
Maurits, in my experience, word's never had a problem resuming from a suspend.

I've seen CD burning apps have issues, and other apps that deal with real-world external devices have issues, but never word (or Excel or Outlook, or...).

And I open and close my laptop lid ALL the time.

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 18, 2006 7:27 AM by ..
>> "You are vulnerable to attack until the next reboot" would be indicated so that the user would know whether their work or the pending reboot is more important.

A boot process can take away 6 minutes, not counting the time to reopen the applications, resuming work etc. There are times (often) when these minutes are precious and cannot be wasted. Of course you can say security is more important but this is seldomly so. Infact there is a huge probability that the specific issue fixed would not affect me anyway, and, above all, Microsoft patches to OS tipically come after 15 days (at least) after the attack is in the wild.. it is not a day more which breaks the whole thing.

That said, for me it's not a problem because usually I check away every "automatic" thing.

About those automatic things... do someone knows how to disable attachment filtering in MSN and Outlook ? It's just plain stupid that I cannot receive an exe or an xml.. You can warn me, but I SHOULD HAVE THE LAST WORD.

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 18, 2006 7:52 AM by uniware
a) Windows autoupdate.
Once upon a time, I found my IE doesnot work suddenly. After several minutes, I decided to reboot the computer. It worked well after the reboot. I thought hard and guessed it's something related with Windows' autoupdate.

b) POWER button on some keyboards.
I think the POWER button on keyboards is a bad design. As a programmer, I need to play with different kinds of computers. Some of them have different kinds of keyboards. I remember that I have mispressed the POWER button on some of the keyboards for many times. Yes, I did tell the computer to power off, but I donot want it actually. I was punished by my carelessness. But, can't we design the keyboard better?

# Empirical data on laptop use

Saturday, February 18, 2006 8:56 AM by Steve Loughran
James Summerlin says "Not a single one of you has spent the resources MS has in researching this problem"

James, I have actually invested time logging how end users use laptops, and have presented the results to partners such as MS and Intel, and a summary, "The Secret Life of Notebooks" to the ACM conference on human factors in 2000. That was six years ago. (follow the link above)

By logging system power events, network state changes, application foreground changes etc, I had a pretty good model of system use, the key conclusion being "network state matters a lot more than battery; people work differently offline".

The other thing I discovered (not in the ACM paper) was the unofficial sleep state, S6. This is the hibernate from which the OS never recovers, "the big sleep". All too often in the logs the system would hibernate, then suddenly the log would jump to system boot. My hypothesis was the OS (win98SE mostly) couldnt handle the change in state when it resumed -network, devices etc, and ended up crashing.

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 18, 2006 8:05 PM by Justin Olbrantz (Quantam)
"Regarding the hardcoded C:\WINDOWS\ insanity, I'm guessing that's why Windows 2000 installs to <drive>:\WINNT by default, but the later NT-based OSes (XP, 2003, etc.) install to \WINDOWS\?  I wonder how many applications were broken by the behavior in WinNT/Win2K."

I've actually had a virus install itself in my C:\WINNT\system32. This immediately caught my attention, because I didn't HAVE a WINNT directory - my Windows directory was WINNT_3 (long story) :P

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 18, 2006 8:16 PM by Justin Olbrantz (Quantam)
I have a question: why not poll programs for how soon they can be ready for suspend ("now", "real soon", and "never") and display something like a green/yellow/red light on the shut down Windows box, so the user can decide for themselves whether or not to suspend (of course whatever the user says will be done, regardless of any misbehaving programs)?

# Word autosave

Sunday, February 19, 2006 2:05 AM by Maurits
> The best way to prevent that is to save a copy of the file first, then overwrite the original

IIRC, Word 5.0 saved over the original file, wherever it happened to be.  Later versions switched to an "AutoRecover" procedure.  In "AutoRecover", a copy of the present state of the file is saved in the temporary directory, which is usually on a local hard drive.

# re: Because programmers were trusted to do the right thing, part 2

Sunday, February 19, 2006 4:35 AM by 8
>Something like "You are vulnerable to attack until the
>next reboot" would be indicated so that the user would
>know whether their work or the pending reboot is more
>important.

>People seem to forget that the reboot isn't necessary
>just because the system is in an inconsistent state,
>but because the system is vulnerable to attack.

Except users don't care. And they shouldn't have to.

# Different laptops do different things on lid-close and such

Sunday, February 19, 2006 3:42 PM by :: Wendy ::
I always thought that it depended on who provided the laptop (Dell, Toshiba etc) what the lid close action is.  

Yep I want to be able to change some things like if the lid-close action is wrong for my laptops purpose.  

I want Software developers and PC manufacturers to make a 'best-guess' informed by researching what users do.  Then provide easily discoverable options to change their 'best guess' when they know there is a lot of diversity in what users want to do.  

I do not want lots of dialogs asking me to make settings choices because I'm the user and have a right to choose.  

I don't want options giving me 'choices' that I cant make,  fake-choices where the developer thinks they are doing me a favour but I really am not equipped to make the decision.  For example:

"The program 'xyzzy.exe' has indicated that the system should not be suspended. Do you want to suspend anyway?

How can I make a decision on that kind of information.  The last program that blocked shutdown was IE.  It looked closed to me.  I choose to 'end the process now' because it's what I said earlier and I have no idea what's going on so I couldnt make an informed decision.  That is - there is no decision.

Sometimes,  it feels like software developers are using 'give the user choice' as an excuse to
a) sidestep making potnetially expensive and complex design decisions
b) demonstrate they want to give the user control - as if this was always good.  

I dont want to be given choices that are based on a pressumption of technical knowledge or simply supply insufficient information to enable me to make an informed decision.

 
PS  My laptop power connectiion is sufficiently flakey since the 'melt' experience that now I will have to get a new one soon.  SIGH.  

# re: Because programmers were trusted to do the right thing, part 2

Sunday, February 19, 2006 4:52 PM by Dean Harding
Wendy: I totally agree! I even made a post on the same topic a while ago: http://www.codeka.com/blogs/index.php/dean/2005/03/08/when_choice_is_bad

Too bad no one reads my blog :p~

# re: Because programmers were trusted to do the right thing, part 2

Sunday, February 19, 2006 6:52 PM by Miral
"Apart from those two things, this can be extended to other stuff such as locked files that you can't rename, move or delete. I want a "kill all handles of this file" button in the failure dialog."

I use Process Explorer for that.  Whenever I want to rename/delete something and it won't let me, I fire up ProcExp and ask it who has it open.  Most of the time, I then just summarily close the handle.  (Usually, it tends to be the Indexing Service.  But not always.)

# re: Because programmers were trusted to do the right thing, part 2

Sunday, February 19, 2006 7:06 PM by Wesley
I'd also like to chime in to say that I reinstalled Windows XP on my Toshiba notebook, and at no point was it mentioned that "Automatic Updates" will automatically cause reboots.  At the first boot, it does ask if you want updates downloaded and installed automatically. Nowhere was there a mention of rebooting. (That may be implied as veteran users of Windows knows that most updates require reboots, but new users can't possibly know that, or that the "Later" snooze button only works for 5 minutes each time.)

# re: Because programmers were trusted to do the right thing, part 2

Sunday, February 19, 2006 7:47 PM by BryanK
Responding to myself here, because I've thought of a few more reasons Linux doesn't have the "you must reboot" problem, nor does it have a problem with mismatched libraries.

Shared libraries have a "soname" field (at least on ELF systems, which is all of them now).  When a program is linked, the linker command references the "bare" library name (for instance, libipc.so).  This filename is a symlink to the full-version library file (e.g. libipc.so.1.0.5), which the linker links in.  That file may have a soname of (e.g.) libipc.so.1.

When the linker links in the libipc.so.1.0.5 file, it writes a field into the executable that refers to the soname of the library, *not* the full name.  Later, when the program is run, the runtime linker/loader reads the soname out of the executable and loads the soname file, not the full-name file.  dlopen() likewise is supposed to use the soname (although it can use any name whose symlink points at the correct file).

(There's a separate program, ldconfig, which creates a symlink from each library's soname to its highest-version full name.  ldconfig is supposed to be run every time a library is installed.  So the dynamic linker/loader loads the newest library version through the soname symlink.)

Now, the rule for the library author is to change the soname if and only if there's an binary-incompatible change in the library.  The full filename can change whenever the author wants it to (some packages, e.g. OpenSSL, change it at each release so that multiple releases can coexist if needed, but this is not the only way to do it).

This way, all compatible library versions (including ones whose only difference to the previous is a bugfix) have the same soname.  So when the bugfixed library gets installed, the version with the hole gets unlinked, the new version gets installed, and subsequent process startups use the new version.  But since the soname is the same, that means it's completely compatible; old and new versions can talk to each other without problems.

There's still a problem if the bugfix makes the new version incompatible with the old.  In that case, there's no choice but to recompile (or at least relink) everything that uses the library.  But because the new library has a different soname, it'll at least not segfault or whatever on processes that haven't been fixed.

This situation (bugfixes being incompatible) is rare, though.  And even if everything using the library has to be recompiled (e.g. if it's a bug in the C library), all the new executables can be installed and started without rebooting the kernel.  Even /sbin/init, though it would take a bit of coordinating.  (It can re-exec itself once its binary has been replaced.  It would just have to be told to do so; I'm not sure whether this is possible.)

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 4:42 AM by 8
But it gets even better: there is a central package manager that makes sure all dependencies are properly met. And there is source for all applications, so they all get to be compiled for the latest library versions. If it fails, a bug is filed and depending on the maintainer and the importance of the package it gets fixed sooner or later. THAT is a *huge* advantage, as it makes constant BC'ing irrelevant. If a binary doesn't work, compile it yourself. Don't scream 'but the average user cant', because the average user wouldn't need to get a binary someplace somewhere and install it. Packages are installed through applications like Synaptic and YaST, lots of them. And all of them were specifically compiled for the release.

Granted, there are plenty distro's that lack this ability, but the popular ones do a good job staying popular that way.

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 8:04 AM by BryanK
Heh -- Gentoo.  Where *everyone* compiles it for themselves.

;-)

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 10:19 AM by 8
Apparently it seems to be Microsoft's favorite distribution: http://channel9.msdn.com/ShowPost.aspx?PostID=65355 . I like to use Ubuntu, and have used Debian and SuSE before that.

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 12:39 PM by J
"If these are particularly dire, the program has an OBLIGATION to alert the user. Imagine suspending in the middle of a write to a document on a network drive, for example."

Oh good.  Now you've designed your program to punish the user so that if they click "Yes, I want to suspend now", they corrupt their files. Brilliant design.

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 3:45 PM by Nekto2
Should there be a message like "WM_YOU_WILL_DIE" and "in X seconds" as a parameter. So The app will know it's fate and write it's last will? :)))))
It will be for new apps and programmer should just make best choice of what to do and it which order if it expected it's software to crash soon. First to write down simple flag "we are crashing" so it will know that on next startup. Then to try to save some data without any question to user. (It should be required - no GUI interaction).

And that will be solution to 0% battery and UPS no power messages.

ps. It's fun to boot up laptop to find out dialog box "You have no power left, so we are shutdowning" :))  It was just hibernated with the rest of apps.

pps. As for updates - the question is not "are you need automatic reboot". The question is - "are you need automatic installation of updates". The person who desides that Windows will automatically install updates is responsible for any data loss becouse of "inconsistence state" ;)
The best choice (IMHO) is the one when updates are installed only after user confirmed it wants to reboot and most off Apps are already closed.
Ok there may be than situation "Oh wait - I need not really any reboot, so hey - all could start up again without reboot" :) But it is rare situation to consider ;))

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 20, 2006 4:15 PM by 8
Good sense of humor, Nekto2 :D

If all apps were designed like this: http://en.wikipedia.org/wiki/Crash-only_software
The first sentence isn't really true, but it goes on about right: "Correctly written components of crash-only software can microreboot to a known-good state without the help of a user. Since failure-handling and normal startup use the same methods, this can increase the chance that bugs in failure-handling code will be noticed, except when there are leftover artifacts, such as data corruption from a severe failure, that don't occur during normal startup."
It means that starting the application is the same as recovering, and closing it is the same as crashing.
There's also a strategy where subsystems of an app can decouple and reattach to prevent the "we're about to crash" scenarios.

# re: Because programmers were trusted to do the right thing, part 2

Tuesday, February 21, 2006 6:06 PM by Jason Spiro
Sean W. wrote above:
> ... I've set this machine to update using "Let me choose when to install them"
> as you suggested.  That said, I remember I used to have this thing set to do
> exactly that, and it would never remind me at all that anything needed to be
> done:  No messages, no notices, nothing more than an icon in the system tray...

Maybe you've disabled balloon tips. The systray icon normally pops up a balloon tip that says "New updates are ready to install."

> that's easily overlooked among a dozen others.

The system tray is misused nowadays. Too many apps install tray icons that don't do much other than slow down system startup. Why do RealPlayer, QuickTime, WinZip, and my Synaptics touchpad driver all need to show tray icons? Is it to provide free advertising for the manufacturers?

Also, instant messengers (except for Gaim) and P2P clients seem to always minimize themselves to the system tray, as the rant at http://shell-shocked.org/article.php?id=285 explains. This stops me from Alt-Tabbing to my IM clients. Instead, I have to fuss with tiny icons (I'm use a laptop with a touchpad) or press Ctrl+Win+Tab a few times to display a hard-to-see dotted icon selection border. IM clients should have a Minimize button, a Minimize to Tray button, and a Close button. Each button should do what it is supposed to.

# re: Because programmers were trusted to do the right thing, part 2

Wednesday, February 22, 2006 7:18 AM by 8
Do they all work with Alt+Tab when they are not iconified? Atleast one of them that I know (ICQ) uses a toolbar dialog frame by default IIRC.

# re: Because programmers were trusted to do the right thing, part 2

Saturday, February 25, 2006 12:41 PM by memet
Poor Raymond (or maybe lucky). You are becoming so popular that you will start needing a moderation system pretty soon to weed out the 'trolls'.
I really love your blog, but when you have to read through 100+ posts of people who claim to know *the* only right way to do things, it quickly gets tiresome and pointless - there is no real debate here.
It reminds me of a very funny article I had once read (slightly coarse language warning): http://www.jaypinkerton.com/blog/archives/001160.html
quote:
"[...]I'm no hypocrite. My opinions? They don't matter either. Not to you, anyway. They matter to me, of course--if I'm deciding which movie to rent, I'm the first person I ask. But I wouldn't expect you to care one way or another. I could type lengthy manifestos about my religious, political and fashion preferences all day. If you were polite you might pretend to read them. "

Well, I guess I'm just saying that I don't pretend to read the debates, but I still do love the posts. Rock on Raymond.

# re: Because programmers were trusted to do the right thing, part 2

Monday, February 27, 2006 2:31 AM by Norman Diamond
People call this kind of thing a troll too, but think about where this kind of thing comes from.

I just noticed that the Windows Event Viewer contains logs of failed shutdown attempts, at least sometimes.  The logs include links to Microsoft's web site, where "Windows Help and Support Center" provides really useful helpful information, such as the really useful helpful information that I will quote below.

This is help and support in Japanese, though part of it is funny Japanese that will be understandable by most readers here.  I'm not going to bother translating the few words that really are Japanese, and they'll probably get scrambled by the blog's software, but they're not important.

Now I've just noticed that this Help and Support information says it applies to Windows version 5.2.  Version 5.2 is Windows XP x64, Windows 2003 x64, and Windows 2003 32-bit, right?  Windows XP SP2 32-bit is still version 5.1, right?

So, does the recommended procedure of pressing the Ctrl key while clicking on the menu header of the Windows Task Manager's Shutdown menu really have some effect in version 5.2 stuff that it doesn't have in version 5.1?  Or is the recommended procedure equally trollish there as it is in Windows XP SP2 32-bit?

Or sure, we can repeat the ordinary shutdown effort, which only repeated the same failure 3 times.

Pulling the power cable worked.

Here are Microsoft's recommendations.

詳細
製品: Windows Operating System
ID: 1073
ソース: USER32
バージョン: 5.2
シンボリック名: WARNING_EW_SHUTDOWN_CANCELLED
メッセージ: The attempt by user %2 to restart/shutdown computer %1 failed
   
説明
This event is written when a user or application attempts, but fails, to restart or shut down the computer by using either the graphical user interface (GUI) or the shutdown command.

   
対処方法
If you still want to restart or shut down the computer, save any open files, close any applications that are running, and then you can:

Use either the graphical user interface (GUI) or the shutdown command again.
Press CTRL+ALT+DELETE, and then while pressing CTRL, click Shut Down to force a shutdown.
Press the reset or power button on the computer.

# re: Because programmers were trusted to do the right thing, part 2

Tuesday, February 28, 2006 3:08 AM by Norman Diamond
How hard is it to change the balloon notification from saying "You can continue working while updates are being installed" to "You'd better stop working because the system is in a frankenstate while updates are being installed"?

I am grateful that I know not do do any further work in this machine (a guest PC under Virtual PC 2004) until its updates finish and it reboots.  I am grateful that I know not to believe this assertion.  But why hasn't Microsoft fixed it?

http://www.geocities.jp/hitotsubishi/frankenstate.png

# re: Because programmers were trusted to do the right thing, part 2

Wednesday, March 01, 2006 9:07 AM by Nekto2
Just an item in shutdown dialog:

- Shutdown
- Hibernate
- Reboot to UPDATED windows

;)

or checkbox "Apply any new updates".
New Comments to this post are disabled
 
Page view tracker