Condividi tramite

Creazione di un nuovo driver primitivo

  • Articolo

Usare un driver primitivo per gestire e gestire il software che usa l'installazione basata su INF, ma non necessariamente legato a un determinato dispositivo hardware.

Background e vantaggi dei driver primitivi

Prima di Windows 10 versione 1903, alcuni tipi di software che usavano l'installazione basata su INF, ma non erano necessariamente legati a un particolare dispositivo hardware non erano completamente supportati dal sistema operativo. Anche se questi componenti software usavano file INF come manifesto per l'installazione, il sistema operativo non era direttamente a conoscenza di questo scenario e non aveva il supporto per gestirlo in modo nativo.

Poiché questi componenti software non erano collegati a un dispositivo hardware, si installavano nell'intero sistema indipendentemente dall'hardware. Di conseguenza, non c'era alcuna garanzia che queste parti di software siano state installate, disinstallate o gestite correttamente durante l'aggiornamento del sistema operativo.

A partire da Windows 10 versione 1903, la piattaforma Plug and Play gestisce e gestisce questo tipo di pacchetto software come entità di primo livello, con conseguente miglioramento dell'affidabilità e un comportamento corretto di tale software, in particolare durante gli scenari di aggiornamento e reimpostazione del sistema operativo.

I tipi di software che sfruttano questo nuovo supporto della piattaforma sono denominati driver primitivi. I driver primitivi continuano a usare l'installazione basata su INF e la piattaforma sottostante usa l'archivio driver per tenere traccia di tutti i file pertinenti.

La piattaforma Plug and Play sottostante installa, disinstalla e mantiene lo stato del driver nell'aggiornamento del sistema operativo.

Concettualmente, questi infs vengono gestiti in modo diverso. [DefaultInstall] (e spesso, [DefaultUninstall]) sono stati elaborati da SetupAPI in modo simile a uno script, in cui l'INF è stato usato come manifesto e SetupAPI ha eseguito le istruzioni nelle sezioni pertinenti per conto del chiamante.

Annullamento delle modifiche (per eseguire una disinstallazione) richiesta specificando una sezione INF che ha eseguito il set opposto di istruzioni come sezione di installazione. I driver primitivi basati su INF, tuttavia, non richiedono una sezione di disinstallazione.

I driver primitivi usano le stesse API di installazione e disinstallazione dei driver di dispositivo, in cui l'API di disinstallazione eseguirà il set inverso di operazioni durante l'operazione di installazione e l'azione di installazione o disinstallazione del pacchetto driver elaborerà tali sezioni.

Requisiti INF per accedere alle funzionalità dei driver primitivi

  • La sezione Version deve essere completa, proprio come i driver PnP.

    • La direttiva Provider deve essere compilata.

    • La direttiva Class deve essere compilata.

    • La direttiva ClassGuid deve essere compilata.

  • Il driver deve essere conforme a DCH.

  • Non è possibile che sia presente alcuna sezione [Manufacturer].

  • Le sezioni [DefaultInstall] devono essere decorate dall'architettura e non è possibile che siano presenti versioni non dichiarate.

    • Risposta esatta: [DefaultInstall.NTamd64]

    • Risposta errata: [DefaultInstall]

  • [DefaultUninstall] potrebbe non essere presente in INF (vedere compatibilità legacy per un'eccezione).

Driver primitivi destinati solo Windows 10 versione 1903 e successive

I driver primitivi destinati solo a Windows 10 versione 1903 e successive devono usare DiInstallDriver e DiUninstallDriver per installare e disinstallare correttamente il software dall'archivio driver.

I driver devono anche usare Dirid 13 per specificare correttamente l'archivio driver come destinazione desiderata da installare.

Compatibilità legacy

Anche se [DefaultUninstall] è vietato nei driver primitivi, viene fatta un'eccezione per motivi di compatibilità del sistema operativo di livello inferiore. Windows introduce una direttiva INF che fa sì che una versione del sistema operativo che supporti i driver primitivi ignori la sezione [DefaultUninstall]. Se il pacchetto driver deve supportare le versioni del sistema operativo di livello inferiore, includere la sintassi seguente per garantire che la piattaforma gestisca in modo appropriato tali casi:

[DefaultUninstall.NTamd64]
LegacyUninstall=1

Le sezioni [DefaultInstall] e [DefaultUninstall] devono essere ancora decorate per l'architettura; tuttavia, includendo , LegacyUninstall=1Windows ignora la sezione [DefaultUninstall] (in Windows 10 versione 1903 e successive). In questo modo, è possibile includere tale sezione in INF, in cui può essere usato di livello inferiore con un'applicazione di installazione/disinstallazione legacy per disinstallare il pacchetto driver primitivo.

A partire da Windows 10 versione 1903, se si passa una sezione [DefaultInstall] o [DefaultUninstall] all'API InstallHInfSection in setupapi.dll, il pacchetto driver verrà controllato per determinare se supporta la funzionalità del driver primitiva. Se supporta la funzionalità del driver primitivo, anziché elaborare la sezione specificata nel modo legacy, l'INF viene passato a DiInstallDriver o DiUninstallDriver, a seconda delle esigenze. In questo modo, un singolo programma di installazione può usare i driver primitivi nelle versioni compatibili del sistema operativo e mantenere il supporto per le versioni precedenti del sistema operativo.

Conversione da un driver di dispositivo INF

La conversione di un INF che usa [Manufacturer] in una che usa [DefaultInstall] richiede modifiche secondarie all'INF. A differenza di una sezione [Manufacturer], una sezione [DefaultInstall] è sia un punto di ingresso che una sezione di installazione. Questo combina concettualmente la sezione [Manufacturer], [Models] e [DDInstall] in una.

L'INF seguente riceverà un errore 1297 in InfVerif perché non viene installato in alcun 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

L'INF precedente può essere convertito in un INF basato su [DefaultInstall], come illustrato di seguito.

[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