Holy cow, I wrote a book!
My Little Program about manipulating the zone identifier for downloaded files
appears to have struck a nerve with commenter Tess,
launched into some sort of diatribe about how Microsoft should
stop being a busybody and warning users about opening files that
You are welcome to disable the feature if it offends you so.
For bonus points, you can set a bunch of other policies
to make your computer even more dangerous.
Here's a list of them.
For example, if your goal is to create the most insecure
deployment of Internet Explorer, you can set
Inclusion list for moderate risk file types and
Inclusion list for low risk file types both to
and then on top of that, set
Launching applications and unsafe files to
Enabled (not secure)
so that Internet Explorer never warns you about running anything.
Welcome to 1995. Enjoy your stay.
If you don't specify a sort order, then the DIR command
lists the files in the order that the files are returned by the
Um, okay, but that just pushes the question to the next level:
What order does
FindFirstFile return files?
The order in which
FindFirstFile returns files in unspecified.
It is left to the file system driver to return the files in whatever
order it finds most convenient.
Now we're digging into implementation details.
For example, the classic FAT file system simply returns the names
in the order they appear on disk,
and when a file is created, it is merely assigned the first available
slot in the directory.
Slots become available when files are deleted,
and if no slots are available, then a new slot is created at the
Modern FAT (is that an oxymoron?)
with long file names is more complicated
because it needs to find a
sequence of contiguous entries
large enough to hold the name of the file.
There used to be (maybe there still are) some low-level disk
management utilities that would go in and
your directory entries.
The NTFS file system internally maintains directory entries
in a B-tree structure, which means that the most convenient way
of enumerating the directory contents is in B-tree order,
which if you cover one eye and promise not to focus too closely
looks approximately alphabetical for US-English.
(It's not very alphabetical for most other languages,
and it falls apart once you add characters with diacritics
or anything outside of the Latin alphabet, and that includes spaces
The ISO 9660 file system (used by CD-ROMs) requires that directory
entries be lexicographical sorted by ASCII code point.
Pretty much everybody has abandoned the base ISO 9660 file system
and uses one of its many extensions, such as Joliet or UDF,
so you have that additional wrinkle to deal with.
If you are talking to a network file system, then the file system
on the other end of the network cable could be anything at all,
so who knows what its rules are (if it even has rules).
When people ask this question, it's usually in the context of
a media-playing device which plays media from a CD-ROM or USB thumb drive
in the raw native file order.
But they don't ask this question right out;
they ask some side question that they think will solve their problem,
but they don't come out and say what their problem is.
So let's solve the problem in context:
If the storage medium is a CD-ROM or an NTFS-formatted USB thumb drive,
then the files will be enumerated in sort-of-alphabetical order,
so you can give your files names like
000 First track.mp3,
001 Next track.mp3, and so on.
000 First track.mp3
001 Next track.mp3
If the storage medium is a FAT-formatted USB thumb drive,
then the files will be enumerated in a complex order based on the
order in which files are created and deleted and the lengths of their
But the easy way out is simply to remove all the files from a directory
then move file files into the directory in the order you want them
That way, the first available slot is the one at the end of the directory,
so the file entry gets appended.
Of course, none of this behavior is contractual.
NTFS would be completely within its rights to,
for example, return entries in reverse
alphabetical order on odd-numbered days.
Therefore, you shouldn't write a program that relies on any particular
order of enumeration.
(Or even that the order of enumeration is consistent between two runs!)
A customer (via their customer liaison)
started by asking why they were seeing an unexpected
access control entry in the security descriptor of an object.
The ACEs on the parent grant access to
but the ACEs on the child object (which should simply have been
inherited from the parent) include an extra entry for Bob.
How did Bob get access to the child object?
When we view the details of the ACEs, it lists the Bob entry
as Inherited from parent.
But there is no Bob entry in the parent!
"Probably because Bob is the CREATOR OWNER."
Thanks for the explanation,
but even if Bob is the CREATOR OWNER,
how can we explain that the permission is inherited from the parent?
The permission is inherited from the parent because the parent has
specified the rights of the CREATOR OWNER,
and Bob is the creator/owner.
As part of the inheritance process, the rights of the
CREATOR OWNER get assigned to Bob.
CREATOR OWNER is not a real person.
It is a placeholder that
gets replaced with the actual creator/owner when the
object is created.
If Bob created the child object, then the permissions of
CREATOR OWNER will be given to Bob on the child object.
The CREATOR OWNER is not a live entry that dynamically
updates to match the current creator/owner.
It is a static entry that is assigned at the point of creation.
Changes to the owner in the future have no effect because
the identity has already been snapshotted.
(I think a less confusing name would have been simply OBJECT CREATOR,
since creation happens only once.)
(Note that there is a little extra weirdness here:
If the creator is a member of the Administrators group,
then the CREATOR OWNER rights get assigned to the
entire Administrators group instead of the specific user
who created it.
You can change this behavior by tweaking the
Default owner for objects created by members of the Administrators
The customer liaison conferred with the customer, and determined
that, at least in one of the cases they were studying,
Bob was not the original creator.
What actually happened was that at some point,
Bob was granted access to the
parent object and all its sub-objects.
Later, somebody went back to the parent object and told it to
revoke Bob's access to the parent object and all its sub-objects.
But "If we cancel the process fast enough, then we get the
strange behavior as originally described."
You asked for Bob's access to the parent object and all its
sub-objects to be revoked,
so the tool you used started a recursive tree walk from the parent
object looking for any objects that Bob has access to
and removing them.
But if you cancel the operation partway through, then that tool
didn't get a chance to finish the job,
and you obviously are left in a situation where Bob's access was
only partially revoked.
The customer liaison confirmed,
Yes, that's what happened.
It's nice of the customer liaison to confirm the diagnosis,
but it still baffles me that they were confused by this in the
To me this is one of those So what did you expect type of
You start an operation, then partway through, you cancel it,
and then you're surprised that the operation did not run to completion.
Another converse of
How do I programmatically create folders like
My Pictures if they were manually deleted?
Why do folders like "My Pictures" come back after I delete them?
How do I prevent folders like My Pictures from being recreated?
Starting in Windows 7, there is a group policy
Disable Known Folders
which lets you specify a list of known folders which should be disabled.
If somebody tries to create a known folder programmatically,
the call will fail with
Note that this policy only blocks creation of the folder.
If the folder already exists, then the policy has no effect.
(You're locking the door after the horse has bolted.)
A customer reported that when their application called
the GetVersionEx function,
it sometimes reported incorrect values.
the logs collected from clients shows that the first time
the program was run
on a Windows 7 machine,
the operating system was
correctly reported as 6.1.7600 (Windows 7),
but the second time it was run, the operating system was
erroneously reported as 6.0.6000 (Windows Vista).
This was definitely strange behavior,
and upon further questioning, the customer admitted that their
application was a setup program.
The fact that it was a setup program was the missing ingredient.
What happened is that the setup program ran,
correctly detected the version as Windows 7,
and then started installing its pre-requisite components.
The installer for one of the pre-requisites failed,
causing the entire setup to fail.
Program Compatibility Assistant
noticed that the initial attempt to install the program failed,
and it guessed (based on its internal heuristics)
that the problem was that the program had an incorrect operating
system version check.
After the first setup failed,
the Program Compatibility Assistant puts up a dialog box saying,
"Hey, I think I know what went wrong.
This setup program has a bad operating system version check.
Do you want to give it another shot?"
If the client says, "Go for it",
then it will run the setup program again,
but with a false operating system version.
Unfortunately, the heuristic that the Program Compatibility Assistant
used was a false positive in this case,
so saying "Go for it" was the wrong answer.
(Not like the client had any idea.
This was a case of the computer
asking the user a question they cannot answer.)
The fix is to add a manifest to the setup program
specifying whether it needs to run as administrator.
It doesn't matter what the manifest says as its requirements;
the fact that the manifest said anything at all means that the setup program
understands the new rules introduced in Windows Vista
and doesn't need the Program Compatibility Assistant's help.
(You can read
the Excluding Programs from PCA section
for other ways to disable the Program Compatibility Assistant
for a program.)
The Visual Effects dialog box has three options,
"Let Windows choose what's best for my computer,"
"Adjust for best appearance,"
for crappiest appearance best performance."
Some people have discovered the registry key where the Visual Effects
dialog box remembers which radio button was most recently checked,
but they found that when they programmatically manipulate the
registry key, there is no effect on the actual visual settings.
What's going on?
What's going on is that the registry key is just there to tell you
what you want to hear.
It remembers which radio button you clicked,
so that when you reopen the dialog box,
the same radio button will be selected by default.
The actual work of changing the setting happens when you click
the OK or Apply button.
The registry key is just for show.
If you want to change a Visual Effects setting programmatically,
you need to make the corresponding API call for that visual effect.
For example, you might call
SystemParametersInfo with the
to programmatically enable or disable non-client animation.
Note of course that by doing this you are using a global solution
to a local problem.
The user's visual effects preferences should be modified by the user,
not by a program.
Windows 8 added a new hotkey:
takes a snapshot of your screen and puts it into
the Screenshots folder of your Pictures library.
But what if you are on a tablet with no PrtSc key?
On tablets, you can perform the same operation by pressing
Windows button + Volume down.
Both of these are the hardware buttons on the tablet,
not on any keyboard.
A customer was running Windows Server 2003
("Still in support until 2015!")
and they have some custom application that monitors all
They noticed that there were a lot of failed Alternate Data Stream
queries coming from Explorer,
and that was causing the custom application's logs to fill with
largely useless information.
These Alternate Data Stream queries are being made in order to
extract file metadata for the pop-up infotip.
(Windows later abandoned the use of Alternate Data Streams for
file metadata since Alternate Data Streams were so fragile
and were easily damaged or lost.)
The customer found that if they unchecked
Show pop-up description for folder and desktop items,
this solved the problem on some of their machines, but not all of them.
They asked the Explorer team what else needs to be done to stop
the ADS queries.
The piece they were missing was the status bar.
If the status bar is enabled,
then it shows the same information that would have appeared
in the infotip.
Turning off the status bar fixed their problem.
When you connect to another computer via Remote Desktop,
you have the option of injecting your local drives
into the remote computer,
Device and Resource Redirection.
These injected drives are available under the UNC
\\tsclient\X where X is a drive letter
on the local machine.
The name TSCLIENT
combines a bunch of internal technical terminology,
so it makes perfect sense to the people who wrote it,
but not as much to outsiders.
(They may have chosen this name
just to make themselves look smart.)
The letters TS stand for Terminal Services,
which was the former name of the technology now known as
And the word client
refers to the local computer, the one that is connected to the remote
In Terminal Services terminology, the machine you are connect from is
and the machine you are connecting to is the server.
There's another level of confusion in the name of the feature.
People often call these \\tsclient\X
thingies Redirected Drives,
which collides with the
local drive letters that have been mapped
to a network resource.
In the user interface, these are usually called Mapped Network Drives.
From the command line, you create these things via the
NET USE command.
Okay, enough with the confusing terminology.
For today, we're talking about Remote Desktop Device Redirection,
where the redirected device is a drive letter.
If you open My Computer and look under Other,
you'll see those drives which were injected from the local computer.
Your first tip-off that there's something funny about these drives:
They don't show up in the Network Location section
like other mapped drives;
instead they show up under the rather generic-sounding Other.
That's because these drives aren't really drives.
They are folder shortcuts,
a special type of shortcut that grafts one part of the shell
namespace into another.
The ones created by Remote Desktop Device Redirection are
shell instance objects,
which is a way of creating certain types of
shell extensions using just a handful of registry keys.
Since they aren't really drives,
some things that work for real drives don't work for these fake drives.
And one of those things is that Explorer thinks that they don't
support the New Folder command because when Explorer asks,
"Do you support IStorage?" (because that's the interface
that Explorer uses to create new folders),
the answer is
"No, you silly rabbit. I'm an Other!"
Now, it turns out that the Terminal Services folks could've
customized their Other to say,
"Actually, yeah, I do support IStorage."
You do this by setting the bit 0x00000008 in the
Attributes value of the
ShellFolder key when you registered your instance object.
The Terminal Services folks forgot to set that bit,
and the result is no New Folder button.
Sorry about that.
As a workaround, you can create your new folder by typing
\\tsclient\X into the address bar.
That folder is the thing that the folder shortcut is pointing to
(so it's just another name for the same thing),
but since it's the real thing,
it correctly reports the SFGAO_STORAGE flag,
and the New Folder button appears.
Windows Vista introduced
Session 0 Isolation
which enforces the rule that services should not display UI.
If a service tries to display UI,
another service known as the
Interactive Services Detection service
detects this situation and signals the user that a service
wants to display UI and gives the user an opportunity to switch
to the service desktop, respond to the UI,
and then switch back.
If the user ignores the service for about one minute,
it switches back automatically,
on the assumption that something went bad with the detection
and the service is actually finished with its UI.
(That way, the user doesn't get stuck staring at session 0 forever.)
More than one
customer wanted to know how to configure this one minute timeout.
The correct solution to the problem is not to configure
Interactive Services Detection
but rather to fix your service so it doesn't show UI in session 0.
It's like saying,
"When I mail a letter and get the postal code wrong,
the letter reaches the destination eventually, but it takes much
longer than a letter sent with the correct postal code.
How can I get letters sent with the incorrect postal code
to reach their destination faster?"
The answer is to
stop putting the incorrect postal code on your letters.
In other words, stop
throwing garbage on the sidewalk.
Troubleshooting Interactive Services Detection.