012. I Shipped, Therefore I Am

Attending and presenting at the first Win32 Windows Professional Developer Conference (PDC) and meeting (and being intimidated by) Dave Cutler along the way. Shipping my first product while navigating the contentious battle for the real first product.

Back to 011. A Strategy for the ‘90s: Windows

By July 1992, it seemed like the whole of the industry gathered in San Francisco at the Moscone Center for the first Win32 Professional Developers Conference, which came to be known as the Win32 PDC, named after the 32-bit Windows APIs that were unveiled and the cornerstone of the event. For the first time Microsoft also mentioned Chicago, the code name for the successor to Windows 3.11, which would become Windows 95, real soon now. More than 5,000 developers attended this event, an enormous number, and were introduced to Windows NT 3.1 Preliminary Release Build 297, dated June 28 and provided to attendees. As I recall, something like 25,000 developers ultimately received the first CDROM.

Windows NT was a next-generation operating system, aiming for the professional workstation and high-end data center markets to compete with Unix and VMS (from Digital Equipment Corporation, DEC). TThe project leader and architect was the legendary Dave Cutler (DaveC) and included a group of experienced industry engineers also from DEC, collectively the key members of the original VMS team. Windows NT was a 32-bit (and soon 64-bit) operating system designed from the start to run on several of the latest microprocessors, including those from Intel rival AMD and Silicon Valley upstart MIPS. When it was under development, it was always scheduled to ship real soon now, though the project was always under control and managed with military precision and discipline. The task of building NT was immense. Like every project, it just took longer than people thought it would, even the most experienced people.

At the PDC the OS was referred to as a beta by most. Not quite a beta, officially it was labeled Preliminary Release for Developers. It was a build (basically the most current version that worked). The team was extremely hardcore about maintaining daily quality. Every day a build was created that was reliable enough for the team to self-host. The NT daily build was as solid as anything Microsoft was doing at the time, and it was a new OS built from scratch running on brand new hardware. It was impressive, even in its early stages.

Along with the compiler and tools from the Languages group, a major effort, we released a beta version of our entire MFC application framework, which eventually became version 2.0. This included the ability to create Windows programs for NT on MIPS and ‘386 chips (by this time the industry was calling chips ‘386 because the i386 from Intel had a competitor in the AMD Am386 which was fully compatible), and Win32 (and also Windows 3, now referred to as Win16). For the sake of completeness, I should mention “Win32s” the implementation of the Win32 API on Windows 3.1. It was viewed as potential way to expand Win32 applications to existing PCs. In the end it sounded better than it really was (we even considered using it for the C++ product), but at the time it was comforting to developers who thought it would expand the reach of new Win32 applications and a classic Microsoft approach of trying to include existing hardware and code in a new strategy.

Reaching this milestone was huge for our AFX team, all 18,692 lines of code.

Our team shipped our first product! I shipped a product! It was a beta and all, but still. It was on a CDROM and everything!

It was also my first time speaking at an industry conference. This was a huge conference with many tracks and a wide range of developers. C++ and OOP were extremely hot topics, so I ended up giving a talk to what seemed like the largest room I had ever been in, certainly bigger than the USENIX ballroom and bigger than any meeting on Microsoft’s campus. By this time, we had a great story to tell about being reformed oopaholics and “hardcore”, using C++ as a better C, and, importantly, about our class library being all about Windows and not competing with Windows or duplicating it.

A funny thing happened along the way to the PDC—I got to meet DaveC. It was terrifying. And then gratifying.

As soon as it became clear that MFC and C++ would ship with the PDC release of Windows NT we were introduced to the NT “ship room.” This was a conference room, but one where the team met every day to discuss bugs and propose changes to the product. The NT team (and many other teams) preferred to call it the “War Room” as a source of pride, sometimes even officially with an officially engraved door sign. I always hated that term and wouldn’t use it (building software is not a war, at the very least). It was lorded over by the most imposing engineer I ever met, DaveC. Everyone was terrified of Dave. No one wanted to be responsible for slowing down the progress or worse introducing an error somewhere that caused problems for others. The ship rooms in Apps were challenging but nothing at all like this one. During the NT project, Dave famously put his fist through the wall. The team memorialized the hole by writing the date next to it with a marker and putting a wood frame aound it. Things were different over there. My role was to attend these meetings regularly and not say anything, and if I was asked something, to say that “MFC was on track and had no issues.” And then go back and do everything to have no issues. Keith Rowe (KeithRo) had the job representing the compiler to the ship room and was constantly given a much harder time at these meetings. I am certain his Canadian disposition served him well in these moments. I just sat in the back and wasn’t allowed to make a mistake.

