As noted in the article, projects Ren and Stimpy were merged into a single
project, which became Outlook.
You could say that Stimpy became Outlook, too.

Outlook Express (code name Athena)
was originally known as Internet Mail and News.
This was back in the day when the cool, hip thing for
Web browsers to do was to incorporate as many Internet client
features as possible.
In the case of Internet Mail and News,
this was POP (mail) and NNTP (news).

After Outlook became a breakout hit,
the Internet Mail and News project
was renamed to Outlook Express
in an attempt to ride Outlook's coattails.
It was a blatant grab at Outlook's brand awareness.
(See also: SharePoint Workspaces was renamed OneDrive for Business;
Lync was renamed Skype for Business.)

The decision to give two unrelated projects the same
marketing name created all sorts of false expectations,
because it implied that Outlook Express was a "light"
version of Outlook.
People expected that Outlook Express
could be upgraded to Outlook,
or that Outlook Express and Outlook data files
were compatible with each other.

Code name reuse is common at Microsoft,
and for a time, the code names Ren and Stimpy
were popular,
especially for projects that were closely-related.
(As I vaguely recall, there was a networking client/server project
that called the server Ren and the client Stimpy.
But I may be misremembering, and Ren and Stimpy
may just have been the names of the two source code servers.)
You may have heard the names
Ren and/or Stimpy
in reference to
some other projects.
Doesn't mean that your projects are related to any others with the
same name.

A friend of mine grew up in a rural area.
The family got their water from a well and had to fluoridate it manually
with tablets.

