Steve Dyer

Image: Adam Ferris. Detail from CA1. 2013.

In the summer of 1998 I graduated from college and went to work as a programmer at Microsoft in Redmond, Washington. I was put on the group that was building MSN Messenger Service, Microsoft’s instant messaging app. The terrible name came from Marketing, which had become something of a joke for always picking the clunkiest and least imaginative product names. Buddy List? C U C Me? MSN Messenger? No, MSN Messenger Service. I’ll call it Messenger for short.

At the time the big players in instant messaging were AOL Instant Messenger (AIM), Yahoo, and ICQ. AIM had tens of millions of users; AOL had become the country’s biggest dial-up provider in the mid-’90s by blitzing everyone’s mailboxes with CD-ROMs, and all AOL users instantly became AIM users. Yahoo and ICQ each had millions of users. Those were big numbers for the 1990s.

It was a large project: on the desktop program (“client”), we had to create a sleek user interface to let people see their buddies when they came online, allow them to change the color of the font in a cool way, and so on. That is, we had to create a program that would do everything the other chat programs could, then add a few wrinkles of our own. The server-side team had to notify users about the comings and goings of other users, so that if your buddy Gordon logged on, the server would tell your client that he was there (we, on the client side, had to take the notification and display it to the user properly). The server side also had to integrate our functionality with Hotmail, which had tens of millions of users and which Microsoft had acquired in 1997.It was imperative that every Hotmail user be able to log on to Messenger with a Hotmail address and password as seamlessly as possible. This was not simple.

The initial team consisted of about ten people, though it gradually expanded to several times that size. On the client side we’d meet to discuss what needed to be done, what kinds of features we wanted, what we could do and couldn’t do. Then we’d go and do it. I was 20 years old, the youngest person on the team, and very green. I was given little chunks of the project to work on at first, then bigger ones. I worked on the instant messaging windows: the “type your message here” window and the “transcript” window above it. I added better font control and helped make the client work with non-Latin character sets like Chinese/ Japanese/Korean, Indic, Hebrew/Arabic (right-to-left, a particular pain). I managed when the windows would pop up, how they could be moved around, and how scrolling worked in them (scroll bars were very buggy in Windows!). Handling shutdown was a pain, making sure the windows closed down neatly and all the program’s resources were cleaned up properly without the program crashing.

After we finished the user part of the program, we had some down- time while waiting for the server team to finish the Hotmail integration. We fixed every bug we could find, and then I added another little feature just for fun. One of the problems Microsoft foresaw was getting new users to join Messenger when so many people already used the other chat programs. The trouble was that the programs, then as now, didn’t talk to one another; AOL didn’t talk to Yahoo, which didn’t talk to ICQ, and none of them, of course, would talk to Messenger. AOL had the largest user base, so we discussed the possibility of adding code to allow Messenger to log in to two servers simultaneously, Microsoft’s and AOL’s, so that you could see your Messenger and AIM buddies on a single list and talk to AIM buddies via Messenger. We called it “interop.”

