|Desktop Bridge Takes Win32 Apps Into The Windows Store|
|Written by Mike James|
|Monday, 19 September 2016|
This has the feel of a "come into my parlour said the spider to the fly" story. Desktop Bridge is an opportunity but it is also an invitation to accept a walled garden approach to software.
Microsoft has allowed some Win32/.NET apps into the Windows Store via its Desktop Bridge.
"Today we’re pleased to announce that new apps including Evernote, Arduino IDE, doubleTwist, 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.
The technical accomplishment is very small in that the Desktop Bridge just wraps the original Win32 app so that it can be treated like a Universal Windows Platform UWP app.
The documentation says:
When that app is launched, it does not run inside an app container, but instead it runs as the user as it normally would.
But the app runs in a special environment where any accesses that the app makes to the file system and to the Registry are redirected. The file named Registry.dat is used for Registry redirection. It's actually a Registry hive, so you can view it in the Windows Registry Editor (Regedit). Note, that this mechanism means that you can't use the Registry for inter-process communication. The Registry wasn't designed for, and is not well-suited to, that practice in any case.
When it comes to the file system, the only thing redirected is the AppData folder, and it is redirected to the same location that app data is stored for all UWP apps. This location is known as the local app data store, and you access it by using the ApplicationData.LocalFolder property. This way, your code is already ported to read and write app data in the correct place without you doing anything. And you can also write there directly. One benefit of file system redirection is a cleaner uninstall experience.
Inside a folder named VFS, you will see folders that contain the DLLs that your app has dependencies on. These DLLs are installed into system folders for the classic desktop version of your app. But, as a UWP app, the DLLs are local to your app. This way, there are no versioning problems when UWP apps are installed and uninstalled.
Notice that the app runs in two portions - the old Win32 API full trust code and the new UWP app container portion. You can only get all of the benefits of the UWP and expect your app to run on any device if you have removed all of the full trust code into the UWP container. This is quite a lot of work and accounts for the bulk of the effort in creating a true UWP app from what you already have. Microsoft put the best possible spin on this aspect with:
"At your own pace, you can add UWP features to your app such as background tasks, app services, and many more. You can use the rich UWP feature set in your app."
Of course it isn't quite the "no pressure" approach to UWP that it is being presented as. Once you get your old legacy app onto the new platform you have taken the first step on the road to a full conversion which is a job you are going to have to do and with no further help from the bridge. It isn't so much a bridge as something that dumps you in the middle of the river and points out the swim isn't so far and it will do you good.
There is also the small matter that in converting to UWP you are accepting Microsoft as your boss. It decides what goes into the Windows Store and what doesn't. Any changes it makes in the future you are going to have to live with and if you don't like it your only option is to walk.
All of the software walled-gardens come with the promise of improved sales, but they also come with a loss of freedom. It is up to you to decide if it is worth it.
Checkout the promo video for more details:
or email your comment to: email@example.com
|Last Updated ( Monday, 19 September 2016 )|