Communication interprocessus (IPC)

Cette rubrique explique différentes façons d’effectuer une communication interprocessus (IPC) entre les applications plateforme Windows universelle (UWP) et les applications Win32.

Services d’application

Les services d’application permettent aux applications d’exposer les services qui acceptent et retournent des conteneurs des propriétés de primitives (ValueSet) en arrière-plan. Les objets enrichis peuvent être transmis s’ils sont sérialisés.

Les services d’application peuvent s’exécuter soit hors processus en tant que tâche en arrière-plan, soit en processus au sein de l’application en premier plan.

Il est préférable d’utiliser les services d’application pour partager de petites quantités de données lorsque la latence en quasi-temps réel n’est pas nécessaire.

COM

COM est un système distribué orienté objet qui permet de créer des composants logiciels binaires capables d’interagir et de communiquer. En tant que développeur, vous utilisez COM pour créer des composants logiciels réutilisables et des couches d’automatisation pour une application. Les composants COM peuvent être en ou hors processus, et communiquer via un modèle client et serveur. Les serveurs COM hors processus sont utilisés depuis longtemps comme moyen de communication entre objets.

Les applications empaquetées avec la fonctionnalité runFullTrust peuvent inscrire des serveurs COM hors processus pour l’IPC via le manifeste du package. Il s’agit de COM empaqueté.

FileSystem

BroadFileSystemAccess

Les applications empaquetées peuvent effectuer une IPC à l’aide du système de fichiers étendu en déclarant la fonctionnalité restreinte broadFileSystemAccess. Cette fonctionnalité accorde aux API Windows.Stockage et aux API Win32 xxxFromApp l’accès au système de fichiers étendu.

Par défaut, l’IPC via le système de fichiers pour les applications empaquetées est limitée aux autres mécanismes décrits dans cette section.

PublisherCacheFolder

PublisherCacheFolder permet aux applications empaquetées de déclarer des dossiers dans leur manifeste qui peuvent être partagés avec d’autres packages par le même éditeur.

Le dossier de stockage partagé présente les exigences et restrictions suivantes :

• Les données du dossier de stockage partagé ne sont pas sauvegardées ou itinérantes.
• L’utilisateur peut effacer le contenu du dossier de stockage partagé.
• Vous ne pouvez pas utiliser le dossier de stockage partagé pour partager des données entre des applications provenant de différents éditeurs.
• Vous ne pouvez pas utiliser le dossier de stockage partagé pour partager des données entre différents utilisateurs.
• Le dossier de stockage partagé n’a pas de gestion des versions.

Si vous publiez plusieurs applications et que vous recherchez un mécanisme simple pour partager des données entre elles, PublisherCacheFolder est une option simple basée sur le système de fichiers.

SharedAccessStorageManager

SharedAccessStorageManager est utilisé conjointement avec les services d’application, les activations de protocole (par exemple, LaunchUriForResultsAsync), etc., pour partager des StockageFiles via des jetons.

FullTrustProcessLauncher

Avec la fonctionnalité runFullTrust, les applications empaquetées peuvent lancer des processus de confiance totale au sein du même package.

Pour les scénarios où les restrictions de package sont un fardeau ou que les options IPC manquent, une application peut utiliser un processus de confiance totale en tant que proxy pour interagir avec le système, puis l’IPC avec le processus de confiance totale lui-même via les services d’application ou un autre mécanisme IPC bien pris en charge.

LaunchUriForResultsAsync

LaunchUriForResultsAsync est utilisé pour l’échange de données simple (ValueSet) avec d’autres applications empaquetées qui implémentent le contrat d’activation ProtocolForResults. Contrairement aux services d’application, qui s’exécutent généralement en arrière-plan, l’application cible est lancée au premier plan.

Les fichiers peuvent être partagés en transférant les jetons SharedStorageAccessManager à l’application via ValueSet.

Bouclage

La bouclage est le processus de communication avec un serveur réseau à l’écoute sur localhost (l’adresse de bouclage).

Pour maintenir la sécurité et l’isolation réseau, les connexions de bouclage pour l’IPC sont bloquées par défaut pour les applications empaquetées. Vous pouvez activer les connexions de bouclage entre une application empaquetée approuvée à l’aide de fonctionnalités et de propriétés de manifeste.

