Holy cow, I wrote a book!
During the development of Windows 95, as with the
development of any project, the people working on the
project write side programs to test the features they
are adding or to prototype a feature.
After Windows 95 shipped, some of those programs
were collected into the first edition of the
Windows 95 Power Toys.
As I recall, the first edition contained the following toys:
I wasn't around when the decision was made to package these
toys up and ship them, so I don't know what the rule was for
deciding what was PowerToy-worthy and what wasn't.
Nor do I know where the name PowerToy came from.
(Probably somebody just made it up because it sounded neat.)
Upon the enormous success of the PowerToys, a second edition
was developed. This time, people knew that they were writing
a PowerToy, as opposed to the first edition of the PowerToys
which was merely cobbled together from stuff lying around.
The second edition of the Windows 95 PowerToys added
FindX, Send To X, the Telephony Locator Selector,
XMouse, and Tweak UI.
Later, the kernel team released their own set of toys,
known as the
Windows 95 Kernel Toys.
Alas, the original blurb text is not on the Microsoft downloads site,
here's an archived copy.
(In reality, it was I who wrote all of the Kernel Toys, except for the
Time Zone Editor, which came from the Windows NT Resource Kit.
I also wrote the somewhat whimsical original blurb.)
This was all back in the day when it was easy to put up
something for download. No digital signatures, no virus checking, no
paperwork. Just throw it up there and watch what happens.
Today, things are very different.
Putting something up for download is a complicated process
with forms to fill out in triplicate and dark rooms with card readers.
I wouldn't be surprised if an abandoned salt mine in Montana were
Nowadays, every team at Microsoft seems to have their own PowerToys,
trading on the good name of the Windows shell team who invented the
whole PowerToys idea. (As far as I can tell, we don't get any royalties
from other divisions calling their toys "PowerToys".)
A quick check reveals the following PowerToys available for download
from Microsoft; I may have missed some.
(Plus, of course, the
Windows XP PowerToys, which does come from the shell team.
The Internet Explorer team originally called their stuff PowerToys,
but they later changed the name to
Web Accessories, perhaps to avoid the very confusion I'm discussing here.)
What's frustrating is that since they are all called
"PowerToys", questions about them tend to go to the shell team,
since we are the ones who invented PowerToys.
We frequently have to reply,
"Oh, no, you're having a problem with the XYZ PowerToys,
not the classic Windows PowerToys. We're the folks who do the
classic Windows PowerToys."
the blog name "PowerToys"
has been co-opted by the Visual Studio team to promote their
Powertoys for Visual Studio 2003.
Some people claim
that Tweak UI was written because Microsoft got tired of responding to
customer complaints. I don't know where they got that from. Tweak UI
was written because I felt like writing it.
That page also says that sometimes PowerToys vanish without warning.
A few years ago, all the Windows XP PowerToys
were taken down so they could be
given a security review. Some of them didn't survive and didn't come back.
Other times, a PowerToy will be pulled because a serious bug was found.
Since PowerToys are
spare-time projects, it can take a very long time for a bug
to get fixed, tested, and re-published. For example, the
HTML Slide Show Wizard was pulled after a (somewhat obscure)
data-loss bug was found.
Fixing the bug itself took just a few days, but testing and filling
out all the associated paperwork took six months.
There's no moral to this story. Just a quick history lesson.
To detect programmatically whether your 32-bit program is running
on 64-bit Windows, you can use the IsWow64Process function.
Do not do
as some people do and
hard-code the list of 64-bit processors.
You'd think that after the hard-coded list of 64-bit processors
changed the first time (when x64 was added to ia64), people would have
learned their lesson.
But how do you detect programmatically from your 64-bit process
whether you are running on 64-bit Windows? Easy.
The fact that your 64-bit program is running at all
means that you are running on 64-bit Windows!
If it were a 32-bit machine, your program wouldn't be
able to run.
It's like asking the question, "Is the power on?"
If there were no power, your program wouldn't be able to ask the question.
Of course, if you want a single source code base that can be
compiled both as a 32-bit program and as a 64-bit program,
you have a tiny amount of work to do.
return TRUE; // 64-bit programs run only on Win64
// 32-bit programs run on both 32-bit and 64-bit Windows
// so must sniff
BOOL f64 = FALSE;
return IsWow64Process(GetCurrentProcess(), &f64) && f64;
return FALSE; // Win64 does not support Win16
I threw in a branch for 16-bit programs if you're crazy enough
to be still writing 16-bit Windows programs.