What do I need to do to submit my desktop app to t

Question

I heard that Windows 10 will allow developers to submit their desktop (non-Metro) apps to the Windows Store. I'm developing using C/C++/MFC and WinAPIs.

What do I need to do to submit my desktop app to the store? And what are the requirements/charge?

Answer 1

If you don't want to sit through an hour of this Build 2015 presentation linked by Peter Torr, here's a synopsis of what Project Centennial will entail. Also, as was pointed out already, this is all a preliminary stuff, that is still under development (as of May 2015.)

Applies to Win32/.NET/COM based apps listed in a Windows 10 Store:

• MSIs are "evil". Use APPX packages instead.

• APPX Gloal: one-click installs thru Windows Store, automatic app updates via Windows Store (using file diff'ing - no need to re-download large unchanged files in the package.)

• Microsoft will have an automatic conversion tool: MSI to APPX.

• MSI licensing/DRM will not work: i.e. can't look up CPU serial number, hard drive info, network card MAC addr, etc. (My take: The store app will not be able to access hardware directly.)

• The app will have a live tile & anything else that can be done with the Universal App (or Metro style app.)

• The app's AppxManifest.xml file will define app's file associations.

• The app installs into a sandbox folder with randomized path, example: C:\Program Files\WindowsApps\<GUID>\<Package Name>. This path changes every time a new app version is released.

• The app's sandbox folder will have Root\VFS subfolder that will contain the following redirected subfolders:

  • AppData
  • AppVSystem32Catroot
  • AppVSystem32Catroot2
  • Common AppData
  • ProgramFilesCommonX64
  • ProgramFilesCommonX86
  • System
  • SystemX86
  • Windows

For instance, if your app tries to access C:\Windows it will be redirected to C:\Program Files\WindowsApps\<GUID>\<Package Name>\Root\VFS\Windows invisibly for the app.

• The app's package sandbox folder will have Registry.dat file (that is a registry hive) for that app. All requests to the system registry done by your app will be redirected to that file, including HKLM and HKCU keys. So in other words, your app won't be able to modify any of the shared system registry keys.

• Apps installed via APPX packages cannot share dependencies between their files, nor inter-load other app's package contents.

• Namespace merging (between shared system files and package's Root\VFS folder files):

• Namespace wrire redirection (writing into shared system registry is redirected into your app's Registry.dat file. Also on the file system scale only AppData folder is redirected to your app's Root\VFS\AppData folder):

• The redirected AppData folder will be placed into non-roaming location.

• The store app can run only as a user (which they refer to as a "Full Trust", which in my book is a misnomer) It cannot run elevated, and if it tries to call an API that shows UAC prompt, such API will silently fail.

• The store app cannot install or run NT services.

I believe that there's a way to sign up for any updates on this project.

Answer 2

You should consider watching this //build talk with John Sheehan. It covers the details of Win32 apps in the store (codename Project Centennial). The first detail is "this project is still under development" (as of May 2015).

In a nutshell, you can take an existing MSI-based installed app, run it through a tool to generate an appx, and then you're done. There are some things that won't work (eg installing services, custom licensing / DRM, or running as administrator) but most normal app code will work. The example shown is Adobe PhotoShop Elements, which worked perfectly except for the licensing check (which can now be handled by the Store anyway).