Hey I'm Dave, welcome to my shop! I'm Dave Plummer, retired operating systems
engineer from Microsoft going back to the Windows95 and MS-DOS days, today, I'm speaking
at Oxford university about Microsoft, what it was like there in the 1990s, and some of
the projects I worked on like the Windows Task Manager, Zip Folders, Space Cadet Pinball,
and so on. Unfortunately, due to Covid, the presentation
is all online, but my loss is your gain as now you can watch from the comfort of your
own chair on YouTube. Enjoy! Good morning, afternoon, or evening, as the
case may be wherever you are. Being asked to speak at the ICTF conference
certainly fell into the classic Good News/Bad News pattern. The good news, of course, is that you're being
asked to speak at Oxford. The bad news is that, thanks to the aftershocks
of Covid, you'll be doing it from the comfort of your own basement or garage via Zoom. The exquisite history and architecture of
the campus have been replaced instead by my hot water heater and some old cans of latex
paint. And while working locally has a few advantages,
course, the last bit of bad news is that due to the time difference, I'm speaking to you
live at 2:30AM in the morning my time. I'm rarely entirely coherent at 2:30AM in
the morning and there's no guarantee that today will be an exception! As you've likely deduced from the schedule,
my name is Dave Plummer, and if you don't recognize it that's really to be expected,
as I'm one of the anonymous software engineers enlisted by Microsoft to write operating systems
such as MS-DOS and Windows. Odds are then, that you would know me best
by some of my work, like Task Manager or the ZIP file support in Windows, the port of Space
Cadet Pinball, Product Activation, and so on. Along the way I also worked on products like
MS-DOS, Media Center and a number of other technologies. Of those, I've opted to speak to you primarily
today about the Windows Task Manager and the unlikely story of how it came to be, and in
so doing I'll be able to relate a little about myself, my background, and my time at Microsoft
back in the 1990s. By now the odds are that you've used Task
Manager at some point and have at least a cursory familiarity with its menus and buttons,
but you might be surprised to learn that they didn't always carry the names that they do
today. About the time that I was putting the finishing
touches on the first versions of Task Manager, a new group had started up within Microsoft
called POLCHECK, for policy check. Its sworn duty was to defend our honor by
scouring the Microsoft source code and its products for pretty much anything that would
make us look stupid, unfeeling, out of touch, and so on. Basically, it was a pass of political correctness
and professional sanity run upon the code and was often sorely needed. In the ancient days, programmers could be
known to take out their frustration by leaving comments in the source tree that would make
even the rowdiest of sailors blush. I likely learned more colorful cursing imagery
from reviewing old code than ever I did from reading the bathroom walls at the county fair. Other than security experts and a few folks
in academia, however, few would actually see our internal Windows source code. But many would see the end user product, and
that is why it was important that the product design and user interface reflect the new
kinder, gentler, Microsoft. The days of the harshly angled DOS prompt
were over, and Windows was going to be your friend and your confidante, no longer merely
a rude adversary. We were going to take the sharp edges off
so that nobody got hurt. The most basic checks, of course, were for
profanity. No problem there, as like you, I'm sure, I
tend not to encode a lot of profanity into my products. But when we got to the stage for "violent
imagery", it became clear there would be a few issues. That's because Task Manager is, quite frankly,
a natural born killer. Like the character of Winston Wolfe who serves
as the Cleaner in Pulp Fiction, Task Manager is the one you call when you're facing an
insurmountable computer problem. Task Manager stands there in its little tuxedo,
confronts the problems and makes them go away. When everything else has gone wrong, and the
system is failing down around you, Task Manager is often the tool you reach for to right the
ship and steady its path. And the first thing often you do when a system
has run amok is to find the offending process, and, well... kill it. In the computer science world this harsh notion
of killing tasks and jobs goes back to the 1950s, as does the notion of parent and child
processes. In fact, even the signal-based system of Unix
still used "kill" as the command name, so it's something a systems programmer could
become a little desensitized to over time. Still, even I knew that clearly, we couldn't
ship a product with a big red Kill button or a Kill menu item. We decided that the softer cases would be
called "End Task". Your process wouldn't be harshly killed, it
would sort of wander towards the light in a graceful exit, perhaps saying hello to a
ghostly visage of its parent process as it went by. Shaking hands with the other old processes,
it wound saunter out the exit door while quietly saving it work accompanied by soothing jazz
piano. The harder cases, where the process wasn't
playing nicely, meant we would use the verb "Terminate", and later, "End Process". If a process were behaving badly, and if it
didn't respond to more reasonable requests to knock off whatever it was doing, you could
ultimately Terminate it, assuming you had the correct permissions. The attorneys from PolicyCheck were becoming
a little frustrated with me, as though I had personally made up all this violent verbiage
just to test their patience and the limits of their system. And right when they thought we were done,
he asked me for the final menu items. We were on the last page now, the process
page, and it's not very user friendly to begin with. It's really where I hid all the nerd knobs
for low level process monkey business. The first major verb after Kill Process was
the very unfortunately named "Kill All Children". We struggled a while with that one before
finally agreeing to call it "End Process Tree". And the final one? It was simply renamed Shutdown and Exit. But what did it actually do? Well, as far as functionality, its purpose
was to rapidly flush buffers and exit. All apps would stop, a complete service shutdown
would occur and then final system exit. Particularly if the Component Object Model
and its threaded apartments were in use it really come down to "Kill all children, then
kill self, and then burn down the rental apartment". So, thank goodness for Policy Check, because
the life of a Task Manager can be a dramatic and scary one. In the Beginning
It's always hard to know where to begin a story such as this. I decided to embrace brevity for your comfort
and to compress two centuries into a few sentences. If you do go back far enough, my ancestors
owned and operated the Sportsman public house in Luton, about an hour from Cambridge. The youngest emigrated to Canada in the early
1900s after obtaining a land grant for a homestead in Saskatchewan. Soon a family hardware store was opened in
town, and that business continued on down for four generations. My Dad's store was just down the alley from
our house, as was my retired Grandfather's workshop, and so every day from about the
age of 5 on up, especially in the summers, I would wander down and hang out with my Dad
at the hardware store for a while and then visit my grandfather at his shop. Not only did his shop feature an actual Coke
machine, he had the key, and sometimes he'd open it up and grab us each a bottle. As a little kid, being able to open the Coke
machine seemed to me to be the ultimate in power and privilege! Between the hardware store and grandpa's shop
I spent a great deal of time hanging around with folks that were busy fixing, inventing,
and building things, and I think that was somehow formative. Of course, what was hardware for them would
turn out to be software for me, but the core instincts are very similar, I think. By 1980, when I was 11 and able to venture
a little further from home, I made my way into the local Radio Shack, a retail electronics
chain. There, out of the boxes but not yet set up,
sat something I'd only heard of: a computer. The TRS-80 Model 1, Level 1, with 4K. When I asked when it was going to be ready
to see, they said they weren't sure how to hook it up yet. In a move that would become somewhat of a
theme in my life, I offered to set it up even though I clearly had no idea what I was doing. They must have felt I was precocious enough
to humor with their expensive system because they said "sure, kid, have a shot" and left
me to it. Now in all honesty, it wasn't much different
from connecting a component stereo, except Tandy, in their infinite wisdom, used the
exact same round 5-pin-DIN connector for video, power, cassette, and keyboard, but I still
somehow managed not to blow it up. It was to be my first experience with "Das
blinkin lights" and I loved it. The more LEDs something had, as far as I was
concerned, the better. Once up and running, I naively performed a
Turing test of sorts on the machine by typing English commands into the BASIC interpreter. My only prior computer experience had been
watching Star Trek, where the machines could answer sufficiently logical human questions. It failed miserably and responded only with
SN? which I decided must mean spelling error. Later I would figure out it was a Syntax error,
but at that age I didn't know what syntax meant anyway. Suffice to say, I didn't get very far that
first day, but I walked or rode my bike down there every Thursday night and Saturday morning,
and the manager, Brian Patmore, graciously let me key in the BASIC programs I had dreamed
up in elementary school in the days prior. I didn't even save any of these early programs
to cassette and keyed something new in every time. I initially had no idea how limited the interpreter
truly was, but I learned quickly. There were no books on how a kid could learn
Zed 80 assembly language, at least not that I could find. While the Radio Shack guys were friendly,
initially they knew less about the machine than I did. And as nice as they were about letting me
exploit Regina's Thursday night shopping policy, I couldn't spend all my days sitting on a
stool in the corner of a retail store. My family couldn't afford a cutting-edge computer
like the TRS-80, but by the time I entered high school in 1982 my dedication to the subject
had convinced my parents to stretch their budget enough to purchase a Commodore 64. I was also fortunate that the high school
I attended had an excellent Computer Science teacher by the rather apt name of Mr. Breit. He stoked our interest in the material by
assigning interesting projects like a prime sieve competition and he gave us extra-credit
assignments called "Trivials" that challenged kids of all abilities. Thanks to cars and girls and various other
distractions my path to university was a circuitous route that took about six years, but I got
there eventually. It was a foregone conclusion, I suppose, that
I'd study computer science In some form, but I still had no real idea what I wanted to
do when I grew up. Would I be a game programmer, or write the
code to run the clock on microwave ovens? I really had no idea. I was going in the right general direction
even though I didn't know precisely what my ultimate destination was going to be. It all became suddenly clear during my summer
break during my third year of college. I was working a summer internship at the phone
company where I was converting their network over to 10BaseT and each day I had an hour
for lunch in the food court. I took to reading each day as I dined with
the old and the bored, and one book I picked up was called "Hard Drive: Bill Gates and
the Making of the Microsoft Empire". As I read the book, I became increasingly
entranced by the stories of the people and the projects at the company. The people there sounded like me, they acted
like me, and apparently, they paid them fairly well for doing so. It was everything I didn't even know that
I had been looking for. I became increasingly certain that, unlikely
as the prospects might be, Microsoft was the place I wanted to be. But Seattle is a long way from Saskatchewan,
and it was in another nation entirely. How would I ever get there from where I was? Even had I lived next door, Microsoft was
already receiving on the order of 100,000 job applications a year. The odds were stacked against me, but I had
one trick up my sleeve, as it were. I had been putting myself through college
by writing and selling applications for the Amiga series of computers, such as the program
known as HyperCache, which had quite a following in the Commodore community. In those days before the web, software often
came with a registration postcard that you would complete and mail in, and my program
was no exception. I had a stack of a few thousand little blue
cards, so I started to go through them all looking for anyone with a Microsoft email
address. I found about four people in total and wrote
a polite email to each one. I explained that I was a computer science
student nearing graduation and that my goal was to land a position or internship with
Microsoft. One person wrote back, a fellow by the name
of Alistair Banks. He was a British fellow who happened to be
working Stateside at the Microsoft headquarters at the time. He gave me what was perhaps the greatest gift
you can give to an aspiring college graduate, and that was the direct contact emails of
a few Microsoft development managers that were actively hiring. I wrote to each of them in turn and after
a lengthy phone screen I was flown out for a set of all day interviews that, were I successful,
would net me an internship for my final summer of school back in 1993. I would be working on the MS-DOS team under
a senior developer by the name of Ben Slivka. [Slide: Microsoft Campus]
Microsoft Interview Microsoft interview loops used to be famously
grueling. You spend the entire day there. You start with an interview at the Human Resources
Department to make sure you're sane and bathed, and if so, you're then off to a series of
5 one-hour coding interviews where you stand at a whiteboard and answer brain teasers and
write C and assembly code until you can't go any further. They push you until they stump and/or break
you, and then depending on how those first five interviews go, you might make it to the
"As Appropriate" interview, which is the hiring manager. The answer is Boolean at each of the steps
- Hire or No Hire. You cannot almost hire a person, and thus
there are no maybe responses allowed. You only get to the final interview if most
everyone else has said "Hire", since the team must be fully bought in on who gets hired:
it's not just up to the boss. In fact, the boss is the last one to decide,
and the team determines who makes it that far. The coding problems are simple tasks that
you can fit on one whiteboard, like how to reverse a doubly linked list. Or how to count the number of bits that are
set in a word. Attempt to factor a prime number, that sort
of thing where there's an obvious and trivial approach that can be refined and then optimized. You want to see their thought process, and
you want to see what they consider to be "good enough". Take the case of counting the number of bits
that are set in a 32-bit word. The na ve approach is to OR it with one, increment
a count if true, shift the word over by one bit, and repeat. Do that 32 times and you've got your answer. But that can be improved - you can stop as
soon as the remaining word is zero, after all. As the interviewer, you watch to see if the
person picks up on those little optimizations as they chew on the problem. But what about long runs of zeros separated
by ones, that seems like a waste of time. Well, it turns out that instead of ANDing
with one, you AND with the number itself less one, and that way you only do one operation
per actual bit that was initially set. If three bits are set, you only do three tests. In other words, there's the simple answer,
the fast answer and the "smart enough to get yourself hired" answer. Starting Internship at Microsoft
I learned quickly that I'd made it, and right after final exams at school, I flew down. After a couple of hours of New Intern Orientation,
they gave me an office, an account, and a copy of the MASM assembler. From there, it's sink or swim. Remember, it was still 1993: There was no
World Wide Web to look things up on. There was no Google or Wikipedia or Stack
Overflow. I had never written a line of x86 code before,
and they were expecting me to be productive immediately. I was sitting in an office with a chair, a
desk, a used PC and a network cable. Where do you even start? I can't overstress the 'straight into the
fire part' - it's not like phone company where they give the intern a token task that he
or she can't screw up and won't cause a problem when they inevitably do anyway. In contrast, Microsoft has me working on the
core codebase on new features for MS-DOS, which is a multi-billion-dollar business. Bill Gates has us over to his house for a
BBQ to talk about it over a few beers, and I'm supposed act like this is all totally
normal for me. They do take their interns seriously. There are only perhaps 5 or 6 developers in
total on MS-DOS and most of that team is feverishly rewriting the hard disk compression engine
to not use a hash-table, which it turns out the Stac Corporation managed to somehow get
a patent on and that Microsoft lost a lawsuit over. Thus, with the big brains working on the hard
problems, it's me and one other intern developer responsible for pretty much every new feature
in MS-DOS 6.22. I wrote the new SmartDrv CD-ROM cache, moved
Doublespace Into the High Memory Area, made Diskcopy single pass finally, fit the entire
upgrade onto a single floppy using binary deltas, and so on. The work took about three months, and even
though I felt I had done a good job, there was no guarantee that an internship would
ever translate into a full-time position. When my summer was over, I went back to hometown
of Regina to go back to class and hope the phone might ring one day. I started final semester of university, taking
classes in two of my favorite areas from two of my favorite professors - advanced operating
systems topics with Dr. Hamilton and a sweeping tour of uncommon languages from Ada to Prolog
that I'd otherwise never have had the opportunity to touch with Dr. Yang. The school Is Incredibly fortunate that both
are still there today! The Microsoft Offer
And I remember exactly where I was and what I was doing when that offer call came in that
fall. I was being offered a full-time software design
engineer position in Redmond with complete relocation benefits, visa and immigration
assistance, the works. And the salary? Are you ready? You've all heard of the Microsoft millionaires
of that era... well, it was under 25,000 pounds a year. That's all they were paying, but I didn't
care. I didn't negotiate. Whatever it was, it was enough. I wasn't in it for the money, even if I thought
I was at the time. It wasn't until the UPS delivery drivers went
on strike that summer that I found out they were making a fair bit more than I was! But I didn't care, and there were these other
things called "stock options?" that worked out OK in the end. What I found especially interesting was to
compare notes with the other new hires from places like MIT and Harvard. They got the -exact- same offer as I did,
right down to the penny. My fianc and I flew to the United States and
I was taken into the big glass room for my immigration interview. As she watched from the outside, she could
see the Immigration Officer flailing his arms and turning red in the face and yelling. Clearly, I was headed back to Canada and my
Microsoft dreams were not to be. But what she didn't know, because she couldn't
hear anything, was that he had already long since stamped and approved my work Visa. He was upset because every time he printed
a document in Word it would print blank piece of paper at the end, and it was wasting paper,
and since I was going to work for Microsoft, he wanted me to fix it for him, right then
and there. So I did - I fixed the borders at the border
and he let me on through. That May I flew back one weekend, convocated
from the U of R on Friday, got married on Saturday, and then permanently relocated internationally
to the USA on Monday. And by the way, if you are planning a wedding,
I strongly endorse the approach of hiding out in another country while all the hard
decisions are made for you. Then just fly in the day before, get married,
and fly back out. Truly hassle free! [Slide: Dave at Work]
VisualZIP and Task Manager I spent the majority of my career in Windows
NT, which became Windows XP, and is today the code you know as Windows 10. Back in those days, just like today, I liked
to code. I liked to code a lot. In fact, I'd code all day at work at Microsoft
and then come home and code on my side projects at night until bed. I'm also the kind of guy who's just genuinely
curious about what's going on my in my system and who enjoys seeing machines of any kind
busy at work. I could literally sit and watch Norton Speed
Disk shuttle blocks and sectors around my disk in a fascinating dance for longer than
I probably should. Heck, I've even defeated the safety and propped
the lid of my washing machine open to watch it run a full cycle out of curiosity about
how it worked; there could be a whole spectrum of reasons why, but I think I'm just wired
that way. Now that I was working on the fledgling Windows
NT, with all its complicated internal mechanisms, I wanted to get some insight into what was
going on with my own desktop as well, and that interest led to Task Manager. Today you might think of Task Manager primarily
as a way of dealing with rogue apps and frozen desktops, but that ability was secondary to
the monitoring piece of determining what was programs were running, what resources were
in use, what was still free, who owned what, and most important, what if anything looked
out of the ordinary. It was more about inspection than control. What was running, how much memory each process
was using, how many threads of execution each had operating, how many graphics handles it
had outstanding, and so on. With a glance, a knowledgeable developer could
now easily spot a resource leak with ease. In a way it's a debugging tool written by
a developer that even end users ultimately found useful. I wrote that first draft in my den at home
and then took the resultant rough program into work. In those days we followed a practice known
as Eating Our Own Dogfood, which meant we were self-hosted on the newest builds of Windows
NT even as we worked to create them. Eventually several other developers talked
me into giving them copies, and it spread amongst the team. It eventually came to the notice of Dave Cutler,
the designer of Windows NT and our only other boss beyond Bill Gates. Fortunately, he was a fan of the fledgling
Task Manager and gave me permission to add it to the main Windows source tree. A few days later, Task Manager was part of
Windows. No money exchanged hands and no contracts
were signed. I simply added it to the project source tree
and changed the copyright headers. It was very much a wild west in comparison
with how you would go about it today. The best part about it at the time, at least
from my perspective, was that once I added it to the product, my hobby became my day
job. The software that I had been tinkering with
in my den now became my primary full-time job for a few months. It would be very much like if you had a hobby
of building and painting little birdhouses, and then one day you brought one in to show
your boss, and your boss said "You know Dave, really like your little birdhouses, and we're
going to pay you to build them while you're here at work too." My birdhouses just happened to be things like
Task Manager. Contrast that experience with the one I had
about a year later involving the system software known as ZipFolders. That's the code that enables you to download
and browse through Zip archives using the Windows shell, and it lets you drag and drop
in and out to compress and decompress files, and so on. I had written it at home but released it as
shareware. I was selling perhaps a dozen copies a day
when somehow a Windows product manager at Microsoft stumbled across the utility and
decided that it, too, belonged in the operating system as part of Windows. To that end she called me early one morning
at home, before I'd left for work, to explain that they wanted to purchase the program from
me for inclusion in Windows, and would I be willing to discuss it? I offered to stop by her office that morning,
which seemed to unnerve her - she demurred and said I should talk to Microsoft Travel,
which confused the heck out of me. Why would I schedule a travel visit to Microsoft
when I worked there every day? I lived only a few blocks away! It turned out, after some uncomfortable back
and forth, that she had no idea that I worked at Microsoft, just as she did! She had merely researched, tracked down, and
cold-called the author of ZipFolders, who happened to be me, at home to explore an acquisition. As a result, my choices were quite limited. If I did not sell it to Microsoft, they would
simply develop their own or buy a competing one, and I'd have to stop selling mine or
quit my day job - I couldn't just continue selling mine in competition with my own employer
once they had entered the market! And so, I cheerfully accepted their first,
best, and only offer. Still, everyone was happy: I showed up at
work the next week in a red Corvette and ZipFolders remains as part of Windows to this very day. Turning the story back to Task Manager itself,
you can't just stick a piece of shareware into an operating system and call it good. There is a huge difference in required code
quality and robustness between an app you cranked out over a weekend and a part of the
Windows operating system. It would take a lot of work to bring my quick
and dirty draft up to the standard required for inclusion in the operating system, and
that work would comprise my day job for the coming weeks or months. As you can imagine, when it comes to an app
like Task Manager, the accuracy of the data its reporting is paramount, and early in its
development I was chasing an annoying bug related to total CPU usage. It was all calculated very precisely for each
process based on the system accounting, but when they were added up individually, very,
very rarely, it would flash briefly greater than 100 percent. I stared at my code until I could barely see
straight, but I just couldn't find a problem. I convinced myself that the problem had to
be in the kernel's accounting, but blaming the kernel is almost akin to claiming "it
must be a compiler bug" when you really don't understand what your own code is doing. The bar for blaming the kernel guys was very
high, and when I did try, they were unmoved. They were pretty certain it had to be my problem. In order to try to catch this weird edge case,
I placed an assertion in the code. An assertion is a statement which verifies
that a particular condition is always true, and I added one to continually check and validate
on every machine everywhere that the total was 100 percent or less. It would also re-check that total once per
second. My assertion would trigger if the total was
ever more than 100 percent. The plan was to run this through the entire
gauntlet of nightly NT Stress tests across the team. What is an NT Stress test? Well, each and every night every developer,
before they left, would start a test suite that put their PC to work running the day's
latest test build of Windows under enormous load. It would call every API and do everything
it could think of to destabilize or crash the system so that we could attempt to catch
those cases and debug through them and fix them. There were many people whose full-time job
was entirely to devise new ways to abuse the operating system in the hopes of breaking
it. These tests would run all night on every machine
we had, all while each was connected to a debugger. Any oddity would be investigated by the developer
responsible for that particular area. They could connect to the machine's debugger
remotely from anywhere, even from home, and that gave them the opportunity to inspect
the issue live. Into this mix I added my assertion message
that the CPU time was never greater than 100 percent in total. If it ever was, an alert message would pop
up on the user's desktop and if NT Stress were running, it would stop right there the
debugger. And yet nothing ever happened. We could never catch it happening during stress,
and the few times it did happen live during interactive daily use were harder to catch. Since repro cases were so exceedingly rare,
I got a little desperate and did something unconventional: I put my home phone number
in the message. If this ever happened to anyone in the Company
testing the product, I wanted to know about it right away, no matter what. In the meantime, I moved onto other issues
and kind of forgot about the message. That was unfortunate, because it means I also
forgot to remove it, and my home phone number, before we publicly shipped the Windows Beta
far and wide around the world. It meant that every time the issue manifested
itself to anyone anywhere on the planet, my home phone number would be displayed to the
user. Not smart. A few weeks later we caught a case in the
debugger on a machine at work. I debugged it far enough to convince myself
the problem had to be in the kernel, and I handed the debugger connection off to them
to investigate further. Sure enough, there was, in fact, a tiny accounting
error somewhere in the kernel that happened very rarely that would push reported CPU time
over 100, and Task Manager had just been dutifully reporting that. It wasn't my bug, and it was now fixed, both
of which made me happy, and I removed my home phone number from future versions of Windows. 25 years later I still have that same home
number, and thankfully, no one has ever called. As if dealing with the Shell and Task Manager
wasn't bringing me enough to do at the time, I also volunteered to write the Windows NT
version of Space Cade Pinball. Our Senior VP wanted to be able to show off
how Windows NT could support gaming, and what better way than to include a game that's fun
and visually compelling yet still runs on pretty much any computer, no matter how old
and frail? It's a rare opportunity to add a new game
to Windows and mine was going to make Solitaire look like Minesweeper. Given all the original IP from Maxis, I thought
it would be smooth sailing until I discovered such complications as the sound engine it
used being written entirely in fast x86 assembly language with few comments, which effectively
necessitated reverse engineering it and then rewriting it from scratch in C++ so that it
could work on all of our CPUs, including the RISC platforms. The nice thing about having worked on Space
Cadet Pinball is the street cred it gave me when volunteering at my kid's school to teach
their computer labs. Those little kids could care less about most
anything I'd worked on with that one exception: they all seemed to know and love Pinball. And being able to make a little show of walking
over and entering a "secret code" that only I knew that gave them infinite lives? Priceless. One reason that it was important to maintain
a small size is that Task Manager is a bit like the Highlander - there can be only one. Or at least there should only be one instance
of it running at any time. There are a number of different ways that
you can launch Task Manager, so managing the single instance problem really has to be up
to the program itself. Task Manager does this by looking for another
instance as soon as it starts. If it finds one, it sends a private message
to the existing instance with a challenge code. The running instance must provide the correct
response within 10 seconds. Any failure or unexpected results along the
way and Task Manager will launch a new instance so that in theory you're never stuck without
a usable task manager. Even if one is a zombie, another will be created
to take its place. Your worst case is having multiple Task Mangers
running. Task Manager takes a number of other defensive
steps so that it has the best shot at providing at least the basic functionality that you
would normally find on the Processes page. For example, even though it's not the first
page, it's created first. Then I check memory, and if I've gotten that
far but memory is low, as in under eight megabytes, then you get a severely reduced Task Manager
with a much smaller memory footprint, but one that is still able to do basic process
reporting and management. You should be able to get a Task Manager up
and running with what today would be almost no memory free. One nice little touch owes its existence to
a story I'd heard. Apparently, the GPS failed on a helicopter
near Seattle and so the pilot needed to know his current location in order to set his bearings
on the map. They came upon a low-rise office complex,
and so they hovered outside a window and quickly made up a sign that said, "WHERE ARE WE?". The person inside the building furiously wrote
up a sign of their own and held it up to the pilot which read "YOU ARE INSIDE A HELICOPTER". To the amazement of the passengers, the pilot
then flew directly to the airport. When questioned how he'd suddenly known where
to fly, the pilot explained "When I saw an answer that technically correct but totally
unhelpful, I knew immediately we were outside Microsoft headquarters, and I knew my way
from there." In the event that Task Manager gets an error
condition it doesn't recognize, it goes to some great lengths to get the system to parse
the error into a meaningful message, with the aim being that you never get a silly message
like "ERROR: The Operation Completed Successfully". In addition to the goals of small size and
robustness, my most important personal goal was actually flicker free painting and resizing. Although the operating system provided all
of the tools necessary, before Task Manager I cannot think of another application with
that many list columns and controls that could be arbitrarily resized live in all directions
without flicker or flashing. It seems a minor thing until you've experienced
it both ways. I went to some great lengths to avoid even
a single instance of flicker. The process list, for one, is a fairly complex
affair that takes full advantage of most everything the excellent system ListView control has
to offer. For example, if only a single cell of a single
row has changed in the complete process view, only that tiny little rectangle is invalidated
and repainted. In the initial incarnation of Task Manager,
I did not want any rubber baby buggy bumpers to protect the user from themselves. By that, I mean that I wanted the operating
system itself to be the arbiter of what you were allowed to do, not me in the form of
rules inside Task Manager. If you wanted to terminate the whole Shell
or even a process like Winlogon that would cause the system to then bluescreen immediately
- by design - you could do it as long as you had the appropriate administrative system
rights and credentials. You could also do things like mark a CPU-bound
process as real-time priority and effectively hang the system if you so wished. That led to some bad press however as a few
smarmy computer journalists showed how you could, as super user given the correct rights,
crash a Windows machine with Task Manager in a single click. Never mind that you could delete the main
hard drive partition as well, so it's kind of a silly point, but it made for bad PR. Another idiosyncrasy of the code is that it
contains a number of functions and controls named Dave. For example, there's Daves Frame Window Procedure,
Init Daves Controls, Daves Frame Class, Daves Group Class, and so on. This was not so much a doff of the cap to
my own megalomania as a side effect of the code having started its life as a pet project. These are all cases where the operating system
provided a version of a control, such a group box, but I super-classed and customized that
behavior. To distinguish my version from the system's
original one, I simply added my name, Dave, as a prefix. It made sense when I was working alone on
it, but I likely should have updated those names when we brought the code in house. It was probably a Priority 3 item in Raid,
which is what we called our bug tracking database. What often happens to trivial changes in the
real world is that being trivial, people procrastinate on them until they actually have the spare
time to work on trivial stuff, but by then it's too late in the product cycle to accept
even trivial changes that don't fix an important bug, and naming isn't an important bug. And so, sometimes trivial but harmless items
never get fixed and as a result, the Dave classes have persisted across the ages. There are literally ten ways you can start
Task Manager, but my personal favorite, however, is one I added to the logon process, since
it'sounds by definition always running if you're logged in. Simply press Control Shift Escape which will
signal the logon manager to start a fresh Task Manager for you even if everything else
is gone or bunged. This is also a handy shortcut if you're working
in a VM because you don't then have to deal with the special ctrl-alt-del key sequence
being captured by the host. Trust me, though: Ctrl Shift Escape is the
way the kids are all doing it now. Well, if we're talking about starting
