This article discusses a few challenges in porting a win32 app to Windows 8 Desktop. We use POV-Ray*, an open-source ray tracing program, to illustrate these issues. Three approaches are considered: running unchanged binaries on Windows 8, recompiling for Windows 8 using Microsoft Visual Studio* 2012, and redesigning the app to use the touch and sensor capabilities available in Windows 8. We also identify several compile-time errors you may encounter.
With the release of Windows 8, many software developers are curious about the effort required to migrate code. I will cover a few of the obstacles I encountered in this article, and show areas for possible improvement, including extending the basic touch support.
The Windows 8 Desktop UI allows legacy applications, programs created for previous versions of Windows, to be installed without changes to the code. The legacy apps will run smoothly using the mouse and keyboard, and can be easily adapted to use touch. These apps handle touch through “fuzzy hit targeting” or “touch-target locking.” Touch is registered as an area and connected to the most likely intended target instead of a minute area being selected.
The precompiled package of POV-Ray installs on Windows 8 and uses the keyboard and mouse without issue. There is, however, a problem with touch. When using touch to vertically drag content in the text editor, the scrollbar moves as expected, but there is no change in the editor. This unusual behavior is due to POV-Ray’s use of an external library for the text editor. Most win32 applications use standard controls and will not encounter this problem when running in Windows 8 Desktop.
In addition to simple touch support, Windows 8 Desktop applications can be pinned to the start screen as easily as to the taskbar, creating a Windows 8 UI tile. Right-clicking on the program in an Explorer window, as shown in Figures 1 and 2, will show these options.
Figure 1) "Pin to start" available on right-click menu
Figure 2) Quick and easy tile
To augment the functionality of a program and use new features in Windows 8 (such as enhanced touch and other sensor input), you should recompile the source code in Visual Studio 2012.
Enhanced Touch and Sensors
Touch is one of the most exciting enhancements on many Windows 8 platforms. Legacy applications have basic functionality, such as a sliding touch to scroll on scrollable text areas, but including support for touch gestures gives new control. Touch gestures are the standard commands for a device using only the touch screen (e.g. tap, zoom, rotate, etc.). By customizing the reactions to these inputs, the interface becomes more intuitive and moves beyond a pseudo-mouse. The ability to zoom and rotate on the render views would be a valuable addition to POV-Ray. The basic support interprets touch movement similar to mouse clicks, allowing only the selection of an area to render.
Codemax, an external library, is used to provide the text editor in POV-Ray. This fact makes fixing the scroll bar disconnect a sizable task. The library itself can be ported and enhanced to solve this problem. The scrolling would need to be triggered by an event listener capturing the WM_GESTURE that indicates a panning motion on the text area. This could be limited to multi-touch panning in order to reserve single-touch swiping for selecting text.
If the application has use for other available sensors (e.g. shaking a gyroscopic tablet to jostle the table in a pinball game, or an interactive map identifying the user’s location via GPS), you should add support. Most legacy applications, like POV-Ray, were designed without anticipating this technology. Their interfaces are only optimized for a keyboard and mouse. You will break the conceptual integrity of an application if you add arbitrary features just because the sensors are available. By selectively implementing sensor support, the user experience grows expressive while remaining robust. Without superfluous inputs, the program will be solid and more stable. It will also run smoothly on platforms with limited available sensors.
Common Errors and Problems
There are usually a few build errors when a sizable codebase is recompiled in the newest version of Visual Studio, and POV-Ray was no exception. With a bit of research, most errors can be resolved with little effort.
Changes to Underlying Code Libraries
When a project is built, there are often numerous core libraries included. With any update to the compiler, those libraries may have changed, causing new warnings or errors in the project’s code.
POV-Ray has some macro redefinitions that will no longer compile, as shown in Figure 3. The compiler was complaining that “true” and “false” were being redefined. Fortunately, added warnings in the code made it easier to find which keywords have been redefined. Beyond just throwing an error, these helpful warnings (the list of #define statements on the right side of Figure 3) are included to identify the problem areas. Without these warnings, any keyword redefinitions triggered the same generic error, and the developer wasted precious time tracking it down.
Figure 3) #define false and #define true identified and disallowed by xkeycheck.h
This change alone didn’t fix the error, however. A related issue continued even when the redefinitions were removed. The include order in POV-ray failed when compiling for Windows 8. The source of the error was previously identified with the header “winnt.h.” In response to this problem, one option is to change these inclusions to winnt.rh or windows.h. Since POV-Ray didn’t directly include winnt.h, this was not a workable approach. I followed the header chain (via the /showIncludes compiler option, shown in Figure 4) to find the problematic occurrences. The file throwing the error was included by config.h. By moving the inclusion of ”config.h” later in the include order, as shown below, the restructured dependency order satisfies Visual Studio.
Figure 4) /ShowIncludes output
#include <math.h> #include <stdio.h> #include <string.h> #include <limits.h> //#include "config.h" Moved lower to change include order #include "configbase.h" #include "fileinputoutput.h" #include "config.h" //That's better
Outdated project configuration
When migrating a project to a new version of the compiler or target system, previous workarounds or shortsighted fixes may cause issues as severe as (or worse than) those they originally fixed.
The only such hiccup with POV-Ray was an old preprocessor definition identifying the wrong version of Windows, as shown in Figure 5, which caused a compile-time error when POV-Ray checks the version to ensure compatibility with required functions. Removing that definition solved the problem.
Figure 5) Windows version defined as 0x500 (implying the operating system is always Windows 2000)
In Windows 7, apps were required to meet certain criteria to qualify for the Windows Software Logo Program. The Windows 8 parallel for this is the Windows 8 Desktop App Certification Program. This certification proves an app’s compliance with certain protocols and requirements to ensure seamless compatibility with Windows 8 systems. As the MSDN reference for certification states, “Successfully passing Windows App Certification allows for your app to be showcased in the Windows Compatibility Center and it’s also a necessary step to listing a desktop app reference in the Windows Store.”
Additional information and specifics on these criteria can be found here.
POV-Ray does not currently meet the qualifications to be certified. The install process is not compatible with the Windows App Cert Kit validation program. Changing the process to meet the standards would allow further aspects of the program to be evaluated.
With these changes, your old application can now run on shiny new platforms like Windows 8 Desktop. POV-Ray made this transition relatively smoothly, but there are areas where it could be improved.
Pre-existing Windows applications can be installed on Windows 8 Desktop without changes, but the touch support will be minimal. Enhancements can be made by recompiling in Visual Studio 2012. Resources are available from both Microsoft and Intel on adding touch and sensor capabilities to your app.
Microsoft Windows 8 Desktop Certification: http://msdn.microsoft.com/en-us/library/windows/desktop/hh749939.aspx
Microsoft guidance on designing for touch: http://msdn.microsoft.com/en-us/library/windows/desktop/cc872774.aspx
Intel guidance on designing for touch and sensor capable devices: http://software.intel.com/en-us/articles/ultrabook-touch-and-sensors-resources/
Brad Hill is a Software Engineer at Intel in the Developer Relations Division. Brad investigates new technologies on Intel hardware and shares the best methods with software developers via the Intel Developer Zone and at developer conferences. He is currently pursuing a Master of Science degree in Computer Science at Arizona State University.
Copyright © 2012 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.