It is unfortunate, but I think Dr. McCoy from Star Trek: The Original Series said it best: ‘Windows 10 Mobile is dead, Jim“…. and just to pile on with one more.
Buried underneath the red shirt like death of Windows 10 Mobile lies the amazing Universal Windows Platform (UWP).
The developer capabilities of the Universal Windows Platform have been documented in many a location.
UWP provides:
- Full developer parity at the API and framework level across all flavors of Windows 10, Xbox One, HoloLens, and Windows 10 Mobile devices.
- A simplified install model via APPX bundles.
- A per-app separation of registry and file systems.
- XAML controls ‘just work’ across all Windows 10 / UWP devices.
- Targeting the UWP API set ensures that your app works across Windows 10 / UWP devices.
In my experience, there is nothing weirder than seeing your Windows 10 / UWP app just work on an Xbox One, in a virtual projected rectangle via a HoloLens, and via mouse and keyboard on a standard Windows 10 PC.
The above diagram is from the great Build 2016 presentation – .NET Overview given by Scott Hanselman and Scott Hunter.
UWP fits within a completely different vertical of development than the existing Windows Desktop technologies of Windows Presentation Foundation (WPF) and Windows Forms. As such UWP has access to the more modern feature set common to Windows Store applications. UWP has both duplication and subsets of API / XAML features that exist within WPF.
Right now may be a good time to take a look at your existing Windows Desktop apps and assess if they can be moved to UWP.
A UWP port of your legacy desktop app will allow access to modern UWP features:
- Live tile support
- Push notifications
- Cortana
- Background Downloader
There are 3 primary techniques to bring your current legacy desktop app to UWP:
- Project Centennial
- Straight UWP + Portable Library Breakout
- Brokered Windows Runtime Components
Microsoft’s Project Centennial can be thought of as a UWP enabling wrapper for your existing Windows Desktop app. You may be able to repackage your existing Windows Desktop application and run it as a UWP app via a Project Centennial wrapper on the forthcoming Windows 10 Anniversary Update. As with all huge development efforts, there may be some caveats to using Project Centennial to package your Windows Desktop app as a UWP app (i.e. driver installation for custom hardware devices is not supported).
Update: Project Centennial based apps can go-live against the Windows 10 Anniversary Update as of August 2, 2016.
A straight UWP + Portable Library code breakout of your app could allow the features of existing Windows Desktop apps to be migrated in a straightforward way to Windows Store / UWP applications.
Note that the main UI layer of your existing Windows Desktop app is not easily converted to UWP.
- WPF XAML is not the same as UWP XAML with differences in control support, touch events, and lack of Triggers in UWP XAML.
- UWP + XAML is a radical departure from WinForms. The headaches you may have encountered going from WinForms to WPF are only magnified in a WinForms to UWP conversion due to no real access to the underlying Win32 API set.
Brokered Windows Runtime Components allow a UWP app to tunnel between the UWP API and the Windows Desktop environment to run full .NET Framework 4.6 code on the Windows Desktop side. The downsides of this approach are many, the most limiting of which is that this technique can only be used on sideloaded UWP apps, not on UWP apps which are meant to be distributed via the Windows Store.
Interesting and non-obvious outcomes I have discovered during Windows Desktop app to UWP app code migrations:
- You discover that there may exist possibilities for your app on Android and iOS with your existing code via third party Portable Libraries and your own code as Portable Libraries running via Xamarin.
- I have found that having UWP compatible code, and Portable Libraries, allows you to create live prototypes that can bring your business services into an augmented reality future on Microsoft’s HoloLens, and a passable default experience on Xbox One.
We are at a true maturity point across the Windows, iOS, and Android ecosystems when it comes to repurposing managed code across all the .NET runtime variants via portable libraries. There is no better time than now to dust off that old-school Windows Desktop code and see how you may be able to put it to great new purposes on modern devices via UWP / .NET Core and/or Xamarin for iOS and Android.
I believe that the great things that Microsoft has shipped via their Universal Windows Platform have been lost in the 5 year sideways journey to catch up to Android and iOS. That sideways journey started with Windows CE variants in the form of Windows Phone 7; through the slight update of Windows Phone 8; the flub of full Windows 8; the long forgotten Windows RT / Windows On ARM strategy; through the full revamp (and necessary stepping stone) that was Windows Phone 8.1; and onto today’s real deal: Windows 10 / Universal Windows Platform.
Microsoft always nails something the third time they take a stab at it. In this case it feels like they have something real with UWP after 5 or 6 stabs and a whole bunch of missteps.
In a recent post to ArsTechnica, Peter Bright, master writer of all things Microsoft, wrote up a concise technical history regarding the path that Microsoft took in order to arrive at the current Universal Windows Platform destination.
With the maturity and solidity of UWP, and the positive mindshare linkage to Windows 10 via marketing and branding schemes, I think it is right to declare that UWP gets Microsoft out of the ‘Bull wandering through a china shop’ phase. With UWP, Microsoft is firmly into ‘We have something that is truly a firm third place contender, and primed for growth’ territory.
Windows Desktop app development has always been a major pain when it comes to:
- Installation and Upgrades — The only clean way to do this was with Windows Installer, and the only clean way to do Windows Installer is Windows Installer XML (just look at that crazy XML schema, and bizarre otherworldly installer object model — Thank goodness for Votive though!)
- COM + Win32 API / PInvoke — No matter what you do, it always seems like you have to resort to COM or Win32 / PInvoke for something.
- Device Access — It seems as if you need to know DIFx to install a driver, then have to know way too much about Windows Driver Model, Bluetooth sockets, or UMDF just to get read and write streams to your device from a program.
- Security — How many times have you seen the ‘Red Banner Dialog of Doom‘ while installing something? Only to be told to click ‘Install this driver anyway’?
To solve the above platform deficiencies, the Windows platform needed a simplified app development model along the lines of Android and iOS. They have that scheme today in the form of UWP, with far superior tooling in Visual Studio 2015, and far easier app coding with C# / XAML.
On previous projects, the primary things holding back any sort of Windows Desktop to Windows Store / UWP migration were:
- Third Party Software Libraries — Tied directly to full .NET Framework 4.x and usable only in Windows Desktop apps.
- Specialized device access (i.e. USB / COM Port / Bluetooth) — Oft times these devices came from third parties as well as an access library written for the device that was only usable on Windows Desktop apps.
The third party software library realm has softened quite a bit. Many third party libraries that were directly tied to full .NET Framework 4.x have been open sourced (allowing you to pull needed bits out), or turned into Portable Libraries for use in UWP (and other mobile platform) applications.
If your existing Windows Desktop app requires integration with devices, you may have some issues with a straight Project Centennial wrap of your app. You may have to adapt and rewrite your device access layers against UWP APIs.
Specialized device access has matured greatly within UWP / Windows Store apps with the release of Windows 10 / UWP. There are now fully supported UWP API sets which allow:
- Bluetooth access
- Legacy Bluetooth device stream access.
- Bluetooth LE GATT access.
- Standard Serial Port access.
- Custom USB device access (especially true if you used WinUSB for the driver) – Even a good code sample.
A more friendly environment has been created in the world of Windows application development via a series of fortunate events:
- The depths of despair that came with Windows 8 are gone with the rise of Windows 10.
- The purchase of Xamarin by Microsoft.
- Along with the support guarantees and savvy short term moves made since the acquisition.
- Maturity of open source code + flexible licensing of that code
- The rise of the UWP, iOS, and Android compatible Portable Library.
In general, the environment is such that it is a great time to look at a way to fracture and/or pivot your Windows Desktop apps onto UWP, and possibly even iOS and Android via Xamarin. Give it a try, you might be surprised how far your existing old-school code can stretch across modern devices.
Your pivot to get your Windows Desktop application working on Universal Windows Platform may even work on Surface devices from The Next Generation.
Super Development 
Leave a Comment