If you currently have a desktop or phone application running on an earlier version of Windows, you may have made the decision to port your apps to Windows 8 or Windows Phone 8 to take advantage of the great new features built into Microsoft’s new offerings. Microsoft’s consumer promotional video above is quite impressive. So what do you need to consider?
Regular Desktop or Touch Screen
Porting apps to Windows 8 can be quite simple or very complex. Of the two main Windows 8 operating modes, porting a traditional Windows desktop application to Windows 8 desktop mode involves little or no effort. Most applications will simply “just work” on the Windows 8 desktop, or at most require some simple compatibility settings.
For the Windows 8 touch screen mode, variously known as “Metro”, “Modern”, or “Store” mode, the process of porting gets quite involved. To accommodate touch mode, Microsoft did a major reshuffle of their technology stack–adding, removing, improving, and deprecating many features. The end result is a very rich and powerful technology stack that is quite capable, but also requires a major effort to port an existing mouse/keyboard application into the touch based environment.
Issues To Consider
The list of items to consider in porting an existing app to Windows 8 is quite long. Here we mention just a few key items:
- New Interfaces. In the interests of platform security, many interfaces have been simplified and locked down. The new low level access to the Windows 8 operating system for Store mode applications is termed the “WinRT” API, and for the most part replaces the traditional Win32 API used in desktop mode applications. One important example is socket based network access. The traditional Winsock 2 interface for accessing networks has been completely suppressed in Store mode, and replaced with a set of WinRT classes. The WinRT classes operate at a much higher level than Winsock. Applications using Winsock need significant redesign to operate with the WinRT networking classes.
- Performance Enhancements. In order to have a “performant” user interface that does not “hang” at various times, Windows 8 strongly encourages and sometimes demands usage of “async” interfaces. The idea is to never have the GUI user thread waiting for an operation to complete, which would cause the screen to stop responding to user input. To effectively use asynchrony, Windows has developed the idea of “tasks” that automatically initiate threads from an existing thread pool to create a multi-threaded application in an organized and highly efficient manner. The use of asynchrony not only stops user interface stalls, but also makes effective use of multi-core CPU’s now found on most devices. The overall result is the very smooth and fluid user interfaces seen in Windows Phone 8 and Windows 8 Store mode. The usage of asynchrony in C# is greatly facilitated through various adjustments to the C# language syntax. For C++/CX, a large number of templates are used to implement asynchrony, although their use and debugging can often be obscure. Existing Win32 applications will need a significant amount of work to make use of Windows 8 asynchrony.
- Shared Technology with Phone 8. One overarching theme is the integration of technologies across various device platforms. Because Windows Phone 8 now runs on the Windows 8 NT kernel rather than on the Windows CE 6 kernel used for Windows Phone 7, Windows Phone 8 applications can now share much in common with Windows 8 Store mode applications. Thus large amounts of code and design can be shared between an application ported to Windows Phone 8 and also Windows Store 8.
- Touch Interface Support. In order to support touch interfaces, asynchrony, and security considerations, a vast array of new classes have been generated for Windows 8. Plan on investing a significant amount of your time to educate yourself on all of the new ways of doing things. It can be a bit frustrating at the beginning, but over time you can begin to appreciate the overall plan and benefits of all of these changes. Microsoft has added many pages to their website to describe the changes. Some of the information here is preliminary, incomplete, or simply incorrect, so be aware you may need to supplement this information with results of web searches and third party publications.
My Current Project
For an in-house project I am currently porting to Windows Store 8 and Windows Phone 8, I have directly faced the issues outlined above. Previous releases of Aton Connect terminal emulation products supported various Microsoft platforms including Windows Mobile, Windows CE, Windows ASP.NET, and Windows desktop (Win32). Aton Connect is based upon about 140,000 lines of C/C++ native code for communication protocols, coupled to a managed code wrapper for UI support.
As I address the remaining issues enumerated above, I will be sharing my experience and solutions with you. Future posts will address these and other points in more depth.