Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo descreve como o exemplo de driver DCHU aplica os princípios de design DCH. Você pode usá-lo como um modelo para aplicar os princípios de design DCH ao seu próprio pacote de driver.
Se pretender uma cópia local do repositório de exemplo, clone a partir de Windows-driver-samples.
Algumas partes do exemplo podem usar diretivas e APIs que só estão disponíveis em determinadas versões do Windows 10 e superiores. Consulte Instalação de dispositivos e drivers para ver em que versão do sistema operativo uma determinada diretiva é suportada.
Pré-requisitos
Antes de ler esta seção, você deve se familiarizar com os Princípios de Design DCH.
Visão geral
O exemplo fornece cenários em que dois parceiros de hardware, a Contoso (um integrador de sistemas ou OEM) e a Fabrikam (um fabricante de dispositivos ou IHV) estão a trabalhar juntos para criar um driver compatível com DCH para um dispositivo no próximo sistema da Contoso. O dispositivo em questão é um kit de aprendizagem OSR USB FX2. No passado, a Fabrikam escrevia um pacote de driver herdado que era personalizado para uma linha de produtos específica da Contoso e, em seguida, entregava-o ao OEM para lidar com a manutenção. Esse processo resultou em uma sobrecarga de manutenção significativa, então a Fabrikam decidiu refatorar o código e criar um pacote de driver compatível com DCH.
Use seções/diretivas declarativas e isole adequadamente o INF
Primeiro, a Fabrikam analisa a lista de seções e diretivas INF que são inválidas em pacotes de driver compatíveis com DCH. Durante este exercício, a Fabrikam observa que está a utilizar muitas dessas seções e diretivas no seu pacote de controlador.
Seu driver INF registra um coinstalador que aplica configurações e arquivos dependentes da plataforma. O pacote do driver é maior do que deveria ser, e é mais difícil fazer a manutenção do driver quando um bug afeta apenas um subconjunto dos sistemas OEM que enviam o driver. A maioria das modificações específicas do OEM está relacionada à marca. Portanto, a Fabrikam precisa atualizar o pacote de driver toda vez que adiciona um OEM ou quando um pequeno problema afeta um subconjunto de sistemas OEM.
A Fabrikam remove as seções e diretivas não declarativas e usa a ferramenta InfVerif para verificar se o arquivo INF do novo pacote de driver segue o requisito INF declarativo.
Usar INFs de extensão para criar componentes em um pacote de driver
Em seguida, a Fabrikam separa personalizações específicas para parceiros OEM (como a Contoso) do pacote de driver base em uma extensão INF.
O trecho a seguir, atualizado de [osrfx2_DCHU_extension.inx], especifica a Extension classe e identifica a Contoso como o provedor, tendo em conta que possuem o pacote de drivers de extensão.
[Version]
...
Class = Extension
ClassGuid = {e2f84ce7-8efa-411c-aa69-97454ca4cb57}
Provider = Contoso
ExtensionId = {zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz} ; replace with your own GUID
...
Em [osrfx2_DCHU_base.inx], a Fabrikam especifica as seguintes entradas:
[OsrFx2_AddReg]
HKR, OSR, "OperatingMode",, "Default" ; FLG_ADDREG_TYPE_SZ
HKR, OSR, "OperatingParams",, "None" ; FLG_ADDREG_TYPE_SZ
Em [osrfx2_DCHU_extension.inx], a Contoso substitui o valor do Registro OperatingParams definido pela base e adiciona OperatingExceptions:
[OsrFx2Extension_AddReg]
HKR, OSR, "OperatingParams",, "-Extended"
HKR, OSR, "OperatingExceptions",, "x86"
O sistema sempre processa extensões após o INF base, mas sem ordem definida. Se você atualizar um INF base para uma versão mais recente, o sistema ainda reaplica as extensões depois de instalar o novo INF base.
Instalar um serviço a partir de um arquivo INF
A Fabrikam usa um serviço Win32 para controlar os LEDs na placa OSR. Eles vêem este componente como parte da funcionalidade principal do dispositivo, por isso o incluem como parte de sua base INF ([osrfx2_DCHU_base.inx]). Este serviço de modo de usuário (usersvc) pode ser adicionado e iniciado declarativamente especificando a diretiva AddService no arquivo INF:
[OsrFx2_Install.NT]
CopyFiles = OsrFx2_CopyFiles
[OsrFx2_Install.NT.Services]
AddService = WUDFRd, 0x000001fa, WUDFRD_ServiceInstall ; Flag 0x2 sets this as the service for the device
AddService = osrfx2_DCHU_usersvc,, UserSvc_ServiceInstall
[UserSvc_ServiceInstall]
DisplayName = %UserSvcDisplayName%
ServiceType = 0x10 ; SERVICE_WIN32_OWN_PROCESS
StartType = 0x3 ; SERVICE_DEMAND_START
ErrorControl = 0x1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %13%\osrfx2_DCHU_usersvc.exe
AddTrigger = UserSvc_AddTrigger ; AddTrigger syntax is only available in Windows 10 Version 2004 and above
[UserSvc_AddTrigger]
TriggerType = 1 ; SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL
Action = 1 ; SERVICE_TRIGGER_ACTION_SERVICE_START
SubType = %GUID_DEVINTERFACE_OSRFX2% ; Interface GUID
DataItem = 2, "USB\VID_0547&PID_1002" ; SERVICE_TRIGGER_DATA_TYPE_STRING
[OsrFx2_CopyFiles]
osrfx2_DCHU_base.dll
osrfx2_DCHU_filter.dll
osrfx2_DCHU_usersvc.exe
Você também pode instalar esse serviço em um componente ou extensão INF, dependendo do cenário.
Utilizar um componente para instalar software antigo a partir de um pacote de controladores
A Fabrikam tem um arquivo osrfx2_DCHU_componentsoftware.exe executável que eles instalaram anteriormente usando um coinstalador. Este software herdado exibe as chaves de registro definidas pela placa e exigidas pelo OEM. Este executável é um aplicativo baseado em GUI que só é executado no Windows para edições de área de trabalho. Para instalá-lo, a Fabrikam cria um pacote de driver de componente separado e o adiciona em sua extensão INF.
O seguinte trecho de [osrfx2_DCHU_extension.inx] usa a diretiva AddComponent para criar um dispositivo filho virtual:
[OsrFx2Extension_Install.NT.Components]
AddComponent = osrfx2_DCHU_component,,OsrFx2Extension_ComponentInstall
[OsrFx2Extension_ComponentInstall]
ComponentIds=VID_045e&PID_94ab
Em seguida, no componente INF [osrfx2_DCHU_component.inx], a Fabrikam especifica a diretiva AddSoftware para instalar o executável opcional:
[OsrFx2Component_Install.NT.Software]
AddSoftware = osrfx2_DCHU_componentsoftware,, OsrFx2Component_SoftwareInstall
[OsrFx2Component_SoftwareInstall]
SoftwareType = 1
SoftwareBinary = osrfx2_DCHU_componentsoftware.exe
SoftwareArguments = <<DeviceInstanceId>>
SoftwareVersion = 1.0.0.0
[OsrFx2Component_CopyFiles]
osrfx2_DCHU_componentsoftware.exe
O código-fonte para o aplicativo Win32 está incluído no exemplo.
O pacote de driver de componente só é distribuído em SKUs de área de trabalho devido à segmentação definida no painel do Centro de Desenvolvimento de Hardware do Windows. Para obter mais informações, consulte Publicar um driver no Windows Update.
Permitir comunicação com um aplicativo de suporte de hardware
A Fabrikam gostaria de fornecer um aplicativo complementar baseado em GUI como parte do pacote de Driver do Windows. Como os aplicativos complementares baseados em Win32 não podem fazer parte de um pacote de Driver do Windows, a Fabrikam porta seu aplicativo Win32 para a Plataforma Universal do Windows (UWP) e emparelha o aplicativo com o dispositivo.
O trecho a seguir mostra como o pacote de driver base adiciona um recurso personalizado à instância da interface do osrfx2_DCHU_base/device.c dispositivo:
WDF_DEVICE_INTERFACE_PROPERTY_DATA PropertyData = { 0 };
static const wchar_t customCapabilities[] = L"CompanyName.yourCustomCapabilityName_YourStorePubId\0";
WDF_DEVICE_INTERFACE_PROPERTY_DATA_INIT(&PropertyData,
&GUID_DEVINTERFACE_OSRUSBFX2,
&DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities);
Status = WdfDeviceAssignInterfaceProperty(Device,
&PropertyData,
DEVPROP_TYPE_STRING_LIST,
sizeof(customCapabilities),
(PVOID)customCapabilities);
O novo aplicativo (não incluído no exemplo) é seguro e você pode atualizá-lo facilmente na Microsoft Store. Com o aplicativo UWP pronto, a Contoso usa o DISM - Gerenciamento e Manutenção de Imagens de Implantação para pré-instalar o aplicativo em imagens da edição Desktop do Windows.
Acoplamento estreito de vários arquivos INF
Idealmente, deve haver contratos de controle de versão fortes entre base, extensões e componentes. Há vantagens de manutenção em ter esses três pacotes atendidos de forma independente (o cenário de "acoplamento flexível"), mas há cenários em que eles precisam ser agrupados em um único pacote de driver ("firmemente acoplado") devido a contratos de controle de versão insatisfatórios. O exemplo abrange ambos os cenários:
DCHU_Sample\osrfx2_DCHU_extension_tight
Quando a extensão e o componente estão no mesmo pacote de driver ("firmemente acoplado"), a extensão INF especifica a diretiva CopyINF para que o sistema copie o componente INF para o sistema de destino. DCHU_Sample\osrfx2_DCHU_extension_tight\osrfx2_DCHU_extension\osrfx2_DCHU_extension.inx demonstra esta técnica:
[OsrFx2Extension_Install.NT]
CopyInf=osrfx2_DCHU_component.inf
Você também pode usar esta diretiva para coordenar a instalação de arquivos INF em dispositivos multifuncionais. Para obter mais informações, consulte Copiando arquivos INF.
Observação
Embora um driver base possa incorporar uma extensão (e direcionar o driver base na etiqueta de envio), não é possível publicar uma extensão que esteja agrupada com outro driver no ID de hardware da extensão.
Executar a partir do repositório de drivers
Para facilitar a atualização do driver, a Fabrikam especifica o armazenamento de driver como o destino para copiar os arquivos de driver usando o dirid 13 sempre que possível. Usar um valor de diretório de destino de 13 pode resultar em estabilidade melhorada durante o processo de atualização do driver. Aqui está um exemplo de [osrfx2_DCHU_base.inx]:
[DestinationDirs]
OsrFx2_CopyFiles = 13 ; copy to driver store
Para obter mais informações sobre como localizar e carregar arquivos dinamicamente do repositório de driver, consulte o artigo Executar do repositório de driver .
Resumo
O diagrama a seguir mostra os pacotes de driver que a Fabrikam e a Contoso criaram para seu driver compatível com DCH. No exemplo de acoplamento flexível, eles fazem três envios separados no painel do Centro de Desenvolvimento de Hardware do Windows: um para a base, um para a extensão e um para o componente. No exemplo estreitamente acoplado, eles fazem dois envios: base e extensão ou componente.
O ficheiro INF do componente corresponde ao ID de hardware do componente, enquanto a base e as extensões correspondem ao ID de hardware da placa.