Choosing Win32 Desktop or WinRT for Touch‑Enabled Line‑of‑Business Apps on Windows 8

Decision and Constraints

The recommended approach is to use Windows Runtime (WinRT) as the primary UI framework for touch‑enabled line‑of‑business (LOB) applications on Windows 8, keeping any essential Win32 code in a separate desktop process that communicates via AppService when needed.

Constraints

• Support multi‑touch input.
• Comply with Windows Store certification rules.
• Limit background execution to approved triggers (TimeTrigger, MaintenanceTrigger, etc.).
• Declare required capabilities in the app manifest.
• Remain compatible with Windows 7 for enterprises that have not yet upgraded.

Option Comparison

Aspect	Win32 Desktop	Windows Runtime (WinRT)
Touch UI	Requires custom handling of touch messages.	Provides native touch‑optimized controls (e.g., GridView, InkCanvas).
Distribution	MSI/EXE or enterprise deployment.	Windows Store (or side‑loading for enterprise).
Background services	Unrestricted; can run any executable.	Limited to specific background triggers; subject to CPU/network quotas.
Hardware access	Full access to Win32 APIs and devices.	Limited by declared capabilities (e.g., internetClient, location).
Language support	C/C++, C#/.NET, VB.	C#, VB, JavaScript/HTML, C++.
Compatibility	Runs on Windows 7 and later.	Requires Windows 8 or later.

Trade‑offs

WinRT delivers a polished, touch‑first experience and Store visibility but enforces capability declarations, restricts background tasks, and excludes Windows 7. Win32 offers unrestricted hardware access and backward compatibility but lacks built‑in touch optimizations and Store distribution channels.

Implementation and Validation

1. Create a blank WinRT XAML/C# project in Visual Studio targeting Windows 8.
2. Add touch‑enabled UI: place a Canvas on the main page and handle pointer events for drawing.

   <Canvas Background="White" PointerPressed="Canvas_PointerPressed" 
           PointerMoved="Canvas_PointerMoved" PointerReleased="Canvas_PointerReleased" />
   

3. Register a TimeTrigger background task to sync data every 15 minutes.

   var builder = new BackgroundTaskBuilder { Name = "SyncTask", TaskEntryPoint = "Tasks.SyncTask" };
   builder.SetTrigger(new TimeTrigger(15, false));
   BackgroundTaskRegistration reg = builder.Register();
   

4. Build the solution (Release configuration) to produce an .appx package.
5. Run the Windows App Certification Kit (WACK) locally on the package to verify Store compliance (API usage, manifest correctness, performance, security).
6. Validate touch interaction: deploy the app to a Windows 8 tablet or touch‑enabled laptop; tap, drag, and pinch on the Canvas and confirm the expected drawing or UI response.
7. Validate background task: advance the system clock by 20 minutes (or wait) and observe that the SyncTask runs at the scheduled interval. You can check execution via Event Viewer under Applications and Services Logs → Microsoft → Windows → BackgroundTasks‑Operational.

Limitations and Practical Checks

Background tasks in WinRT are subject to strict CPU and network quotas; exceeding these limits will cause the task to be terminated by the system, so designers must keep work lightweight and defer heavy processing to the foreground when possible. Mixing Win32 and WinRT processes requires explicit inter‑process communication (e.g., via AppService or named pipes) and adds deployment complexity, as both components must be packaged and signed correctly for Store or enterprise distribution.

A practical way to check the result is to run the app on a touch device, verify that touch gestures produce the expected UI response, then manually trigger the background task (by adjusting the system time) and confirm its execution in the Event Viewer log. If WACK passes and both touch and background behaviors are observed as described, the implementation satisfies the decision criteria.