Join the conversation

    • There may be some confusion here, because the Desktop App Converter doesn’t convert a desktop application to a UWP app. It is Microsoft providing a starting point in this process for more complex desktop applications which require some rewriting. So after you run the converter on a desktop application, what you get out is a desktop application with some extra little bits.
      So no, you will have to fully go through the procedure of converting a Win32 application to UWP in order to get it to run on other devices.

  1. Sorry, but there is no path forward for desktop applications. We have two technologies for developing desktop applications – MFC, which is older than the Internet, and WPF, which has been dead for 5+ years and was a nonstarter because it was managed code. Then, Microsoft started Metro/Modern/Store apps, which actually provided a modern way to do development in native code, but only for “Store” apps. Now we have UWP, which is very limited in its UI for desktop-style apps (look at Edge, the poster-child UWP app and how poor its user interface is compared to Chrome, Firefox or even IE). And after the massive flameout of WPF, I am waiting at least 5 years to adopt any new Microsoft development framework. Microsoft has hugely failed ISV desktop application developers, and this tiny little deployment bone they have thrown us in the form of the Desktop Bridge does not begin to make up for it.

  2. Browsing the Github samples, I’m lost about access to the WinRT API. So far, I have ONLY seen examples with “Win32” apps that are .NET. Are live tiles/app servicess and more only possible when using managed code and when using Visual Studio?

    • Hi Jens,

      You can absolutely use WinRT APIs from non-managed code. Here is a C++ example for using Live Tiles:

      These same code snippets work within a Win32 app that has completed step 1 of the Desktop Bridge.

      You can also build AppX packages manually and thus Visual Studio is not required. However there are free SKUs of Visual Studio that can do a lot of the heavy lifting automatically, so for the best experience I recommend using VS.

      Hope this helps!

    • The only thing that is required is that you need a Windows Runtime application to go along with the live tile. If you want a live tile for a desktop application then you need to do some really awkward things. You can see this for yourself because the TileNotification class doesn’t have the DualApiPartition attribute, meaning it will only work from a Windows Runtime app.
      The major reason why you may think managed code is because Microsoft decided that the best way to program for WinRT is to use an extension language, which was based on C++/CLI, the managed syntax. The code is actually native code.
      Another thing to point out is that none of this is also Win32 code, since it is targeting the Windows Runtime, it is Windows Runtime code.
      Finally, it is something that Microsoft dislike mentioning, and quite often passes off as something you don’t want to do, but you can use standard C++ to write WinRT applications. The problem is that when you do this, you are stuck using the native COM interfaces, rather than the API projections that you get with Visual Studio. You are also stuck feeling your way through, since Microsoft has barely documented this at all. But even if you did use the raw interfaces, you still wouldn’t be able to use a live tile from a desktop application.

      • Thank you very much. I do understand that a desktop application, by itself, is not able to update live tiles. I was more thinking about the sharing contracts, notifications (oh, they also need a “companion app”), and most importantly, the app services needed for this.

        So it looks like it IS going to be possible, but probably not a lot of fun. I’ll probably just get the app service thing working, and then have to do new features all in Visual Studio. Ugh.