Windows Community Standup discussing Multi-instancing, Console UWPs and Broader File-system Access

During our February Windows Community Standup, we discussed three long-awaited features that add a new dimension to how you build UWP apps. Based on developer feedback these topics are top of mind – multi-instance support, UWP console applications and broader file system access.

With the latest Insider build and SDK, we’re introducing some major new features that provide exciting new opportunities for building UWP apps. The first feature is multi-instancing. This is an opt-in feature. Some apps don’t need or want multi-instancing – but some do.

Note that multi-instancing is not the same as multi-view. A regular single-instanced app can use the multi-view feature, and this works well for those apps where it makes sense. The standard Microsoft Calculator is a good example of an app that uses multi-view. You can have multiple different calculator windows open, each performing different calculations. However, there is still only one Calculator.exe process running, so if the app crashes, or the user terminates the app via TaskManager – then all calculator windows will be closed. This is perfectly fine for this kind of app – but consider if this were to happen with an app that is editing multiple data files. In the worst-case scenario, the user would lose all edits, and possibly even corrupt all of the open files.

With multi-instancing, you get multiple separate instances of the app – each running in a separate process. So, if one instance fails, it doesn’t affect any of the others.

The second new feature is support for Console UWP apps. Think of traditional non-UWP command-line tools. These are apps that don’t have their own windows – instead they use the console window for both input and output. Up until now, you could build console apps, but not console UWP apps. With the latest release, you can build a console UWP app, and publish it to the Store. It will have an entry in the app list, and a primary tile you can pin to Start. So, you can launch it from Start if you want – however, you can also launch it via the command-line in a Cmd window or PowerShell window, and this is likely to be the more normal way to execute such an app. The app can use the console APIs and even traditional Win32 APIs such as printf or getchar.

Multi-instancing and console UWPs are important additions to the platform, and both types of app can also benefit from the additional file-system access that has been added in this release. In fact, any app can take advantage of this. This broader access comes in two forms.

The first is used if the app has an AppExecutionAlias (either a regular windowed UWP app or a console UWP app). In this case, the app is granted permissions to the file-system from the current working directory and below. That is, the user executes the app from a command-line, and they choose the location in the file-system from which to launch the app. The app will have file-system permissions from that point downwards.
The second file-system feature grants permissions to the entire file-system (or, strictly, grants the app the exact same permissions to the entire file-system as the user who is running the app). This is a very powerful feature – and for this reason, it is protected by a restricted capability. If you submit an app to the Store that declares this capability, you will need to supply additional descriptions of why your app needs this powerful feature, and how it intends to use it.

The latest API documentation can be found: