Communicating with desktop apps (Win32), NT services, or drivers
This section describes how your Game Bar widget can communicate with your existing desktop app, windows service, or driver.
Desktop App
If you need your Game Bar widget to communicate with your existing desktop app there are some important issues to consider:
- How will your desktop app be acquired and installed?
- How will your desktop app get launched?
- What communication type will you use?
- Microsoft Store policy compliance.
All the above issues are simplified if you package your desktop app and include your Game Bar widget in the same package.
Package desktop applications. If your desktop app is packaged, you can choose to deliver it to clients through the Microsoft Store or another method. Further, your Game Bar widget can more easily launch your desktop app, and without the need for any store policy exceptions.
If you choose not to package your desktop app, you can still communicate with it from your Game Bar widget, but there will be the following limitations:
- You will need a Microsoft Store policy exception to link from your Game Bar widget to a download website for your desktop app.
- You will need a Microsoft Store policy exception to directly communicate with our desktop app.
- You will only be able to Protocol launch your desktop app unless you build a packaged full trust process (packaged desktop app) that does the launch of your real desktop app.
Inter-process communication options
Below are the inter-process communication (IPC) options available.
Named pipes
Your desktop app process can create a named pipe and allow access to your UWP app (Game Bar Widget). To allow access grant access to SECURITY_WORLD_SID_AUTHORITY as well as your desired SID (package SID or app capability SID). You can follow the Custom Capability RPC sample for how to construct a security identifier. Note that if you're using package SID, you don't need any of the logic used in the sample that converts the Custom Capability to its SID form. You'll just use the package SID directly.
Remote Procedure Calls (RPC)
Your desktop app process can create an RPC server that your UWP app (Game Bar Widget) can communicate with. To allow access, grant access to SECURITY_WORLD_SID_AUTHORITY as well as your desired SID (package SID or app capability SID). You can follow the Custom Capability RPC sample which demonstrates this. Note that if you're using package SID, you don't need any of the logic used in the sample that converts the Custom Capability to its SID form. You'll just use the package SID directly.
COM
For COM, your desktop app needs to be the server and your UWP Game Bar widget needs to be the client. How your desktop app registers the COM objects depends on whether your desktop app is part of the package or not.
Un-packaged desktop app
If you choose not to package your desktop app, you will need to register your COM objects in the Windows registry when your app is installed.
Packaged desktop app
For a packaged app you will register your COM objects via the appx manifest.
COM server OLE document support desktop bridge
Regardless of your desktop app being packaged or not, while your desktop app process is running, you will register the COM objects as being hosted by your server.
Registering a running EXE server
App Services
This option is only available if you package your desktop app.
How to create and consume app service
This API allows communication using a message pattern via a WinRT API. The API supports sending primitive types and binary blobs.
NT Service or Driver
To access an NT Service or Driver, you would follow the method for Hardware Support Apps (UWP apps that access NT Services and/or Drivers). The method for an NT Service is the same as the RPC method described above. For drivers, you will still use device IO control. This topic is discussed on MSDN and channel 9 in more detail.
Communication Channel Security
With many of the methods above, you will need to control access to the endpoint you create on your full trust side (desktop app, NT service, or driver). We recommend one of two ways of allowing access to your Game Bar widget:
- Package Identity
- App Capability. Typically, Custom Capability you own
App Capabilities and App Packages both have Security Identifier (SID) representation. Most communication endpoints can have security descriptors which grant access to apps based on these SIDs. In both cases, you need to open access to "Everyone" (SECURITY_WORLD_SID_AUTHORITY) in addition to the App Capability or App Package SID.
The simplest way to allow communication between your desktop app and UWP app (Game Bar Extension) will be to set the security identifier to allow the SID of your Package. However if you want your desktop app's communication endpoint to be protected against side-loaded apps, or more flexible in cases where you may want to change your app's identity (thus changing the Package SID), you can use a Custom Capability. There is more overhead to creating and managing a Custom Capability, so it is a tradeoff.
Package SID
The Package SID of your app is used to grant your app access to a communication endpoint. You can acquire your app's Package SID in one of two ways:
- If you've already associated your local app project with its corresponding app entry on partner.microsoft.com, visit partner.microsoft.com, go to your app's page, then Product management -> Product Identity. You'll see the SID below the Package Family Name (PFN).
- After your app is installed, navigate to
HKLM\Software\Microsoft\SecurityManager\CapAuthz\ApplicationEx\<your package full name>. Under this key you'll see a value calledPackageSid.
Custom Capability
To leverage a Custom Capability, you'll follow the steps that you would for an HSA app. Hardware Support App