Criando um novo driver primitivo

Use um driver primitivo para manipular e gerenciar software que usa instalação baseada em INF, mas não está necessariamente vinculado a um dispositivo de hardware específico.

Antecedentes e benefícios dos drivers primitivos

Antes do Windows 10 versão 1903, certos tipos de software que usavam instalação baseada em INF, mas não estavam necessariamente vinculados a um dispositivo de hardware específico, não eram totalmente suportados pelo sistema operacional. Embora esses softwares usassem arquivos INF como um manifesto para instalação, o sistema operacional não estava diretamente ciente desse cenário e não tinha suporte para lidar com ele nativamente.

Como esses softwares não estavam vinculados a um dispositivo de hardware, eles seriam instalados em todo o sistema, independentemente do hardware. Como resultado, não havia garantia de que esses softwares fossem instalados, desinstalados ou manipulados corretamente na atualização do sistema operacional.

Começando com o Windows 10 versão 1903, a plataforma Plug and Play lida e gerencia esse tipo de pacote de software como uma entidade de nível superior, resultando em maior confiabilidade e garantia de comportamento adequado de tal software, especialmente durante cenários de atualização e redefinição do sistema operacional.

Os tipos de software que aproveitam esse novo suporte de plataforma são chamados de drivers primitivos. Os drivers primitivos continuam a usar a instalação baseada em INF e a plataforma subjacente faz uso do Driver Store para manter o controle de todos os arquivos relevantes.

A plataforma Plug and Play subjacente instala, desinstala e mantém o estado do controlador na atualização do sistema operativo.

Conceitualmente, esses INFs são gerenciados de forma diferente. Anteriormente, [DefaultInstall] (e muitas vezes, [DefaultUninstall]) eram processados pela SetupAPI de forma semelhante a um script, onde o INF era usado como um manifesto e a SetupAPI executava as instruções nas seções relevantes em nome do chamador.

Desfazer as alterações (para executar uma desinstalação) exigia especificar uma seção INF que executasse o conjunto oposto de instruções como a seção de instalação. Os drivers primitivos que utilizam INF, no entanto, não exigem uma seção de desinstalação.

Os drivers primitivos usam as mesmas APIs de instalação e desinstalação que os drivers de dispositivo, onde a API de desinstalação executará o conjunto inverso de operações como a operação de instalação e o ato de instalar ou desinstalar o pacote de driver processará essas seções.

Requisitos INF para acessar a funcionalidade primitiva do driver

• A seção Versão deve estar completa, tal como acontece com os drivers PnP.

  • A diretiva Provider deve ser preenchida.

  • A diretiva Class deve ser preenchida.

  • A diretiva ClassGuid deve ser preenchida.

• O motorista deve estar em conformidade com DCH.

• Nenhuma seção [Fabricante] pode estar presente.

• As seções [DefaultInstall] devem ser decoradas com arquitetura e nenhuma versão não decorada pode estar presente.

  • Correto: [DefaultInstall.NTamd64]

  • Incorreto: [DefaultInstall]

• [DefaultUninstall] pode não estar presente no INF (consulte compatibilidade herdada para uma exceção).

Drivers primitivos destinados apenas ao Windows 10 versão 1903 e posterior

Drivers primitivos direcionados apenas para o Windows 10 versão 1903 e posterior devem usar DiInstallDriver e DiUninstallDriver para instalar e desinstalar corretamente seu software em/do armazenamento de drivers.

Os drivers também devem usar Dirid 13 para especificar corretamente o Driver Store como o destino desejado para a instalação.

Compatibilidade herdada

Enquanto [DefaultUninstall] é proibido em Primitive Drivers, uma exceção é feita para a compatibilidade do sistema operacional de nível inferior. O Windows introduz uma diretiva INF que faz com que uma versão do SO que suporta controladores primitivos ignore a secção [DefaultUninstall]. Se o seu pacote de driver precisar suportar versões de SO de nível inferior, inclua a seguinte sintaxe para garantir que a plataforma lidará adequadamente com esses casos:

[DefaultUninstall.NTamd64]
LegacyUninstall=1

As seções [DefaultInstall] e [DefaultUninstall] ainda devem ser decoradas com informações de arquitetura; no entanto, ao incluir o LegacyUninstall=1, o Windows ignora a seção [DefaultUninstall] (no Windows 10, versão 1903 e posterior). Ao fazer isso, você pode incluir essa seção em seu INF, onde pode ser usado de nível inferior com um aplicativo de instalação/desinstalação herdado para desinstalar o pacote de driver primitivo.

A partir do Windows 10 versão 1903, se passar uma seção decorada com arquitetura [DefaultInstall] ou [DefaultUninstall] para a API InstallHInfSection em setupapi.dll, o pacote de driver será verificado para se determinar se suporta a funcionalidade básica do driver. Se ele oferecer suporte à funcionalidade de driver primitivo, em vez de processar a seção especificada da maneira herdada, o INF será passado para DiInstallDriver ou DiUninstallDriver, conforme apropriado. Desta forma, um único instalador pode fazer uso de drivers primitivos em versões compatíveis do sistema operacional e manter o suporte para versões anteriores do sistema operacional.

Convertendo a partir de um driver de dispositivo INF

A conversão de um INF que usa [Manufacturer] em um que usa [DefaultInstall] requer pequenas alterações no INF. Ao contrário de uma seção [Fabricante], uma seção [DefaultInstall] é um ponto de entrada e uma seção de instalação. Isso combina conceitualmente a seção [Fabricante], [Modelos] e [DDInstall] em uma só.

O seguinte INF receberá um erro 1297 no InfVerif porque ele não é instalado em nenhum hardware:

[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

O INF acima pode ser convertido em um INF baseado em [DefaultInstall], conforme mostrado abaixo.

[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