With the understanding that few professional developers will ever re-create their apps for the UWP platform, Microsoft is trying a different tack. Again.
That tact, of course, is Project Centennial, or the Desktop Bridge as it’s now called. The idea here is a good one: Provide developers with existing desktop applications with a half-step into the UWP world by letting them add more modern features to those apps without starting over from scratch.
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
“In addition to Windows Store distribution and modern deployment technology, the Desktop Bridge enables you to use exciting Universal Windows Platform (UWP) features and capabilities that were previously unavailable to existing PC software,” the Windows Apps Team notes in a new post to the Windows Developer Blog.
The post cited above provides a few specific examples of what developers can do to modernize (or perhaps “UWPize”) their apps by utilizing the Desktop Bridge. For those who go back a ways, it may be helpful to know that Desktop Bridge is based on the App-V app packaging technology that Microsoft first provided to enterprises a decade ago. It is a way to sandbox applications and shield them from the rest of the system. And vice versa.
Among the capabilities described are:
Windows Store distribution. Desktop Bridge apps can be distributed through the Windows Store, unlike native desktop applications.
Modern user interfaces. Using Desktop Bridge, it’s possible to add new UWP user interfaces to legacy applications. These interfaces will look more modern and help applications blend in better on Windows 10.
UWP services. Applications packaged with Desktop Bridge can access UWP app services that would otherwise by limited to true UWP apps.
UWP background tasks. True UWP apps are modern mobile apps that are managed by the system automatically. But Desktop Bridge apps can access a key part of that functionality by enabling UWP background tasks like push notifications. That way, even if your legacy application isn’t running, it can still take advantage of this key feature.
Share support. Desktop Bridge apps can become a Share target, meaning that they can appear in the Share list that appears when you attempt to share content from other UWP apps. For example, a desktop photo editing application could become a target whenever the user wants to share a photo.
As Microsoft notes, the Desktop Bridge is applicable to all PC software. Meaning, any developer can easily package their app and then start adding UWP features.
As I noted earlier today in UWP is Key to the Long-Term Success of Windows 10, however, the benefits of UWP are largely unknown to both users and developers. And in this case specifically—the Desktop Bridge, that is—there are only a few high-profile examples of developers taking on this half-step approach.
One, of course, is Evernote. Late last year, Evernote dropped its full-on UWP app, which was a toy, and instead packaged its full-featured desktop application with Desktop Bridge and made it available via the Store. My understanding is that it is adding UWP features as well.
The other big example is Adobe Photoshop Elements, which I use and recommend. Adobe isn’t supporting any additional UWP features to my knowledge, but because of its Store distribution, it supports up to 10 PC installs. When you buy this product directly from Adobe, you get just two, and you must remember to activate and deactivate it as you move from PC-to-PC. Desktop Bridge for the win.
The issue, of course, is that Microsoft has been pushing Desktop Bridge for quite some time. This technology was announced at Build 2015 and was made publicly available with the Windows 10 Anniversary Update in August 2016. And like UWP itself, it’s seen little uptick. Which I think explains the regular drumbeat of reminders from Microsoft, like this week’s post.
Which makes me wonder about the viability of an end user tool to package third party applications in a Desktop Bridge distributable. Such a tool couldn’t add more UWP features to legacy applications, but it would make them more manageable—with one-click install and uninstall—and safer to use. I would be all over such a thing.
8578
<blockquote><em><a href="#40753">In reply to </a><a href="../../../users/hrlngrv">hrlngrv</a><a href="#40753">:</a></em></blockquote>
<p>They probably could convert Notepad and Wordpad to UWP, but MS has the same problem all developers would face: Do you make the UWP version identical to the Win32 version which would be redundant, or try to "Metroize" the UI and annoy your current users with big touch-oriented controls on multiple pages. There isn’t a viable market for UWP only Windows which is the only platform that could truly benefit from UWP and Windows "Cloud" devices aren’t going to change that.</p>
8578
<p>The problem here is that UWP has nothing Win32 developers need. "Modern" here just means "different" not "better". And industry-wide, recent UI approaches have devalued usability in favor of the trendiest aesthetics. If you take a Win32 productivity program and convert it to UWP so that it functions identically to the original, it won’t be useful on any non-PC platform anyway because of ergonomic differences. If you convert it and change the UI to accommodate non-PC platforms, it will be less efficient to use and legacy customers won’t like it. These "one-size-fits-all" approaches have been tried for 40 years and they’ve always failed.</p>
8578
<p>Here’s some additional things that MS could have done better to promote "metro":<br />Pledge to charge nothing to put apps in their store for the first 2 years<br />Take only 0-10% of the purchase price<br />Pay whatever it took to get more cell companies to support their phones at launch<br />Not require the Pro version of Windows to emulate phones.</p>
8578
<blockquote><em><a href="#41110">In reply to </a><a href="../../../users/hrlngrv">hrlngrv</a><a href="#41110">:</a></em></blockquote>
<p>I should have mentioned WP7 explicitly. WP7’s introduction was the point at which my suggestions could have been useful (although it might not have been enough anyway). But I agree that MS’s ego wouldn’t have been likely to allow taking such steps.</p>
8578
<blockquote><em><a href="#41314">In reply to </a><a href="../../../users/hrlngrv">hrlngrv</a><a href="#41314">:</a></em></blockquote>
<p>Perhaps, but it really wasn’t the first opportunity to learn that lesson: MSN TV, MSN Search, Zune, Kin, Passport etc. </p>
8578
<blockquote><em><a href="#40790">In reply to </a><a href="../../../users/c.hucklebridge">c.hucklebridge</a><a href="#40790">:</a></em></blockquote>
<p>Well, they’re not byte to byte the same just as each new update of W10 isn’t identical, but they are very close particularly at the API level. Most of the differences are buried at a low level. From the customer’s POV however, the most significant difference is the incompatibility between 10 and 8 (possibly to push people to 10 rather than for any technical reason). The point is that if the market doesn’t like Metro, they aren’t going to like UWP either.</p>
8578
<blockquote><em><a href="#40765">In reply to </a><a href="../../../users/Winner">Winner</a><a href="#40765">:</a></em></blockquote>
<p>When MS reads the tech pressing saying "Post-PC, mobile is the future" etc they get scared. And when MS is scared they make the dumbest decisions. They read that Netscape was going to bury Windows because it’s all about the browser so they got entangled in antitrust there (and of course, it turned out that the company with the biggest share of browsers don’t rule the Internet as they feared). They read the Java was going to bury Windows so they adopted it and modified it in a way that favored Windows but got them in more legal trouble (mostly because the courts didn’t realize that few developers would use Windows to create a cross-platform Java app. They created Win8 because it was all about mobile. </p>
8578
<blockquote><em><a href="#40978">In reply to </a><a href="../../../users/hrlngrv">hrlngrv</a><a href="#40978">:</a></em></blockquote>
<p>I once created a context menu item that when selected from a directory would invoke a script which would alter the content of all the Word files in that directory according to a particular set of requirements and then change the end of each filename to reflect the current date. All without enabling or creating any macros within the Word documents themselves. The details aren’t important but it reduced the client’s preparation time from about 6 hours to 10 minutes. It’s hard to imagine how this could be done efficiently using a UWP version of Word.</p>
8578
<blockquote><em><a href="#41007">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41007">:</a></em></blockquote>
<p>I agree that there’s no point in full Office being converted to UWP because it would simply be redundant at best. The applications that you mentioned are also redundant at best (and in some cases inferior to their Win32 counterparts). Currently there are no UWP-only devices other than Windows Phone 10. So far the market has chosen against any Windows version that can’t run Win32 apps. You believe that will change but so far there’s no evidence to support that belief.</p>
8578
<blockquote><em><a href="#41052">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41052">:</a></em></blockquote>
<p>Have each of those apps been measured against their Win32 counterparts with respect to power requirements by a neutral third party? I suspect even MS hasn’t done the comparison for each app. To the extent that customers care about battery life (obviously not relevant to desktops) they pay attention to how many hours of use a particular device gets on a single battery charge. They don’t choose their software based on how much power it uses. </p>
8578
<blockquote><em><a href="#41111">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41111">:</a></em></blockquote>
<p>Your link is dead. You’d have to describe your methodology. The fact that you just assume that comparing your UWP app to your Silverlight app says something about Win32 doesn’t inspire confidence. To prove a significant advantage for UWP, you’d have to compare performance across many applications. Otherwise is just anecdotal evidence.</p>
8578
<blockquote><em><a href="#41148">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41148">:</a></em></blockquote>
<p>The Lifecycle is only mentioned once and it’s very light on details. I note that if I’m running NotePad, and switch to another application and then invoke the task manager, it indicates that NotePad is using 0% of the CPU. The point is that how many resources an application uses has at least as much to do with what it’s designed to do and how it’s implemented as it does on the lifecycle model.</p>
8578
<blockquote><em><a href="#41224">In reply to </a><a href="../../../users/hrlngrv">hrlngrv</a><a href="#41224">:</a></em></blockquote>
<p>Actually task manager reports to the nearest .1%. But despite the precision task manager uses, it applies to UWP apps as well.</p>
8578
<blockquote><em><a href="#41233">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41233">:</a></em></blockquote>
<p>I wouldn’t consider VLC to be representative of Win32 apps in general. Very few play videos. But as I mentioned before, proving that UWP extends battery life in general would require comparing a broad range of applications using different frameworks or no framework at all. Of course, many Win32 applications don’t have a UWP counterpart so the comparison probably can’t even be made. </p>
8578
<blockquote><em><a href="#41284">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#41284">:</a></em></blockquote>
<p>Many, many Win32 apps do exactly what you describe. There’s nothing that prevents them from doing so. If they have a process in the background, they have a specific reason for it. In some cases they perform a function that is impossible in UWP. It’s always been possible to trade performance for fewer use of resources. IMO opinion it’s better to leave that trade-off to the application developer than to the "dead-hand" of the OS.</p>
<p>Anyway, we are not convincing each other and have spent a lot of time on this, so I’ll stop. </p>
8578
<blockquote><em><a href="#40841">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#40841">:</a></em></blockquote>
<p>How difficult it is to install a Win32 application and to uninstall it is entirely up to the developer. Installation can be as simple as downloading a single EXE file and uninstall can be as simple as deleting that EXE. More complicated install scenarios may be necessary to support functionality that is impossible to perform using UWP. In other cases, steps are involved in installation to set options that would have to be set later in a UWP possible requiring multiple pages visits.</p>
<p>We can all speculate on what will happen in the years to come, but the current evidence doesn’t support the idea that UWP is going to succeed. For example, I searched Dice.com for "Universal Windows Platform" jobs and got 5 hits nationwide. If I do the same search for C# I get 6,590 positions.</p>
8578
<blockquote><em><a href="#40948">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#40948">:</a></em></blockquote>
<p>The registry slowing boot time and crap left over by bad implementations are too obscure for the average user to appreciate. They don’t even know what the registry is and would have no idea how to find left over files. The fact is that any full Windows is going to have a registry and competent developers know how to handle it properly.</p>
<p>Most of those "one man bands" making consumer apps are doing it as a hobby and aren’t making a living doing it. Those apps alone aren’t going to drive broad acceptance of the platform or motivate professionals to develop for it.</p>
<p>Although UWP has only been around for year and a half, the foundation was established with WinRT 5 years ago. XAML has been around 2008. So the idea that it’s just taking devs awhile to get "up to speed" isn’t credible. Here’s what MS says about the transition from Windows 8 runtime to UWP:</p>
<p>"While porting, you’ll find that Windows 10 shares the majority of APIs with the previous platforms, as well as XAML markup, UI framework, and tooling, and you’ll find it all reassuringly familiar."</p>
8578
<blockquote><em><a href="#40956">In reply to </a><a href="../../../users/thurrotcommentator">thurrotcommentator</a><a href="#40956">:<br /></a></em>
<p><br />The point is that since they don’t know why their PC is slowing down, the fact that it may isn’t relevant to their acceptance of UWP.</p>
<p>I never said UWP = WinRT. My point was that someone who is familiar with developing "Metro" style apps and has used XAML doesn’t have much of a learning curve to create UWP apps. There’s no driving force to make the ecosystem more "mature".</p>
<p>This is no "Windows on ARM" product available at this time. The Surface Phone hasn’t even been officially confirmed and may never exist. When you say 16% vs 20% what products are you talking about?</p>
<p>The issue isn’t what devices can run UWP apps, but whether people will buy them or developers will develop for them. Obviously buying an XBOX isn’t necessarily and indication of interest in UWP apps.</p>
</blockquote>
8578
<blockquote><em><a href="#40949">In reply to </a><a href="../../../users/illuminated">illuminated</a><a href="#40949">:</a></em></blockquote>
<p>As I’ve stated elsewhere, you can create your Win32 application as single EXE file than can be downloaded and run immediately and don’t require any reboots. How is UWP any simpler than that? The vast majority of Win32 apps don’t create a process in the system tray to remind you of updates. More common is a menu item in the application that you can invoke to check for updates. For some people this is superior to UWP automatic updates since it allows the user to decide if they want to update or not.</p>
8578
<blockquote><em><a href="#41339">In reply to </a><a href="../../../users/Asgard">Asgard</a><a href="#41339">:</a></em></blockquote>
<p>"C# has nothing to do with Win32. But it has everything to do with .NET and UWP."</p>
<p>The original .NET framework was released in 2002 and it was a layer over Win32 with C# as it’s primary language. So if C# has nothing to do with Win32, it has even less to do with UWP since UWP didn’t exist for most of its history.</p>
<p>I don’t know which comment of mine you’re responding to, so I’m not sure what argument you are trying to make about C#.</p>
<p>As far as "meaningful" applications are concerned, what meaningful applications have been made for UWP, iOS, or Android that isn’t either mobile-oriented or an scaled down equivalent of a Windows or OSX application?</p>
<p>IMO, the low-hanging fruit of application ideas have all been picked years ago. Going forward it’s going to be a lot harder to come up with a "killer" app no matter what platform or OS a developer prefers.</p>