Microsoft's Desktop App Converter tool can now be downloaded from the Windows Store

Microsoft has announced that its Desktop App Converter tool, which turns standard Windows desktop applications into Windows 10 apps, is now available directly from the Windows Store.
In a blog post, Microsoft stated:
This will enable updates of the Desktop App Converter with the latest features and bug-fixes to automatically be available to you as soon as we release them.
Microsoft also announced that desktop Windows app installers InstallShield, WiX and Advanced Installer all now support the Desktop Bridge tools, "enabling developers to directly build an app package with their existing desktop app using the bridge as part of their existing developer workflow."
We have seen a number of Windows desktop apps, such as Evernote, be released in the Windows Store in the past several weeks. Microsoft has now confirmed those plans with more to come:
Today we're pleased to announce that new apps including Evernote, Arduino IDE, Double Twist, PhotoScape, MAGIX Movie Edit Pro, Virtual Robotics Kit, Relab, SQL Pro, Voya Media, Predicted Desire and korAccount will become available in the Windows Store within the next few days for Windows 10 customers running the Anniversary Update. As the apps become available in the Store, you will be able to find them in a full collection of apps built using the Desktop Bridge in the Windows Store.
If you're a developer, you can grab the Desktop App Converter from the Windows Store now to start publishing your own converted Win32 apps to the Store.
Download Desktop App Converter from the Windows Store (opens in new tab)
Windows Central Newsletter
Get the best of Windows Central in your inbox, every day!
-
but they still run on pc?
-
Of course !
-
I think he meains, "Only PC?" And the answer is, "Yes" to that, too. BUT, MJF is reporting that "a Microsoft spokesperson" has said that this is only step 1. Soon, "some adjustments to make the apps full UWPs would then enable them to function on Surface Hub, HoloLens, and Windows Phone."
-
One step is still quite a leap coming from msft. This practicality and effort is what users and fan base demand.
-
This should be headlines. If those will be able to run on mobile/hololens/surface hub, too, then it is a big move. Especially for mobile and Continuum.
-
Who else is buying things from windows store, not mobile users. Windows 10 biggest user base is PC users, the mobile ship has sailed and MS missed it.
-
@gold-stars, I think you're missing the point of Microsoft's strategy -- you are right that MS missed the mobile boat with Windows Phone 7 and 8, but with 10, by using the same OS and developing UWP and the common store, they make it easy for developers to also release mobile versions of the apps. This is step 1 in getting back into mobile -- solve the app problems by leveraging their greatest strength, namely the PC install base. If they have a good solution, people will use Windows Phone. As proof I point to iPhone and Android -- they started with no users -- all smartphone users were on Windows Mobile, or Blackberry or Palm OS back then. There is no end point at which there are final winners and losers. It's a constant struggle to gain and hold market share. Microsoft is doing it right, this time.
-
WOW !! Finally, some momentum in this area !!
Now push Mobile updates and make it better too. :) Islandwood. :D -
So I'm guessing we can't do this with programs and such if we aren't developers...? I was hoping it was a simple plug-n-play type deal so I can play stuff, but I know there's no way that's true.
-
Haha...I was wondering the same thing. There are a few website I'd like to see as an app, desktop or otherwise
-
You can use this yourself on most any desktop app and then side load it as a UWP wrapped app. This is great for that reason alone; although it is not the intended purpose, it allows an end user to wrap legacy desktop apps and then benefit from containerizing it. There are some apps that won't work though; the app can't demand admin privlages or certain low level system access for example.
-
I might have to try this maybe... Although I'm not a programmer and I don't know much about programming. Time to google!
-
Or Bing.
-
Of COURSE Bing! But the phrase "Time to bing" doesn't roll off the tongue quite like "Time to google" does. Haha.
-
Lol, yeah. True.
-
Mobile is more more important these days.People spend more time on mobile MS.
-
People aren't buying their mobiles. They're focusing where their customers are. That's why MS is Android/iOS first in mobile, Win10 Mobile last.
-
You're right, they're not buying Win Mobile. Number one reason is because lack of apps. Getting devs to port to PC first could result in their tweaking the code a little further with tools like Islandwoond and making it available on Mobile.
-
So does this mean we will have a uwp evernote app soon?
-
Maybe
-
Say's the answer in the article.
-
This should be part of the os so we could convert our own apps on the fly.
-
What is the difference between a Windows desktop app and a Windows 10 app?
-
UWP I guess
-
Install from store instead of media or download, and sandboxed instead of potentially having full access.
-
Question about the sandbox: Does UWP keep the application from filling up the registry, etc., and causing bit rot? It seems like no matter how many "modern" apps you install and uninstall, it has no effect on system performance.
-
An app built from the ground up as UWP is fully sandboxed and has no need for the registry. A legacy Win32 desktop app wrapped as a UWP app is also sandboxed, but of course it expects to see the registry and file system etc. So the UWP wrapper gives the app it's own virtual registry and file system to play in so it never touches your real system registry or file system.
-
Yes, UWP apps cannot access the system registry
-
If you're talking about these centennial converted (ex)win32 apps as Windows 10 app now, than the difference is not so big for the average user, he just sees, that he can install his favorite win32 apps from the Store with one click, and gets updates as soon as they're published. For developers, it's a bit more different. Centennial basically creates an apps package, that contains their Win32 apps, so they can use UWP apis as well, not just win32 ones, and they can publish it to the Store this way. Other than that, these apps are sandboxed, so they left no junk in the registry once they're uninstalled. This increases the level of security. Of course, MS thinks, they'll go full UWP in time this way, so they'll be able to run on every Windows 10 device, not just PCs. So this is the difference, in short.
-
Those apps are also invisible to automation via COM, which defeats the necessity of using the registry at all.
-
I hope developers would find this as a sweet deal to work on. Conversion shouldn't be tougher than fresh coding, right?
-
Did you ever visited a code brown field made by a host of devs, with lots of them unavailable for questions?
-
Existing preferred developer workflow for C# applications is copy-paste or zipping. So, simply taking a folder or zip file is not possible?
-
Available for mobile? Lol.
-
A good start, this is what MS needs to be doing to save Windows Store and UWP in the long run. The Windows store needs people to be buying things from it more than anything else and the only significant user base MS has is PC users who's opinion of the store is very low precisely because it doesn't have the win32 apps they normally use/buy. Once Windows Store has more eyeballs and is making money for devs than uptake of full UWP apps could be more likely. Hololens and Xbox are more of a driver for UWP than Windows Phone. Trying to force mobile UWP apps on PC users was a huge mistake, one they finally are now realizing.
-
not installing on my pc says will not work on your device and require x64 architecture
-
This is very exciting news. One thing I'm wondering about is how it will handle Windows applications that pop up lots of windows? At work we're working on a new WPF app which our boss insisted must open new windows every time the user wants to do something. (I don't understand why and this isn't the way most WPF apps I know of or have worked on, behave.) All UWP apps that I've used use a model in which when you want to do something new will change the view from within the container to display the new view, etc. How will this Desktop App Converter work with something that insists upon behaving like its the mid-1990s?