Ever since Microsoft started leaking details about its upcoming version of their flagship product, Windows 8, there has been firestorm of controversy among Microsoft’s faithful.  Many Silverlight application developers and publishers feel like they have been willfully misled into investing in a technology that Microsoft is now apparently abandoning. Many IT Pros dislike and fear the retraining efforts they will have to make with new Start Screen and other Windows shell changes. Finally, many ASP.NET web developers don’t see how Windows 8 relates to them despite the fact that Microsoft is adding “WinJS”, a runtime that allows Web developers to leverage their existing skills to build native applications.  On the ground, it may seem like things are going badly for Windows 8, but with a little developer ingenuity and a lot more communication and documentation from Microsoft, Windows 8 could be the product that saves Microsoft from being a victim of their own success.

Take the Start Screen for example—In order to finally enable OEMs to build devices that can truly be considered a “Tablet PC”, Microsoft has to provide a way for users to launch applications.  One might be tempted to think that the Start Menu in Windows 7 could be adapted to serve this purpose, but fingers are just not good at tapping on small icons or icons that are densely packed.  Making the Start Menu a full screen experience is really the only way to get enough space to create a truly usable touch-optimized experience.  We in the Emerging Experience group have known this for years as practically every single touch based application that we have built has been a full screen app.  On top of this, Microsoft’s Start Screen’s animations are extremely fluid and natural, and so to us it seems like a natural platform from which to launch our showcase applications.

To give a little background about ourselves and our applications, we are a technology agile group, which means that we use the technology that creates the best experience for our customers. Many of our apps are built using WPF but we also have apps that are built using Flash.  Obviously attempting to port our applications would not be a good strategy for the Flash apps, but even after a brief investigation, I quickly decided that attempting to port all of our WPF applications was a non-starter.  The Metro APIs are far too different and who knows if, after porting the WPF applications, I would even end up with an app that worked?  The solution, it was decided, was to leave the existing showcase applications as they were but to simply create live tiles for them so that they could be invoked.

The problem with this solution is that it is not possible to really take advantage of the Live Tile infrastructure from a Win32 app.  In a Metro-style (WinRT) application you can supply different resolution images for the tiles by altering the AppX manifest, but Win32 Applications don’t have AppX manifests.  It might seem trivial to simply create a WinRT application that upon launch invokes one of our showcase applications, and to use the WinRT app’s AppX manifest to customize the Live Tile, but unfortunately the relationship between WinRT and Win32 is significantly more complex than that.  First of all, WinRT applications can call some Win32 APIs, but it explicitly cannot create new processes—this is part Microsoft security model for WinRT apps.  On top of that, even though WinRT apps can call many Win32 APIs, many of those calls either fail outright or fail to have the desired result.  Clearly this is an area where Microsoft can do a much better job in providing documentation. 

To work around these limitations, I decided to create a WPF application that lives in the System Tray as a notification icon.  The entire purpose of this WPF application is to listen for network calls and then launch and activate the requested application.  At this point our WinRT “launcher” application was simply responsible for initiating the network call and then close itself down.

While this worked beautifully in the debugger, I was surprised to find that it did not work once the applications were freed from the debugger.  Sure, the Launcher application still made a network call to the WPF application and the WPF application still launched the showcase application, but the showcase application was never displayed.  The problem, it turns out, is that the Win32 function “SetForegroundWindow” on which my WPF application was indirectly relying behaves differently if the calling application is being debugged.  Clearly the Windows shell makes use of a facility to show the desktop when the user clicks on the Desktop tile in the Start Screen, but when I asked Microsoft about this and SetForegroundWindow,  I was essentially told that this was by design and that only the end user should control which window has focus.  I understand the wisdom of this decision, but this answer didn’t get me any closer to being able to launch our showcase applications from nice looking Live Tiles.

While I wouldn’t propose that developers do this in production applications, Windows 8 isn’t a production OS itself—and I still hold out hope that will make this whole endeavor moot by they release Windows 8.  With the disclaimer in effect, the way that I solved this problem was to create a third Windows Forms application whose sole responsibility is to run CDB, the command-line debugger, and automate it to launch and attach to the WPF application.  Because the WPF application has a debugger attached, it is now able use the SetForegroundWindow API and the entire system works as expected.  In fact, by not creating a Window in the Windows Forms application and launching CDB without a console window the entire hack is invisible to the user and everything transparently works as expected.

While there probably are other ways to achieve the same effect, this really should highlight noteworthy holes in Microsoft’s messaging and documentation.  First of all, I can understand that Metro-style apps won’t be backwards compatible on Windows 7, but this is no reason not to provide a facility to make Win32 apps forward compatible the Windows 8 Start Screen’s Live Tiles.  Also, while I understand that, generally speaking, it is not good design to allow application developers to control which application is active, at the same time there are always exceptions and this functionality should be enabled/disabled in registry settings or group policy and not be decided in a one-size-fits-all fashion.  But with this said, Windows 8 is actually proving to be a natural evolution of Windows 7 and a good platform on which to build touch-based experiences.  With all the talk Silverlight, Javascript, and strategy, it’s easy to forget that applications are only valued for creating good user experiences and that Windows 8 delivers a great user experience for a pre-Beta operating system.

Share

•