Holy cow, I wrote a book!
During Windows 95 beta testing, people ran the System Properties page and complained
about "missing memory".
The Windows 95 System Properties page reports the amount of memory available to Windows
as system memory, which is not necessarily the same as the amount of memory installed
in your computer.
For example, you may have an old DOS device driver that allocates a large amount of
memory for itself, which prevents Windows 95 from using it. Or you may have a dreaded
UMA machine, where your so-called 8MB of memory is actually being divided between
main system memory and video memory. So if you have an 8MB UMA machine and you're
running at 800x600 8bpp, you actually have only 7.5MB of memory, since the other half-meg
got eaten by the video card.
When we displayed the actual amount of memory available to Windows, we got lots of
bug reports from people asking, "I paid for 8MB of memory, where is it?"
The first letter of the program is the accelerator and there's nothing you can do
about it. So if you have ten programs by Microsoft, they all use the accelerator "M".
(Yes I hate this too. The first thing I do after installing a Microsoft program is
go into the Start menu and delete the word "Microsoft" from the front.)
For Win32 menus, the ampersand character acts as the marker for the menu accelerator.
For example, you would set your menu text to "Save &As" to set Alt+A as the accelerator
for the menu item.
Blue means compressed; green means encrypted.
This is an example of one of those "come on, it's a tiny, simple feature" requests.
Yes, the code to do this isn't particularly complicated, but it adds another element
of "Ha ha, I'm going to do something in a way that you will never be able to figure
out unless somebody tells you."
We get a lot of these little requests. If we accepted them all, you'd have icons with
so many incomprehensible decorations you'd never be able to figure out what all the
colors and markers mean.
So the next time you say to yourself, "Windows should change the appearance of X if
simple condition Y," imagine what it would be like if we actually did even twenty
of those simple things.
Because Windows thinks a screenreader is running.
If a screenreader is running, then the Advanced Options dialog will add "ON" and "OFF"
to the end of each checkbox item so the screenreader program can read the state to
a blind user.
The nice thing about the schwa sound is that you don't have to spell it.
Many thanks to C-J Berg for fixing my Swedish spelling errors. I probably introduced
some new ones here, though.
But why Swedish?
Well, it wasn't Swedish initially. Many years ago, I saw an ad in the local newspaper
that read, "Free Norwegian lessons, Tuesday nights at Xyz Church, Ballard." (Ballard is
the Scandinavian neighborhood in Seattle.) I read it and though Norwegian lessons
would be a fun, borderline goofy, thing to do. Especially since I figured most of
the other people in the class were there because their parents forced them. When the
Olympics were held a few years later in Lillehammer I was again inspired to learn
Norwegian, because the sound of the language appealed to me.
But it never really got past the "Gosh that would be fun" phase, until this year.
A friend of mine moved to Sweden, so I figured, "Well, if I'm going to learn a Scandinavian
language, Swedish seems the better choice now. And besides, it means I get to talk
to the people who work at IKEA in their native language!" (Nevermind that the people
who work at the Seattle IKEA probably don't speak Swedish anyway.)
Attended my first formal Swedish lesson last night. It's great to recapture the simultaneous
thrill and frustration of trying to have a conversation in a language you don't really
It's a small class - Swedish isn't exactly one of the "big-name" languages out there.
I always feel sorry for the student who can't seem to shake the bad American accent.
I remember in high school, we had a student who spoke German with a thick Midwestern
accent. It was painful to listen to.
I thought it was just me, but it seems to be a common trait: When people are learning
their third language and they get stuck, they instinctively fall back, not on their
first language, but on their second. For me, it means that when I can't find the Swedish
word for something, I substitute the German word. One of my classmates falls back
on Spanish. (Technically, German isn't my second language, but I never got very good
at the other language before German, so German acts as the de-facto second language.)
In order to understand this properly, it helps to know where WM_MOUSEMOVE messages
When the hardware mouse reports an interrupt, indicating that the physical mouse has
moved, Windows determines which thread should receive the mouse move message and sets
a flag on that thread's input queue that says, "The mouse moved, in case anybody cares."
(Other stuff happens, too, which we will ignore here for now. In particular, if a
mouse button event arrives, a lot of bookkeeping happens to preserve the virtual input
When that thread calls a message retrieval function like GetMessage,
and the "The mouse moved" flag is set, Windows inspects the mouse position and does
the work that is commonly considered to be part of mouse movement: Determining the
window that should receive the message, changing the cursor, and determining what
type of message to generate (usually WM_MOUSEMOVE or perhaps WM_NCMOUSEMOVE).
If you understand this, then you already see the answer to the question, "Why does
my program not receive all mouse messages if the mouse is moving too fast?"
If your program is slow to call GetMessage, then multiple mouse interrupts
may arrive before your program calls GetMessage to pick them up. Since
all that happens when the mouse interrupt occurs is that a flag is set, if two interrupts
happen in succession without a message retrieval function being called, then the second
interrupt will merely set a flag that is already set, which has no effect. The net
effect is that the first interrupt acts as if it has been "lost" since nobody bothered
to pick it up.
You should also see the answer to the question, "How fast does Windows deliver mouse
The answer is, "As fast as you want." If you call GetMessage frequently,
then you get mouse messages frequently; if you call GetMessage rarely,
then you get mouse messages rarely.
Okay, so back to the original question, "Why do I get spurious WM_MOUSEMOVE messages?"
Notice that the delivery of a mouse message includes lots of work that is typically
thought of as being part of mouse movement. Often, Windows wants to do that follow-on
work even though the mouse hasn't actually moved. The most obvious example is when
a window is shown, hidden or moved. When that happens, the mouse cursor may be over
a window different from the window it was over previously (or in the case of a move,
it may be over a different part of the same window). Windows needs to recalculate
the mouse cursor (for example, the old window may have wanted an arrow but the new
window wants a pointy finger), so it artificially sets the "The mouse moved, in
case anybody cares" flag. This causes all the follow-on work to happen, a side-effect
of which is the generation of a spurious WM_MOUSEMOVE message.
It's actually a signal to Explorer to look harder.
It doesn't mean that the directory is read-only.
If a folder has the Readonly or System flag set, then Explorer will look for a desktop.ini file
which describes the folder customizations. For performance reasons, Explorer does
this only if the directory has the +R or +S flag. (This is enormously important on
There are two KB articles on this subject, and I will defer to them for much of the
discussion. This is the version
that applies to Windows XP and Windows Server 2003. There is also a
version that applies to older versions of Windows, although the UseSystemForSystemFolders policy
Coders shold use the function PathMakeSystemFolder to mark a folder as
requiring special attention from Explorer.
Somebody in a comment asked, "Why not draw the text vertically?"
Ah, now you get to learn about the exciting world of vertical text.
We originally intended to run text vertically in the new XP Start menu. In original
designs for the menu, your name ran vertically up the left side of the menu instead
of running across the top.
Rotating text is problematic in languages that traditionally run vertically, such
as Chinese. Since you probably don't have Chinese fonts installed, pretend that %, &,
and ' are the Chinese characters for your name. In traditional
vertical text, it would be written as shown in Example 1 below. Notice that the English
text is rotated clockwise. This preserves the top-to-bottom reading order.
As a concession to Western influences, it is permissible to render Chinese characters
left-to-right, in which case your name would be written as "%&' (Amy
Compare this to the traditional Western way of rotating text. Text which would normally
be rendered as "Amy Smith" is rotated counter-clockwise and rendered as shown
in Example 2.
Now consider what happens if you take a Chinese name rendered the Western way, "%&' (Amy
Smith)", then rotate the Western way, resulting in Example 3. Notice that from a Chinese
point of view, everything is upside-down! The character that is supposed to be at
the top (%) is now at the bottom.
Windows for many years now has been multilingual.
This means that the same underlying code runs regardless of language. Changing a language
merely changes the strings being displayed. This means that there can be no language-specific
UI. In this case, it means that we can't have separate rotation rules for Chinese
as opposed to English or German.
(And even if we were allowed to have separate rotation rules, we would have to be
able to tell whether the name was in the form above or was in the form "Amy Smith
(%&')". In this form, we should rotate it as in
example 2, since this is an English string with Chinese characters embedded; as opposed
to our example above where we had a Chinese string with English characters embedded.
Those of you who have seen Arabic and English mixed together get to see punctuation
marks bandied about with similar degrees of confusion.)
Multilingual support also explains why you see things like "1 folder(s)" instead of
"1 folder" and "2 folders". Why not have two format strings, one for when the number
of items is exactly one, and one for when the number of items is two or more?
Well, for one, that would significantly increase the number of strings we would have
to carry around. (If you say "just add s to make the plural" then you really need
to get out more!)
For two, some languages (such as Slovene) have a "dual" number in addition to singular
and plural. The Lahir language has singular (one), dual (two), trial (three), paucal
(a few), and plural (many). So now you have to have perhaps five versions of every
string that contains a replacable number.
This also explains why you see a lot of strings of the form "Property: Value" (for
example, "Last modified: Monday, September 29, 2003") instead of a phrase ("Last modified
on Monday, September 29, 2003"). This is necessary to avoid problems caused by grammar.
If you attempt to compose a phrase, you have to worry about subject/verb agreement,
gender and number agreement, declensions, all sorts of things that computers aren't
good at. The only safe solution is to avoid it entirely and use the "Property: Value"
We did get one special exception to the "grammar independence" rule: Personalized
folders. When you view somebody else's "My Documents" folder, it says "Chris's Documents".
We made this request to the translators and they worked really hard to make sure that
the templates for possessive forms were accurate in all the languages we support.
(Fortunately, we didn't have to deal with languages where the form of the template
depended on us knowing whether Chris is a man or a woman.)