Tom Miller Interview

by Jason Olson, 1/4/2005

It is no secret that I love game development. It is also no secret that I love Managed DirectX (otherwise, this whole site wouldn't be here, would it?). These are the reasons that I am proud to say that I've had the pleasure over the last month or so to conduct an interview with Microsoft's Tom Miller, the "father" of Managed DirectX.

In this interview, we will find out how Managed DirectX came to be, as well as certain design decisions made while creating it. If you enjoy this stuff as much as I do or you just wish to get an insight into the man behind the scenes, I implore you to read on!!

JO: How long have you been working at Microsoft?

TM: I started working at Microsoft in May of 1997, although I didn't join the DirectX team for a while after that. I worked on small internal projects for MCS (Microsoft Consulting Services) for a few months before joining the Visual Basic (6) team later that year. I worked on various tools that shipped with the IDE. When VB6 shipped I moved over to the Office 2000 team where I worked in the 'core' office group (not specific to any one component, such as Word, but components that were shared). I wasn't in the Office team very long though, and moved over to the DirectX team in June of 1999.

JO: How did you manage to put yourself into a position to spearhead the development of Managed DirectX?

TM: When I was first hired into the DirectX team, my original job was to help in the development of the samples for the 'new' DirectX for Visual Basic (5/6) library we were shipping in the DirectX7 SDK. That quickly led to writing components for the DXVB library itself, which in turn led to 'owning' the entire DXVB development. While we were finishing up the DirectX 8.1 SDK (mid 2001), I began looking at this 'new .NET stuff' that was brewing over in the developer division. I recognized relatively quickly the high 'potential' for this technology and began working on a 'prototype' version of directx running under this runtime in my 'spare time'. Back then, I was calling this prototype "DirectX.NET" because everything was being called .NET.

Anyway, I worked feverishly on this prototype (the D3D portion) until I had a working copy of one of the more complex D3D examples in the SDK at the time. The performance of the sample was about on par with the DXVB code we had before, but was still relatively 'slow' compared to the C++ example it was based on. After showing the demo to multiple people in the group and implementing the rest of the DirectX API, we had our first 'public' showing of the technology at GDC in March of 2002.

So I guess a short answer to the original question would be: "I was like Nike. I just did it."

JO: What were your primary concerns when first architecting the Managed DirectX API?

TM: Anyone who saw the initial 'alpha' version of Managed DirectX at GDC back then (I still have the CD!) would barely recognize the code that Managed DirectX is today. The *very first* design decision was basically "Make everything look exactly like it does in the C++ world". The objects were all named just like the COM interfaces, the structures were all the same (with all the caps like D3DCAPS9), and there was essentially a 1:1 correspondence between the managed function and the unmanaged function. The API itself was nothing more than a simple passthrough between the 'managed world' and the 'unmanaged world'. It accomplished what it set out to do, but when compared to the great API work going into the .NET Framework itself, it looked outdated, and 'hard'..

We made a concious decision shortly after that release to focus on ease of use, and api consistency with the rest of the framework. The API matured, and many of the benefits it has built in now came from this focus early on. That being said, speed was never disregarded. After all, we're the DirectX team, games are the most common things created with our API's and games need to be fast. If a situation arose and the 'ease of use' method was simply too slow to be used in 'real time' in a game engine it wouldn't be used. In these scenarios we would provide a 'faster' alternative.

JO: As a developer, how much do you find yourself using Patterns and/or Refactorings, consciously or subconsciously?

TM: Sure, although I'd probably say it's more 'subconscious' now than anything. It just comes naturally with the territory for me nowadays.

JO: I notice that a lot of architectural designs with Managed DirectX correlate to designs already established within the .NET Framework. How much effort was put into leveraging the design decisions already established in the .NET Framework?

TM: If you would have seen the original version we showed at GDC in 2002 you would be surprised at how much it did *not* follow any of the guidelines.. After that release though (I essentially now had everything 'working') we spent a large portion of time updating the assemblies to fall into the guidelines/designs that the rest of the .NET Framework was using. The entirety of time spent between Beta1 and Beta2 was this 'redesign' of the API. It was quite a challenging time to say the least.

JO: Was a tool like FXCop used to verify the design of the Managed DirectX code base? If so, to what extent was it used?

TM: Yeah, we use all of the tools available to us at any given time, including FxCop. The 'problem' we faced when using FxCop is the enormously large number of 'false positives'.. Managed DirectX is written entirely in Managed C++ and the code that the compiler generators FxCop doesn't like. For example, when you declare an event in MC++ it also generates some protected methods like 'raise_EventName'.. That one item breaks two FxCop 'rules' (no underscores, protected methods in a sealed class). Multiply that by the hundreds and you can easily have thousands of these 'false positives'. We find these tools to be invaluable to the development though, even if we possibly miss some of the 'real' issues amongst all of the false positives.

JO: What type of testing takes place against the Managed DirectX API before each release?

TM: While I do have much contact with the test team for the assemblies, I wouldn't be comfortable speaking for them. I will say that they have quite a large 'sign off' sheet that they must complete before each release that includes running all of the tests they have written, all of the samples, etc..

JO: What are your three most favorite things about Managed DirectX?

TM: That could be interpreted a multitude of ways.. For example, I consider people using (and enjoying) an API that I designed and built to be quite awesome. It's definitely my favorite thing about Managed DirectX by a long shot. However, when looking at the API itself, the "ease of use" built into the API is another one of my favorite things. Lastly, i suppose it would be the opportunities that doing that work has afforded me. It's allowed me to write books, which is something I've always wanted to do, and with game companies now releasing games using the API, it's a whole other sense of accomplishment.

JO: What area do you feel has the most room for improvement in Managed DirectX?

TM: API clarity. While the API is already 'cleaner' than the native API, and more inline with the guidelines that the rest of the CLR uses, it's still not there. There's still quite a few of esoteric items that could be improved on. That doesn't even consider the new stuff coming out with Whidbey such as generics, etc.. These are all things that I have plans on addressing in the near future.

JO: Any last things you would like to say about Managed DirectX for the readers out there?

TM: Well, not that I can think of right now.. =) Keep writing the games and apps.

JO: Thanks for taking the time to answer these questions!

If you would like to read more about Tom Miller, you can find his blog at

As usual, if you have any suggestions for DirectX, you can go through the normal channels either by using the newsgroups or emailing