Holy cow, I wrote a book!
Some time ago, somebody clicked the "Contact me" link
in the navigation bar, and despite the warnings, asked a
"If you have a question you can post it to the suggestion box."
Please, don't use a bot which pretends to be you to answer e-mails.
Especially such a poorly-designed one.
Maybe those people were right.
Perhaps I'm a robot.
(It would certainly be a lot easier for me if I were.)
I've been informed that the Redmond branch of the
Microsoft Company Store
has begun stocking the dead tree edition of
"But wait, your book isn't printed by Microsoft Press;
it's published by Addison-Wesley Professional.
I thought the company store only stocked Microsoft Press titles."
I'm told that this is a pilot program.
(And no, I don't know what the success criteria are.)
When I stopped by the store a few days ago, they were in the process
of reorganizing the book section, so not only was my book not up,
neither were any others!
But it should be there "any day now."
And remember, I'll gladly sign your book
but you have to tell me what to write.
this article on how you can
assemble a 10-day survival pack to keep in your car for just $25.
Possible Christmas gift idea? Who knows.
Don't forget the duct tape.
For good or ill, email is the most heavily used communication system
so much so that
most people at Microsoft are known by their email addresses,
sometimes more so than by their legal names!
most everybody at Microsoft knows
by his email address, "stepto"
(pronounced as if it were spelled "steptoe").
Notice that the name of his personal domain is
he has basically adopted his email address as his persona.
This example is hardly an unusual one
of how one's identity becomes wrapped
up in one's email address.
It's more likely to happen if
your email address results in something catchy and easy-to-say
Though most people don't take to this extreme;
he tells me that he doesn't typically respond to the name "Stephen" any more!
All this is a rather long set-up for today's story,
which is an amusing look at what happens when somebody
new to the company hasn't quite incorporated the Microsoft email
culture into their world view.
The names have been changed, of course, but the essence of the
story is true.
Subject: What is adamsmit's email address, I need some bug info
Thanks in advance.
Thanks in advance.
Y manages to keep a straight face in the reply.
Subject: RE: What is adamsmit's email address, I need some bug info
Cc: Adam Smith (firstname.lastname@example.org)
the weird sports questions you always
wondered but knew were too stupid even to ask.
Think of it as the sports version of
Well, he sort of gives away the answer to the last question in
the title of his book,
Andy Roddick Beat Me with a Frying Pan.
The stories behind how he set about finding the answers to these
absurd questions are even more entertaining than the answers themselves!
an interview with Only a Game's Bill Littlefield.
[Direct link - Real format]
On a somewhat concidental note,
tonight I'm going to watch the
take on the
making good on
my earlier admission of the possibility of seeing another hockey game.
Hopefully with normal-sized goalies.
the theoretical maximum file size on NTFS is 264−1 clusters,
the current implementation of the NTFS driver supports files up
to "only" 16TB minus 64KB.
(In other words, the disk format supports files up to
but the current drivers won't go above 16TB−64KB.)
Back in 2002,
in order to verify that the drivers did indeed support files
as big as their design maximum,
the NTFS test team sat down,
created a volume slightly bigger than 16TB,
and then created a file of the maximum supported size,
filling it with a known pattern.
After the file was successfully created,
they then ran another program that read the entire file back into
memory and verified that the contents were correct.
(They ran other tests, too, of course, but those are the ones that
are important to this story.)
How long did it take to create this nearly-16TB file?
Around three days.
Verifying that the data was written correctly
took about four days.
(Yes, it's strange that reading was slower than writing.
I don't know why, but I can guess and so can you.
Maybe the read test did a bunch of extra verification.
Maybe the read test used random access as well as sequential access.
Or maybe there was just rounding error in the reporting of the duration.
I wasn't there, so I don't know for sure.)
Back in 16-bit Windows,
MS-DOS cast a long and dark shadow.
The really ugly low-level munging was very much in the MS-DOS spirit.
You opened files by setting up registers and issuing an int 21h,
just like in MS-DOS.
Although the interrupt went to Windows instead,
Windows maintained the MS-DOS calling convention.
Process startup followed the same
"real men write in assembly language" philosophy.
All the parameters to a 16-bit program
were passed in registers.
The entry point to a 16-bit process received the following
parameters on Windows 3.1:
Hey, nobody said that 16-bit Windows was designed for portability.
The first thing a 16-bit program did was call the
This function receives its parameters in registers,
precisely in the format that they are received by the program
The InitTask function initializes the stack,
the data segment, the heap,
retrieves and prepares the command line,
recovers the nCmdShow parameter that was passed
to WinExec, all the normal startup stuff.
It even edits the stack of the caller so that real-mode stack
walking works (critical for memory management in real-mode).
When InitTask is all finished,
it returns with the registers set for the next phase:
Once InitTask returns, the stack, heap, and data segment
are "ready to run," and if you have no other preparations to do,
you can head right for the application's WinMain function.
Minimal startup code therefore would go like this:
call far InitTask
test ax, ax
push di ; hInstance
push si ; hPrevInstance
push es ; lpszCmdLine selector
push bx ; lpszCmdLine offset
push dx ; nCmdShow
... some lines of code that aren't important to the discussion ...
call far WinMain ; call the application's WinMain function
; return value from WinMain is in the AL register,
; conveniently positioned for the exit process coming up next
mov ah, 4Ch ; exit process function code
int 21h ; do it
Why wasn't the application entry point called main?
Well, for one thing, the name main was already taken,
and Windows didn't have the authority to reserve an alternate definition.
There was no C language standardization committee back then;
C was what
Dennis said it was,
and it was hardly guaranteed that Dennis would take any special steps to
preserve Windows source code
compatibility in any future version of the C language.
Since K&R didn't specify that implementations could extend the
acceptable forms of the main function,
it was entirely possible that there was a legal C compiler that
rejected programs that declared main incorrectly.
The current C language standard explicitly permits implementation-specific
alternate definitions for main, but
requiring all compilers to support
this new Windows-specific version
in order to compile Windows programs
would gratuitously restrict the set of compilers you could use for
writing Windows programs.
If you managed to overcome that obstacle,
you'd have the problem that the Windows version of main
would have to be something like this:
int main(int argc, char *argv, HINSTANCE hinst,
HINSTANCE hinstPrev, int nCmdShow);
Due to the way C linkage was performed,
all variations of a function had to agree on the parameters
they had in common.
This means that the Windows version would have to add its parameters
onto the end of the longest existing version of main,
and then you'd have to cross your fingers and hope that the C language
never added another alternate version of main.
If you went this route, your crossed fingers failed you, because
it turns out that
a third parameter was added to main
some time later,
and it conflicted with your Windows-friendly version.
Suppose you managed to convince Dennis not to allow that three-parameter
version of main.
You still have to come up with those first two parameters,
which means that every program's startup code needs to contain
a command line parser.
Back in the 16-bit days, people scrimped to save every byte.
Telling them, "Oh, and all your programs are going to be 2KB bigger"
probably wouldn't make you a lot of friends.
I mean, that's four sectors of I/O off a floppy disk!
But probably the reason why the Windows entry point was given a
is to emphasize that it's a different execution environment.
If it were called main,
people would take C programs designed for a console environment,
throw them into their Windows compiler, and then run them,
with disastrous results.