Kenny Kerr

Here’s what you can expect from me in terms of training material this year.

Pluralsight

Last year I published C Programming Language Fundamentals and Direct2D Fundamentals. The latter provides a comprehensive introduction to the original version of Direct2D that first shipped with Windows 7. Here’s a preview.

Later this month I will release Direct2D Fundamentals – Part 2. This new course focuses on the version of Direct2D that first shipped with Windows 8. It includes the necessary information about Direct3D and DXGI that you will need to leverage Direct2D 1.1 as well as everything you need to know in order to use Direct2D on the Windows desktop, with the Windows Runtime, with XAML, on the Windows Phone, and much more.

If this sounds interesting then get yourself ready by working through Direct2D Fundamentals – Part 1. That will give you the necessary groundwork for part 2.

MSDN Magazine

I first wrote about Direct2D in the magazine back when Windows 7 was in beta.

Introducing Direct2D

Drawing with Direct2D

Layered Windows with Direct2D

Direct2D and the Desktop Window Manager

Windows Phone and Direct2D (more recently)

I decided to spend a bit more time this year on Direct2D, both to bring some more attention to this great API as well as to introduce some of the Direct2D-related innovation in the Windows 8 family of operating systems. As such, here is an outline of topics for my Windows with C++ column over the next few months.

February: Creating Desktop Apps with Visual C++ 2012 – A desktop application primer

March: Rendering in a Desktop App with Direct2D – From USER/GDI to Direct2D 1.0

April: Introducing Direc2D 1.1 – Where Direct2D embraces Direct3D and DXGI (on the desktop)

May: Direct2D and the Windows Runtime

June: Direct2D and XAML

What Next?

I am planning to do a Pluralsight course on Classic COM and WinRT using modern C++ and WRL. I may also spend a few months later this year focusing on WRL in my Windows with C++ column.

I know Kate Gregory is also planning some more excellent C++ and Visual Studio material for Pluralsight.

Beyond that, what would you like to see in terms of training material?

You can also find me on Twitter at @kennykerr

SyncTools is a meta-tool that keeps a folder on your computer up-to-date with all the latest tools from Sysinternals. Simply pick a folder where you would like to keep the Sysinternals tools and run SyncTools.exe in that folder. It will download all of the tools and check for updates on tools it previously downloaded. Any time Mark Russinovich publishes an updated version or even a completely new tool, simply rerun SyncTools.exe to download it for you.

Using SyncTools

Download SyncTools.exe and copy it to a local folder such as C:\Tools.

The first time you run SyncTools.exe it will download all of the tools.

When new tools or updates are available, simply rerun SyncTools.exe to check for updates and it will download updates as necessary.

A * prefix means it’s a new file while a u prefix mean it’s an update. If there’s a problem with a download then a ! prefix is used and a description hints at the problem.

In the screenshot above, I didn’t have a copy of Autoruns, LiveKd and PsKill were updated, but I left Process Explorer running and SyncTools was not able to update it. The solution is simple: simply close the tool in question and rerun SyncTools and it will try to download the update again.

How it works

I wrote this little tool a few years back as an excuse to use asynchronous WinHTTP and it has served me well. Last night I rewrote it from scratch as I had some new techniques I wanted to explore. This version is simpler, although not quite as fast as it only downloads one file at a time.

The first thing it does is download the Sysinternals directory listing. If SyncTools was previously run it will then check the file signatures from the directory listing with the information from the last run. Only new or updated files will be download.

By default, it ignores the following files either because the web server won’t serve them up anyway or because they just aren’t of any use.

*.sys
*.html
*.cnt
*.scr
*.hlp
*.txt
*.asp
*.aspx

If you would like to tailor this list, simply create a text file in your tools folder called .SyncIgnore and place any file name patterns in it, each on its own line.

Finally, you can use the -u and -d arguments to tweak the tool’s behavior. The -u argument lets you provide an alternative URL and the -d argument lets you specify something other than the current directory to sync to.

SyncTools.exe -d C:\Tools -u http://live.sysinternals.com

Enjoy!

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

When starting a new project, do you ask yourself whether your program will be compute-bound or I/O-bound? You should. I’ve found that in most cases it’s either one or the other. You might be working on an analytics library that’s handed a pile of data and keeps a bunch of processors busy while crunching it all down to a set of aggregates. Alternatively, your code might spend most of its time waiting for stuff to happen, for data to arrive over the network, a user to click on something or perform some complex six-fingered gesture. In this case, the threads in your program aren’t doing very much. Sure, there are cases where programs are heavy both on I/O and computation. The SQL Server database engine comes to mind, but that’s less typical of today’s computer programming. More often than not, your program is tasked with coordinating the work of others. It might be a Web server or client communicating with a SQL database, pushing some computation to the GPU or presenting some content for the user to interact with. Given all of these different scenarios, how do you decide what threading capabilities your program requires and what concurrency building blocks are necessary or useful? Well, that’s a tough question to answer generally and something you’ll need to analyze as you approach a new project. It’s helpful, however, to understand the evolution of threading in Windows and C++ so you can make an informed decision based on the practical choices that are available.

