Hey, I'm Dave, Welcome to my Shop!
I'm Dave Plummer, retired operating systems engineer from Microsoft going back to the
Windows 95 and MS-DOS days.
Back in the bad old days of the 1990s, my internship at Microsoft started off with a
little party in Bill Gates' back yard and ended with a phone call demanding answers
about the secret back door in MS-DOS that had been tracked back to my office.
It was a hell of a summer, and I'm here to tell you all about it: The Secret Life of
Microsoft Interns.
The first time I met Bill was almost thirty years ago in his back yard.
A pair of burly security guards in too-tight purple Microsoft polo shirts politely escorted
me through his home on the West Side of Lake Washington.
Coming from a one thousand square foot home, it was certainly a mansion in my Midwestern
eyes, though only a tiny fraction the size of the more famous home he would later build
sprawling across the hillsides of the lake's Eastern shore.
Windows 95 was still in the future, and I was at Microsoft working on the older operating
system known as MS-DOS.
I was just temporary -- not even a full-time "blue badge" yet -- but back in those days
Microsoft was small enough that once every summer Bill would have the top college prospects
over for a BBQ.
Out on the lawn with a Northwest microbrew in hand, they clustered around him hoping
to catch his interest in conversation.
Each of us had no doubt prepared something clever to say, just in case the opportunity
presented itself: perhaps an insight about or criticism of a Microsoft product so perceptive
or biting that he'd recognize our innate genius amongst the crowd and pluck us, like a gem,
from the front lines.
That was the daydream.
The more likely reality was that after our burger and beer we'd be hurried out the front
door and back to Redmond to work 16-hour days, competing directly against one another to
see who the best was, who they would keep.
They all came from the best schools: MIT and Princeton in the USA, Waterloo in Canada.
With over 100,000 job applications coming into Microsoft every year at the time, just
being one of the 30 was an incredibly big deal.
Especially if you were from the University of Regina, like I was.
That's way up in Saskatchewan, if that helps, but either way I was really at Microsoft by
virtue of having put myself through college by writing software for a competing computer
platform.
Called "HyperCache", my program had sold a few thousand copies before it popped up on
Microsoft's radar.
My task now was to write something like it for their MS-DOS and release it for a hundred
million PCs, instead of a few thousand.
If that went well there was a good chance at a full-time spot upon graduation - complete
with their famously lucrative Microsoft stock options.
Failing that, I could always go back to my old job at 7-Eleven (and so you can imagine
why I wanted to make a good first impression).
I remember distinctly that the scene reminded me of the old vector video game called Star
Castle: we gathered in concentric circles around Bill as the setting sun glistened off
the lake behind us.
Few dared probe toward the center, where Bill himself stood alone, but I had the advantage
of Ben, my manager.
He knew Bill and he also seemed completely unfazed by fame or fortune.
Ben pulled me straight through the gauntlet of would-be proto-nerds and presented me directly
to Bill as if I were a prized protege.
He told him, "This is Dave, our intern from Canada.
In the space of four months..." his voice trailed off to list the very real technical
accomplishments that I had worked so hard to complete so far.
I listened in earnestness at first, but I became highly distracted with one very real
problem.
It hadn't actually been four months as Ben had said.
It only took three months.
Not four.
It was a small thing, but still a very important detail.
I was sure they'd want to know.
I cleared my throat, spoke up and interrupted them with the correction: "Three months."
Surprised, they both stopped, turned, and looked at me.
My heart sank.
Once again, as always, I had spoken out of turn, somehow saying just the wrong thing
at precisely the wrong time.
That much was obvious, and that was three decades ago.
In the first thirty seconds, I'd not only cut off my own manager but interrupted and
corrected Bill Gates.
If there's anything I suck at, it's knowing precisely when it's my turn to talk in a conversation.
There could be a whole spectrum of reasons why that is, but it's always been true, so
I think I'm just wired that way.
That faux pas aside, the evening went well, and we slowly drifted back to campus to get
back to work or to our furnished rental apartments for some sleep before returning to work the
next morning.
Either way, your performance wasn't going to be graded based on your decorum at a cocktail
party anyway.
It was, I believed, based on the quality and quantity of the code you cranked out.
I figured that was all that mattered.
I was wrong of course, but at least I was close.
So, what kind of code was I working on?
What do they have interns handle?
You'd imagine that interns would get the lowliest of tasks, the ones that wouldn't matter too
much if they screwed them up.
Maybe typing the serial number of everyone's PC into an Excel spreadsheet for inventory
tracking, that sort of thing?
No.
Microsoft doesn't roll that way, or at least they didn't back then.
You were expected to hit the ground running and to be productive like any other member
of the development team, working on real features and bugs, and right soon after getting there.
It's sink or swim, baby.
When I got to the little 8x10 office they'd reserved for me, it was about the size of
my basement bedroom back home, except there was just a door and no windows.
Two big brown wooden 1990s desks sat ready to receive two interns and their computers,
and there was an unused 386SX16 machine and a cheap monitor already sitting on one of
them.
It would become my first dev machine.
Someone handed me an ethernet cable and they told to "get enlisted".
Now remember, I was an Amiga programmer by trade, but fortunately I had spent a summer
back in college at the phone company setting up LANs for MS-DOS 3.3 machines, so I actually
had my machine up and running on the LAN in no time.
But getting information for ANYTHING meant you had to bug SOMEONE.
There was no Web of course, and no internal alternative.
So, I'd wander down the hall looking for someone who knew what they were doing and that I hadn't
bugged with a question too recently.
I'd hit an office with a nameplate like "Aaron Reynolds" and I'd casually ask, "Hey Aaron,
do you happen to know the name of the source code control server?"
like I was some Russian spy.
He'd give me a weird look and perhaps an answer like "Do you mean TAL\MSDOS?" and I'd say
"Yeah..." and then run back to my office.
I could be busy for an hour or two before I hit the next snag and needed the password
to something or to know where something lived, or the name of the print server, and I'd have
to bug someone else.
This whole dance of not being given the information I needed and having to extract it elsewhere
without unduly annoying too many productive developers was a careful one, and it was totally
unnecessary.
Any of the devs on the team could have spent 90 minutes with me on the first day and just
told me everything I needed to know - here's the tools you need, and where they live.
Here's the source code you'll be working on, and how to get it.
Here are the people you need to meet in order to get your code changes reviewed and checked
in.
It could have been so painless, and yet it was all a mysterious process.
I don't know if they were just really busy or they preferred to just leave you to, as
I said, sink or swim by your own devices and see how it goes.
I think the honest answer is "both".
They seemed to be in a bit of a crisis mode over Doublespace right then, and perhaps I
just started at a bad time.
In fact, I became so adept at prodding people for whatever I needed to prime the information
pump that I likely became too dependent on just asking other people.
Eventually it got to the point that I would reflexively ask the appropriate person instead
of looking at the appropriate resource, like the source code, simply because it was faster
and easier for me.
But of course, that also distracts a second person, so you quickly learn that you have
to solve such things on your own unless you're truly stuck.
There's an old saying that there are no stupid questions, and maybe that's even true.
But if you ask too many fair questions, people might start to wonder about you, not the questions
themselves.
I figured that out and adapted, of course, but not until I'd burned a few bridges with
a few folks by asking questions that I should have figured out on my own.
My advice to you these days, then, is to Google the hell out of it and if you have to bug
someone else, at least lead with the fact that you did, in fact, search hard on your
own and approximately what you did in that regard.
Then at least they'll know you tried, and you're not just being lazy.
With nothing online yet, about the only thing I was given on paper was a two-column printout
of one of Ben's pieces of x86 assembly - his implementation of printf.
As you can imagine, printf does some reasonably complex parsing, at least for being in assembly
language, and this truly was a very nice piece of code.
Just two pages long, I think, it was intended to convey what the coding standards were for
the MS-DOS team, and what I was to follow for naming conventions indentations, and so
on.
It was impressive and it set a high bar.
Everything I would do that summer was done in x86 assembly - not even a single line of
C yet.
We also used an old version of the assembler, known as MASM 2.
There were several newer versions of MASM available, but you didn't want the code generation
to change from one version of MS-DOS to the next if you could avoid it, since people in
those days could even rely on the location of particular opcodes.
I had written a lot of 6502, 68000, and PDP-11 assembly in the past, but I'd never actually
written any x86 before my Microsoft internship, but other than the operand order being reversed
from what I was used to, I adapted pretty quickly.
I actually love coding in assembly, and I got to do a lot of it that summer.
The first task I given was to take the Smartdrv hard drive cache and make it support CD-ROMs.
That meant learning everything from the red book CD standard to the MSCDEX software extensions,
not to mention retrofitting it into an existing cache implementation.
I took the old SmartDrive's original author, Chuck, for coffee where I had my first ever
latte as he explained roughly how the cache was architected.
Finally armed with some information, I went straight to work and had it all working promptly.
The difference in performance for CDs was enormous, so it was a big feature, and I was
pretty proud of it!
Games like Myst went from glacial to snappy.
My next task was to take the Doublespace compression engine, which might have been called Drivespace
by that point, and to move it into the High Memory Area.
On an MS-DOS machine there's only 640K of main memory available to programs no matter
how much you install in the machine, so every byte is sacred.
Doublespace was rather large, and so moving it up to high memory would be a big gain in
free memory down low.
The only problem was that I didn't know what the difference between low and high memory
even was, let alone how to do anything about it!
Not being an MS-DOS programmer, it was all new to me.
I couldn't find coverage of the HMA in the typical programmer tomes of the day, but I
did track down a couple of magazine articles in the corporate library and read through
those.
Soon enough, I had that all up and working too.
From there I moved on to making disk copy single pass.
By that I mean that in all versions of MS-DOS before that, if you wanted to copy a floppy
disc, it did so in several passes.
You had to swap disks back and forth between the source and the target half a dozen times
or more as it used only a small RAM buffer.
I rewrote Diskcopy to use temp space on the hard drive if available, and that made it
far more usable and a lot faster.
The only trick was how and where to allocate disk space in a world where no two homebrew
PCs were quite alike, but I eventually got it work safely and reliably.
As if it hadn't been busy enough so far, my final major project of the summer was to make
the entire MS-DOS 6.2 upgrade, which might have normally been 3 or 5 floppy discs, fit
on a single disk.
Imagine the savings multiplied by many millions of floppies, not to mention the amount of
plastic that ultimately didn't wind up in landfills.
But how to fit many discs of information on a single floppy, given everything was already
highly compressed?
The key was that we planned to ship only the changes - the deltas - from the most common
prior version of MS-DOS.
That way, if you already had MS-DOS 5 or whatever the base version was, you just needed a single
floppy.
But almost every file changes a little bit from version to version, so you can't just
ship some changed subset of the files.
The solution was to ship binary diffs: the deltas which, when applied to each file, would
generate the new file by patching the old one in place on the hard drive.
Scanning for and generating and applying binary diffs can be a hard task to do efficiently,
so I opted to start with some code that someone connected me with on the FoxPro team.
FoxPro was a database product that we had recently acquired, and for some reason they
had binary diff code, so I started with that and adapted it to the task.
Sure enough, the entire upgrade fit on a single floppy disc even with a little room to spare.
And I always thought the naming was clever as well: they called it the StepUp instead
of Setup.
I think you could buy it in the grocery store checkout aisle, even: it was everywhere.
I've got a copy of the MS-DOS for Dummies upgrade, even.
One of the more entertaining and instructive aspects of my summer was to watch the intern
in the office adjacent to mine write scandisk.
You might remember it as the full-screen, MS-DOS GUI hard drive repair tool.
It was written, as far as I know, pretty much end to end by a co-op student named Richard.
Scandisk is quite a formidable program, so as you can imagine, Richard was - and presumably
still is - quite a formidable programmer.
I used to like to waste a bit of his time nights and weekends by sitting in his guest
chair and picking his brains over how things worked.
His editor of choice was vi, and he was a Master of It.
His hands worked the keyboard like a dying man typing his last will and testament, but
if you looked closely, surprising little text emerged on the screen.
Vi is one of those editors where you use a ton of inline control characters to move the
cursor around, tag, copy, and move text, and so on.
Now not me, of course.
I only know how to insert, replace, or delete text at best.
But Richard was so adept with the vi-command set that he essentially became one with his
editor, or so it seemed.
Being an intern is your first exposure to the Microsoft review process as well.
Given the amount I had completed in the few short months I had to do it in, combined with
their importance to the product and the Company, and I figured I had rocked it.
I didn't know what the top score was, but like most young people, I wanted it.
It was not to be, however, as I scored a 4 on the 5.0 scale.
Technical merits aside, I was still adapting to the Microsoft internal culture and how
to navigate my way around it successfully, which held me back a little bit.
I'd still argue for a 4.5, but it would seem small and petty to worry about a thing like
that 30 years later.
Wouldn't it?
The two highlights of my summer, though, were the Microsoft Company Meeting and the Microsoft
Company Picnic.
Both merit their own episodes, so I won't dwell too long on either, but the meeting
was hosted by Dana Carvey and Kevin Nealon.
Hans and Frans pumped up the room before Church lady interviewed Bill, which was a little
cringeworthy, unfortunately.
But between the SNL hosts and Steven Ballmer losing his mind onstage to get the crowd worked
up, it was a huge morale boost, and I was absolutely certain by that point that I wanted
to return to Microsoft full time if they made an offer.
Besides, the data centers for both the local IBM subsidiary and the Wheat Pool Cooperative
in my hometown had already turned me down, so I didn't have to feel too bad about Canadian
brain drain if it came to pass!
My then-lovely-girlfriend, now lovely wife, was able to fly down and attend the Company
picnic with me, which was a grand affair at a nearby mountain retreat complete with everything
from base jumpers to monster trucks, a huge food court with everything you could possibly
want, and tons of entertainment and activity aimed at the family.
It wasn't quite the Firm, if you remember that book and movie, but it was becoming very
easy to like being at the Company.
About a month after I returned from my internship to my hometown, I finally received a call
from Microsoft.
I privately hoped and even assumed that it was the call to make me a full-time offer,
since it was unlikely that they'd call to NOT offer me a job.
On the line was Ben, my manager from my internship in MS-DOS.
He wasn't calling to make any offers.
He wanted to know what I knew, how much I knew, and when I knew about the secret back
door that had been planted in the MS-DOS executive.
They had tracked it back to the LAN port in my very own office, and there was some explaining
to do.
They were not amused, to say the least.
Even back then Microsoft had many layers of review and quality control, not to mention
corporate security, to help prevent such rogue actions, and of course it was promptly caught
long before it had any chance of making it into the product.
Once they had found the code, they tracked it back to the source logs, and discovered
that the change had been checked in from my shared office.
The other intern who worked in my office is the one who had checked the code out and made
the change.
I was not implicated in modifying the code at all, as he had clearly done it, but how
much did I know?
Was I involved in any way?
It wasn't a back door in the security escalation sense, but even to call it an Easter Egg would
be too kind.
It was a hidden command line switch added to one of the common MS-DOS commands such
that if you invoked it with a special character on the command line, it would print "I love
Sex" over and over in a loop.
Finding out about it on the call was the first I'd heard of it.
I was speechless, and a bit clueless, because the answer was simple - I had no idea.
The intern had not looped me in or involved me in any way, nor would I have let such a
thing go unreported anyway.
Never mind that I don't believe in Easter eggs in operating systems to begin with, but
this was pretty lowbrow.
I love sex?
Seriously?
And I didn't even really get the sense that the guy was a big time player.
Suffice to say I pleaded innocent, and they must have fortunately taken me at my word.
At the time of the phone call, though, I thought this guy had completely boned my chances.
I mean why take the chance with me?
What if I did have something to do with it?
Maybe this person had fully confessed and had cleared me, I have no idea.
All I know is that I did ultimately get an offer to come in and interview for full time,
so they must have been confident that I'd not been involved.
But I came THIS close to truck driving school.
So, thanks, Ben, for believing in me and taking the chance.
If you enjoyed this particular story but you're not yet subscribed to my channel, I'd be honored
if you took a moment right now to do so.
That'll also let me know I'm going the right direction with this episode, I'll make more
like it, and if you turn on the bell icon, you'll even be notified of them when I do.
It's a win-win.
As always, remember I'm not selling anything, and I don't have any Patreons, I'm just in
this for the subs and likes, so if you did enjoy the episode, please be sure to leave
me one of each before going.
YouTube apparently really does care if you like the video or not: they call it engagement.
And don't forget to head on over to Dave's Garage at the end of the month for a Livestream
on Sunday the 28th of February at 10 AM Pacific, 1PM Eastern.
All questions will be answered, all inquiries addressed, and you can help me plan for future
episodes!
The more the merrier, so bring a friend.
Our first ever livestream had a 1000 folks show up and it was a lot of fun, so please
do stop by on the 28th.
Thanks for joining me here in the shop.
In the meantime, and in between time, I hope to see you next time, here in Dave's Garage.