Création d’un pilote primitif

Utilisez un pilote primitif pour gérer et gérer des logiciels qui utilisent une installation basée sur INF, mais qui ne sont pas nécessairement liés à un périphérique matériel particulier.

Arrière-plan et avantages des pilotes primitifs

Avant Windows 10 version 1903, certains types de logiciels qui utilisaient une installation basée sur INF, mais qui n’étaient pas nécessairement liés à un périphérique matériel particulier n’étaient pas entièrement pris en charge par le système d’exploitation. Bien que ces éléments logiciels utilisaient des fichiers INF comme manifeste pour l’installation, le système d’exploitation n’était pas directement au courant de ce scénario et n’avait pas de prise en charge pour le gérer en mode natif.

Étant donné que ces logiciels n’étaient pas liés à un appareil matériel, ils s’installaient sur l’ensemble du système, quel que soit le matériel. Par conséquent, il n’était pas garanti que ces logiciels étaient correctement installés, désinstallés ou gérés lors de la mise à niveau du système d’exploitation.

À compter de Windows 10 version 1903, la plateforme Plug-and-Play gère et gère ce type de package logiciel en tant qu’entité de niveau supérieur, ce qui améliore la fiabilité et garantit le bon comportement de ces logiciels, en particulier pendant les scénarios de mise à niveau et de réinitialisation du système d’exploitation.

Les types de logiciels qui tirent parti de cette nouvelle prise en charge de la plateforme sont appelés pilotes primitifs. Les pilotes primitifs continuent d’utiliser l’installation basée sur INF et la plateforme sous-jacente utilise le magasin de pilotes pour effectuer le suivi de tous les fichiers pertinents.

La plateforme de Plug-and-Play sous-jacente installe, désinstalle et gère correctement l’état du pilote lors de la mise à niveau du système d’exploitation.

D’un point de vue conceptuel, ces INF sont gérés différemment. Auparavant, [DefaultInstall] (et souvent, [DefaultUninstall]) étaient traités par SetupAPI de manière similaire à un script, où l’INF était utilisé comme manifeste et SetupAPI exécutait les instructions dans les sections appropriées pour le compte de l’appelant.

L’annulation des modifications (pour effectuer une désinstallation) nécessite la spécification d’une section INF qui a exécuté l’ensemble d’instructions opposé à la section d’installation. Toutefois, l’utilisation des pilotes primitifs INF ne nécessite pas de section de désinstallation.

Les pilotes primitifs utilisent les mêmes API d’installation et de désinstallation que les pilotes de périphérique, où l’API de désinstallation effectue l’ensemble inverse d’opérations comme l’opération d’installation, et l’acte d’installation ou de désinstallation du package de pilotes traite ces sections.

Exigences INF pour accéder aux fonctionnalités de pilote primitif

• La section Version doit être complète, tout comme les pilotes PnP.

  • La directive Fournisseur doit être renseignée.

  • La directive Class doit être renseignée.

  • La directive ClassGuid doit être renseignée.

• Le pilote doit être conforme à DCH.

• Aucune section [Fabricant] ne peut être présente.

• Les sections [DefaultInstall] doivent être décorées d’architecture et aucune version non décorée ne peut être présente.

  • Correct : [DefaultInstall.NTamd64]

  • Incorrect : [DefaultInstall]

• [DefaultUninstall] peut ne pas être présent dans le fichier INF (voir Compatibilité héritée pour une exception).

Pilotes primitifs ciblant uniquement Windows 10 version 1903 et ultérieure

Les pilotes primitifs ciblés uniquement pour Windows 10 version 1903 et ultérieure doivent utiliser DiInstallDriver et DiUninstallDriver pour installer et désinstaller correctement leurs logiciels dans/à partir du magasin de pilotes.

Les pilotes doivent également utiliser Dirid 13 pour spécifier correctement le magasin de pilotes comme destination à installer.

Compatibilité héritée

Bien que [DefaultUninstall] soit interdit dans les pilotes primitifs, une exception est faite pour la compatibilité du système d’exploitation de niveau inférieur. Windows introduit une directive INF qui oblige une version du système d’exploitation qui prend en charge les pilotes primitifs à ignorer la section [DefaultUninstall]. Si votre package de pilotes doit prendre en charge les versions de système d’exploitation de niveau inférieur, incluez la syntaxe suivante pour vous assurer que la plateforme gère correctement ces cas :

[DefaultUninstall.NTamd64]
LegacyUninstall=1

Les sections [DefaultInstall] et [DefaultUninstall] doivent toujours être décorées d’architecture ; toutefois, en incluant la LegacyUninstall=1section , Windows ignore la section [DefaultUninstall] (dans Windows 10 version 1903 et ultérieure). Ce faisant, vous pouvez inclure cette section dans votre inf, où elle peut être utilisée de niveau inférieur avec une application d’installation/désinstallation héritée afin de désinstaller le package de pilote primitif.

À compter de Windows 10 version 1903, si vous passez une section [DefaultInstall] ou [DefaultUninstall] avec architecture à l’API InstallHInfSection dans setupapi.dll, le package de pilotes est vérifié pour déterminer s’il prend en charge les fonctionnalités primitives du pilote. S’il prend en charge la fonctionnalité de pilote primitif, plutôt que de traiter la section spécifiée de la manière héritée, l’INF est passé à DiInstallDriver ou DiUninstallDriver, le cas échéant. De cette façon, un seul programme d’installation peut utiliser des pilotes primitifs sur des versions de système d’exploitation compatibles et maintenir la prise en charge des versions de système d’exploitation précédentes.

Conversion à partir d’un inf du pilote de périphérique

La conversion d’un INF qui utilise [Manufacturer] en un qui utilise [DefaultInstall] nécessite des modifications mineures dans l’INF. Contrairement à une section [Fabricant], une section [DefaultInstall] est à la fois un point d’entrée et une section d’installation. Cela combine conceptuellement la section [Fabricant], [Modèles] et [DDInstall] en un seul.

L’inf suivant reçoit une erreur 1297 dans InfVerif , car il ne s’installe sur aucun matériel :

[Manufacturer]
%Company% = Driver, NTx86, NTamd64

[Driver.NTx86]
%DeviceDesc% = InstallSection_32,

[Driver.NTamd64]
%DeviceDesc% = InstallSection_64,

[InstallSection_64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg

[InstallSection_64.Services]
AddService = MyService,, MyService_Install

[InstallSection_32]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg

[InstallSection_32.Services]
AddService = MyService,, MyService_Install

L’INF ci-dessus peut être converti en inf basé sur [DefaultInstall], comme indiqué ci-dessous.

[DefaultInstall.NTamd64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg

[DefaultInstall.NTamd64.Services]
AddService = MyService,, MyService_Install

[DefaultInstall.NTx86]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg

[DefaultInstall.NTx86.Services]
AddService = MyService,, MyService_Install