1997: Joining DirectX
Every good story begins in the middle
I’ve been writing autobiographical accounts of my career here and there.
This excerpt is from the Microsoft chapter, after we finished porting Softimage’s flagship 3D authoring tool and before the very public OpenGL v. Direct3D debate.
After we shipped the Softimage port and handed it off to the Montreal team, we spent a few months trying to decide what to do next. As part of the Advanced Consumer Technology group under Craig Mundie, we were chartered to build the full suite of 3D authoring tools needed to advance Microsoft’s business and technical interests. We were particularly interested in building a 3D authoring tool – like Softimage 3D, but starting with a clean slate. It was a complicated proposal, though: the authoring tool would have to be co-designed with the runtime that would deliver the user experience, and the Windows platform had to rapidly evolve to be able to render 3D graphics efficiently. It was a tall order, and our team wound up spending more time debating code names than defining (let alone building) a product. To pass the time, I multithreaded the ray tracer I’d written as my undergraduate thesis and published as my first book.
At some point during that time in early 1996, the MicroNews (Microsoft’s internal newspaper) published an interview with Eric Engstrom, the General Program Manager of DirectX, a suite of APIs designed to run games. DirectDraw had just shipped in December (it missed the cut for inclusion in the Windows 95 CD), and Eric had big plans for the future. The charter for DirectX started out as “kill DOS” – Windows 95 used sophisticated virtualization technology to enable MS-DOS apps to run, even more than one of them at once, in a controlled environment where each instance thought it was running on a whole MS-DOS computer. Maintaining the compatibility layer for MS-DOS was onerous, and since it did not have a driver model to speak of (applications just poked and prodded the hardware to do things like color the pixels on the monitor), platform innovations like so-called SuperVGA graphics adapters all had different ways to access features that were otherwise similar, like higher video resolutions than had been possible on the original, 1986-era VGA hardware. Games like id Software’s DOOM could run on Windows 95, but only in “full-screen DOS mode,” which also presented platform risks: if they misbehaved, Windows couldn’t always protect the rest of the system from being affected. It is a bedrock principle of operating system design that unprivileged applications shouldn’t be able to force the whole system to reboot, and continuing to support MS-DOS applications that directly manipulated the hardware was not a viable long-term strategy. A superficial market analysis concluded that the only applications still running on MS-DOS were games: everything else was being ported to Windows as quickly as possible.
So, Eric and his friends Craig Eisler and Alex St. John, the chief evangelist for DirectX1, went to GDC, the Game Developers’ Conference, and did a tremendous amount of requirements gathering. Their mission: find out what it would take for game developers to target Windows instead of DOS. Over and over and over again, they were told: “Give us direct access to the hardware, that’s the only way we can get the performance we need.” Direct Access. To the hardware. That developer feedback was the inspiration for the Direct in DirectX2 – and the APIs had names like DirectDraw (to cover SuperVGA hardware), DirectInput (for mouse and keyboard input – Windows’s native callback-based APIs were unsuitable for gaming), DirectSound (for audio devices), and Direct3D (for 3D applications). In most of those domains, there was pent-up demand for APIs that would enable game developers to write portable code that ran on any Windows PC, and also were future-proof to hardware that hadn’t yet come out. The benefit to Microsoft was that upstart hardware vendors had a lower barrier to entry: they only had to design compliant hardware and write some driver software to plug their hardware into the Windows ecosystem.
As a first order of business, Microsoft offered to port DOOM itself to DirectDraw, so developers could see that DirectX was a viable gaming platform. John Carmack and John Romero had struck it big with DOOM, a shareware game that ran on DOS and pushed VGA display adapters to the very limits of their capabilities.
For Direct3D, the situation was a bit different because 3D graphics was newer to the platform, and we didn’t have years of catching up to do with hardware that had been shipping on MS-DOS. To save time and get a head start on hiring, Eric, Alex and Craig had found and purchased a British company called RenderMorphics whose flagship product was a “game engine” that enabled other developers to easily build 3D games. The RenderMorphics team prided themselves on their game development expertise and the high performance of their software, especially their 3D rendering software that was optimized to run on Intel’s x86 CPUs. RenderMorphics turned their Reality Lab library into the first version of Direct3D, which shipped in DirectX 2.0, in mid-1996, shortly after I’d read about the team.
By then, I’d grown mightily fatigued from doing nothing but trying to pick a code name for a 3D authoring tool that seemed as hypothetical months into the project as it had at the beginning. So, I looked up the office numbers of the DirectX team and walked over to Building 27. I found Eric Engstrom’s office first. Someone had taken a printout of the Yellowstone Park warning about bears, scratched out the word “bear,” and written “Eric Engstrom” in its place. But Eric wasn’t in office.
Keep at least 100 yards (93 m) from
bearsEric Engstroms at all times and never approacha bearan Eric Engstrom to take a photo.Never feed
bearsEric Engstroms.BearsEric Engstroms that become dependent on human food may become aggressive toward people and have to be killed.If
a bearan Eric Engstrom approaches or touches your car, honk your horn and drive away to discourage this behavior.Review the best practices before you hike or camp in bear country, and learn what to do if you encounter
a bearan Eric Engstrom.
Nonplussed, I continued exploring the DirectX office space, and found Craig Eisler in his office. He was a solidly built former competitive weightlifter with a demeanor that could be impish at times, but with a dark side (I later learned that when someone had done an errant checkin that caused a regression, he picked up a keyboard and snapped it in half with his bare hands, scattering keys everywhere). I told Craig I’d read about DirectX in MicroNews and wanted to join the team.
“Well,” he said mournfully, “the only reqs I have left are for driver development.”
“I can do drivers!” I told him brightly. And it was true. I’d been building Windows drivers for Data Translation’s frame grabbers in my previous job.
It was only much later that I found out that Craig and Eric held driver developers in low esteem. I’d inadvertently volunteered to mop floors for the DirectX team.
As an aside, I will say that one of the great secrets of tech companies’ success is a liberal transfer policy. It has a dual impact: on the one hand, it enables the best engineers to choose what to work on, so they stay interested and motivated. On the other, it enables those same engineers to leave projects that are poorly run or aren’t destined for business or technical success. In the late 1990s I saw many capable engineers transfer to the DirectX team because they thought games on Windows were cool, and they wanted to work on that technology. I just happened to be an early convert.
But before we could effect the transfer, some bureaucratic trivia had to be dealt with. When transferring within a company, the hiring team has to burn a req; and some transaction has to be done with the team who is “losing” an engineer. In my case, my boss’s boss’s executive assistant made it her special project to make the transfer as painful as possible for me. She ordered my computer removed from my office and told me the DirectX team would have to buy me a new one. I wanted to continue using it, because I’d already configured it to build the Direct3D drivers I was trying to build.
I found the IT guy who’d taken my computer on her orders.
“Do you still have it?”
“Yeah, it’s right here,” he pointed out my computer amidst the piles of equipment in his office.
“Give it back to me. I’ll carry it over to Building 27.”
“Clara3’s gonna be pissed.”
“Who cares? And why the fuck do I have to set up a new dev machine just because I transferred teams?” I wondered. “I’m not leaving the company.”
“Fuck it,” he said eventually, shaking his head. “Go ahead and take it.”
I later found out that a week before our conversation, he’d given his two-week notice. He was going to work as an IT specialist at Vulcan Northwest, Paul Allen’s company. The only reason I got to keep my computer across the organizational change was because the guy who’d been ordered to confiscate had had one foot out the door.
“Evangelist” was an actual job title at Microsoft, modeled after Apple Computer’s job title of the same name, for whom Steve Jobs was the chief evangelist as well as the CEO during his tenure at Apple. As one might expect, an evangelist’s job was to encourage adoption of new technology.
The meaning of X is obvious in this context, but less obvious is that the X in “DirectX” later became the X in Xbox.
The admin for the old organization (not her real name).