Monthly Archives: November 2012

Direct2D Fundamentals – Now on Pluralsight!

My latest course is now available on Pluralsight. This one takes me back to what I enjoy most: Windows and C++ together. Here’s a quick introduction to the course.

Direct2D is a native, immediate-mode, graphics rendering library that provides uncompromising performance. Its focus is on two-dimensional rendering, providing a rich array of primitives for rendering vector graphics, bitmaps and text. It’s designed to squeeze as much out of the underlying Direct3D-based GPU as humanly possible while retaining a surprisingly enjoyable API surface.

Who should attend?

Any developers interested in the future of cutting-edge graphics for both games and applications on the various Windows platforms needs to take a close look at Direct2D.

What will you learn?

As its name suggests, Direct2D Fundamentals covers the core rendering facilities of the Direct2D library. You’ll quickly learn everything you need to know in order to start using Direct2D, from window plumbing to COM essentials. You’ll then learn all about the window render target, brushes, geometries, bitmaps, transforms and text. This course is packed with detailed demonstrations so you’ll see a lot of hands-on coding. There’s no cut-and-paste here. Everything is written by hand and illustrated graphically. You’ll quickly feel right at home with the most powerful 2D graphics API on Windows.

What’s next?

I know a lot of you are excited to learn about the improvements to Direct2D in Windows 8, especially around XAML and Direct3D interop. Well the good news is that I’m focusing on that next and the plan is to publish another course covering these topics as soon as possible. However, Direct2D Fundamentals sets the foundation for everything that you will be doing with Direct2D so it’s a great place to start.

Follow me on Twitter at http://twitter.com/kennykerr

 

Windows 8, where’d you put my HWND?!

Programmers seem to love abstractions, blissfully unaware of what’s happening under the covers. I guess that’s part of the appeal of .NET and its endless pile of abstractions. But if you’re anything like me you need to know what’s really going on. Even if you still end up using some of those abstractions, having a sense for what lives underneath can help you debug your code and ultimately create better software.

Today I want to share just one little-known fact about Windows 8 apps and that has to do with windows. Traditionally, each desktop application on Windows had at least one top-level window created via the CreateWindow function and represented by an HWND – a window handle. It wasn’t hard to see that .NET Windows Forms apps or even WPF apps still relied on an HWND for each top-level window that appeared on the desktop.

But in this brave new Metro world where everything is so fast and fluid it seems that developers are again gloriously ignorant of the fact that each app still has an HWND. I can’t really blame them as it’s pretty well hidden, but it’s still there. A little perspective again comes in handy. If you have any experience writing Windows services you will know that you are just a guest inside your own process. The same is true of Metro apps. As soon as your application’s process is created, the clock starts ticking. If you don’t hand over the wheel to the Windows Runtime, then before long Windows will shoot you in the head and your process is gone.

It begins, at least for CRT-based applications (any app produced with Visual C++) in good-old wWinMain. Yes, the default project templates try to hide wWinMain and replaces it with a silly main function designed to look like .NET but which just wastes memory and processor cycles. Anyway, the way your app relinquishes control to the Windows Runtime is by calling the static (in the C++/CX sense) CoreApplication::Run function. Your app simply implements the IFrameworkViewSource and IFrameworkView interfaces and the Windows Runtime will let you know when it needs your attention. Of course, if you’re writing a XAML based app then this is all implemented for you – another abstraction – but it’s all still there behind the scenes.

Regardless of whether you’re writing a “CoreApplication” directly or using the XAML framework, your app will have a top-level window represented by the CoreWindow class. You cannot create a CoreWindow yourself but the Windows Runtime graciously creates one for you. Once your app is up and running (specifically any time after your IFrameworkView::SetWindow implementation is called) you can call the static CoreWindow::GetForCurrentThread function to get hold of it.

auto w = CoreWindow::GetForCurrentThread();

Now it gets a little trickier. You see, there are some things a particular Windows Runtime object would rather not share with you but might want to share with someone else. Such discrimination is provided through cloaked interfaces that are not included in the Windows Runtime metadata, and not exposed by your friendly IInspectable interface. You have to use good old QueryInterface to discover whether such a cloaked interface is being offered. Of course, you first need to know what to query for. I’ll save you the trouble of guessing. Here it is:

struct __declspec(uuid("45D64A29-A63E-4CB6-B498-5781D298CB4F")) __declspec(novtable)
ICoreWindowInterop : IUnknown
{
    virtual HRESULT __stdcall get_WindowHandle(HWND * hwnd) = 0;
    virtual HRESULT __stdcall put_MessageHandled(unsigned char) = 0;
};

You can now crack open your CoreWindow with reinterpret_cast to reveal IUnknown and then query for the ICoreWindowInterop interface:

ComPtr<ICoreWindowInterop> interop;
HR(reinterpret_cast<IUnknown *>(w)->QueryInterface(interop.GetAddressOf()));

Now it’s a simple matter of calling the get_WindowHandle virtual function to get your app’s HWND.

HWND hwnd;
HR(interop->get_WindowHandle(&hwnd));

Don’t believe me? Just declare your old friend GetWindowText from USER32 and you will be rewarded with the window’s title, which the Windows Runtime sets based on information in your app’s package manifest.

extern "C"
int __stdcall GetWindowTextW(HWND hwnd, PWSTR text, int count);

WCHAR text[1024];
GetWindowTextW(hwnd, text, _countof(text));

So what can you do with this HWND? Well not very much. The reality is that everything on Windows 8 is rendered with Direct3D. Even your aging GDI app is ultimately composited together with other windows and presented to the screen as if the whole desktop were one giant DirectX application, and in some ways that’s what it is.

So even though you can get the HWND for your app, you already have access to the window’s Direct3D surface which is far more powerful than anything you could do with the HWND on your own. So why does this cloaked interface exist? Why to allow Direct3D to get your HWND of course! Oh, and ICoreWindowInterop exists on Windows Phone 8 as well.

The Evolution of Synchronization in Windows and C++

My latest column for MSDN Magazine is now available online as well as in print.

In this month’s column I’m going to explore the state of synchronization in Windows and C++. I’ll start with a review of the synchronization primitives provided by Windows itself and then consider the alternatives provided by the Standard C++ Library. If portability is your main concern, then the new C++ library additions will be very appealing. If, however, portability is less of a concern and performance is paramount, then getting familiar with what Windows now offers will be important.

You can find links to more of my articles here.