Archive for December 2012
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.Follow @kennykerr