Q&A

DirectX Marks the Spot

A co-developer of DirectX replays Microsoft's media game.

Alex St. John, best known as the creator of Microsoft's DirectX, is now founder and CEO of game software publisher WildTangent Inc., which is perhaps not-so-coincidently based in Redmond, Wash. St. John got his start in development before he even reached puberty, and while that's not uncommon today, he did so back in the 1970s on COBOL and Basic with a Commodore computer. A native of Alaska, where he was home-schooled, St. John began his illustrious career in publishing and vector graphics with that early coding, which would lead to his tenure at Microsoft and ultimately at WildTangent.

How did you get started at Microsoft?
Microsoft hired me to be the evangelist for Microsoft publishing and graphics. Part of the job was to make sure that Windows 95 and Windows NT were competitive with Apple for professional publishing and imaging applications. So I did a lot of work to get the graphics and print architectures of those operating systems overhauled to be more high-end.

What year was that and what OSes were you targeting?
I came out of the publishing industry in 1992 and I was a Mac guy. I had never done any Windows development when I joined Microsoft in '92. I did graphics architecture for roughly my first two years there and basically slid into DirectX late in 1994.

When you came in, wasn't there already a technology in place to do video and graphics?
Alex St.JohnIt was a standard that was pushed by Intel that was just giving you direct access to a contiguous video frame buffer. It was just designed for video hardware acceleration. The video team in the operating system group was working on that project.

It was actually prior to that, when I was working on WinG, which was basically the Create DIB section API for Windows 95. WinG was kind of a prototype for that that was made for Windows 3.1. The DDI interface and the WinG projects were some of the earliest efforts in adding gaming to the OS.

"DirectX was really made as an entirely skunkworks project, with no executive support, and with a high risk that we would all lose our jobs if we didn't do something that knocked it out of the park." ”
Alex St. John, CEO and Founder,
WildTangent Inc.

There was actually a third technology that most people don't remember that I worked on, that was really the prototype for what became DirectDraw-remember WinDoom and Pitfall Harry on Windows 95? Those were actually based on an undocumented Windows API called KillGDI. What they did was they shut down the Windows graphics system and gave the Windows application direct access to VGA APIs and rendering modes. So the very first Windows 95 games that people saw that were hardware acceleration or at least bypassed Windows APIs were actually based on that KillGDI prototype interface that I had built.

Where did the mandate for DirectX come from?
There's a fascinating document. It's almost the Magna Carta of DirectX media. We wrote a strategic document called "Taking Fun Seriously." There were some things that were amazingly prescient and some things that were amazingly off base. It's a very interesting read. And all the original research we did to justify the project is in there too.

I hired contractors. Remember John Miles? He was famous in the games industry for the Miles Sound System. All the DOS games generally licensed the Miles Sound System for audio playback. John built the prototype for DirectSound for me.

There was a brilliant engineer at Microsoft -- a guy who deserved a lot of credit for DirectX -- a lot of it he initiated. A guy named Todd Laney, who I think is still at Microsoft. He's an absolute genius. He's the one who helped me get the KillGDI API and DirectVideo access working. He also wrote the Create DIB sections of Windows 95 that gave you your first decent bitmap graphics speed within Windows itself. DirectInput was Craig Eisler's first DirectX API, and that was all Craig. And DirectPlay, the first multiplayer API, was [from] a British contractor I used to work with in England named Ian Robertson.

What was the purpose of that document?
The whole goal was to figure out how to addict the marketplace to Windows applications and development tools. In many cases people in that group were tasked with making Windows and Microsoft tools competitive with other techies' solutions that Microsoft considered competition in that era. So on the graphics and media side, of course, Microsoft felt it was competing with Apple.

Originally, Gates was frustrated that QuickTime was so prevalent on Windows for video playback. He had several teams of evangelists whose whole job was to make a more compelling Windows media solution for video playback. There was sort of a no-win effort to try to one-up Apple in video. It just never paid off.

As a strategist I said, 'You guys have a bad strategy. The problem is that Apple already took leadership in video, they're popular, and nobody really wants Microsoft to win. So we have to focus on an area of multimedia unrelated to video and pioneer something Apple doesn't do ...'

I said: 'You've got thousands of DOS games out there that are hugely popular. So if you're trying to replace DOS in people's homes with Windows, all the work you're doing for Windows 95 is meaningless if you don't get the games. If Microsoft wants Windows 95 to be a consumer operating system and if Microsoft wants to steal the perceived leadership in media from Apple, the right strategy is not to focus on video but to focus on gaming.'

I wrote the prototype trying to get the resources to build these technologies to get this movement going. I invested a huge amount of effort with these two friends of mine [Craig Eisler and Eric Engstrom]. We did a huge amount of work on this document and we went to Bill Gates. And the response that we got was a sort of, 'Hey, nice effort you guys, thanks for your input.' There was a period where I was tremendously frustrated because I couldn't figure out how to get it done or how to get support for doing it.

I went to my manager at the time, a guy named Rick Siegal, who was very supportive. I said, 'We justified it. We made a good case. I don't feel like anybody takes this seriously, how do I get resources?' It was a very interesting era at Microsoft and he looked at me like I was crazy. He said, 'You know, Alex, I don't even know why you're asking! You know the answer's no. If you're at Microsoft and you're going to make it happen, you just do it. If you [mess] up or fail, you get fired. And if you don't have the courage to risk being fired, you aren't the one to do this. So if you have to ask, the answer's no.'

