Programmiertechnisch stimmt das auch.
Naja, vielleicht fällt diese Hürde bald. Zumindest für bestimmte Treiberarten. Denn Microsoft hat schon mit anderen Sprachen geliebäugelt. Bestimmte Usermode-Treiber können bereits heute in anderen Sprachen entwickelt werden, da sie pur auf
Win32 aufsetzen.
Hinzukommen die fehlenden Header Übersetzungen. Kann man zwar auch übersetzen, nur wird da ausgiebig Gebrauch von C Sprachfeatures gemacht, die sich nicht so einfach nach Delphi übersetzen lassen.
Eigentlich sind da - bis auf die Macros - nicht sonderliche viele C-spezifische Features.
Microsoft hatte beim
DDK (Driver Development Kit, später in WDK: Windows Driver Kit umbenannt) bis zu den Versionen für Windows 2000 keine Toolchain (Compiler, Linker etc) beigelegt. Einspringen sollte damals die aktuelle Version von Visual C++. Das war umständlich. Mit dem
DDK für XP änderte sich das und die Toolchain lag bei. Microsoft riet auch explizit davon ab die Toolchain von irgendeiner Visual C++ Version zu benutzen, sondern empfahl jene im
DDK/WDK. Die entsprechenden Werkzeuge, die sich an das damalige Buildsystem für Windows anlehnten, waren aber umständlich. Dies führte zu Brückenlösungen wie
VisualDDK oder meinem
DDKWizard, der auch nur eine schöne Oberfläche für meine Neufassung von
ddkbuild.cmd war (es gab/gibt noch die älteren Versionen von
Don Burn und von OSR's ddkbuild.bat).
Es gab viele Rezepte bzgl. der Nutzung anderer Toolchains: Nico's Variante für Delphi darf hier ruhig erwähnt werden, aber auch welche unter Nutzung von GCC mit MinGW oder des Visual C++ Compilers. Alle diese Rezepte verkannten aber die speziellen Herausforderungen und richteten sich explizit gegen den Rat von Microsoft zum Thema Treiber. So gilt im Kernelmode eine Beschränkung des Stacks pro Thread. 12 KiB für "normale" Threads und knappe 64 KiB für
GDI-Threads.
Code:
KERNEL_LARGE_STACK_COMMIT equ 03000H
KERNEL_LARGE_STACK_SIZE equ 0F000H
KERNEL_STACK_SIZE equ 03000H
DOUBLE_FAULT_STACK_SIZE equ 03000H
Typische Bugcheck-Codes im Fall des Überlaufs wären PANIC_STACK_SWITCH und UNEXPECTED_KERNEL_MODE_TRAP. Das passiert, wenn ein beliebiger Treiber zuviel Stack frißt. Und bei Filtertreibern, welche übereinander sitzen und dann als Stapel auf einem PDO aufsetzen, kann man sich denken, daß 12 KiB ziemlich knapp sind, wenn ein halbes Dutzend Filtertreiber im System nicht allzu ungewöhnlich sind und man als Treiberentwickler jederzeit mit Stacknotstand rechnen muß. Die Toolchains im den DDKs/WDKs bringen dazu spezielle Werkzeuge mit um mittels statischer Code-Analyse zu ermitteln wieviel Stack die Funktionen im eigenen Treiber fressen (Array auf dem Stack ist ja durchaus Usus für Usermode-Entwickler). Genau genommen war das
DDK/WDK bis vor einiger Zeit die billigste Variante um an statische Analysewerkzeuge für Windows-C/C++-Entwicklung zu kommen. Es gibt noch weitere spezielle Werkzeuge die ebenfalls ausschließlich im
DDK/WDK zu finden sind, weshalb es höchst unsinnig wäre hier krampfhaft zu versuchen an den vorhandenen Mitteln vorbei eine Lösung für ein eigentlich nicht vorhandenes Problem zu finden.
Und jetzt erkennt man auch was Luckie mit folgender Aussage gemeint haben könnte:
Nur für Windowstreiber benötigst du Tools von Microsoft und die verstehen kein Delphi.
Erst mit Windows 8 besann sich Microsoft auf eine Integration des WDK in Visual C++. Präziser, Visual C++ ist heute die Voraussetzung für die neue Generation der WDKs, denen keine Toolchain mehr beiliegt. Damit schließt sich sozusagen der Kreis. Aber natürlich nicht ganz, denn als Treiberentwickler sind wir die absolute Minderheit, weshalb man bei Microsoft etwas schnarchnasig hinterherhinkt wenn es um die Anpassung der neuen WDKs an die aktuellsten VS-Versionen geht.