Just keeping it Metro

Yes, Metro, not Retro. Or actually I should say Windows Store App now. As in, the new interface for Windows 8, mainly aimed at tablets and smartphones. Namely, I got myself a Windows 8 Pro update early on, at a low price. However, I wanted to install it on a separate partition, and keep my current installations in tact, with multi-boot. So I had to do some repartitioning in order to install Windows 8 properly. I didn’t get round to that until recently. And so I finally have a Windows 8 machine at my disposal now, both to test my code on, and to play around with and see what is new.

I did some reading on what’s new in the Windows 8 SDK. I also installed Visual Studio 2012 Express for Windows 8, and figured I’d have a look at creating Windows Store Apps. I noticed that their Direct3D examples were basically just using regular C++ code for the D3D part. They then used managed C++ to link it to the new Core UI environment, which is .NET-based. It is the exact same Direct3D 11.1 as for regular desktop apps, with only one change really: instead of attaching a swap chain to a handle of a desktop window (hWnd), you now create a swap chain for a CoreWindow. Effectively, it comes down to changing only a single function call, the one that creates the swap chain: http://msdn.microsoft.com/en-us/library/windows/desktop/hh404559(v=vs.85).aspx.

I already have a Direct3D 11 engine written in C++, so this looks promising. Let’s see what it takes to make it work inside a Windows Store App environment.

Phase one: Windows 8 SDK

First things first. Since Windows 8 is still fully backward-compatible with earlier versions of Windows (despite some people trying to cloud the issue), my code just worked as-is on Windows 8 in desktop mode. This version was still built with Visual Studio 2010, using the Windows 7 SDK and the old DirectX SDK from June 2010. The first step towards a Windows Store App would be to import the project into Visual Studio 2012, and make it work with the Windows 8 SDK (still as a desktop app).

One of the first things I ran into, was that I had to fix some QuickTime headers, because they defined a GetProcessInformation() function, which is also in the Windows 8 API, and so it clashed: http://msdn.microsoft.com/en-us/library/windows/desktop/hh448381(v=vs.85).aspx. The QuickTime SDK also came with its own stdint.h header, which interfered with the Windows 8 SDK one. The QuickTime SDK has not been updated since 2007 though (and there still is no support for x64), so I don’t expect Apple to release an update anytime soon.

Phase two: D3DX

Now I could build the code with VS2012, but I was still dependent on the old DirectX SDK, because my code made use of D3DX, which is not in the Windows 8 SDK. Since the DirectX SDK does not support ARM, I would never be able to port the engine to ARM devices as long as the D3DX code is there, so now would be a good time to replace that legacy code with the new libraries.

There are basically three different tasks I perform with D3DX:

  • Shader compilation
  • Texture loading
  • Mathematics

Shaders should now be compiled with the D3DCompiler library, which is included in the Windows 8 SDK: http://msdn.microsoft.com/en-us/library/windows/desktop/dd607340(v=vs.85).aspx.

There is no library for textures included in the Windows 8 SDK. However, Microsoft has released an open source project by the name of DirectXTK (Tool kit): http://directxtk.codeplex.com/. This handles DDS loading for all devices, and it handles the ‘legacy’ formats as well (jpg, png, gif, tga etc), with the exception of Windows Phone. On Windows Phone, the codecs for these formats are not included.

For mathematics, there is the DirectXMath library, which is included in the Windows 8 SDK: http://msdn.microsoft.com/en-us/library/windows/desktop/hh437833(v=vs.85).aspx. DirectXMath is entirely based on C++ inline functions and templates, and will use intrinsics for SSE2 (x86/x64) or NEON (ARM). You can also disable the use of intrinsics, if you still want to remain compatible with pre-SSE2 CPUs (Pentium 4 and Athlon64 were the first to have SSE2). I think I will want that for the x86 build of my engine. For x64, SSE2 is supported by definition. Likewise, there will not be any Windows RT devices with ARM CPUs that do not have NEON.

Since my engine is still a multi-API engine, supporting Direct3D 9 and 10/10.1 as well, it was slightly more difficult to get rid of the D3DX dependencies than with just Direct3D 11 code. I can use the new shader compiler for D3D10 and higher, but D3D9 will still need to rely on the old D3DX compiler. The DirectXTK texture functions will only work with D3D11, and I will need to use D3DX for the older versions (unless I want to extend the DirectXTK code myself, to make it support the other APIs, but I don’t really see much of a point in that).