This article carries on where I left off in November with The Evolution of Synchronization in Windows and C++.

You can find links to more of my articles here.

The December issue of MSDN Magazine includes a special feature article I wrote about WebSockets and Windows 8.

The WebSocket protocol aims to provide bidirectional communication in a Web-saturated world dominated by clients solely responsible for establishing connections and initiating request/response pairs. It finally allows applications to enjoy many more of the benefits of TCP, but in a Web-friendly way. Considering that the WebSocket protocol was only standardized by the Internet Engineering Task Force in December 2011—and as I write this is still under consideration by the World Wide Web Consortium—it’s perhaps surprising just how comprehensively Windows 8 has embraced this new Internet technology.

In this article I’ll first show you how the WebSocket protocol works and explain its relationship to the larger TCP/IP suite. I’ll then explore the various ways in which Windows 8 enables programmers to easily adopt this new technology from within their applications.

My Windows with C++ column resumes in January. You can find links to more of my articles here.

You can also find me on Twitter at http://twitter.com/kennykerr

I was quite surprised when the veil of secrecy over the Windows Phone 8 SDK was finally lifted and it was revealed that its API had in fact very little in common with the Windows 8 API.

Windows 8 essentially provides two APIs for writing (Metro) apps. There’s the XAML API and then there’s Direct3D. Yes, you can incorporate them in various ways but that’s beside the point. The first revelation was that Windows Phone 8 does not share Windows 8’s XAML API. There are various political/marketing/technical reasons for this that I won’t go into here, but needless to say I was not pleased. What a missed opportunity. I can only hope they will correct this very soon. But fair enough it is what it is so moving on.

I then looked further and noticed with some relief that Windows Phone 8 supports essentially the same Direct3D 11 API that Windows 8 does. There are some restrictions but it’s the same API. Great! I can write a native C++ app using Direct3D and by extension Direct2D. Direct2D is after all just a user-mode library built on top of Direct3D, but a very important one at that. It powers such notable apps as Internet Explorer on both Windows and Windows Phone.

Then to my horror, I get to the bottom of this page and I see this:

Not deterred I downloaded the SDK, wrote the basic CoreApplication plumbing for a Direct3D app, wrapped the swap chain buffer in a Direct2D bitmap, set it as the target of the Direct2D device context, and dressed up some pixels.

Apart from some swap chain restrictions imposed by Direct3D 11 on the phone, the app is the same as what I would write for Windows 8. To get it to work I needed to pull in the headers and libs since the Windows Phone SDK does not include those for Direct2D and DirectWrite but that’s it. I fired up the emulator and sure enough, it worked:

That looked promising but being a skeptic I didn’t trust this as proof of concept. The emulator runs on Hyper-V, which does not yet emulate ARM so it has to be an x86 build of the Windows Phone. It is possible, I speculated, that somehow something is different enough on the actual devices that it won’t work. So I waited.

Well tonight my Windows Phone 8 device finally arrived and within minutes I had my USB cable out and deployed this exact same app to the phone and look at what I see in front of me right now:

It just works. So I’m left wondering. Why is Direct2D “entirely unavailable” for phone applications? Direct2D is an incredibly powerful graphics library that would allow developers to write more compelling apps far more quickly for the Windows Phone.

I love the Windows Phone. It is an incredibly polished consumer device. It is based on the incredible Windows 8 operating system. But the official API leaves me wanting more.

Update: I’ve asked around at Microsoft. Apparently, you won’t be able to get into the app store if you use Direct2D. You’ve been warned.

Update 2: Some inside and outside of Microsoft have claimed or speculated that this was a hack. This is not a jailbroken phone. I did not copy any DLLs from Windows 8/RT. I have a Windows Phone Dev Center account that I used to deploy to the phone. I wrote the code using only Visual C++ 2012. I didn’t bother posting any code as I had my doubts about this getting past our friendly app store curators. If anything the point here is just that Windows Phone 8 has much more in common with Windows 8 than the Windows Phone API lets on.

Update 3: I’ve been asked to provide source code. Here it is. It’s basically the same as what you would write for Windows 8. There’s no Direct2D debug layer and the Direct3D swap chain is very different. In the follow-up to my Direct2D Fundamentals course at Pluralsight, I will be describing this code in detail, in particular the relationship between Direct2D, Direct3D and XAML, and how it plays out on Windows 8, RT and Windows Phone 8. So stay tuned.

Update 4: I can also confirm that the Windows Imaging Component (WIC) as well as the Windows Animation Manager both work great on Windows Phone 8. For the details of how to get it all to work, please check out my latest course: Direct2D Fundamentals – Part 2.

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

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.