Microsoft has a problem. For over 30 years, they have successfully upgraded the OS while simultaneously bringing the bulk of older applications along. Sure, they screwed up the app compatibility story between Windows XP and Vista (or, as you experienced it, XP to 7). However, more than any other OS vendor, Microsoft has earned high marks on compatibility over the years. Microsoft’s customers have done well leveraging this capability, and many of them depend heavily upon it. At all of the large enterprises that I work with, at least 10% of their apps are 10 years old (or older). A large percentage of these really old apps are in-house apps that the company no longer has the ability to maintain or replace.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But now everything at Microsoft is about the cloud. They have a plan to evolve and bring both ISV partners and customers along. To be frank, they’re not keen about you bringing your crap along for the ride and would like to see your apps modernized. Microsoft has a plan for apps and has been acting on it. I view this current strategy for apps as being four-fold. The strategy will no doubt will evolve over time (things that don’t make a lot of sense often do), but you’d better understand where it is now.
Part 1: Universal Windows Platform Apps
You might know them as Windows 10 Apps, Modern Apps, Windows 8 Apps, or App Store Apps, but Universal Windows Platform apps (UWP apps) is the correct term currently. UWP apps reflect Microsoft’s desire to get out from under the support baggage of a lot of old APIs and entice developers back into the fold.
The traditional Windows API (application programming interface) is over 30 years old and has been updated every two years. It now includes:
- a lot of stuff that people don’t use;
- a lot of stuff that people do use, but that doesn’t have documentation anymore; and
- a lot of stuff that has been officially deprecated for years but still works anyway.
I’m pretty confident that even Microsoft doesn’t know what a large percentage of the API is anymore. More than once, Microsoft development teams have asked me for examples of an app that uses a particular API when they couldn’t figure it out.
So Microsoft went for a clean break with UWP apps and created a new API for developers. One of Microsoft’s goals for this new API is to be as device and OS-independent as possible, with a hope to reduce or possibly eliminate future compatibility issues. Apps developed for this new runtime (called .NET Core) are delivered in a new format called AppX (replacing the ubiquitous MSI). The new API is substantially smaller than the traditional Windows APIs of .NET and “Win32”, both in runtime file-size and in the breadth of interfaces supported. But more than just being a new API that removes duplicate ways to do the same thing, the runtime environment for AppX software is also often very restrictive in terms of what an application may or may not do.
In essence, UWP apps run in an isolation environment (generally called a sandbox, but using ideas originally used for App-V). They are prohibited from making any system changes or interfering with any other applications. In practice, UWP apps today are stand-alone and don’t interact with other apps.
It is precisely these restrictions that have limited the popularity of UWP apps by developers, even though it is easier to write a new app in UWP than the Windows API (assuming the design can work in either runtime environment). However, the “Universal” part of the story from Microsoft is what has been most interesting.
UWP apps can run on Windows 8 and higher desktops and tablets, as well as Windows 10 Mobile, HoloLens, and Xbox, but not on Windows 7. In all likelihood, developers will have separate builds for the different screen sizes, but almost all of the code is common and they can build all versions into a single AppX bundle package for uploading into the Windows Store. UWP apps can be designed to share settings and state information using OneDrive, rather than Roaming Profiles or UEM solutions. So if you run on multiple devices, you can just pick up where you left off as you go from one to another.
To further entice developers and earn the name Universal, Microsoft also promised to open source and port the runtime to the iOS and Linux operating systems. While the runtime is available on Windows now, the first version of the ported runtime is scheduled for release this fall. To solidify this approach for a single development environment for all devices, last February Microsoft bought Xamarin, a popular cross-development tool for mobile apps.
This all is great for Microsoft-oriented developers that can use the new runtime, and that have the majority of their customers on devices using the runtime. However, there are a lot of developers and apps out there that don’t fit that criteria.
If you look at what is in the Microsoft Store currently, the existing UWP apps tend to be either games or a local front end to a web-based or native-cloud application. This isn’t surprising given that enterprises are still primarily on Windows 7 today. Enterprises don’t really care (or care enough yet) about the apps that are in the Windows Store. Enterprises that I talk to that have Windows 10 projects ongoing generally want to prevent desktop users from accessing the Windows Store at all. They’re not even all that keen about the Windows Store for Business yet, either. So for Microsoft to make their strategy work for businesses, they need to get the kinds of applications ISVs traditionally have sold to enterprises into the Store.
As part of this effort, eventually Microsoft will have to extend the new API and runtime to remove some of the restrictions that prevent UWP apps from functioning like all of the great productivity apps that the enterprise requires, i.e. apps that work together in ways that a company can use to build business processes. We’ll have to wait and see how this pans out. In the meantime, Microsoft has other parts of their strategy to help…
Part 2: Windows Bridges from other operating systems
Microsoft came up with the idea to help developers that built apps on other platforms port them to Windows. This was realized as the Windows Bridge for iOS and the (now defunct) Windows Bridge for Android.
The Windows Bridge for iOS brings Visual Studio support for Objective C, the language most commonly used to build iOS apps. (It provides other porting support, too.) Microsoft is trying to win back game developers they lost to Apple. Currently, those developers often write for iOS first, port to Android, and then maybe port to Windows. With the Bridge for iOS, Microsoft is trying to fill the Windows Store with more apps.
The Windows Bridge for Android, otherwise known as Project Astoria, was a similar project to bring Google developers and apps into the fold, but Microsoft suddenly dropped it last winter. The reasons are not clear, but it is known that the work was way behind schedule, and with Microsoft buying Xamarin, it may have been less necessary.
Anyway, Microsoft is hoping that while developers are getting involved with the Windows Store, they’ll see the possibility of a single build system that, without porting, can create apps that run on all major desktops, tablets, and phones. Sounds too good to be true? Well, yeah. Even though most of the code can be common, developers will still have separate projects for additional platforms, and there are platform-specific things that they will likely need to deal with.
If you ignore what happened to Windows 10 Mobile lately, this was a great strategy to get developers back. I’m not sure they’re going to convert diehard Apple developers, but they are stemming the defection of Microsoft developers. If they get enough winning software running across all platforms they still could win this in the long run.
Part 3: Windows Bridges from other Microsoft platforms
This part of Microsoft’s strategy is aimed at bringing existing apps into the future.
Windows Bridge for Silverlight
Silverlight may have been a great idea initially, but by the time it was ready the writing was already on the wall—UWP or HTML5 are the future for these apps. Like Flash, the sooner we can get rid of Silverlight the better. This bridge is designed to help developers port their work to one of these new technologies. As bridges go, this one appears to simply be porting advice rather than tooling.
Windows Bridge for Hosted Web Apps
This bridge is designed to help an existing website develop a UWP front end that can be added to the Windows Store as an app, without affecting the back-end site. It also includes a component to help port existing Chrome Hosted Apps to UWP apps. Otherwise, this bridge is mostly a ploy to interest web developers into making UWP apps so they can modernize the user experience (for example, by integrating with local hardware frameworks for GPS, cameras, or voice input) without too much back-end work.
Windows Bridge for Desktop: aka Project Centennial
The most talked about bridge in the IT pro world, Project Centennial is now released and has a new name, so we have to stop calling it Centennial now. Windows Bridge for Desktop it is. This is Microsoft’s play to help software vendors move their old crappy code (oh I’m sorry, I’m supposed to call it high quality but outdated “legacy” or “classic” code) to the modern world.
Far short of being a porting tool, it’s more similar to the Bridge for Hosted Web Apps. You get a UWP front end and most of the existing traditional Windows API code, executables, and DLLs, combined into an AppX package distributable through the Windows Store. So there are two components in it:
- A UWP app front-end, which pretty much starts out as a shortcut and possibly “live tile.”
- A Windows Bridge for Desktop package, which is all of the old code running in yet-another-isolation-environment (YAIE, which is pronounced the same as “Yeah, just what we need!”).
Microsoft’s idea is to entice the developer to get into the Windows Store, and then start moving features from the old code into the new front end until the old code finally disappears.
The Windows Bridge for Desktop environment is, in essence, a cross between the AppX isolation environment and the App-V isolation environment from which they both sprang. The purpose of the Windows Bridge for Desktop isolation environment is to protect the system and other applications from bad things the code might do by doing many of the same kinds of redirection that App-V does. So if the original code was safe, the theory is that the app is a good candidate for this Bridge. If the old code wasn’t safe, it still might be made safe thanks to the to the App-V-like redirections.
I worked with a few of my own old apps to see how well the process works. I started by using the Desktop App Converter tool, which is another tool that Microsoft released in the spring that allowed some simple apps to be converted without source code. This tool has garnered the interest of far too many IT Pros who mistakenly think they can just convert all of their existing apps. I can assure you that such a plan cannot succeed. Other than the most simple of apps, the process requires source code access.
Originally the Desktop App Converter tool used the new Windows Containers technology that is in Windows 10 1607, and you could use some PowerShell to install/capture the software similar to an App-V sequence capture. This is the same container technology that will be in Server 2016, and so far I don’t think anyone has come up with a use for it in the desktop OS other than this. Microsoft recently updated the Desktop App Converter to an app (appropriately hosted in the Windows Store), but the app is simply a new front end to that process. Without the ability to make source code changes to an app, only the simplest of apps work reasonably through the Desktop App Converter alone; it is more intended as a quick pass to be done by an ISV to better understand the scale of work ahead and any restrictions they may run into for a proper conversion.
I also ported some of my other apps to Windows Bridge for Desktop apps, working with the source code in Visual Studio and leveraging tools from FireGiant, Flexera, and AdvancedInstaller. Each of these works differently, but basically the developer removes (or conditionally compiles out) problematic code and adds a new installation/setup project. With a proper setup project, you end up with a UWP front end that consists of the shortcuts, icons, and “live tiles”. You can add notifications and background tasks (essentially replacing icon tray components of the original app). This front end simply makes it look and feel more like a UWP app and launches your main program.
Currently, there are many restrictions placed on Windows Bridge for Desktop apps. Although they run in an isolation environment, Microsoft insists that the “do no harm” rule is in effect, so they implemented some severe restrictions on the traditional APIs that may be used. Unfortunately, they really have not documented what the restrictions are, but essentially, they appear to be intended to ensure that the software never gets any form of elevated privileges.
Through my testing, I developed a fairly full list of restrictions that I discovered. Many of these seem to apply to situations that would run afoul of Microsoft’s goal of eliminating elevated privileges, so they’re likely to be permanent. Several others may be temporary restrictions (as in “the dev team at Microsoft didn’t have time to figure them out”). But as there’s no documentation from Microsoft (they’ve just given examples in presentations and blog posts), we can’t be sure which are permanent. The box below is an updated version of the list of restrictions that I presented this summer at BriForum.
One additional item that might belong in the box is licensing. Licensing would need to be removed, then Microsoft would take care of it via the store. Whether this is a feature or restriction is quite subjective.
In Microsoft’s view, developers will want to convert their software because, of course, they will all want to be in the Microsoft Store. Ultimately they hope developers will move functionality from the traditional side of their package to the Universal side until the need for the bridge goes away. Because of the limitations, however, developers currently view the bridge as more like a turnip than a carrot. Part of the reason is that while the effort to produce a Bridge version of an app is small, the market is only Windows 10 1607, and that market is still very small in the enterprise.
The runtime for Windows Bridge for Desktop was released as part of the Windows 10 1607 build in July. Microsoft had not yet worked out the mechanisms for how developers would submit these to the Windows Store for approval, so there were no available Bridges apps then. Instead, they debuted a bit later, at the Ignite conference in late September. Of course Microsoft had a few well-chosen partners ready with Apps ready on day one... not that I was able to actually identify any of these in the Store when I looked.
Evernote was one of the highlighted Windows Bridge for Desktop apps at Ignite, so I downloaded it from the Windows Store and installed it in a Windows 10 1607 machine. I was surprised to see that there was no indication in the store that this was a Bridges app. In fact, the app listed Windows 8 and above as minimum requirements, so I wasn’t sure this was even the Bridges version (since the runtime needed wouldn’t be present on Windows 8). Possibly Microsoft is using some bundling here for different platforms.
When I ran the app I could clearly see that it was a Bridges version rather than a traditional UWA. The telltale sign is that the application (and traditional tray icon) are processes created by the user’s explorer shell process rather than svchost (used for “normal” UWA apps). Quite frankly, post-install there is very little to indicate that it isn’t just a traditionally installed app. The main signs are that it has a “live tile” (albeit a static image that doesn’t change) and that there isn’t a record for it in the programs and features area. But the bottom line is that we don’t really know how many Bridges for Windows 10 apps are actually in the store right now because you can’t tell until after you download and install the store app and look for the telltale signs.
Microsoft’s success with the Windows Bridge for Desktop will not be determined overnight. This is a long-term play to encourage vendors to modernize their apps. Even if the volume of released apps is low, if it gets the developers engaged in the process of modernizing their apps in any form it should be marked as a win for Microsoft.
Part 4: App-V
With the release of Windows 10 1607 and Windows Server 2016, Microsoft has moved their App-V technology into the core of the OS. This means that Windows 10 Enterprise customers no longer need to buy MDOP or install a client. It is just there. You simply need to turn it on.
In reality, getting independent software vendors (ISVs) to embrace and support App-V may be the ultimate win for Microsoft. It took over 10 years for Citrix to get ISVs to support their apps running on XenApp. App-V support by ISVs has been lagging, even though the majority of large companies have been using it to deliver their software.
Last year I detected a small shift in interest by ISVs, possibly fueled by Microsoft talking to them about Centennial. They are finding that it is actually a lot less work to just support App-V rather than build new projects. Now that it is part of the OS, I think that most of the better ISVs will want to support the platform. It makes their existing apps work in a dynamic and contained way, and without having to change a single line of their code. Microsoft hasn’t made any noise about maybe allowing App-V packages into the store, and since App-V isn’t licensed for the Home/Pro versions they probably won’t, but I’m not sure that ISVs care.
Until (or if) ISVs completely re-write their business apps as UWP apps (or more likely as “cloud native” apps with a UWP app front end), App-V in-the-box looks like a winning strategy. ISVs can leverage their code base, and customers can leverage apps that interact with each other and are more powerful and productive, whether they are hosted in the cloud or not. I figure this means another 10 years.
Microsoft’s current strategy to move developers and their customers to running more modern apps in the cloud is a work in progress. Until enterprises make the move from Windows 7 to 10, the value proposition for ISVs to embrace the new set of options is low. This will improve over time, but as things currently stand I believe many will be unable to make the move to UWP apps due to current limitations. Microsoft will no doubt make additional changes to help. So stay tuned!
Ultimately I believe that apps will go cloud native, but that is a long, long, way off. It seems like we have been constantly heading in that direction for about 20 years using many different “new things” that are now obsolete. So these strategies might not be the ones that make it happen, but it feels like we are getting closer.