Windows Store Apps only support D3D11.1 anyway, so they are not affected by what happens in the code for the other APIs. So it is not a problem when there are still some D3DX-ties there.

The mathematics are a slightly different story, since this code is shared by all APIs. D3DXMath was originally built as a set of extensions to the native D3DVECTOR and D3DMATRIX structures in Direct3D 9. In Direct3D 10 and newer, there are no native structures at all in the API. I used the same D3DXMath types as I did in D3D9, to keep things simple. But now it means that if I want to replace D3DXMath for D3D11, then I need to replace it for all APIs.

Since DirectXMath still use vectors and matrices, the memory layout is still very similar, and it is still quite easy to convert between Direct3D9/D3DX types and DirectXMath. Microsoft has an overview page on mixing the two: http://msdn.microsoft.com/en-us/library/windows/desktop/ff729728(v=vs.85).aspx

I decided to go for a quick hack initially. Namely, a lot of my functions and objects use D3DX structures and functions directly. If I were to rewrite all that with DirectXMath at once, it would take quite some time. Instead, I removed the D3DXMath.h from my project entirely, and typedef’ed some compatible DirectXMath types to D3D9/D3DX types. So now my code would actually use DirectXMath types, instead of D3DX ones. Something like this:

#if !defined(D3D9)
typedef DirectX::XMFLOAT3 D3DVECTOR;
typedef DirectX::XMFLOAT4X4 D3DMATRIX;
typedef DirectX::XMFLOAT2 D3DXVECTOR2;
typedef DirectX::XMFLOAT3 D3DXVECTOR3;
typedef DirectX::XMFLOAT4 D3DXVECTOR4;
typedef DirectX::XMFLOAT4X4 D3DXMATRIX;
typedef DirectX::XMFLOAT4 D3DXPLANE;

Then I made simple replacement functions for all the D3DXMath functions that I used, implementing them with simple DirectXMath statements. Something like this:

inline D3DXMATRIX* D3DXMatrixMultiply(
  _Inout_  D3DXMATRIX *pOut,
  _In_     const D3DXMATRIX *pM1,
  _In_     const D3DXMATRIX *pM2
    DirectX::XMStoreFloat4x4( pOut,
       DirectX::XMMatrixMultiply( DirectX::XMLoadFloat4x4(pM1),
                                  DirectX::XMLoadFloat4x4(pM2) )

    return pOut;

So I now had my own ‘D3DXMath’ implementation, which used DirectXMath underneath.

The code still compiled and worked the same as before, except I no longer had to link it against any D3DX libraries for D3D11. D3D9/10/10.1 would still use D3DX for some operations, but the mathematics were still done with DirectXMath.

Now I can just rewrite some of the code with more optimal DirectXMath at a later time (using aligned types everywhere would be nice for starters). It may already be slightly more efficient than the original D3DX code anyway, since the compiler is now emitting SSE2 intrinsics inline, rather than just linking to precompiled code.

Phase three: ARM

Now that I had removed one of the largest x86-only dependencies from the code, it was time to try and compile it for ARM, and more specifically, the new Windows Runtime environment. The Windows Runtime (WinRT) environment is basically a subset of the old Win32 and .NET environments. Microsoft provides a number of pages on MSDN to explain the differences: http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx

The Windows Phone 8 environment is more or less a subset of WinRT, also still supporting some of the Win32 API: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662956(v=vs.105).aspx

The .NET environment implements a subset of the regular .NET framework, combined with new libraries such as the Core UI: http://msdn.microsoft.com/en-us/library/windows/apps/br230302.aspx

Ironically enough, the .NET code in my codebase turned out to be the most difficult to port to WinRT. There have been a number of changes in C++/CLR, which means that the .NET wrapper I have made, would not compile for a Windows Store App. Likewise, the C# code depends on some third-party libraries such as SlimDX, which will not work either, so I could not use any of the existing .NET code. So for now I concentrated only on the C++ engine itself, and hooking that up to a minimal user-interface.

Anyway, after having cleaned out the remaining x86-only code, mainly DirectShow and QuickTime (these should be replaced with Media Foundation code for the future), I only had a small number of compile errors left. One thing is that the unsafe functions in the CRT now generate errors rather than just warnings. So I decided to finally fix these by using the *_s() functions for string processing and such.

Aside from that, there are a number of legacy functions that were no longer supported. Things like InitializeCriticalSection(). There is an InitializeCriticalSectionEx() that has been around since Windows Vista, which is supported however, so it was easy to fix. The same goes for CreateEvent() vs CreateEventEx() for example. And CreateFile() is not available either, but there is CreateFile2(). So these were all just quite straightforward fixes.

Sadly I do not have an ARM-powered Windows RT/Phone device yet, and the simulator included with Visual Studio is just a virtualized x86 environment. So although I can compile my engine for ARM now, I have not actually tested it yet. The x86 version works like a charm though. I’ve made a simple test application where my engine creates a textured donut (what else?), and I’ve tiled it with the Windows Store, so you can see that it is in fact running in the new UI of Windows 8:


Another interesting tidbit in the new Win8 APIs was this little flag: http://msdn.microsoft.com/en-us/library/windows/desktop/hh404455(v=vs.85).aspx. Yes, apparently Microsoft now allows you to detect whether you run on a tile-based deferred renderer (read: PowerVR hardware), so you can make special optimizations. Very nice!

And what do you think of Windows 8?

There has been a lot of discussion about the new user interface of Windows 8. And also about the new Windows Store, and the alleged doom for independent software vendors and all that. And how this is the end of Windows, and how people should move to linux instead. Well, that idea is laughable, when you think about it. Because even if you think Windows 8 is not as nice as Windows 7, it still makes a whole lot more sense to just stick to Windows 7 than to move to linux. The Windows 8 desktop looks and feels more similar to Windows 7 than any linux desktop environment. And Windows 8 is more compatible with Windows 7 than any linux environment. So I don’t quite see why Windows 8’s slightly different UI should move anyone to an OS with an even MORE different UI, especially since it is also a completely different OS, which is not compatible with your existing Windows applications. Some people are quite twisted.

I personally don’t really care about UIs. I have used tons of different systems over the years, and still do. While there are Start Menu apps for Windows 8, I don’t see the fun in that. I prefer to use Windows 8 as its designers meant it, so without the classic start menu. And indeed, once you get the hang of the new UI, it is not bad really. The key to Windows 8 for power users is not the new Start page, but rather the new shortcut keys. Windows has always had a number of clever shortcut keys (one of my favourites being ctrl+shift+esc to pop up the Task Manager. Which has been massively improved in Windows 8 by the way, and allows you to manage start-up programs as well). But Windows 8 introduces a number of new ones: http://windows.microsoft.com/en-us/windows-8/new-keyboard-shortcuts#1TC=t1

Just press the Windows key and start typing the app you want to start. That’s what you probably did since Windows Vista anyway, since Start Menus tend to be full of crud and slow to navigate by mouse. Or press Windows+Q to get to your Apps tile immediately. Anyway, just check the list and play around with it, there’s some interesting stuff for any power user.

Aside from that, Windows 8 worked fine for me so far. It’s fast, and the experience is generally quite smooth. There are a few minor glitches, but you get that with any new OS. It’s been fine for daily use for me, even better than Windows 7.

But you want to know what bothers me? No Solitaire! That’s right! That game has been part of Windows for a long, LONG time, but now it is gone (as are the other games, such as MineSweeper). I liked to play Solitaire every now and then, get your mind off things for a few moments, then get back to work with a fresh outlook on things. They offer some cardgames in the Windows Store now, but they are fullscreen. And that’s just not very nice on a large monitor. Luckily I am not the only one who missed these games. I first tried to start the games from Windows 7, but they refused. I suspected that there may be some version check in there (why?!). I figured I’d Google around first, and if all else fails, I’d take a stab at removing the version check. But, apparently I wasn’t the only one who was annoyed with this, and I found that there were some ready-made patches available already: http://www.howtogeek.com/122145/what-happened-to-solitaire-and-minesweeper-in-windows-8/


Another key thing that is missing, for some users at least, is the XP mode. I occasionally used it for older hardware. Then again, I have replaced most of that hardware since, so I don’t know if I will ever need it again.

This entry was posted in Direct3D, Software development, Software news and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

9 Responses to Just keeping it Metro

  1. MacOS9 says:

    Windows 8 looks slick, particularly on the Surface Pro (nice to see a full OS on a tablet instead of the somewhat limited iOS from Apple’s tablet/phone ecosystem).

    Couple of questions for you Scali regarding Win8:

    (a) how does security on it measure up when compared to Win7? (I noticed that Microsoft Security Essentials has been supplanted by Windows Defender…)

    (b) also, what are your thoughts on running third-party antivirus programs?? (or is the one provided by Microsoft more than enough…)

    Look forward to reading your comments.

    • k1net1cs says:

      As for (a), AFAIK Windows Defender in Windows 8 is basically Microsoft Security Essentials.


      A bit confusing, yes, but that’s just how it is.
      In a sense, Windows Defender replaces MSE, but in reality it’s one and the same.
      The weird thing is, you can still manually install MSE, although that would turn Windows Defender off (just like when you install any other third-party antivirus solution).

  2. MacOS9 says:

    Interesting…. I am assuming that Defender is ever-so-slightly optimized for Win8 however, even if it can be manually replaced with Essentials?? Thank you for the response Kinetics. Hope to hear from the illustrious Scali on this too.

    I have the odd (and pleasant) feeling that MSE and/or Defender are better than third-party antivirus nonsense, and when coupled with Secunia, to keep tabs on old software and the risks of running un-patched software – are perfectly fine security.

    Also, what about such virus vectors as email programs and web browsers? Perhaps Internet Explorer 10 is secure enough, if not more so, than often touted products like Firefox and Opera, since it integrates more effectively with the OS? And Windows Live Mail…is perhaps as safe a choice as Thunderbird or the non-html, old-school Sylpheed mail program?

    I will not comment on Apple’s Safari for Windows since it is no longer being updated for Windows unfortunately, and Chrome/Chromium I don’t care for much…unless I can be convinced otherwise.

    Always a pleasure hearing your thoughts.

    • Scali says:

      Well, as said already, Defender in Win8 is more or less Security Essentials (which in itself was more or less the successor to an earlier Windows Defender).
      It’s perhaps not the most secure solution, but it’s better than nothing, and it’s a lot less intrusive than most other virus scanners. It’s all I use (I never used real-time scanners before Defender/SE, because they slowed down my system too much).
      I suppose security-wise there is little difference between Win7 with SE and Win8 with Defender.

      Another big improvement in security comes with IE10, with its enhanced protection mode. You can read about it here: http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx
      Basically it runs the browser tabs in special AppContainer environments, isolated from the rest of the system (which is quite memory-hungry, so I wouldn’t recommend it unless you have at least 4 GB in your system).

      Then again, Microsoft backported IE10 to Windows 7 recently: http://windows.microsoft.com/en-us/internet-explorer/download-ie
      Which includes the full enhanced protection mode as well, so again I don’t think there’s much of a difference with Windows 8 security-wise.

  3. MacOS9 says:

    Thanks for the reply Scali, will definitely read up on enhanced protection mode. By the way, what are your thoughts on the often-touted Firefox and Opera browsers?

    Sometimes I wonder what’s the point of using them and thinking you’re (falsely) more secure than with IE, especially since many of those other browsers don’t even do sandboxing (i.e., app-container environments)??

    • Scali says:

      Yes, I think the story is similar to this old blogpost: https://scalibq.wordpress.com/2011/06/25/os-xsafer-by-design

      IE10 offers some new security measures that afaik no other browsers offer yet. Nevertheless, IE is still the ‘sweetheart’ of hackers, because of its large userbase. Even if its design is more secure, nothing is ever 100% (especially when users can still disable security features when prompted). So it may be that despite the more secure design, it may still be exploited more often, either through user error, or through some bugs.

  4. Pingback: When old and new meet: lessons from the past | Scali's OpenBlog™

  5. Pingback: DirectX 12 is out, let’s review | Scali's OpenBlog™

  6. Pingback: Windows and ARM: not over yet | Scali's OpenBlog™

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s