• Toutes les applications empaquetées participant à des connexions de bouclage doivent déclarer la fonctionnalité privateNetworkClientServer dans leurs manifestes de package.
• Deux applications empaquetées peuvent communiquer via le bouclage en déclarant LoopbackAccessRules dans leurs manifestes de package.
  • Chaque application doit répertorier l’autre dans son LoopbackAccessRules. Le client déclare une règle « out » pour le serveur, et le serveur déclare des règles « in » pour ses clients pris en charge.

Les applications et services non empaquetés n’ont pas d’identité de package. Ils ne peuvent donc pas être déclarés dans LoopbackAccessRules. Vous pouvez configurer une application empaquetée pour vous connecter via un bouclage avec des applications et des services non empaquetés via CheckNetIsolation.exe, mais cela n’est possible que pour les scénarios de chargement indépendant ou de débogage où vous avez un accès local à l’ordinateur et que vous disposez de privilèges administratifs.

• Toutes les applications empaquetées participant à des connexions de bouclage doivent déclarer la fonctionnalité privateNetworkClientServer dans leurs manifestes de package.
• Si une application empaquetée se connecte à une application ou un service non empaqueté, exécutez CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> pour ajouter une exemption de bouclage pour l’application empaquetée.
• Si une application ou un service non empaqueté se connecte à une application empaquetée, exécutez CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> pour permettre à l’application empaquetée de recevoir des connexions de bouclage entrantes.
  • CheckNetIsolation.exe doit s’exécuter en continu pendant que l’application empaquetée écoute les connexions.
  • L’indicateur -is a été introduit dans Windows 10, version 1607 (10.0 ; Build 14393).

CheckNetIsolation.exe est également utile pour le débogage des problèmes d’isolement réseau.

Canaux

Les canaux permettent une communication simple entre un serveur de canaux et un ou plusieurs clients de canaux.

Les canaux anonymes et les canaux nommés sont pris en charge avec les contraintes suivantes :

• Par défaut, les canaux nommés dans les applications empaquetées sont pris en charge uniquement entre les processus du même package, sauf si un processus est de confiance totale.
• Les canaux nommés peuvent être partagés entre les packages en suivant les instructions pour le partage d’objets nommés.
• Les canaux nommés (dans les applications empaquetées et non empaquetées) doivent utiliser la syntaxe \\.\pipe\LOCAL\ du nom du canal.

Registre

L’utilisation du Registre pour l’IPC est généralement déconseillée, mais elle est prise en charge pour le code existant. Les applications empaquetées peuvent accéder uniquement aux clés de Registre auxquelles elles sont autorisées.

En règle générale, les applications de bureau empaquetées (voir Génération d’un package MSIX à partir de votre code) tirent parti de la virtualisation du Registre afin que les écritures de registre globales soient contenues dans une ruche privée dans le package MSIX. Cela permet la compatibilité du code source tout en réduisant l’impact global du registre et peut être utilisée pour l’IPC entre les processus du même package. Si vous devez utiliser le Registre, ce modèle est préféré à la manipulation du registre global.

RPC

RPC peut être utilisé pour connecter une application empaquetée à un point de terminaison RPC Win32, à condition que l’application empaquetée dispose des fonctionnalités appropriées pour correspondre aux listes de contrôle d’accès sur le point de terminaison RPC.

Les fonctionnalités personnalisées permettent aux fabricants d’ordinateurs (OEM) et aux fabricants de matériel (IHV) de définir des fonctionnalités arbitraires, de mettre à la liste de contrôle d’accès leurs points de terminaison RPC avec eux, puis d’accorder ces fonctionnalités aux applications clientes autorisées. Pour obtenir un exemple d’application complet, consultez l’exemple CustomCapability.

Les points de terminaison RPC peuvent également être mis en liste ACL vers des applications empaquetées spécifiques pour limiter l’accès au point de terminaison à ces applications, sans nécessiter la surcharge de gestion des fonctionnalités personnalisées. Vous pouvez utiliser l’API DeriveAppContainerSidFromAppContainerName pour dériver un SID à partir d’un nom de famille de package, puis mettre en liste ACL le point de terminaison RPC avec le SID, comme indiqué dans l’exemple CustomCapability.

Mémoire partagée

Le mappage de fichiers peut être utilisé pour partager un fichier ou une mémoire entre deux processus ou plus avec les contraintes suivantes :

• Par défaut, les mappages de fichiers dans les applications empaquetées sont pris en charge uniquement entre les processus au sein du même package, sauf si un processus est de confiance totale.
• Les mappages de fichiers peuvent être partagés entre les packages en suivant les instructions pour le partage d’objets nommés.

La mémoire partagée est recommandée pour partager et manipuler efficacement de grandes quantités de données.