Charles Petzold

I am thrilled to announce that beginning in the January 2013 issue of MSDN Magazine, I will be writing a new column called DirectX Factor focusing on using DirectX in Windows 8 (and Windows Phone 8) applications. You can read the first installment on line, as well as Michael Desmond's Editor's Note about the new column.

Like many developers, I've been very intrigued by the strategy Microsoft has taken with Windows 8. For writing Windows Store applications, three general approaches are available, all of which combine a markup langauge and a programming language:

• Managed code (C# or Visual Basic) with XAML

• Native code (C++) with XAML

• JavaScript with HTML

Regardless of the implications of Alan Turing's famous 1936 paper on computability — that all programming languages satisfying a minimum set of capabilities are equivalent — many of us have given up pursuing the grail of a single programming language and a single platform suitable for all applications. In real life, there is no such thing. Turing's analysis says nothing about important issues such as syntactic and semantic flexibility and concision, programmer productivity, ease of debugging, program assurance, and performance. Every programming language has different strengths, and the choice of a programming language and programming interface must be based on a balanced analysis of all these needs.

If your needs don't require intense number crunching or high-performance graphics or audio, you'll probably gravitate towards the conveniences of a managed language like C# or Visual Basic, or the familiarity of JavaScript, in writing your Windows 8 programs.

But for those needs where every nanosecond counts, you have the option of using a language that compiles into native machine code, and which gives you access to the powerful audio and graphics facilities of DirectX. The challenges of using C++ with DirectX in Windows 8 (and Windows Phone 8) applications is the focus of this new DirectX Factor column.

Yes, I know about SharpDX and SlimDX that provide access to DirectX through managed languages. And I have experience with XNA, first on the Zune HD and then on Windows Phone 7. But think about it: If you're using DirectX for performance, isn't it a little bizarre to begin the job by wrapping all the APIs in another layer of code just so you can access them from a managed language?

If you want to write the bulk of your program in C# or Visual Basic or JavaScript, it makes much more sense to write the high-performance code directly in C++ and consolidate it in a Windows Runtime Component that can then be accessed from these other languages.

This new DirectX Factor column in no way implies that I've "given up" on C# and XAML. If I encounter a Windows 8 programming job that requires rather simple graphics — or none at all — I'm still much more inclined to favor a C# and XAML solution. I can code faster, debug faster, and get the program running faster, and I don't have to worry about free, delete, and Release.

But the year 2013 marks a 10-year anniversary* for me of doing C# and XAML programming, and there are times when both programmers and writers need a fresh challenge. DirectX is nothing if not challenging, and I'm getting real kicks from working with it.

I'm very excited about DirectX Factor. I hope to do many cool things with Windows 8 and DirectX in the months ahead, and I hope you'll come along for the ride.

* A 10-year anniversary working with XAML is indeed coming up for me: In April 2003 I signed a contract for a book entitled Programming the Windows Client Platform that eventually became my first WPF book, Applications = Code + Markup, and in the late summer of 2013 [Correction: 2003] I wrote the article "Create Real Apps Using New Code and Markup Model" that described the platform then known as Avalon.