I went and thought about it for a long time, and I hate to say it, but that conversation is what changed my career at Microsoft. Because until then, I was just another smart guy in the machine.

At that point, I said, 'All right, what the [heck]? I'll hire contractors without asking for management approval. I'll go talk to the OS guys and commandeer anybody I can persuade to build the technology for me, without asking. I'll burn money and just take the consequences a year from now.'

And that's what we did. We hired people. We diverted resources from the engineering projects just by talking people into working on it. And we said, 'You know a year from now if we haven't done something that moved the needle, we'll just get in huge trouble when people ask, "You spent how many millions of dollars on what? Did you get approval from anybody?"'

So DirectX was really made as an entirely skunk-works project with no executive support and with a high risk that we would all lose our jobs if we didn't do something that knocked it out of the park.

Do you have a Windows Presentation Foundation (WPF) and DirectX analogy?
I haven't spent a bunch of time rooting around to see what I think of the technology. But I'll tell you what the root of my cynicism is: Many presentation layers that people have forgotten come and go. And the reason they come and go shares many commonalities.

There was a very interesting reason DirectX was so successful and it had to do with the name. What DirectX meant, really, was that it was designed to be simple -- pretty low-level. It didn't do a bunch of work for you, it didn't solve all the problems, but it tried very hard to get out of the way and give you access to very low-level graphics capabilities. I'll always be first to admit that it didn't always achieve as much directness as it should have, but it was tremendously empowering in its elegance and simplicity.

But when you take 30,000 brilliant engineers who have to come to work and do something for their paycheck every day, they just factory out their technology often with very little -- how do you put it -- commercial context. So when you really want to apply these things commercially, there are always a lot of devils in the details. But these guys have moved on.

One of my greatest frustrations and irritations, even at Microsoft, is you had this enormous pile of half-polished legacy stuff that wasn't any fun to clean up -- like doing the dishes or cleaning your room. It's much more fun to make something new.

There were all these things that sort of half worked or were in the way a little bit or were kind of productive that were accumulating, while everybody was off having a good time inventing something new and exciting because they wanted to be the first to announce DirectX like we did.

One of the things I'm proud of about DirectX is I didn't ship DirectX 1 and move on. I stuck with it for six generations. The effort that goes into making something new and refining it to the level of commercial usability is an enormously disciplined, boring act after you've done something truly innovative. And very few people, especially at Microsoft, hold focus and stick around to do that anymore.

That's definitely a lament that we hear. An example is framework fatigue with the .NET Framework.
I love C#. I love coding C#. It's my favorite development language today, and I know 14 languages. That's the one I love to code in. I'm a smart guy. I try to get into the .NET Framework stuff and I just go, 'Oh man.' If somebody were paying me to do this all day then I'd probably wade through this mess. You know, the stuff is in the way. I just need some simple APIs.

It would take me less time to build the UI interfaces I need than it takes to figure out how to use the ones you contrived. And that's the weird thing, I'm a smart guy but I'm still human. I can't wrap my head around this stuff. Have we come full circle? In the past companies had to recreate the wheel, then moved to packaged stuff. So is it now more work in a sense to use some of this packaged stuff?
You know when you take a bucket of sand and slowly pour it into a pyramid, the pyramid rises, rises, rises and all of a sudden the whole thing slumps down a couple of inches. What tends to happen with innovation of very complex systems is they throw in a whole bunch of new ideas and garbage and stuff that accumulates, [and the result is] a body of things that don't quite work well. And then there's a period when it slumps down. You throw out all the stuff that doesn't work and simplify and refine everything that you learn, and suddenly it becomes commercially usable. And then you start piling on the innovation again. Again, in many respects, you see it at the biggest scale at Microsoft.

One of the interesting statistics from the creation of DirectX was that at the time we were making DirectX, Windows had 10,000 APIs in its MSDN SDK. Five hundred of them were used by 80 [percent] or 90 percent of Windows applications at the time. They would use the same 500 APIs that were used by Microsoft Office.

In other words, the 500 APIs that mattered to Microsoft, that had to be used by Microsoft's bread-and-butter product, were the only ones refined enough and documented enough for everybody else to use successfully in commercial applications. All the other [stuff] the geniuses were making wasn't in use by anything.

We made a lot of mistakes -- don't get me wrong -- but there were a couple of very simple things done with DirectX that I believe were at the root of that success. DirectX in many respects was an un-API. Windows GDI, this giant, piled-up, complicated, convoluted, hacked-up mess, was the only way to put a picture on the screen. And we were going to replace it with a pointer to a bitmap that you could put any bits you like in. Poof! It was like magic. All of a sudden you could draw anything you liked.

That's the same thing when you look at the .NET Framework. There's this great pile of stuff you're making; maybe it's brilliant and fantastically useful if you're a 10-year Microsoft veteran who does nothing but immerse yourself for all these years so you can navigate it with your brain in a glance. But boy, everybody else would probably like C# and some simple access for the ability to render your own stuff.

About the Author

Michael Desmond is an editor and writer for 1105 Media's Enterprise Computing Group.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube