Holy cow, I wrote a book!
(In the continuing
sporadic series on the wisdom of seventh grade students.)
My friend the seventh grade teacher once had to deal with
a class that had gotten out of hand by assigning the students
a short essay in which they had to address three questions:
One of the more disruptive students answered the questions
An anonymous commenter
wanted to know how to create a dialog box with CreateWindow.
The window class for dialog boxes is WC_DIALOG.
I'm not quite sure why anybody would want to create a dialog box this way,
but there you have it.
"How do you throw out a garbage can?".
Along similar lines, I always wondered how you washed soap.
My posting a while back on
solving one problem by creating a bigger problem
was written from the standpoint of an IT department
doing something like tweaking a logon script.
I even mentioned that context partway through but clearly
didn't highlight it clearly enough.
So say you're an IT department and somebody says,
"Oh, just install this other program and learn a new programming
language and convert your existing batch file to it,
and then your problem will be easy to solve."
You might not be too excited about that type of "solution".
And even if you decide,
"Okay, I can justify to my boss taking
a week away from my other responsibilities
to convert our existing logon script (and all the helper scripts that
assumed that the root logon script was written in batch, say, because
they shared environment variables with it) to this new language
and debug the result,"
you still have the problem of getting that new script interpreter
onto all your company's computers so that when people log on,
your new fancy logon script can run at all.
And since you're a corporation, you have a whole new set of problems.
What are the licensing terms for that new script interpreter?
(A home user may just click "Next" through the license agreement
without reading it; a corporation doesn't have that luxury.)
How are you going to deploy this new script interpreter to all your
(Will it require a reboot since the installer may want to do things like
modify the global PATH?)
If you have a problem with the script interpreter,
who provides the support?
Will you have to pay extra to have it covered by your existing
If somebody finds that the script interpreter is in violation of
a patent, is your company liable for infringement since you are
using that script interpreter as part of your regular business
Maybe these questions are easy to answer,
but you still have to ask them.
Now, let's suppose you are, say, just a regular employee
at a company rather than part of the IT department.
Can you just take a program that you bought or downloaded
and run it on a company computer?
Odds are that if your company has an IT department,
it also has a policy on running "unauthorized" software
on company computers.
(They probably don't care how legal it is,
IT departments will almost certainly get very upset if you
start running a peer-to-peer file sharing program on your
For the home user, the activation energy is much lower.
You just have to convince one person to learn this new
language and translate their batch file into it.
The batch files of home users are probably not hundreds
of lines long, so the translation will probably be
But you may have a harder time of selling your proposal
if the batch file is 800 lines long.
I remember reading a news report on
a court case wherein the defendant claimed
protection under the First Amendment of the United States Constitution.
An interesting angle, especially since the case was being tried in Germany
under German law.
I may be wrong, but it is my impression that
Germany did not ratify the United States Constitution.
There's actually a point to this anecdote.
Occasionally, when someone notes that
Windows doesn't do one thing or another thing
for legal reasons,
people will post comments saying something like,
a German court
that XYZ is legal,
so your reason is bogus."
case of P vs. Q established that XYZ does not apply,
so that concern is irrelevant."
Or more subtly,
"It has been determined that DEF is allowed."
(Whose courts? Whose constitution? Is allowed where?)
You may not realize it, but Microsoft sells software
throughout the world,
and different parts of the world have different laws.
What is legal in one country may not be legal in another,
and Windows needs to conform to the intersection of all those laws.
(On rare occasions, it will change its behavior based on what
country you're in if that country's laws are significantly at odds
with those of the rest of the world.)
Claiming protection under the United States Constitution
or citing a U.S. court decision
doesn't carry much weight in front of a German judge.
Add this to your trivia pile.
a pair of articles that that go into the history behind
how Start Me Up become the theme for the Windows 95 launch.
Generally speaking, I believe that
you should try to avoid giving functions
a boolean parameter (BOOL, bool, etc.)
unless the meaning of that boolean parameter
is blatantly obvious.
Examples of obvious meaning would be
the second parameter to
the EnableWindow function
obviously means the window is being enabled and
FALSE means that it's being disabled)
and the final parameter to ShowScrollBar
obviously means the scroll bar is being shown and
FALSE means that it's being hidden).
In both of these cases, the meaning of the boolean parameter
is encoded in the name of the function itself.
But for functions like CreateEvent,
what does that first BOOL parameter mean?
First, you have to realize that the first BOOL
parameter controls whether you get an auto-reset event
or a manual-reset one.
Does FALSE create a manual-reset event?
Or is that done by passing TRUE?
I can never remember and I have to go looking it up each time.
That first parameter should have been declared as, say, a DWORD
or, even better, an enum
with two legal values, EVENTTYPE_AUTORESET and
Even worse is that CreateEvent has
two BOOL parameters.
Like anybody reading the code later can remember which comes first.
And the mystery bools keep coming.
Consider, for example,
What does true mean?
Heck if I know.
Mind you, this is just my opinion.
Others may disagree with me.
I remember a question from somebody who asked, paraphrasing:
We're writing a secure screen saver that the user can interact with.
We're going to present the user with various types of information,
and if they click on a hot link, we want to
launch a web page on their desktop once the user unlocks the workstation.
We know it's insecure, but we want to do it anyway.
Apparently these people didn't get the memo on security.
Windows tries to make it hard for you to do this to a secure screen saver.
The restrictions on secure screen savers have gotten tighter over time.
Originally, secure screen savers were isolated by putting them on a
Nowadays, Windows also runs
the secure screen saver in a job object, and
when the user unlocks the workstation,
all processes in the job are forcibly terminated.
Even if you came up with some sort of workaround for this,
it's entirely possible that
your workaround will be treated as a security
hole and rendered ineffective in a future version of Windows.
Suppose you find yourself some workaround and are willing to concede
that your technique is living on borrowed time.
It's still a bad idea.
One of the aspects of security that doesn't get much attention
Responding to the user's actions from a secure screen saver
to do anything other than unlock the workstation gives the user
"Yes, I know it's on your auditing logs,
but I assure you, I didn't click on that link.
When I came back from the printer room
and unlocked my workstation, this web site appeared.
It must have been somebody who wandered into my office."
If your screen saver does anything nontrivial,
it becomes something the user can plausibly deny,
because any random person walking by could have done it.
You have an untrackable and unattributable action.
Network security administrators really get the heebie-jeebies
when you say "untrackable and unattributable action".
I'm told that when people ask for this sort of "interactive
secure screen saver", they typically have some sort of
process control program that they want always to be available.
The thing is, if you're going to trust random passers-by with
your control program, then you have basically decided that your
computer's physical security is already assured.
In that case, you may as well create a special account,
configure the computer to auto-logon with that account,
and put the control program in the special account's startup group.
Just run the program like normal.
Don't try to pretend that wrapping it inside a "secure screen saver"
While the rules for secure screen savers have gotten tighter over time,
the rules for insecure screen savers have gotten more and more relaxed.
Insecure screen savers are run on the user's desktop so that they can
do the sorts of funny things that they got away with on Windows 95
such as taking a snapshot of the user's screen and using it as the
basis for a jigsaw puzzle that it animated.
Windows used to kill insecure screen savers as soon as the user touched
a key or moved the mouse, but that behavior was disabled in order to
allow people to write "interactive screen savers".
Some people might argue that allowing insecure screen savers to
interact with the user was a bad idea.
(Yes, Internet Explorer at one point had a screen saver that
did something like this.
I'm told that in follow-up surveys,
no customers actually admitted to liking the feature.)
Inherited permissions on an object are established when it is created.
Once the object has been created, you can change the permissions of
the parent and it won't have any effect unless you explicitly ask for
the inheritable properties to be re-propagated to the child objects.
(You may recall that
the CREATOR_OWNER SID
works in a similar way.)
This rule applies to files, though that can lead to behavior
that some people might consider non-intuitive.
Files are strange from a security perspective because a single
file can have multiple parent folders, thanks to hard links.
Suppose you have two directories DirA and
DirA has an inheritable permission
that gives UserA full access
and denies access to UserB,
while DirB does the same with the roles of the two users reversed.
It's easy to tell who the parent of a file is when it is created,
since a file is created by giving a path, and you can extract
the parent from the path.
For example, if the file DirA\File is created,
it will naturally inherit permissions from DirA.
One the file is created, though, that's the end of it.
Inheritable permissions don't have any effect any more.
This simple rule wouldn't normally cause any problems, except
that files have properties unusual among most named objects:
They can go by multiple names (thanks to hard links)
and can change their names (via renaming).
The apparently counter-intuitive behavior stems from confusing
the object with its name.
For example, suppose we create a hard link to DirA\File
under the name DirB\File.
What effect does this have on the file's ACLs?
Answer: None whatsoever.
The inheritable ACLs on DirB aren't applied to the file
since the file is not being created.
Besides, you couldn't apply the inheritable ACLs from DirB
even if you wanted to because it would create a paradox:
The file resides in both DirA and DirB,
but each of those directories contains contradictory inheritable permissions.
What would the result be if you somehow managed to apply both of them?
All right, then.
We have no choice but to decide that
a file's ACLs don't change when you create a hard link.
Now delete the original link DirA\File, leaving just
Does this change the ACLs now?
If you believe that it should, then you're saying that
inheritable ACLs can take effect even when nothing got created!
After all, we didn't create a hard link; we deleted one.
Okay, maybe you concede that deleting a hard link shouldn't
affect the ACL.
But what did we just do by creating a hard link and then deleting
The net effect is that we moved the file from DirA\File
Which brings us to our third example:
Renaming/moving a file does not change its ACL.
We've just rediscovered the
simple rule that inheritable ACLs take effect
only when a file is created.
Nothing special happens
when a new hard link is created or when the file is moved.
Of course, that simple rule holds only when you look at the file
system at a low level.
Layers built on top of the low-level file system can end up
complicating our simple rule.
When you move a file across volumes
with the MOVEFILE_COPY_ALLOWED flag,
you're saying that "move the file if possible; if not, then
convert it to a copy/delete operation".
The copy operation creates a new file, which means that
inheritable properties on the destination folder
do take effect.
But only if the file motion crosses volumes.
If you're moving the file within the same volume,
then the ACL remains unchanged.
When you pass the MOVEFILE_COPY_ALLOWED
flag, you lose control of the ACL.
(You actually lose control of much more than just the ACL.
Since the file is being copied, none of the attributes from the
original file are kept on the copy.
The copy inherits its encryption and compression
status from the new parent directory.
The copy also gets a new owner, which has follow-on consequences
for things like disk quota.)
Another layer built on top of the low-level file system operations
is the shell's copy engine.
If you use SHFileOperation to move a file
and pass the FOF_NOCOPYSECURITYATTRIBUTES flag,
then it will not preserve the original ACLs on the moved files
but will rather recalculate them from the destination's
(If you want to do the same thing in your own code,
you can call the
SetNamedSecurityInfo function, specifying that
you want an empty, unprotected DACL.)
In Windows XP,
the shell decides whether or not to use this "naive mode" ACL management
based on the following algorithm:
In celebration of their tenth birthday,
Paramount Comedy Channel in the UK
commissioned a study on how regional accents affect perceived funniness,
and the conclusion was that
people from Birmingham have the funniest accents.
The Received Pronunciation, which is the only British accent
most people in the United States are familiar with,
came in dead last.
I'm sure that there are some nuances of class that I miss out on
when I watch a British-made film due to my lack of familiarity
with the connotations that
each accent brings to the table: Which accents are the aristocratic
accents, the working-class accents, the stereotypical football fan
accents, and so on.
I wouldn't be surprised if the advent of mass media has taken its
toll on regional accents, softening the harsher edges and bringing
them a little closer together.
Which I think is kind of sad.
Personally, I think the northern accents are funnier,
like the ones used by
[Assorted typos fixed, 10:15am.]