https://channel9.msdn.com/Events/Build/2016/P504
微软的官方演示，感觉挺简单的。似乎是给桌面应用加了个UWP的壳，界面元素还是桌面的，不过加了壳子很多对系统的底层操作也被隔离开了（估计各种全家桶转uwp就没效果了）

那帮忙转一下迅雷！

我实验了一下，这个转化只要目标程序的安装包可以静默运行（无需操作的全自动安装）就可以转，不需要有源码，所以理论上如果有人偷偷把别人的软件转了放到市场也不是不可能
我在练习转换器使用的时候，成功把射手播放器转换为UWP包，但是我发布者是乱填写的，因此这个appx系统说无法认证的发布者，不能安装，因此还没测试转化后的uwp版能否正常运行
下一步我准备找几个老游戏和rpg maker游戏测试测试看。如果rpg maker游戏能顺利转为可以正常游戏的uwp应用，对于很多rpg maker开发者，这就又多了一条发布游戏的渠道啊

要用这个转换器，必需是win10 14393，下载了14393的开发SDK（装update2的vs2015就有了），然后C盘至少空余十多G的空间，因为那个3G多的base image展开后有10多G

总算弄的可以安装运行了
转化后的播放器可以正常播放

其实限制还是有不少的
微软官方的说明：
This article lists things you need to know before converting your app with the Desktop to UWP Bridge. You may not need to do much to get your app ready for the conversion process, but if any of the items below applies to your application, you need to address it before conversion. Remember that the Windows Store handles licensing and automatic updating for you, so you can remove those features from your codebase.
Your app uses a version of .NET earlier than 4.6.1. Only .NET 4.6.1 is supported. You must retarget your app to .NET 4.6.1 before converting.
Your app always runs with elevated security privileges. Your app needs to work while running as the interactive user. Users who install your app from the Windows Store may not be system administrators, so requiring your app to run elevated means that it won't run correctly for standard users.
Your app requires a kernel-mode driver or a Windows service. The bridge is suitable for an app, but it does not support a kernel-mode driver or a Windows service that needs to run under a system account. Instead of a Windows service, use a background task.
Your app's modules are loaded in-process to processes that are not in your AppX package. This isn't permitted, which means that in-process extensions, like shell extensions, aren't supported. But if you have two apps in the same package, you can do inter-process communication between them.
Your app calls SetDllDirectory or AddDllDirectory. These functions are not currently supported for converted apps. We are working on adding support in a future release. As a workaround, you can copy any .dlls you were locating using these functions to your package root.
Your app uses a custom Application User Model ID (AUMID). If your process calls SetCurrentProcessExplicitAppUserModelID to set its own AUMID, then it may only use the AUMID generated for it by the app model environment/AppX package. You can't define custom AUMIDs.
Your app modifies the HKEY_LOCAL_MACHINE (HKLM) registry hive. Any attempt by your app to create an HKLM key, or to open one for modification, will result in an access-denied failure. Remember that your app has its own private virtualized view of the registry, so the notion of a user- and machine-wide registry hive (which is what HKLM is) does not apply. You will need to find another way of achieving what you were using HKLM for, like writing to HKEY_CURRENT_USER (HKCU) instead.
Your app uses a ddeexec registry subkey as a means of launching another app. Instead, use one of the DelegateExecute verb handlers as configured by the various Activatable* extensions in your app package manifest.
Your app writes to the AppData folder with the intention of sharing data with another app. After conversion, AppData is redirected to the local app data store, which is a private store for each UWP app. Use a different means of inter-process data sharing. For more info, see Store and retrieve settings and other app data.
Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
Your app installation requires user interaction. Your app installer must be able to run silently, and it must install all of its prerequisites that aren't on by default on a clean OS image.
Your app uses the Current Working Directory. At runtime, your converted app won't get the same Working Directory that you previously specified in your desktop .LNK shortcut. You need to change your CWD at runtime if having the correct directory is important for your app to function correctly.
Your app requires UIAccess. If your application specifies UIAccess=true in the requestedExecutionLevel element of the UAC manifest, conversion to UWP isn't supported currently. For more info, see UI Automation Security Overview.
Your app exposes COM objects or GAC assemblies for use by other processes. In the current release, your app cannot expose COM objects or GAC assemblies for use by processes originating from executables external to your AppX package. Processes from within the package can register and use COM objects and GAC assemblies as normal, but they will not be visible externally. This means interop scenarios like OLE will not function if invoked by external processes.
Your app is linking C runtime libraries (CRT) in an unsupported manner. The Microsoft C/C++ runtime library provides routines for programming for the Microsoft Windows operating system. These routines automate many common programming tasks that are not provided by the C and C++ languages. If your app utilizes C/C++ runtime library, you need to ensure it is linked in a supported manner.
Visual Studio 2015 supports both dynamic linking, to let your code use common DLL files, or static linking, to link the library directly into your code, to the current version of the CRT. If possible, we recommend your app use dynamic linking with VS 2015.
Support in previous versions of Visual Studio varies. See the following table for details:
Visual Studio version Dynamic linking Static linking
2005 (VC 8) Not supported Supported
2008 (VC 9) Not supported Supported
2010 (VC 10) Supported Supported
2012 (VC 11) Supported Not supported
2013 (VC 12) Supported Not supported
2015 (VC 14) Supported Supported
Note: In all cases, you must link to the latest publically available CRT.
Your app installs and loads assemblies from the Windows side-by-side folder. For example, your app uses C runtime libraries VC8 or VC9 and is dynamically linking them from Windows side-by-side folder, meaning your code is using the common DLL files from a shared folder. This is not supported. You will need to statically link them by linking to the redistributable library files directly into your code.
Your app uses a dependency in the System32/SysWOW64 folder. To get these DLLs to work, you must include them in the virtual file system portion of you AppX package. This ensures that the app behaves as if the DLLs were installed in the System32/SysWOW64 folder. In the root of the package, create a folder called VFS. Inside that folder create a SystemX64 and SystemX86 folder. Then, place the 32-bit version of your DLL in the SystemX86 folder, and place the 64-bit version in the SystemX64 folder.
Your app uses the Dev11 VCLibs framework package. The VCLibs 11 libraries can be directly installed from the Windows Store if they are defined as a dependency in the AppX package. To do this, make the following change to your app package manifest: Under the <Dependencies> node, add:
<PackageDependency Name="Microsoft.VCLibs.110.00.UWPDesktop" MinVersion="11.0.24217.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
During installation from the Windows Store, the appropriate version (x86 or x64) of the VCLibs 11 framework will get installed prior to the installation of the app.
The dependencies will not get installed if the app is installed by sideloading. To install the dependencies manually on your machine, you must download and install the VC 11.0 framework packages for Desktop Bridge. For more information on these scenarios, see Using Visual C++ Runtime in Centennial project.

微软虽然出了uwp转制工具，但好像没有推广的动作嘛……

慢慢来吧支持UWP