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.
