- O WDDM move o gerenciamento da GPU para Dxgkrnl e miniportas, longe do Win32k.
- O ReactOS está começando agora Drivers O WDDM exibe e negocia modos via VidPn e CDD.
- Uma pilha XDDM sólida continua sendo essencial para avançar em WDDM e DWM.
- O ReactOS 0.4.15 melhora drivers, LiveUSB, desempenho e avança para o amd64.
O ReactOS está em desenvolvimento há tanto tempo que muitos dos colaboradores atuais nem eram nascidos quando ele começou, mas seu objetivo permanece o mesmo: entregar uma experiência ABI compatível com Windows capaz de executar softwares e drivers projetados para o sistema Microsoft. Nos últimos anos, uma das frentes mais ambiciosas do projeto tem sido alcançar o suporte para Hardwares.
Esse processo levou a um objetivo fundamental: aproximar-se da arquitetura moderna de drivers gráficos do Windows. Estamos falando do WDDM, o modelo que substituiu o XDDM desde a era do Vista. Dentro do ecossistema ReactOS, Explorar o WDDM significa entender como o gerenciamento da GPU mudou, quais partes do sistema foram reestruturadas e por que não basta simplesmente “ativar” um driver para fazer tudo funcionar como no Windows.
O que é WDDM e por que ele faz a diferença
O WDDM, o Windows Display Driver Model, introduziu uma profunda reformulação da pilha gráfica: moveu o controle da GPU de componentes como Win32k para um núcleo dedicado (Dxgkrnl.sys) que se comunica com as miniportas do fabricante. Cada revisão (1.0, 1.1, 1.2 e posteriores) define quais interfaces o sistema oferece e como elas são implementadas, um conceito distinto dos níveis de recursos do Direct3D vistos no DxDiag.
Essa arquitetura mais modular e exigente vai além do que o XDDM oferecia. No WDDM, Dxgkrnl atua como orquestrador, e o driver do fornecedor facilita pontos de entrada e contratos claros. Essa separação permite melhorias como memória de vídeo virtualizada, um agendador de GPU e, em geral, maior estabilidade ao mover parte da lógica para o modo de usuário.
Durante anos, a documentação prática para o desenvolvimento aprofundado de drivers de vídeo foi escassa para ambas as arquiteturas, o que dificultou o progresso. Com a maturidade dos drivers de GPU abertos, a comunidade ganhou referências reais para entender como os ICDs OpenGL se comportam, o suporte Vulkan e as transições de modelo.
O que aconteceu com o XDDM? Compatibilidade, sobras e o ponto de ruptura
Desde o Windows 8, o sistema requer que o driver da GPU seja WDDM; no entanto, O XDDM não desapareceu completamenteO Windows Vista e o Windows 7 permitiam que drivers XDDM fossem carregados sem problemas, e ainda existem mecanismos legados que coexistem com o WDDM. O módulo que carrega ICDs OpenGL, por exemplo, praticamente não mudou entre as versões.
A comunicação no WDDM com a miniporta é mais direta. O Win32k mantém um salto de chamada de sistema que Dxgkrnl preenche com a interface apropriada, reduzindo o envolvimento do subsistema antigo na lógica da GPU. De fato, quando o sistema inicializa, rotinas específicas são observadas para vincular o WDDM ao antigo mundo Win32k sem arquiteturas de interface.
Existem dois drivers de vídeo que você deve conhecer em detalhes: TSDDD.dll e CDD.dll. O primeiro, TSDDD, Ele é carregado manualmente na sessão 0 e é um driver XDDM muito básico que praticamente não grava na memória vazia. Na família NT5.x (como base para o ReactOS), uma inicialização de vídeo com falha frequentemente resulta em uma verificação de bug para detectar falha de vídeo; no Vista e versões posteriores, essa situação "real" não ocorre mais graças ao segundo componente.
CDD.dll é o interessante. Enquanto atua como um driver XDDM, ele emite IOCTLs para se comunicar com o WDDM. É a única maneira Dxgkrnl e Win32k se comunicam significativamente Durante a operação gráfica moderna. Durante a inicialização, o Win32k consulta os adaptadores, mas a resposta é substituída por cdd.dll, garantindo a ponte para o WDDM. Um ponto crítico: uma vez habilitado o WDDM, não é possível executar um driver XDDM em paralelo.
OpenGL ICD, Vulkan e a relação com o sistema
Os ICDs OpenGL são carregados usando o módulo tradicional e seu fluxo não varia excessivamente entre o Vista, 7, 8 e versões posteriores, o que facilitou o teste cruzado usando ICDs de diferentes gerações. O Vulkan se comporta de forma semelhante: o sistema delega a interação com a GPU a essas camadas, mas no WDDM, a miniporta e o Dxgkrnl estabelecem o "contrato" de hardware propriamente dito.
Essa estrutura híbrida explica por que ainda vemos resquícios do XDDM coexistindo com o WDDM em componentes do sistema. A ponte CDD.dll permite que o Win32k continue cumprindo sua função clássica sem bloquear o caminho moderno, enquanto o Dxgkrnl e o miniport assumem a tarefa crítica de gerenciar a GPU.
Compilando drivers WDDM para testes no ReactOS
Para iniciar um driver WDDM, você precisa de uma peça auxiliar: displib.lib do WDK, que expõe o ponto de entrada para inicializar o driver e "acordar" Dxgkrnl sem vinculação a ele. O fluxo é particular: a API de inicialização é invocada, as estruturas de dados são passadas para Dxgkrnl e, em seguida, Dxgkrnl retorna o controle chamando o retorno de chamada de Bota da miniporta do provedor.
Esse retorno de chamada fornece as interfaces para o restante da comunicação com o Dxgkrnl. Neste ponto, O Win32k não parece nada no início do miniport, o que representa uma diferença fundamental em relação ao mundo XDDM. Essa adaptação foi fácil de implementar no ReactOS, abrindo caminho para a importação e compilação de drivers WDDM que também continuam funcionando no Windows.
WDDM no ReactOS: foco na tela
As APIs D3DKMT são usadas para aceleração DirectX e OpenGL, então para o primeiro experimento no ReactOS optamos por Concentre-se no básico: obtendo saída de vídeoÉ aqui que o universo VidPn (Video Presentation Network) e o suporte de hardware associado dentro do Dxgkrnl entram em jogo.
Desde o Windows 8 existem os chamados KMDOD, uma variante das miniportas WDDM que eles dispensam a aceleração 3DEles são mais fáceis de entender e começar a usar: eles permitem que você gerencie modos de vídeo, monitores e trajetórias sem depender do planejador e de outros subsistemas complexos do Dxgkrnl.
Para o ReactOS, o experimento foi construir um Dxgkrnl mínimo que consultaria os modos disponíveis via VidPn, os entregaria ao CDD e ativaria o CDD quando o Dxgkrnl estivesse pronto. O resultado: o sistema começou a falar com seu primeiro driver WDDM agora mostre a imagem em condições reais.
Primeiros sucessos: BasicDisplay.sys e drivers de fornecedores
Ao carregar BasicDisplay.sys no ReactOS, a conclusão foi inesperadamente positiva: O WDDM se mostrou mais tolerante do que o esperado.Foi até possível lançar drivers de fornecedores somente para a parte de exibição, sem exigir que eles suportassem aceleração 3D.
Em testes posteriores, as saídas de vídeo apareceram com mais drivers, incluindo um driver para Nvidia da época de Windows 7, o que permitiu que o ReactOS Mova os monitores modernos para sua resolução e frequência nativasO gargalo não era o Win32k, mas o suporte real ao hardware, que ainda está sendo expandido.
Por que o XDDM ainda é crucial no caminho para o WDDM
Embora o objetivo final seja o WDDM, o ReactOS exige que sua pilha XDDM esteja em ótimas condições. O motivo é que componentes como CDD.dll e o próprio DWM Eles dependem do bom desempenho do mundo antigo para preencher a lacuna entre o antigo e o novo. De fato, o DWM introduz demandas que a implementação atual do Win32k no ReactOS ainda não consegue atender totalmente, embora haja progresso contínuo.
O suporte para GPUs AMD sob XDDM também foi acelerado, um passo importante para estabilizar o campo antes abrindo caminho para drivers WDDM mais complexosO caminho escolhido é incremental: primeiro tela e modos, depois mais peças de quebra-cabeça.
Principais diferenças entre XDDM e WDDM
Uma das mudanças mais notáveis na migração do XDDM para o WDDM é o tratamento de falhas. Com o WDDM, grande parte da lógica do driver é movida para o modo de usuário, o que significa que Um acidente de trânsito não precisa necessariamente derrubar o sistema. completo. Além disso, o agendador de GPU e a memória virtualizada permitem uma alocação de recursos mais refinada.
No XDDM, o Win32k tinha muito mais peso e a comunicação com o hardware era mais rígida. No WDDM, Dxgkrnl impõe um contrato claro aos miniportos, e o Win32k permanece como uma ponte para o subsistema de janelas. Isso permite novos recursos, como DWM, composição e apresentações mais confiáveis.
- Planejamento e isolamento do trabalho da GPU versus a abordagem monolítica do XDDM.
- Memória de vídeo virtual e melhor gestão de recursos compartilhados.
- Maior estabilidade ao migrar a lógica do driver para o modo de usuário.
- Integração com DWM e rotas de apresentação modernas.
Limitações atuais e trabalho em andamento
Embora o suporte ao driver de vídeo WDDM no ReactOS já seja uma realidade em testes, a compatibilidade de hardware continua ditando o ritmo. Dispositivos reais requerem suportes muito específicos, e cada salto requer subsistemas em expansão: do plug and play ao gerenciamento de memória e watchdogs.
Na inicialização, a comunicação também é observada entre cão de guarda, Win32k e Dxgkrnl para preparar o envio das APIs do D3DKMT dentro do Dxgkrnl; esta é uma etapa de inicialização específica, mas adiciona requisitos adicionais quando se trata de reproduzir fielmente o comportamento do Windows.
Status do projeto, comunidade e chamada para colaboração
O recente avanço em direção ao WDDM tem sido acompanhado por mais atividades em torno do hardware. Há artigos técnicos detalhando o processo e Contribuições são bem-vindas por meio de doações, GitHub ou divulgação.Esta é uma frente grande e de longa distância: cada miniporto e cada rota de apresentação acrescentam nuances.
Vale lembrar, de passagem, a natureza do projeto: ReactOS não Linux ni Unix. Para um análise comparativa, foi escrito do zero para ser compatível com o binário do Windows, permitindo que ele execute software e drivers do Windows nativamente sem recorrer a camadas de compatibilidade como Wine/Proton, embora o projeto também colabore com esse ecossistema FOSS para melhorar os resultados.
Notícias práticas: ReactOS 0.4.15 e melhorias no sistema
Além do WDDM, a versão 0.4.15 trouxe uma boa quantidade de mudanças: novos motoristas armazenamento que melhoram a estabilidade e a compatibilidade com as unidades USB, bem como drivers de rede atualizados. Fontes, o shell da área de trabalho, APIs do Windows, temas e caixas de diálogo também foram ajustados.
Foram feitas melhorias nos caches e no gerenciamento de memória que impactam o desempenho. Além disso, Adicionado suporte LiveUSB Após modificações profundas no gerenciador Plug and Play do kernel, abrindo caminho para mais drivers de terceiros, a interface gráfica recebeu pequenos ajustes para torná-la mais fácil de usar em comparação ao instalador USETUP baseado em texto.
Na seção de áudio, agora é possível começar com a pilha de som do Windows, embora ainda há arestas a serem suavizadas. Também vale a pena notar que a versão 0.4.15 é a primeira a oferecer suporte à arquitetura de 64 bits (amd64) até o desktop, embora ainda não haja uma imagem oficial de 64 bits porque o WOW64 ainda está sendo desenvolvido.
As correções de bugs foram intensas: ícones da área de trabalho atribuídos incorretamente Os problemas resolvidos incluem ícones aprimorados na barra de tarefas e suporte nativo a arquivos ZIP. Tudo isso visa aprimorar a experiência básica do usuário, além de abordar a compatibilidade de hardware.
Download, instalação e requisitos mínimos
As imagens do ReactOS 0.4.15 estão disponíveis no SourceForge. É possível teste na máquina virtual (recomendado para iniciantes) ou instale em hardware real com uma unidade USB criada com utilitários como o Rufus, assim como você faria com o Windows padrão.
Os requisitos são modestos: CPU x86 (Pentium ou posterior), 64 MB de RAM, pelo menos 450 MB de espaço em disco em uma partição FAT16/FAT32 e cerca de 2 GB adicionais Se você planeja instalar software ou jogos, esses requisitos mínimos permitem que computadores da última década ou até mais antigos executem o sistema em cenários de teste.
Recomendações de uso e expectativas realistas
Atualmente, o ReactOS é um projeto experimental. Não é recomendado como sistema operacional primário se você precisar características modernas e compatibilidade total com aplicativos recentes. Para executar softwares mais recentes, o Wine/Proton no Linux continua sendo uma opção muito estável, com um amplo ecossistema de suporte.
Ainda assim, a singularidade do ReactOS o torna o O único sistema aberto que executa binários do Windows sem nenhum middleware estilo emulador. Essa abordagem o torna interessante para laboratórios, compatibilidade com versões anteriores, análises e ambientes controlados onde o comportamento de aplicativos e drivers precisa ser estudado.
Contexto comunitário e mensagens comuns
Em fóruns e espaços sociais, é comum ver lembretes como: ReactOS é um sistema de PC que pode executar programas e drivers do Windows. Às vezes, contadores de membros e usuários on-line também são exibidos, indicadores simples da vitalidade da comunidade que, sem valor técnico, apontam para um interesse crescente no projeto.
Narrativas recentes da mídia até apontaram a coincidência temporal entre o fim do suporte para algumas versões do Windows e Progresso do ReactOS em direção ao WDDMMais do que uma ironia, é um sinal de que a comunidade está alinhando prioridades para permanecer relevante com o hardware e os drivers atuais.
No final, todo esse esforço converge em um ponto: construir uma base sólida onde o WDDM pode se estabelecer sem abandonar o legado do XDDM, que ainda atua como a ligação entre os mundos. Com o CDD.dll como ponte, o Dxgkrnl como cérebro e miniportas melhor compreendidas graças aos drivers abertos, o caminho está pavimentado, embora ainda haja muito a ser percorrido.
Considerando tudo isso, o suporte ao WDDM no ReactOS está passando de uma promessa vaga para um conjunto de marcos tangíveis: Drivers de vídeo que iniciam, modos que negociam bem e monitores que funcionam em resolução máximaA compatibilidade de hardware precisa ser ampliada, peças como o WOW64 precisam ser concluídas e o Win32k e o DWM precisam continuar sendo ajustados, mas a direção é clara e a comunidade já está se esforçando nessa direção.
Escritor apaixonado pelo mundo dos bytes e da tecnologia em geral. Adoro compartilhar meu conhecimento por meio da escrita, e é isso que farei neste blog, mostrar a vocês tudo o que há de mais interessante sobre gadgets, software, hardware, tendências tecnológicas e muito mais. Meu objetivo é ajudá-lo a navegar no mundo digital de uma forma simples e divertida.