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.