Holy cow, I wrote a book!
is a type of sleep state that combines
sleep and hibernate.
When you put the computer into a hybrid sleep state,
it writes out all its RAM to the hard drive
(just like a hibernate),
and then goes into a low power state that keeps RAM refreshed
(just like a sleep).
The idea is that you can resume the computer quickly from sleep,
but if there is a power failure or some other catastrophe,
you can still restore the computer from hibernation.
A hybrid sleep can be converted to a hibernation by simply
turning off the power.
By comparison, a normal sleep requires resuming the computer
to full power in order to write out the hibernation file.
Back in the Windows XP days,
I would sometimes
see the computer in the next room spontaneously
turn itself on:
I'm startled at first, but then I see on the screen that
the system is hibernating, and I understand what's going on.
Hybrid sleep is on by default for desktop systems
but off by default on laptops.
Why this choice?
First of all, desktops are at higher risk of the power outage
scenario wherein a loss of power (either due to a genuine
power outage or simply unplugging the computer by mistake)
causes all work in progress to be lost.
Desktop computers typically don't have a backup battery,
so a loss of power means instant loss of sleep state.
By comparison, laptop computers have a battery which can
bridge across power outages.
Furthermore, laptops have a safety against battery drain:
When battery power gets dangerously low,
it can perform an
Laptop manufacturers also requested that hybrid sleep be off
They didn't want the hard drive to be active for a long time
while the system is suspending,
because when users suspend a laptop, it's often in the form of
"Close the lid, pick up the laptop from the desk,
throw it into a bag, head out."
Performing large quantities of disk I/O at a moment when the
computer is physically being jostled around increases the risk
that one of those I/O's will go bad.
This pattern doesn't exist for desktops: When you suspend a desktop
computer, you just leave it there and let it do its thing.
Of course, you can override this default easily from the Control Panel.
Under Power Options, select
Change plan settings,
Changed advanced power settings,
and wander over into the Sleep section of the configuration tree.
If you're a command line sort of person,
you can use this insanely geeky command line to enable hybrid
sleep when running on AC power in Balanced mode:
powercfg -setacvalueindex 381b4222-f694-41f0-9685-ff5bb260df2e
(All one line. Take a deep breath.)
[Update: Or you can use
powercfg -setacvalueindex SCHEME_BALANCED SUB_SLEEP HYBRIDSLEEP 1,
as pointed out by
I missed this because the ability to substitute aliases is not mentioned
in the -setacvalueindex documentation.
You have to
dig into the -aliases documentation to find it.]
powercfg -setacvalueindex SCHEME_BALANCED SUB_SLEEP HYBRIDSLEEP 1
Okay, what do all these insane options mean?
-setacvalueindex sets the behavior when running on AC power.
To change the behavior when running on battery, use
Okay, that was easy.
The next part is a GUID, specifically, the GUID that represents
the balanced power scheme.
If you want to modify the setting for a different power scheme,
then substitute that scheme's GUID.
After the scheme GUID comes the subgroup GUID.
Here, we give the GUID for the Sleep subgroup.
Next we have the GUID for the Hybrid Sleep setting.
Finally, we have the desired new value for the setting.
As you might expect, 1 enables it and 0 disables it.
And where did these magic GUIDs come from?
Run the powercfg -aliases command to see all the GUIDs.
You can also run powercfg -q to view all the settings
and their current values in the current power scheme.
During a discussion of
the proper way of cancelling I/O,
the question was raised as to whether it was safe to free
the I/O buffer, close the event handle, and free the
immediately after the call to CancelIo.
The response from the kernel developer was telling.
We write back to the buffer under a try/except,
so if the memory is freed, we'll just ignore it.
And we take a reference to the handle, so closing it does no harm.
These may be the right answers from a kernel-mode point of view
(where the focus is on ensuring that consistency in kernel mode
is not compromised),
but they are horrible answers from an application point of view:
Kernel mode will write back to the buffer and the OVERLAPPED
when the I/O completes,
thereby corrupting user-mode memory if user-mode had
re-used the memory for some other purpose.
And if the handle in the OVERLAPPED structure is closed,
then user mode has lost its only way of determining when it's safe to continue!
You had to look beyond the literal answer to see
what the consequences were for application correctness.
(You can also spot the kernel-mode point of view in the clause
"if the memory is freed."
The developer is talking about freed from kernel mode's point of view,
meaning that it has been freed back to the operating system and is
no longer committed in the process address space.
But memory that is logically freed from the application's point of view
may not be freed back to the kernel.
It's usually just freed back into the heap's free pool.)
The correct answer is that you have to wait for the I/O to complete
before you free the buffer, close the event handle, or free
the OVERLAPPED structure.
Don't fall into this trap.
The kernel developer was looking at the world through kernel-colored
But you need to look at the
situation from the perspective of your customers.
When the kernel developer wrote "That's fine", he meant
"That's fine for me."
Sucks to be you, though.
It's like programming an autopilot to land an airplane,
but sending it through aerobatics that kill all the passengers.
If you ask the autopilot team,
they would say that they accomplished their mission:
Technically, the autopilot did land the airplane.
another example of kernel-colored glasses.
To be fair,
after I pointed out the kernel-mode bias in the response,
the kernel developer admitted,
"You're right, sorry.
I was too focused on the kernel-mode perspective and wasn't
looking at the bigger picture."
There is no standard for process exit codes.
You can pass anything you want to ExitProcess,
and that's what GetExitCodeProcess
will give back.
The kernel does no interpretation of the value.
If youw want code 42 to mean "Something
has occurred" then more power to you.
There is a convention, however, that an exit code of zero means
success (though what constitutes "success" is left to the discretion
of the author of the program) and a nonzero exit code means
failure (again, with details left to the discretion of the programmer).
higher values for the exit code indicate more severe types of failure.
The command processor
keyword was designed with these convention in mind.
There are cases where your process will get in such a bad state
that a component will take it upon itself to terminate the process.
For example, if a process cannot locate the DLLs it imports from,
or one of those DLLs fails to initialize,
the loader will terminate the process and use the
status code as the process exit code.
I believe that when a program crashes due to an unhandled exception,
the exception code is used as the exit code.
A customer was seeing their program crash with an exit code of 3
and couldn't figure out where it was coming from.
They never use that exit code in their program.
Eventually, the source of the magic number 3 was identified:
The C runtime
terminates the process with exit code 3.
In Windows 2000,
Explorer let you add properties like Summary and Author to nearly
any file type.
But when you view the files from a machine running
Windows XP or later,
those properties are lost.
Where did they go?
Most file types do not have extensibility points for adding metadata.
For example, every byte of a plain text files is devoted to
text data; there is nowhere to put metadata like Author or Summary.
In Windows 2000,
the shell chose to store this extra information
in NTFS alternate data streams
(or more accurately, the shell chose to use the
STGFMT_FILE storage format, which is
implemented in terms of NTFS alternate data streams.)
Storing the information in alternate data streams attaches the
data to the file without affecting the file contents.
This was a clever idea,
taking advantage of NTFS's ability to attach arbitrary data to a file,
but it also had a serious problem:
Alternate streams are not preserved by
simple and common operations like sending the file by email,
copying the file to a (FAT-formatted) USB thumb drive,
uploading or downloading the file from a Web site,
or burning the file to a CD.
once the file leaves the comfortable confines of your local hard drive,
there's a good chance that the metadata will be destroyed.
To avoid this problem, Windows XP switched to storing the
metadata in the file contents itself.
Doing this, however, requires support from the file format.
Each file type can have registered for it a property handler
which describes how to read and write properties for a file.
(Windows itself comes with a few such handlers,
such as for JPEG images and MP3 files,
with more recent versions of Windows supporting more properties.)
If no such property handler is registered,
the shell will use structured storage, provided the file format is
compatible with structured storage.
The data you added in Windows 2000 are still there.
It's just that newer versions of Windows don't bother looking for them.
(If you were sufficiently resourceful, you could write a program
which opens the file in STGFMT_FILE mode,
reads the properties, then
reopens the file via the shell namespace
writes the properties back out.)
For lots of
about the shell property system,
Ben Karas's blog, which I have been liberally linking to.
A customer (via a
reported that Explorer somestimes showed a thumbnail for
an image file that didn't exactly match the image itself.
I have an image that consists of a collage of other images.
When I switch Explorer to Extra Large Icons mode,
the thumbnail is a miniature representation of the image file.
But in Large Icons and Medium Icons mode,
the thumbnail image shows only one of the images in the collage.
I've tried deleting the thumbnail cache, but that didn't help;
Explorer still shows the wrong thumbnails for the smaller icon
What is wrong?
The customer provided screenshots demonstrating the problem,
but the customer did not provide the image files themselves that
were exhibiting the problem.
I therefore was reduced to using my psychic powers.
My psychic powers tell me that your JPG file has
the single-item image as the camera-provided thumbnail.
The shell will use the camera-provided thumbnail if suitable.
The customer liaison replied,
The customer tells me that the problem began happening after
they edited the images.
one of the images that's demonstrating the problem.
Some image types (most notable TIFF and JPEG)
support the EXIF format for encoding image metadata.
This metadata includes information such as the model of camera
used to take the picture, the date the picture was taken,
and various camera settings related to the photograph.
But the one that's interesting today is the image thumbnail.
When Explorer wants to display a thumbnail for an image,
it first checks whether the image comes with a precalculated
If so, and the thumbnail is at least as large as the thumbnail
Explorer wants to show,
then Explorer will use the image-provided
thumbnail instead of creating its own from scratch.
If the thumbnail embeded in the image is wrong,
then when Explorer displays the image-provided thumbnail,
the result will be incorrect.
Explorer has no idea that the image is lying to it.
Note that the decision whether to use the image-provided thumbnail is not
based solely on the view.
(In other words, the conclusion is not
"Explorer uses the image-provided thumbnail for
Large Icons and Medium Icons but ignores it for
Extra Large Icons.)
The decision is based on both
the view and the size of the image-provided thumbnail.
If the image-provided thumbnail is at least the size of the view,
then Explorer will use it.
For example, if your view is set to 64 × 64
thumbnails, then the image-provided thumbnail will be used if it
is at least 64 × 64.
Wikipedia page on EXIF
points out that "Photo manipulation software sometimes fails to update the
embedded information after an editing operation."
It appears that some major image editing software packages fail to
update the EXIF thumbnail when an image is edited,
which can result in
inadvertent information disclosure:
If the image was cropped or otherwise altered to remove information,
the information may still linger in the thumbnail.
This Web site has a small gallery of examples.
A customer liaison had the following question:
My customer has ZIP files stored on a remote server
from a machine running Windows Server 2003 and
Internet Explorer Enhanced Security Configuration.
When we extract files from the ZIP file,
the last-modified time is set to the current time
rather than the time specified in the ZIP file.
The problem goes away if we disable Enhanced Security Configuration
or if we add the remote server to our Trusted Sites list.
We think the reason is that if the file is in a non-trusted zone,
the ZIP file is copied to a temporary
location and is extracted from there,
and somehow the date information is lost.
The customer is reluctant to turn off Enhanced Security Configuration
(which is understandable)
and doesn't want to add the server as a trusted site
(somewhat less understandable). Their questions are
Why is the time stamp changed during the extract?
If we copy the ZIP file locally and extract from there,
the time stamp is preserved.
Why does being in an untrusted zone affect the behavior?
How can we avoid this behavior without having to disable
Enhanced Security Configuration or adding the server as a
The customer is reluctant to turn off Enhanced Security Configuration
(which is understandable)
and doesn't want to add the server as a trusted site
(somewhat less understandable). Their questions are
The customer has an interesting theory (that the ZIP file is
copied locally) but it's the wrong theory.
After all, copying the ZIP file locally doesn't modify
the timestamps stored inside it.
Since the ZIP file is on an untrusted source,
a zone identifier is being applied to the extracted file
to indicate that the resulting file is not trustworthy.
This permits Explorer to
display a dialog box
"Do you want to run this file?
It was downloaded from the Internet,
and bad guys hang out there,
bad guys who try to give you candy."
And that's why the last-modified time is the current date:
Applying the zone identifier to the extracted file
modifies its last-modified time, since the file on disk is not
identical to the one in the ZIP file.
(The one on disk has the "Oh no, this file came from a stranger
with candy!" label on it.)
The recommended solution is to add the server containing
trusted ZIP files to your trusted sites list.
Since the customer is reluctant to do this (for unspecified reasons),
there are some other alternatives, though they are considerably
(These alternatives are spelled
KB article 883260:
Description of how the Attachment Manager works.)
You can disable
the saving of zone information from the Group Policy Editor,
under Administrative Templates, Windows Components,
Do not preserve zone information in file attachments.
This does mean that users will not be warned when they attempt
to use a file downloaded from an untrusted source,
so you have to trust your users not to execute that random
executable they downloaded from some untrusted corner of the Internet.
You can use the
Inclusion list for low, moderate, and high risk file types
policy to add ZIP as a low-risk file type.
This is not quite as drastic as suppressing zone information for
all files, but it means that users who fall for the
"Please unpack the attached ZIP file and open the XYZ icon" trick
will not receive a "Do you want to eat this candy that a stranger
gave to you?" warning prompt before they get pwned.
But like I said,
it's probably best to add just the server containing the trusted
ZIP files to your trusted sites list.
If the server contains both trusted and untrusted data
(maybe that's why the customer doesn't want to put it on the trusted
then you need to separate the trusted data from the untrusted data
and put only the trusted server's name in your trusted sites list.
There are a few places in Windows where you are asked to enter
your name in order to set up an account.
Just for fun, I went through all the localized versions I could find
and extracted the sample names.
Some locales did not get around to translating all the strings.
If the string was left untranslated (which can happen for
then I left the box blank.
(Locales which did not translate either string have been omitted
from the table.)
My reactions after the table.
The Locales of Windows 7, all divvied up.
Cliff Barbier points out that
after you sort an Explorer view
by name, new items are not inserted in their sorted position.
This goes back to the question of whether sorting is a state or a verb.
If you take an Explorer folder and say Sort by Name,
do you mean
"From now on, always show the contents of this folder sorted by name"?
Or do you mean
"Rearrange the items currently in this folder so they are sorted by name"?
The first case treats sorting a state,
where sorting is an attribute of the folder that persists.
The second case treats sorting as a verb,
where the action is performed so that its effects linger but the action
itself is not remembered.
You might think that sorting is obviously a state,
but STL disagrees with you:
... fill v with stuff ...
std::sort(v.begin(), v.end(), Item::ByName);
When the last line of code appends a new item to the vector,
it is not inserted in sorted order because std::sort
is a verb which acts on the vector, not a state of the vector itself.
The vector doesn't know "Oh, wait, I'm now a sorted vector."
Okay, so in Explorer, is sorting a state or a verb?
"Let's do both!"
Sorting is a state, in the sense that the list of items is presented
in sorted order when the folder is first opened.
It's a verb in that the sorted order is not maintained when new items
are added to the view while the folder is already open.
Placing new items at the end instead of in their sorted position is
necessary to avoid having items move around unbidden.
Suppose you're looking at a folder sorted by name,
you scroll down the list, find the item you want,
and just as your finger is posed to click the mouse button,
another process creates a file in the folder,
which Explorer picks up and inserts into the view,
causing the items to shift,
and when your finger goes down on the mouse button,
you end up clicking on the wrong item.
You can imagine how annoying this can end up when there is a lot of
file creation activity in the folder.
If the items in the view were continuously sorted,
then they would keep moving around
and make it impossible to click on anything!
Mind you, you do have this instability problem when files are deleted
and you are in a non-placed view (like List or Details),
but there's at least a cap on how much trouble deletion can cause
(since eventually you delete all the items that were in the view originally).
It looks like starting in Windows Vista,
Explorer tries to insert new items into their sorted position,
so at least in the modern versions of Windows, sort is a state.
Good luck trying to click on something when the contents of the folder
are constantly changing.
I found it amusing that somebody considered
the fact that Microsoft employees can read my queued-up blog entries
before the articles are published to be
further evidence of Microsoft's evil essence as a monopoly.
Just for the record, this is not evidence of Microsoft's evil
essence as a monopoly.
Rather, it's evidence of Raymond's
evil essence as a monopoly,
the monopoly on blog articles written by Raymond Chen that
haven't yet been published
belongs to me.
We saw some time ago that
taskbar notification balloons don't penalize you for being away
from the computer.
But how long does the balloon stay up when the user is there?
Originally, the balloon appeared for whatever amount of time
the application specified in the uTimeout member
of the NOTIFYICONDATA structure,
subject to a system-imposed minimum of 10 seconds and maximum
of 60 seconds.
In Windows XP, some animation was added to the balloon,
adding 2 seconds of fade-in and fade-out animation
to the display time.
Starting in Windows Vista,
applications are no longer allowed to specify how long they
wanted the balloon to appear;
the uTimeout member is ignored.
Instead, the display time is
the amount of time specified
by the SPI_GETMESSAGEDURATION system parameter,
with 1 second devoted to fade-in and
5 seconds devoted to fade-out, with a minimum of 3 seconds
of full visibility.
In other words,
if you set the message duration to less than
the taskbar behaves as if you had set it to 9 seconds.
The default message duration is 5 seconds,
so in fact most systems are in the "shorted possible time"
If you want to extend the time for which balloons notification appear,
you can use the SystemParametersInfo function to change it:
BOOL SetMessageDuration(DWORD seconds, UINT flags)
0, IntToPtr(seconds), flags);
(You typically don't need to mess with this setting, because
you can rescue a balloon from fading out by moving the mouse over it.)
Note that an application can also set the NIF_REALTIME
flag, which means
"If I can't display the balloon right now, then just skip it."