Come si costruisce il rifacimento di Windows D3D9 dall'origine?

Question

Microsoft distribuisce il codice sorgente per fare riferimento alle implementazioni delle loro diverse API Direct3D a fornitori di hardware, sviluppatori di driver, ecc. Questo codice si basa sul sistema di generazione sempre criptico WDK (precedentemente DDK) e praticamente non funziona mai scatola. Sebbene ampiamente utilizzato, questo codice è semi-privato, quindi non ci sono mai informazioni utili di base disponibili sul Web più ampio. Questo è comunemente usato abbastanza (e un dolore ben noto nel culo in questa comunità), e le informazioni di base sulla costruzione abbastanza insensibili, che dovrebbero essere rilevabili su Google.

Il readme build suggerisce di usare WDK e di compilare con il comando build -cz -daytona . Questo, confusamente, sputa un sacco di output ma non costruisce nulla.

Superando questo, Vista con WDK 6001.18002, l'ultima distribuzione di sorgente d3def9 fallisce nel sottoprogetto link con " impossibile produrre alcun output - avviso trattato come errore. "

XP d3dref9.dll può anche creare confusione, spesso non riesce a trovare intestazioni e tipi D3D.

Answer 1

In genere ci sono due problemi principali abbastanza comuni nella creazione dei drop di sorgenti refrast poiché vengono direttamente da Microsoft.

Innanzitutto, il comando build -cz -daytona è un errore di battitura o si basa su una configurazione esterna aggiuntiva non documentata. Costruire in questa modalità analizza tutta la fonte, ma non specifica mai quale piattaforma (e) costruire. Poiché tutte le piattaforme dirs ( daytona e win9x ), in cui sono specificati gli output effettivi, sono " facoltativi & " nulla è mai stato effettivamente costruito. La soluzione a questo è invece usare il comando build -cz daytona correttamente specificato (nessun ' - ' su daytona ). Questo dovrebbe analizzare le fonti e quindi effettivamente costruire tutto

Oltre questo, di solito ci sono anche problemi con la configurazione predefinita.

I nuovi WDK (ad es. su Vista) generalmente falliscono nella fase di collegamento finale con un errore del linker spurio. Questo è facilmente risolto aggiungendo:

LIBRARIAN_FLAGS = $(LIBRARIAN_FLAGS) /IGNORE:4001

al file di build link / sources.inc . Dopodiché, build -cz daytona nella radice del drop di origine dovrebbe compilare e collegare tutto immediatamente.

Su XP, è anche comune riscontrare problemi se si utilizzano DDK precedenti (pre-Windows Server 2003, ovvero DDK con etichetta "XP"). In particolare, il progetto di rifusione si basa su header D3D9 core esistenti esternamente e questi non sono inclusi in DDK XP. Semplicemente usando gli ultimi WDK (rinominati da "DDK" post-XP) risolvi questo. Contrariamente alla denominazione, tutti i WDK più recenti sono generalmente superset di versioni precedenti e quindi includono ambienti di build per piattaforme tramite XP.

Potrebbero esserci anche problemi con alcune versioni di sorgenti di aggiornamento XP, incluso il codice che innesca più errori pedanti del compilatore nelle versioni più recenti del compilatore WDK. Questi, tuttavia, di solito possono essere facilmente risolti con la compilazione iterativa e la modifica della sorgente in risposta a qualsiasi semplice errore di sicurezza / correttezza sollevato dal compilatore.