Criando um novo driver primitivo
Use um driver primitivo para manipular e gerenciar softwares que usam a instalação baseada em INF, mas não estão necessariamente vinculados a um dispositivo de hardware específico.
Plano de fundo e benefícios de drivers primitivos
Antes de Windows 10 versão 1903, determinados tipos de software que usavam a instalação baseada em INF, mas não necessariamente estavam vinculados a um dispositivo de hardware específico, não eram totalmente compatíveis com o sistema operacional. Embora essas partes de software tenham usado 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 essas partes de software não estavam vinculadas a um dispositivo de hardware, elas seriam instaladas em todo o sistema, independentemente do hardware. Como resultado, não havia garantia de que essas partes de software foram instaladas, desinstaladas ou tratadas corretamente na atualização do sistema operacional.
A partir do Windows 10 versão 1903, a plataforma Plug and Play manipula e gerencia esse tipo de pacote de software como uma entidade de nível superior, resultando em maior confiabilidade e comportamento adequado garantido desse 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 usa o Repositório de Driver para acompanhar todos os arquivos relevantes.
A plataforma de Plug and Play subjacente instala, desinstala e mantém o estado do driver na atualização do sistema operacional.
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, em que 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) exigiu a especificação de uma seção INF que executasse o conjunto oposto de instruções como a seção de instalação. No entanto, os drivers primitivos que aproveitam o INF 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, em que a API de desinstalação executará o conjunto inverso de operações que a operação de instalação e o ato de instalar ou desinstalar o pacote de driver processará essas seções.
Requisitos do INF para acessar a funcionalidade do driver primitivo
A seção Versão deve ser concluída, assim como drivers PnP.
A diretiva Provider deve ser preenchida.
A diretiva Class deve ser preenchida.
A diretiva ClassGuid deve ser preenchida.
O driver deve ser compatível com DCH.
Nenhuma seção [Fabricante] pode estar presente.
As seções [DefaultInstall] devem ser decoradas pela 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 direcionados apenas Windows 10 versão 1903 e posterior
Os drivers primitivos direcionados apenas para Windows 10 versão 1903 e posterior devem usar DiInstallDriver e DiUninstallDriver para instalar e desinstalar corretamente o software no repositório de driver.
Os drivers também devem usar o Dirid 13 para especificar corretamente o Repositório de Driver como o destino desejado a ser instalado.
Compatibilidade herdada
Embora [DefaultUninstall] seja proibido em Drivers Primitivos, uma exceção é feita para fins de compatibilidade do sistema operacional de nível inferior. O Windows apresenta uma diretiva INF que faz com que uma versão do sistema operacional que dá suporte a Drivers Primitivos ignore a seção [DefaultUninstall]. Se o pacote de driver precisar dar suporte a versões de sistema operacional 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 pela arquitetura; no entanto, incluindo o , o LegacyUninstall=1
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 ela pode ser usada no nível inferior com um aplicativo de instalação/desinstalação herdado para desinstalar o pacote de driver primitivo.
Começando com Windows 10 versão 1903, se você passar uma seção decorada por arquitetura [DefaultInstall] ou [DefaultUninstall] na API InstallHInfSection no setupapi.dll, o pacote de driver será verificado para determinar se ele dá suporte à funcionalidade do driver primitivo. Se ele der 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. Dessa forma, um único instalador pode usar drivers primitivos em versões compatíveis do sistema operacional e manter o suporte para versões anteriores do sistema operacional.
Convertendo de um INF do driver de dispositivo
Converter um INF que usa [Fabricante] 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.
O INF a seguir 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