There was just one thing. I thought the Windows NT team was making a mistake, and a big one. We were building MFC to make it easy for programmers to create apps for either 16-bit Windows 3.0 as it was shipping millions of copies and for the new 32-bit Windows NT. We were committed to using the Windows APIs and not fixing them or changing them. Unfortunately, there was an organizational and philosophical schism across the 16-bit Windows 3 team and the 32-bit NT team. The resulting divide created a difference in the APIs for each Windows, a difference in expression (in WINDOWS.H to be specific) that made it difficult for the APIs to work in C++. Ostensibly, this was due to expanding the APIs to handle twice as many bytes that is “widening” from 16 to 32 bits. But much of it was also rooted in assumptions for how compilers worked which were not correct. The functionality was the same, but it would have made it tricky for developers and would not have worked if there was ever a world where we would move from 32 bits to 64 bits (which of course happened a decade later). The idea of a seamless and scalable API from 16-bit to 32-bit (also 64-bit) Windows was a key strategic initiative and it felt like we were at ground zero showing it was not coming together nearly as clean as it could. There were also a good number of gratuitous changes in Windows APIs (among the 350 or so that existed at the time) that were made by the NT team, likely “fixing” some irregularities or inconsistencies in the original Windows APIs.

Jeff thought this was a great opportunity for me to show leadership—an opportunity for advancement as they say in the military. He sent mail to DaveC subject line “Win32 issue” and copied me suggesting that I meet with DaveC.

Once again… terrified.

I was a newly-minted lead who had never shipped. I hid in the back of the ship room. I was trying to ship our product for the first time on the biggest train at Microsoft. I was supposed to meet with a larger than life General of Windows NT. On some level, I wanted none of this.

I went over to meet DaveC though. It was just the two of us in one of the tiny conference rooms (a single 60 inch round table) that made up the interior ends of the single X buildings. I was sitting there. He walked in and looked at me and in an annoyed tone barked, “Who are you and why are you here?” I was prepared with all sorts of printouts and descriptions of the problem and began to explain. There was an argument of sorts but mostly he kept asking me why I waited so long to bring this up. This would be a massive change, when every change was scrutinized, even without the PDC deadline. Like every good engineering manager, I would come to understand figuring out who messed up was far less important than the stress over fixing it so late in the process.

I went on to explain that we were a new project and the first people doing C++ programs on top of both Win16 and Win32. I explained how we modified the code in question and tested it and it works fine—of course everyone always says that about changes. I tried to steer the conversation, to the degree you could call it that, to where Win32 varied from Win16. I didn’t understand why things changed or assign blame. There was some more yelling, though not clearly at me as much as at the situation. I recall sticking to my ground only because it seemed so obvious and even trivial. In hindsight, I had no experience with how off-the-rails things can go by making small changes toward the end of a project. These would be changes in the mother of all files, WINDOWS.H. I really can’t believe I advocated making that change. I’m pretty sure later in my career when sitting in the other seat I never would have accepted it so late.

Nevertheless, the change happened. I didn’t ever get the benefit of an admission of my correct view in person. Rather on my way back to building 17 (while I was feeling like throwing up), DaveC sent an email to Jeff that read, “fine” or something like that. Jeff was proud of me and I was relieved and felt I accomplished something but really it was just weird. To be honest, I felt best when RickP, someone I thought so highly of, said months later, “I heard you went and fought with Dave Cutler [emphasis in his voice] over this change and won.”

Shortly after the PDC, Microsoft C/C++ version 7.0 Development System for Windows released to manufacturing in August 1992. It took time to manufacture and distribute to stores because the box weighed over 42 pounds in shipping and included 23 floppy disks and over 10,000 pages of printed documentation in 24 books. The box was so large that Microsoft’s own manufacturing facility could not handle it and it was ultimately packaged at a plant in Oregon that handled sporting equipment. This was physically the heaviest product Microsoft ever shipped and the last time a developer product was released on floppy disks.