When my friend was a little girl, she was playing around the house
with one of her friends (let's call her friend Alice).
They got into the kitchen cabinet and
found these candy-like things and ate them.
When her mother discovered that they had eaten fluoride tablets,
she called the poison control center for advice.
In addition to telling her to give the girls something-or-other,
they instructed her to keep the girls moving until they
vomited up the tablets.

As it happens, my friend's brother and Alice's brother were
playing outside.
The boys were called inside, informed of what happened, and instructed
to keep their sisters
moving and try to get them to throw up.

The boys couldn't believe their ears.
You want us to chase our sisters until they throw up?
This must be what heaven is like!

The boys assumed their responsibilities with great enthusiasm,
chasing the girls around the yard,
putting them in a swing and spinning them around,
all the stuff brothers dream of doing to torment their sisters,
but this time they could do it without fear of punishment.
Fortunately, the story had a happy ending.
The girls soon vomited up the tablets and
thereby avoided two horrible fates:
(1) fluoride poisoning and
(2) being forced to endure torture from their brothers in perpetuity.

Today's Little Program displays a context menu with a bold item.
I sort of
talked about this some time ago,
but now I'm going to actually do it.
Remember, the boldface item represents the default item.
You should set it to the action that would have taken place
if the user had double-clicked the object.

Note that for expository purposes
(this is a Little Program, after all),
I am not heeding the advice I gave
some time ago.
As a result, this program does not support multiple monitors
or keyboard-invoked context menus.
Read the linked article for instructions on how to fix the code.

When you right-click on the window,
the On­Context­Menu function creates
a pop-up window,
fills it with some dummy commands,
and says that item 101 should be the default.
Then it displays the context menu to the user,
throws away the result,
and destroys the menu to avoid a memory leak.

One of my colleagues ran across this old news clipping
from 20 years ago today.

Flaw reported in Windows 95

THE ASSOCIATED PRESS

SAN MATEO, Calif. — Microsoft Corp.'s long-awaited
Windows 95 operating system has a flaw that can freeze up
computers when running certain applications,
InfoWorld magazine said Friday.

The company is aware of the problem but is shipping 450,000
anyway as part of a preview program,
the magazine said.

"I fear that unless Microsoft goes back to the drawing board
on this operating system,
only light users will get anything out of it,"
said Nicholas Petreley,
the magazine's executive editor.

He said the system's inability to handle several types of
sophisticated applications at the same time made it questionable
for business use.

I can't find a copy of the original InfoWorld article online;
all I can find are citations to it,
like
this one
and
this one.

The clipping had a handwritten note attached:

Bob,

You guys may want to respond to this.

Mom

The report was shortly followed by
a rebuttal from Windows Magazine,
pointing out that this was a beta release,
it is not unusual that an unfinished product has bugs,
and that a similar bug in an earlier beta was fixed within two weeks.

ZOMG! A beta product has a bug!

I found it cute that my colleague's mother chose to bring
this article to her son's attention.

Note that there are dangers here beyond craziness.
You have to make sure that your packing
function is injective (i.e., that it does not assign
the same packed value to two different inputs).
If you use MAKE­LONG as your packing function,
then the two values to be packed must fit into 16-bit integers.

Path­Is­System­Folder is for
marking a directory as "This directory has a nondefault UI behavior
attached to it.
Please consult the desktop.ini file for more information."
You do this when your directory is, say,
the root of a namespace extension,
or it has been subjected to folder customization.
Windows uses it to indicate that the directory
has a localized name,
as well as other funky internal state.

There are two ways to mark a folder as having nondefault UI.
One is to set the
FILE_ATTRIBUTE_READ­ONLY attribute,
and the other is to set the
FILE_ATTRIBUTE_SYSTEM attribute.

Either one works, and
Path­Is­System­Folder checks for both,
returning a nonzero value if either attribute is set.

In its default configuration, Windows
uses the read-only flag
to mark folders with nondefault UI.
However, some applications mistakenly believe that if a
directory is marked read-only, then files within the directory
cannot be modified.
As a result, these applications refuse to let you save your
documents onto the desktop, for example.
To work around this, you can use the
Use­System­For­System­Folders
to tell Windows to use the
FILE_ATTRIBUTE_SYSTEM attribute instead.
Of course, if you do that, you will run into problems with
applications which
mistakenly believe that if a
directory is marked system, then the directory is inaccessible.
So you get to pick your poison.

Programmers who wish to mark a folder as having nondefault UI
should use the
Path­Make­System­Folder function
to set the appropriate attribute.
That function consults the system policy and sets the attribute
that the policy indicates should be used to mark folders
with nondefault UI.

Going back to the original question, then:
The difference between
Path­Is­System­Folder and
checking for folders that are marked hidden+system is
that they check different things and have different purposes.

Back in the early 2000s, a new building opened on the Microsoft
main campus,
and the food services department tried an experiment:
Instead of creating a standard cafeteria,
they decided to make the cafeteria in the new building
a specialty cafeteria.
This new cafeteria was more like a deli,
specializing in offerings like
antipasto, rotisserie chicken, and grilled panini sandwiches.

The idea was that the building would generate cross-building
foot traffic with the building next door.
The food services department
figured that people would typically go to the cafeteria in the
old building next door,
but if they had a hankering for something offered by the
specialty cafeteria, they could walk over to the new cafeteria.

It was an interesting idea, but it didn't work out well in practice
because people are lazy and always go to the nearest cafeteria.
This meant that the people who worked in the new building wandered
into their cafeteria and saw the same specialty offerings every day.
And nobody from the other cafeteria ever came to visit the specialty
cafeteria.

One of my colleagues explained
the dining options in the new cafeteria with a Venn diagram:

◯

Rotisseriechicken

◯

Paninisandwiches

Chickenpaninisandwiches

After a few months, the food services department realized that their
plan wasn't working out too well,
and they converted the new cafeteria into a more traditional cafeteria.

Today's Little Program asks you to type something,
but gives you only two seconds to do it.
This is not interesting in and of itself,
but it shows you how to cancel console I/O.
There is no motivation for this exercise
because Little Programs come with little to no motivation.

Okay, fine, here's the motivation.

We have a GUI application that has a debug console.
When the user exits the application, we cannot shut down cleanly
because the debug console is stuck on a read from stdin.
We want to unstick the thread gently.
We don't want to use
Generate­Console­Ctrl­Event
with CTRL_C_EVENT because that will send the
event to all processes using the same console,
but we don't want other processes to be affected.

If you type something within two seconds, it is reported
back to you,
but if you take too long, then the
Cancel­Io­Ex cancels the console read,
and you get an error back.

If you want to continue, you'll have to
clearerr(stdin),
but if you just want to unstick the code that is
performing the read (so that you can get the program to
exit cleanly), then leaving stdin
in an error state is probably better.

(If you had used Read­File instead
of fgets, the read would have failed
with error code
ERROR_OPERATION_ABORTED,
as documented by Cancel­Io­Ex.)

In
Looking for leaked objects by their vtable,
we used the object's constructor to locate
the vtable,
and then scanned the heap for the vtable to find the leaked object.
But you can run this technique in reverse, too.

Suppose you found an object and you want to find its constructor.
This is not a problem if you have the source code,
but if you are doing some reverse-engineering for application
compatibility purposes,
you don't have the luxury of the application source code.
You may have figured out that the application fails because
the byte at offset 0x50 is zero,
but on the previous version of Windows, it was nonzero.
You want to find out who sets the byte at offset 0x50,
so that you can see why it is setting it to zero instead of
a nonzero value.

If the object has a vtable, you can scan the code segments for
a copy of the vtable.
It will show up in an instruction like

mov dword ptr [reg], vtable_address

This is almost certainly the object's constructor,
setting up the object vtable as part of construction.
You can set a breakpoint here to break when the object is
constructed,
and then you can set a write breakpoint on offset 0x50 to
see where its value is seto.

The Register­Window­Message function lets
you create your own custom messages that are globally unique.
But how do you free the message format when you're done,
so that the number can be reused for another message?
(Similarly,
Register­Clipboard­Format and clipboard
formats.)

You don't.
There is no
Deregister­Window­Message function or
Deregister­Clipboard­Format function.
Once allocated, a registered window message and registered clipboard
format hangs around until you log off.

There is room for around 16,000 registered window messages
and registered clipboard formats,
and in practice exhaustion of these pools of numbers
is not an issue.
Even if every program registers 100 custom messages,
you can run 160 unique programs before running
into a problem.
And most people don't even have 160 different programs
installed in the first place.
(And if you do, you almost certainly don't run all of them!)
In practice, the number of registered window messages is well under 1000.

A customer had a problem with exhaustion of registered
window messages.
"We are using a component that uses the
Register­Window­Message function
to register a large number of unique messages
which are constantly changing.
Since there is no way to unregister them,
the registered window message table eventually fills up
and things start failing.
Should we use Global­Add­Atom
and
Global­Delete­Atom instead of
Register­Window­Message?
Or can we use
Global­Delete­Atom to delete the
message registered by
Register­Window­Message?"

No, you should not use
Global­Add­Atom to create
window messages.
The atom that comes back from
Global­Add­Atom comes from
the global atom table,
which is different from the registered window message table.
The only way to get registered window messages is to call
Register­Window­Message.
Say
you call Global­Add­Atom("X")
and you get atom 49443 from the global atom table.
Somebody else calls
Register­Window­Message("Y")
and they get registered window message number 49443.
You then post message 49443 to a window,
and it thinks that it is message Y,
and bad things happen.

And you definitely should not use
Global­Delete­Atom in a misguided
attempt to deregister a window message.
You're going to end up deleting some unrelated atom,
and things will start going downhill.

What you need to do is fix the component so it does not
register a lot of window messages with constantly-changing
names.
Instead, encode the uniqueness in some other way.
For example,
instead of registering a hundred messages of the form
Contoso user N logged on,
just register a single
Contoso user logged on message and encode
the user number in the wParam and
lParam payloads.
Most likely, one or the other parameter is already being
used to carry nontrivial payload information,
so you can just add the user number to that payload.
(And this also means that your program won't have to keep
a huge table of users and corresponding window messages.)

Bonus chatter:
It is the case that properties added to a window
via Set­Prop use global atoms,
as indicated by the documentation.
This is an implementation detail that got exposed,
so now it's contractual.
And it was a bad idea,
as I discussed earlier.

Sometimes, people try to get clever and manually manage
the atoms used for storing properties.
They manually add the atom, then access the property by atom,
then remove the properties,
then delete the atom.
This is a high-risk maneuver because there are so many things that
can go wrong.
For example, you might delete the atom prematurely
(unaware that it was still being used by some other window),
then the atom gets reused, and now you have a property conflict.
Or you may have a bug that calls Global­Delete­Atom
for an atom that was not obtained via Global­Add­Atom.
(Maybe you got it via
Global­Find­Atom or
Enum­Props.)

I've even seen code that does this:

atom = GlobalAddAtom(name);
// Some apps are delete-happy and run around deleting atoms they shouldn't.
// If they happen to delete ours by accident, things go bad really fast.
// Prevent this from happening by bumping the atom refcount a few extra
// times so accidental deletes won't destroy it.
GlobalAddAtom(name);
GlobalAddAtom(name);

So we've come full circle.
There is a way to delete an unused atom,
but people end up deleting them incorrectly,
so this code tries to make the atom undeletable.
Le Chatelier's Principle strikes again.