This wasn’t elegant, but it wasn’t that complicated, either. A program talks to a server using a well-defined protocol, which is a set of coded instructions sent to and from the server. HTTP (hypertext transfer protocol), used to request and transmit web pages, is one of the most common protocols in existence. It is built on top of TCP/IP (transmission control protocol/internet protocol), the underlying protocol of the internet itself. Internet companies run servers that speak these and other protocols. Some protocols, like HTTP and TCP/IP, are public, documented, and spoken by everyone, but some are private/ proprietary and undocumented. AIM’s protocol, known as OSCAR (for Open System for CommunicAtion in Realtime), was in the latter group. I didn’t have the “key” to decode it. But what I could do was sign up for an AIM account and then watch the communications between the AIM client and the server using a network monitor, a development tool used to track network communications in and out of a computer. That way I could see the protocol that AIM was using. A sample message looked like this, with the hexadecimal representation of the binary on the left and the ASCII character translation of the binary on the right:

  2A 02 EE FA 00 B0 00 0E 00 06 00 00 9B 7D BD 28  *............}.(

  33 41 35 36 35 43 38 37 00 03 00 03 00 28 0D 52  3A565C87.....(.R

  45 41 4C 52 65 67 72 65 73 73 6F 72 00 00 00 03  EALRegressor....

  00 01 00 02 00 10 00 0F 00 04 00 00 00 18 00 03  ................

  00 04 3E 4C BE 8C 00 01 00 00 00 05 00 68 00 02  ..>L.........h..

  00 08 75 73 2D 61 73 63 69 69 00 03 00 02 65 6E  ..us-ascii....en

  00 01 00 48 69 2E 2E 20 41 6E 79 62 6F 64 79 3F  ...Hi.. Anybody?

I didn’t understand what it meant, but I could see when it was surrounding one of my text messages. “Hi... Anybody?” I would write into my AIM chat box and press return, and then on my network trace I would see my “Hi... Anybody?” Some of the protocol was always changing, but some was always the same. Our client took the surrounding boilerplate and packaged up text messages in it, then sent it to the AOL servers. Did AOL notice that there were some odd messages heading their way from Redmond? Probably not. They had a hundred million users, and after all I was using their own protocol. I didn’t even send that many messages. My program manager and I thought this little stunt would be deemed too dubious by management and taken out of the product before it shipped. But management liked the feature. On July 22, 1999, Microsoft entered the chat markets with MSN Messenger Service. Our AOL “interop” was in it.

As people downloaded the client to try it out, they thought it was cool: everything worked, it had more font functions than AOL, it was seamless with Hotmail (which a lot of people had), and, look at this, you could use two services with one program and still talk to your AOL chat buddies! Our lark was paying off.

Of course no one had warned AOL, and they weren’t happy. They pretty quickly started blocking Messenger from connecting to their servers; they’d disconnect the user and pop up an instant message saying, “Use an authorized AOL client at this link: [web URL].” But AOL could only block Messenger if they could figure out that the user was using Messenger and not AIM. As long as Messenger sent exactly the same protocol messages to the AOL servers, AOL wouldn’t be able to detect that Messenger was an impostor. So I took the AIM client and checked for differences in what it was sending, then changed our client to mimic it once again. They’d switch it up again; they knew their client, and they knew what it was coded to do and what obscure messages it would respond to in what ways. Every day it’d be something new. At one point they threw in a new protocol wrinkle but cleverly excepted users logging on from Microsoft headquarters, so that while all other Messenger users were getting an error message, we were sitting at Microsoft and not getting it. After an hour or two of scratching our heads, we figured it out.

Microsoft and AOL were both, obviously, giant companies, and soon the press got hold of the story. On July 24, the New York Times put it on the front page: “In Cyberspace, Rivals Skirmish Over Messaging.” It was like reading about a boxing match that you yourself were in. AOL kept blocking us, wrote the paper of record. “But Microsoft refused to roll over. Late Friday, the software giant said it had revised its MSN Messenger program to circumvent America Online’s roadblock. Within hours, America Online answered that challenge with a new block.”

I framed the article. My name wasn’t in it, but it didn’t matter. That was me!

This was, as I say, 1999. Just two decades after launching MS-DOS, its first operating system, Microsoft was one of the biggest companies in the world. We had 30,000 employees worldwide, about 10,000 of them in Redmond. The campus was about the same size as Yale.

What was Microsoft’s secret? They were, and are, essentially a software company. While hobbyists in the 1970s were trying to figure out how to build a computer small enough to fit in your home, Bill Gates and his partner Paul Allen were figuring out how to write software for when the hobbyists finally figured it out. In 1980, they partnered with IBM to make an operating system, MS-DOS (for Microsoft Disk Operating System), for the first mass-manufactured personal computer. A few years later they partnered with Apple to give early Apple PC users functioning programs, including Microsoft Word. Gates and Allen’s insight was simply that PCs were going to be a big deal, and people would want software for the new machines.

By licensing Microsoft to provide the operating system for PCs, IBM essentially handed them a license to print money. The margins on software were far greater than on hardware, because the physical manufacturing process was negligible—producing disks was cheap and trivial next to microprocessors and peripherals. And since Microsoft was the only company producing the operating system needed to run, ultimately, all software on PCs in the 1980s, it had a lock on guaranteed sales of the ballooning PC industry. IBM wasn’t the only hardware maker in town—far from it—but Microsoft was the only MS-DOS maker.

Microsoft’s rise did not go unnoticed or uncontested. In 1984, Apple debuted the Macintosh. After the Lisa, which came out the year before and cost $10,000, the Mac was the first PC to use an operating system with a graphical user interface (GUI), building on research done at Xerox PARC and elsewhere. The company bought ad time during the Super Bowl to trumpet this revolution in computing, and in truth they weren’t exaggerating. Until the Macintosh, everything had been text; now you could see a visual representation of the inside of the computer— a “metaphorical desktop,” as it was called. When I saw it at age 7, I found it dazzling, but at the time computers weren’t quite powerful enough to make the GUI necessary. I used PCs myself back then and was perfectly fine with typing at the MS-DOS command prompt. But toward the end of the ’80s, home computers became fast enough to make multitasking (running more than one program simultaneously) increasingly valuable, and it was clear that GUIs promised far more user-friendliness than text command lines.

Microsoft thought so too, and in 1985 they released the first iteration of Windows (with, importantly, some elements licensed from Apple). It was basically a clickable list version of the files on the computer, resembling today’s Windows Explorer, plus some other “windows” displaying executable files (a calculator, for example). It was an improvement over the MS-DOS command prompt, but a far cry from the different folders displayed so elegantly on the Macintosh. In 1987, Microsoft released Windows 2.0. This was still clunky, but already better, with overlapping windows and some other useful functions. Apple could see which way things were headed, and in 1988 they sued Microsoft for copyright infringement.

The suit failed. Windows was similar to the Mac operating system, but hardly identical. The appeals court wrote, “Almost all the similarities spring either from the license [for the initial Windows] or from basic ideas and their obvious expression. . . . Illicit copying could occur only if the works as a whole are virtually identical.”

The initial decision came down in 1992 and was affirmed on appeal in 1994. It was a serious blow to Apple during its Steve Jobs–less slump. Hampered by poor management, overpriced computers, and a protectionist attitude toward the Macintosh brand, maintaining that only Apple could make Macintosh hardware, the company saw its market share decline throughout the decade, eventually prompting the return of the exiled Jobs and setting the stage for Apple’s resurgence. Windows, of course, conquered the world, never attaining the elegance or unification of Mac OS, but working well enough that the Macintosh premium was more than most wanted to pay. In Windows 95, the first post-lawsuit release of the operating system, Microsoft went ahead and incorporated Apple’s famous trash can, impishly refashioned as a “recycle bin.” For a good long while, Windows could not be stopped.

Gates and Allen were skilled coders, but the history of software is littered with people just as smart or smarter who did not end up as billionaires. Their strength was on the business side. For years they remained a small company, but you didn’t need to be big to make soft- ware back then. The programs were simple, and they were all that was available, so you could charge a premium for them. The amount of person-hours that goes into a $50 piece of software today dwarfs that of a $50 item of software thirty years ago. In 1983, a word processor so primitive it advised users to put little stickers on their keyboards so they'd know which functions correlated to which keys retailed for $289. For this price it offered a tiny fraction of what most freeware can do today. It was a different world.

In this world, Microsoft stood out. They worked fast, they were aggressive, and they were very cagey. Their strength was never in innovation per se, but in appropriation, improvement, and integration. One slogan that you would hear at the company was that Microsoft made “best-in-class” products. A less charitable way to put this would be to say that upon entering a market, Microsoft would make a product that was better enough than the best out there, and then take over the market. So the quality of Microsoft’s offerings closely tracked the quality of existing offerings.

Lotus’s spreadsheet software 1-2-3 was a good product in the 1980s and early 1990s; consequently Microsoft Excel, which debuted in 1985, became the standout of Microsoft’s nascent Office suite. Word processors like WordPerfect and WordStar were less formidable; as a result, Microsoft Word was considerably less stellar than Excel. And in the absence of any dominant email programs, Microsoft Outlook was buggy and slow, and remained that way well into the early 2000s. Microsoft was far too efficient to waste time improving a project beyond what was needed to defeat their competitors. In the late ’90s I got a chance to tour the legendary Massachusetts computer company Digital Equipment Corporation (DEC, later bought by Compaq), and the difference in culture was remarkable. There were people at DEC who had been working on threading (the manner in which operating systems manage concurrent sets of linear processor instructions) for twenty years. Half the people had PhDs in their areas of specialty. Corners were never cut to release something earlier.

Ah, I thought. This is why Microsoft won.

Microsoft certainly tried to innovate with new products from time to time. Clippy, the little paper clip that popped up occasionally in Microsoft Word, was an innovation. Microsoft Bob, a yellow dog in dark glasses who showed up in Windows 95 to see if you needed help, was an innovation. Cairo, the “revolutionary” new operating system from the 1990s, would have been an innovation had it ever shipped. But as a whole the company was more comfortable entering existing markets and besting competitors. And in the absence of a clear target, planning could become fuzzy and tentative. You see this in the reticence to engage wholeheartedly with the internet in the 1990s: no one was making gobs of money yet, so who was Microsoft to follow? It wasn’t as if Microsoft (and everyone else) didn’t see that there was money to be made; Microsoft just wasn’t about to create the mechanism to do so on its own.[1]

By 1999, Microsoft was poised between financial security and an obscure future. The Windows and Office behemoths ensured the company’s dominance of the desktop operating system and business applications markets for as long as the PC remained a going concern. Even when the US v. Microsoft antitrust trial was at its peak, in 1999–2000, it was hard to see how a feasible antitrust remedy could actually address the problems. Sure enough, the plan to split Microsoft into two monopolies, one for Windows and one for Office, wouldn’t have helped a bit, even if it made it past the appellate court that overturned the initial judge’s ruling and attacked him for trashing Microsoft to the press. The whole case ended up a bizarre and political sideshow, which I’m not sure had more than a negligible impact on the state of the tech industry— other than ensuring that future tech companies kept a far larger battery of lawyers and lobbyists close by.

One interesting thing did emerge (at least for me, as an employee of the company) in the antitrust discovery process: I learned that before I arrived, a war over the future took place at the highest levels of Microsoft, between the “doves” and the “hawks.” The “doves” wanted to embrace other internet companies, like Netscape (which had the best early browser) and even AOL to an extent, and share power with them; the “hawks” wanted to clamp down and try to make Microsoft the provider of internet services. The real bone of contention was Windows: here was the most profitable thing in the history of computers. But a truly aggressive internet strategy would have meant thinking about a world without Windows. This was too difficult. “I don’t want to be remembered as the guy who destroyed one of the most amazing businesses in history,” one senior executive wrote of Windows during this argument. In the end the hawks won and most of the doves left Microsoft. Then the hawks lost.

To understand what happened next in the Messenger war it may be helpful to have some sense of how computers and computer programs work.

Computers are best seen as a series of abstraction layers, one on top of the other. Each layer is more complicated than the next down, and assembles the previous layer’s pieces into more complex, high-level structures. At the bottom you have the hardware itself: the central processing unit (CPU). The CPU consists of more than a billion transistors arranged to execute a particular “assembly” code that is native to that CPU. Assembly is the lowest layer of coding, where you are telling the CPU exactly what to do. And what you can tell it to do is often pretty limited: store this number here, retrieve this number from there, add or subtract these two numbers, and branch to different bits of code depending on some condition or other. In different contexts, these operations can take on different meanings, such as printing text onto a screen or sending something across a network, but the overall level of structure is very primitive. Analyzing and manipulating data is extremely tedious in Assembler.

In the early days of PCs, many programmers did code directly in Assembler. Programs were small enough and performance was critical enough that one needed to micromanage everything at that level. But as computers got larger and more complex, it became unfeasible to code in assembly. And needing to learn a different assembly language for every computer (Apple II, Macintosh, PC) was horrendously inefficient. Better to use a higher-level, CPU-independent language. All the languages you read about today, from C++ to Java to Ruby to Perl, are higher-level languages. They have far more instructional “primitives” that allow you to designate pieces of code as “functions” and abstract over them through “interfaces.” A program called a compiler then takes the code written in these languages and translates it into the assembly code for a particular specified processor, so you can have C++ code that compiles for the PC, or for Linux, or for the Macintosh.

Here’s some assembly for a “Hello world!” program (one that just displays “Hello world!” and exits) in MS-DOS PC assembly, which I’ve borrowed from Wikipedia:

.model small
.stack 100h

.data
msg   db    'Hello world!$'

.code
start:
      mov   ah, 09h   ; Display the message
      lea   dx, msg
      int   21h
      mov   ax, 4C00h  ; Terminate the executable
      int   21h

end start

And here it is in C:

int main() {

      printf(“Hello world!\n”);
      return 0
}

Having a compiler turn the C into assembly, as you might expect, saves a programmer a vast amount of time. It also allows for far greater levels of code reuse, since you can parameterize functions to take different inputs and handle them accordingly. But you lose some control with a higher-level language. Assembly lets you know exactly where every bit of information is going. As you go up the great chain of languages, you lose more and more control over the management of the guts of the computer, which is taken over by compilers, interpreters, and virtual machines. These programs are exceedingly good at managing things automatically, and they don’t make mistakes (unlike humans), but they have their limits. They do not know the overall intent of a program. If you pile on too many abstraction layers, performance can suffer. The downfall of Microsoft’s Vista operating system, which needed to be restarted almost from scratch in order to ship three years late, came because it was written in a new language of Microsoft’s own design, called C#, that did not offer sufficient micromanagement to make Vista run quickly enough. Like Java, C# was considerably higher level than C db ‘Hello world!$’ or C++, and the code responsible for taking care of the lower-level nastiness just couldn’t perform optimally. So they scrapped the C# code and started over in C++. Lesson learned.

A “language” like C++, Java, or Python consists of a certain number of commands, not more than a few hundred, and a certain number of numerical and logical operators, like + and && (for logical AND). Many languages offer the same basic functionality sets; where they differ is in the methods they provide for structuring programs, as well as the amount of abstraction they provide from the underlying computer fundamentals.

So what was Messenger? It was about a hundred thousand lines of code, in C++, implementing everything from pop-up notifications when a buddy logged in, to uninstallation code to remove the program if people hated it, to code to allow you to save IM windows as text files for later, to code to talk to the Messenger servers (and, for a while, the AOL servers). In its early years, it was a small, efficient, lean little program.

I no longer have access to the Messenger code, which remains the private intellectual property of Microsoft. So instead, here is a piece of the open-source C code for the chat program Pidgin. This function, update_typing_icon, is called when the program needs to update the “typing indicator” that tells you whether your buddy is currently typing a message or not.

static void

update_typing_icon(PidginConversation *gtkconv)

{
   

     PurpleConvIm *im = NULL;
  

     PurpleConversation *conv = gtkconv->active_conv;
  

     char *message = NULL;

 

 

     if (purple_conversation_get_type(conv) PURPLE_CONV_TYPE_IM)

         im = PURPLE_CONV_IM(conv);

   

     if (im NULL)

         return;

   

     if (purple_conv_im_get_typing_state(im) PURPLE_NOT_TYPING) {  

         update_typing_message(gtkconv, NULL);

         return;

     }

     if (purple_conv_im_get_typing_state(im) PURPLE_TYPING) {

         message = g_strdup_printf(_(“\n%s is typing…”),

             purple_conversation_get_title(conv));

     } else {

         assert(purple_conv_im_get_typing_state(im_ ==PURPLE_
             TYPED);

         message = g_strdup_printf(_(“\n%s has stopped typing”),
             purple_conversation_get_title(conv));

     }

   

     update_typing_message(gtkconv, message);

     g_free(message);

}

The function takes a parameter called gtkconv that contains information about the chat session (PidginConversation) being updated. The italicized portion of the code is the most important. It calls a function called purple_conv_im_get_typing_state, passing it to the chat session in question. That function then returns one of three possible values: PURPLE_NOT_TYPING, PURPLE_TYPING, or PURPLE_TYPED. A user interface function, update_typing_message, is then called to change what message is displayed on the screen. In the case of PUR- PLE_TYPING, a message with “[Buddy name] is typing” is shown. If PURPLE_TYPED, meaning that text has been entered but your buddy hasn’t typed anything for a bit, “[Buddy name] has stopped typing” is shown. And if no text has been entered and the buddy isn’t typing (PURPLE_NOT_TYPING), then no message is shown at all.

Most of the other functions that this function calls are also part of the Pidgin program, separated into modular chunks so that each can be isolated, tested, and perhaps reused. One exception is the g_strdup_ printf function, which creates the string containing the message to be displayed. g_strdup_printf is part of the open-source GNOME user interface library; because what it does is sufficiently generic, it was considered helpful to include in a popular package of generic user interface code.

All this C code is compiled into assembly by a C compiler, which can then run natively on the processor for which the compiler was designed.

The messenger war was a rush. Coming in each morning to see whether the client still worked with AOL was thrilling. I’d look through reams of protocol messages to figure out what had changed, fix the client, and try to get an update out the same day. I felt that I was in an Olympic showdown with some unnamed developers over at AOL. I had no idea who my adversaries were, but I had been challenged and I wanted to win.

AOL tried different tactics. At one point they seemed to be identifying the Microsoft client because it wasn’t downloading a huge chunk of advertising that the AOL client downloaded. So I changed our client to download it all (and then throw it away). They put in mysterious messages that didn’t seem to affect their client but broke ours because we weren’t expecting them. One day, I came in to see this embedded in a message from the AOL server: “HI. –MARK.” It was a little communication from engineer to engineer, underneath the corporate, media, and PR worlds that were arguing over us. I felt some solidarity with him even though we were on opposing sides.

AOL was putting out absurd propaganda about how Microsoft was behaving like an evil hacker by asking for your AOL password. This wasn’t true, but we weren’t allowed to respond except through our PR department. My team was completely sealed off from the outside world—except for our code, of course.

And then AOL stopped blocking us. It was strange to encounter sudden silence, and while I wanted to believe we’d won, AOL had been too loud and obstreperous to give up without a word.

Maybe a week after the blocks had stopped, I came in to work to find that Messenger had been blocked again, but this time it was different. The AOL server was sending a huge chunk of new gobbledygook that I could not understand. It looked approximately like this:

:

00000040 2A 02 77 9C 01 28 00 01 ........*.w..(..
00000050  00 13 00 00 80 0E A6 1B 00 FF 00 0B 01 18 83 C4 ................
00000060  10 4F 8D 94 24 E4 FE FF FF 8B EC 03 AA F8 00 00 .O..$...........
00000070  00 90 90 90 90 8B 82 F0 00 00 00 8B 00 89 82 4E ...............N
00000080  00 00 00 8B 4D 04 03 8A F4 00 00 00 8D 82 42 00 ....M.........B.
00000090  00 00 89 45 10 B8 10 00 00 00 89 45 0C C9 FF E1 ...E.......E....
000000A0  00 01 00 20 00 00 00 00 00 00 00 04 00 00 00 00 ................
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 10 ................
00000150  08 11 29 EC FF FF 44 00 00 00 00 00 00 00 FF 00 ..)...D.........
00000160  00 00 08 01 00 00 00 00 00 00 90 47 40 00 F8 E9 ...........G@...
00000170  EA FE FF FF 00 00

The first couple of lines here are the standard AOL instant message protocol header, but starting with that “90 90 90 90” bit, it became incomprehensible, bearing no relation to anything the AOL servers had ever sent their client or our client. The vast expanse of double zeros in the middle was also very mysterious, since a bunch of zeros couldn’t contain much meaning.

Our client just ignored it, but the AOL client responded to this gobbledygook with a shorter version of the same gobbledygook. I didn’t know what it was. It was maddening. After staring at it for half a day, I went over to Jonathan, a brilliant server engineer on our team, and asked what he thought. He looked at it for a few minutes and said, “This is code.” As in, actual x86 assembly code. The repeated zeros were what tipped him off. (They signify an empty instruction in x86 Assembler.) The code was telling the server to ignore it. The server was saying, OK.

The pieces then came together. Normally, these protocol messages sent from the server to the client are read and understood as data, not as code. But AOL’s client had a security bug in it, called a buffer overflow. The buffer is a place in a program where you temporarily store data while running some operation, so that the data doesn’t get erased. How- ever, if the buffer doesn’t have adequate protection, very large protocol messages can flood it, overwriting the client code and arbitrarily controlling the functioning of the client program—this is why it’s called a buffer overflow, and it’s a huge security hole, since it gives the server control of the client PC. In the wrong hands, the server can choose to shut down or corrupt or do other terrible things to your computer. AOL knew about this bug in their program and now they were exploiting it! That was what all those double zeros were for—they were just filling up space in the program’s buffer until they hit the end of the AOL client’s buffer and started overwriting executable code with the remainder of the protocol message. AOL was causing the client to look up a particular address in memory and send it back to the server. This was tricky, vastly trickier than anything they’d done so far. It was also a bit outside the realm of fair play: exploiting a security hole in their own client that our client didn’t have!

If I could go back in time, I wouldn’t have given up, but I was out of my depth, and I told the team that I wasn’t sure how to get around this, at least not without a fair bit more time and resources.

Someone had the bright idea of telling the press about the buffer overflow, figuring that if people knew that AOL’s client could and in fact was executing whatever a server sent to it, AOL would be forced to patch their client and could no longer use it to determine that Messenger was an impostor.

Here I only know what happened from the outside, since this wasn’t my department. According to security expert Richard M. Smith, a certain “Phil Bucking” of “Bucking Consulting” sent him a message, alertng him to the buffer overflow in the AOL client:

Mr. Smith,

I am a developer who has been working on a revolutionary new instant messaging client that should be released later this year. Because of that, I have followed with interest the battle between AOL and Microsoft and have been trying to understand exactly what AOL is doing to block MS and how MS is getting around the blocks, etc. Up until very recently, it’s been pretty standard stuff, but now I fear AOL has gone too far. It appears that the AIM client has a buffer overflow bug. By itself this might not be the end of the world, as MS surely has had its share. But AOL is now *exploiting their own buffer overflow bug* to help in its efforts to block MS Instant Messenger.

And so on. Getting the name of MSN Messenger Service wrong was a nice touch, but the rest of it is embarrassingly inept. This developer of a revolutionary new app takes time out from his coding not to promote his app but to take sides in the Microsoft-AOL war? Really? The email also includes a trace of the buffer overflow message itself, which I still remember vividly from the hours I spent staring at it, but the recipient paid more attention to the human language than the protocol messages. And if Phil Bucking’s text wasn’t suspicious enough, he’d also sent the message (via a Yahoo account, ha ha) from one of Microsoft’s computers at a Microsoft IP address, and the IP address showed up in the email headers. In geekspeak, this is what’s called a face-palm.

Smith immediately accused Microsoft of sending the email. Microsoft fessed up. So the news story didn’t become the buffer overflow (a tough sell, probably), but Microsoft’s attempt to bad-mouth AOL under a fake identity (an easier sell). People on various security forums ascertained that the buffer overflow was real and inveighed further against AOL, but the press wasn’t paying attention. The buffer overflow persisted into several later versions of AOL’s client.

So we gave up. I licked my wounds and proceeded on to far more dreary years on MSN Messenger Service, eventually getting buried so deeply in internal company politics that I was no longer able to do anything resembling useful work. The writing was on the wall when I heard one team manager scream, “I have the worst morale scores in the company and I don’t give a shit, because they can only go up!”

Those were the years of Microsoft’s long, slow decline, which continues to this day. The number of things wrong with the company was extraordinary, but they can be summed up by the word bureaucracy. Early on at Microsoft—and even later, when we first started Messenger—you could just do things. You had a good idea, you ran it by your boss, you tried it, and if it worked, in it went. After a while, you had to run everything by a hundred people, and at some point the ball would get dropped—and you’d never hear back. There was the infamous internal review system called “stack rank” that pitted teams against one another and people within each team against one another, too. There was an incredible thirst for “headcount” within a department, so managers would lobby aggressively for independent groups to come under their control. Thus the burgeoning NetDocs, which was intended to be an internet-based document-editing suite, gobbled up a number of small groups in the late ’90s. But NetDocs got eaten by Office, which then proceeded to kill it, thus leaving the door open for Google to debut Google Docs in the mid-2000s. And on it went. Multiyear projects with hundreds of engineers died without the public ever hearing a word. It continues.

I left for Google, but not without making one last mistake. I told my boss at Microsoft I was leaving to work for our direct competitor, and he threatened to sue me. I packed up my things in a box and quit the same day, without saying goodbye to my coworkers. At least Steve Ballmer didn’t throw a chair across the room, as he did when Windows architect Mark Lucovsky told Ballmer that he was leaving for Google. Microsoft was hemorrhaging hundreds of top engineers to Google at the time, and the combination of the talent loss plus the insult to the executives’ egos made for very bad blood. Still, they didn’t sue me.

Despite my ignominious defeat at the hands of AOL’s diabolical mastermind of chat, Messenger did pretty well. We acquired tens of millions of users, millions online at any one time. At some point we put ads into the client, which made some money. I don’t think we turned a profit, but we weren’t a big group, so we weren’t costing Microsoft much either. I added emoticons to the client in 2000—it was the first American chat program to turn a colon and a close-parenthesis into an actual smiley face (I say first American because the South Koreans, who loved chat more than anyone, may have preceded us)—and people loved it. We added internet phone calls to the client, which was cool and raised a bit of revenue on international calls. After I went over to the server side, I helped redesign the server architecture with a very sharp development lead who taught me a lot, as had my original mentor on the client.

Messenger puttered along for many years in limbo. It was unusual in being unkillable (because of all its users) and unassimilable by Windows or Office (because it was part of Microsoft’s internet strategy), which led, I believe, to it never amounting to anything. Taken on its own, it was a success, but a success on which Microsoft was unable to capitalize. Attempts to integrate it with other projects either fell prey to internecine executive warfare or else collapsed into consumer indifference. Despite Microsoft’s purchase of Skype, Messenger is still going today, a little Methuselah wandering in the Microsoft product mausoleum.

Years later at a party I met one of the AOL engineers who’d worked against me. We had a huge laugh over it. He’d left AOL just as I’d left Microsoft, and I complimented him on the genius of the buffer-overrun exploit, even as I bemoaned my loss. It had been a great game, I said. He agreed.