With C7 shipped MFC 1.0, a subset of the pre-release product from the PDC. It was a set of “helper” classes that could be used to make some aspects of C++ easier. It was not a framework for building an application, but rather simply some reusable code. Importantly, it was our team shipping and that is what mattered. At Microsoft, shipping equated to being relevant, plus real artists ship.

MFC 1.0 was constrained, and everything Jeff (and ScottRa) thought would happen did, which was that the product helped our team figure out how to ship. The biggest lesson a new team can have about shipping is that once you ship, it gets easier to do it as a team the next time.

We had work real to do to compete with the NeXT system.

We hardly had time to catch our breath. While we were shipping MFC 1.0, the bulk of the AFX team, about 15 of us, was building an entirely new tool for creating Windows apps, with the code name Composer, playing off the idea of art and artists creating and shipping.

Composer was the tool to compete with NeXTStep Interface Builder, where a developer arranged the dialog boxes and menus of their app using a mouse and GUI. Composer was also going to be the first large-scale Microsoft app written in C++, using MFC. We were self-hosted or, as the Windows NT team called it, eating our own dogfood (An expression rooted in the 1970s commercial for Alpo dogfood—"the kind dogs love to eat”—and later used in an email from PaulMa extolling the virtues of using pre-release software ourselves). Composer was using the complete class library we shipped in beta at the PDC.

We still needed magic though. Composer already had a competitor recently acquired by Borland shipping with their C++. Borland Resource Workshop (BRW) became a favorite among developers. There was also a Borland Class Library called Object Windows Library (OWL). To me, OWL seemed a lot like Old AFX (bloated and different than Windows). With these tools, however, Borland was making significant headway with professionals.

ScottRa was the magician. The key challenge with Windows programming was that it was finnicky and verbose. There was a lot of bookkeeping and rote code that was error prone. Doing simple things, like putting up a dialog box for the user to make some choices and acting on those choices, was hundreds of lines of code, all with ample opportunity for mistakes. For most professional programmers who honed their skills in character mode and MS-DOS, this stuff was maddening.

Visual Basic pioneered the concept of making it easy to code GUI programs. The problem was that it was not viewed as a professional tool and was much more geared toward business app developers and not commercial C programmers. In use, NeXTStep looked like Visual Basic but used what was considered a more professional (albeit obscure) language.

ScottRa previously worked on something used across the big shipping products in Apps (Word and Excel) called SDM, standard dialog manager. It made it easy to design user interface and get information to and from the end-user. He cleverly took those same techniques and built a way for MFC to accomplish this same task. Instead of designing the interface by typing text in an editor, a programmer used Composer to connect windows, buttons, and checkboxes (controls) to MFC C++ classes. The programmer added any extra required code, like if the input needed to be a valid phone number or something. Even better, if the developer needed to add another control, that could be done without any worries about breaking what was there.

We believed we created the first graphical tool for C++ programming that allowed code to be created and modified and then later changed without breaking it. Programming tools that created code were common, but they were usually limited to only creating code once or creating very fragile code that was difficult for programmers to modify or incorporate into large-scale projects.

Composer was slick. Super slick. Thanks to the program management from ClifS and the coding artistry of BradCh, the app itself was pioneering user interface techniques for Windows soon seen across the industry. A favorite example was the small property inspector window that floated on top, always showing the details of what was being worked on. It had a cool little thumbtack to keep it locked in position.

This wasn’t all a theory, either. It was being used in practice. Composer was being used to build Composer, which was itself built with MFC. We were building GUI tools using a GUI framework. Having said that, there was one challenge. We did not have a GUI code editor or debugger. Those tools were still the old C 7 character mode tools. It was not at all clear we could make the tools run well on Windows 3.0, while Windows NT was still not going to be a broadly used commercial product for some time. On the other hand, the next C++ product wouldn’t be ready for some time. This was, again, a classic schedule chicken between two big teams with their own agendas.

The Languages team previously shipped the Quick C compiler for Windows, but it was a different code base from the professional compiler. The editor and debugger, collectively called an integrated development environment (IDE), were not nearly the same level of professional tool as the character mode ones. The challenge was if we as a big team could bring the IDE together with Composer and MFC to create a professional development environment in and for Windows, then we would have something to compete with NeXTStep.

It was rather contentious. The idea of being on Windows 3 was technically problematic because Windows was not robust enough for development. If the program crashed while being written then the programming tools crashed too, probably losing work. Since programs always crashed when being built, Windows was pretty useless as a programing host. That didn’t stop Borland though. Many professionals were on OS/2 and anxiously awaiting (or moving to) Windows NT. For better or worse, there were many fans of the C6 and C7 character mode tools. While the need and wish were obvious, the technical limitations were plentiful.

Schedule chicken is never fun, and generally at this point in Microsoft’s evolving engineer culture, everyone was wrong about their dates. I think many on AFX felt the Languages team was too conservative on making the bet on GUI. Many on the Languages team thought the AFX team was naïve and was not being pragmatic about what could be done or the risk to losing to Borland if we got caught not shipping for a long time while we waited on Windows. There were deep concerns on all sides about performance such as speed to compile a program, which reviewers measured in exhaustive multi-page reviews. There was tension and frustration, and we were still behind both Borland and NeXTStep. The Languages team was much more concerned about Borland, especially with the various teams at Microsoft continuing to make noise about performance relative to Borland. We were just as concerned about NeXT because that was the charter of our group. With no prior product experience and no connection to existing customers, the choice to build GUI tools seemed abundantly clear to me. In reality, I had a lack of empathy and experience upon which to base my opinion.

We needed a decision across the teams, so Jeff scheduled a meeting with MikeMap, who by now was leading all of product development at Microsoft in a sprawling role as executive vice president of the Worldwide Products Group.

This was my first senior executive meeting. I am sure MikeMap had already heard all sides of this in previous discussions with various leaders, as should have been the case. I was a new lead sitting in the outer ring of chairs—the observer seats. Many people were in the meeting, which began with a slide outlining the big decision to be made. The decision was whether to make a big leap to a Windows/GUI integrated development environment on NT or to stick with what we knew to be a favorite among high-end professionals (especially those in Apps), which was a character mode IDE, or could we make something work on Windows 3 (and how). There were schedule questions (and chicken) and also technology questions.

There was an enormous deck with insane levels of detail across marketing and engineering. Right at the start the first slide was labeled, “Decision” and an indication that the team was looking to Mike to lead the way.

MikeMap had a sage and entertaining way of disarming any room and imparting wisdom at the same time, and he was about to do that. He looked around the room and said, in his Oklahoman accent, “There’s a lot here . . . much more than I can absorb in an hour. How long have y’all been working on these foils and this problem?”

The room looked perplexed. MikeMap was still fairly new to most people, especially Languages. Everyone sort of mumbled in their own way, an indication that basically this is all we’d been working on for weeks or more.

Mike then said, “Y’all been working on this longer than me, and know more than I will ever know. Why don’t you just tell me what you decided to do and then we can move the project forward?”

It was an incredible moment and frankly the opposite of everything I’d been culturally prepared to hear. We all envisioned executives as people we went to for answers, especially BillG and the big architects. Here was the newest but most experienced senior person at the company, telling us to decide on our own. Classic Mike, as it would turn out. That single interaction made a profound impression, and it was the first of many lessons from Mike in this same spirit.

Nevertheless, we debated vigorously among ourselves in front of Mike (a mistake). At one point, from the gallery, I overstepped my bounds and pushed too hard and in too negative a way in favor of moving to Windows. At least in my head I thought what I was saying was obvious. Microsoft was a contentious place, but it also wasn’t in-your-face aggressive, especially around Apps, which had a far more refined culture than Windows (especially Windows NT). And definitely wrong to do in front of Mike. And from the gallery.

With all pros and cons aired, the team committed to building a Windows hosted toolset and to find a way to make things work for Windows 3.0, committing to a separate project optimized for NT later. Composer would be one part of a complete Windows development toolset, including a compiler, code editor, debugger, and so on. We were, at least we thought, on a path to have something credible to compete with Borland and NeXTStep. The meeting was tough and what people were really looking for was the right to own the target ship date if they were also being asked to create a new product. That’s what Mike could assure the team.

After the meeting, someone told Jeff that my participation in the meeting was poorly received. He summoned me and insisted that, by the end of the day, I personally go and apologize to the leader of the C++ dev team, Dave Weil (DaveWe) then report back. Sheepishly, I did what I was told. I most definitely learned my lesson.

Jeff was cool like that, perhaps due to his own experiences. At a time when Microsoft barely had any people management at all and most of HR was recruiting, I was getting a lesson. As I would soon appreciate, especially after Windows Word and with the arrival of MikeMap, an incredibly strong and maturing management culture had developed in Apps but still needed to make it to new people like me and to Windows.

It would come to define the teams I later worked on and how we (and I) aspired to lead.

With the tension behind us, we were in the final stages of shipping a Windows IDE, a new Composer, a complete class library MFC 2.0, and a tool for creating apps. This last tool was known as App Wizard, or AppWiz as we liked to call it.

AppWiz was our big demo. In an era where creating a Windows app could take days and required a 900-page book, a developer could with a few clicks and without ever leaving the comfort of Windows create an app. It was industrial strength and professional. We still had to prove to pros that this was not a toy app and was as powerful as writing a C app in the style of Charles Petzold’s Programming Windows book, the bible of Windows programming.

Taking a lesson from shipping MFC 1.0, we tracked daily the lines of code and size in bytes of MFC 2.0 but also the number of clicks, lines of code, and size of the “Hello World” app created with AppWiz. Our goal was to fit Hello World on a single page, or even better a single slide, without cheating or breaking the purity of the MFC app framework. We achieved this goal and it really wasn’t a hack or fake. In a just a few clicks, a fully functional program capable of having multiple windows, file open/save dialogs, help menu (that was important back then), and even an About . . . box (even more important since that is where the name of the programmers often went). The killer feature, which was even eventually employed by Netscape for Windows, was printing with print preview, notoriously difficult features. We made them essentially “free”—all the programmer needed to do was add the code for drawing his or her content on the screen.

Given the compelling nature of the demos, I was about to experience hand-to-hand combat in the world of software and developer tools. Borland was going all out to gain the upper hand, and with the beta release of what was being called C 8 (and what was in the NT PDC build) there was starting to be some grumbling about how efficient and “compliant” MFC was with industry standards.

The way this was done back then was two-fold. First, companies wrote detailed technical white papers of 20 to 30 pages and circulated them to the press and influential analysts. These papers served as background material and were used by writers as sources. They rarely saw the light of day because by reusing the content in them rather than quoting them directly all the analysts and writers seemed more objective and smarter. These white papers amounted to “gentlemanly trash talk.” This was sort of the air war of competition.

Second was the use of the old USENET newsgroups at a grassroots or hand-to-hand combat level. This was much more direct and much less polite when going after each other. USENET was a massive trove of the internet’s first worldwide bulletin board system. It was organized into groups much like today’s Reddit. There were several interesting groups for MFC and C++ with names like comp.lang.c++.standards or comp.os.ms-windows.programmer. Getting on the internet (technically this was pretty much all that was on the internet in 1991) from within Microsoft wasn’t easy back then so often I dialed up from home (or went downstairs to the lobby and used the fax line) and went through my own dial-up service (crazy as it sounds). Eventually the groups were available internally through a mirror site.

On these groups people posted arguments or rants about topics, and then a long argument thread ensued. I spent hours debating people, some anonymous and some from Borland even, over the esoteric aspects of C++ language syntax and rules or topics like the performance of MFC Windows programs. The old internet devolved the same way today’s internet does, only the tools change. Most discussions eventually end up in a stalemate or name-calling.

Eventually, I took matters into my own hands. Back from the Borland Developer Conference (BDC) in San Diego that I attended under an assumed name since my original registration was rejected as a Microsoft employee (Borland was like that), I wrote my first guerrilla marketing and technical buzzsaw taken to a competitive product. A technical buzzsaw was a favorite Microsoft technique used to look at a competitive product (or even code from another team) and quickly find all its flaws or weaknesses. At the conference, they were vicious and trashed the current release of C++ and the beta with MFC 2.0. All fired up, I wrote my first white paper, Borland C++ & Application Frameworks 3.0 vs. Microsoft C/C++ 7.0: An Exposé (A Draft Response Prepared by Microsoft Development). I did my best work to shred the Borland competitive assertions in a whitepaper they distributed at their conference.

This was the start of writing missives late at night in hotel rooms, which became a pattern for some of my best work (said humbly).

We just needed to ship. At least I shipped once, finally.

On to 013. End of the Beginning

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com