Zitat von
Dirkmswt:
Hallo ich hab da mal ne Frage zum dddk2004.
Ich habe mit den Beispielen probiert die nochmals zu Kompilieren,aber trotz Batch kein Erfolg gehabt
Habe auch probiert die linker.exe und was so alles zum Kompilieren notwendig ist in den Ordner zu kopieren wo ich das kompilat machen wollte aber irgendwas zickt da rum.
Bekomme auch keine Fehlermeldung was das ganze nochmals erschwert.
Liegt das vielleicht am Compiler dcc32.exe?
Sei mir nicht böse - lies doch einfach nochmal durch den Thread und zwar in Gänze und achte auf die Einwürfe von Nico und mir.
Bestimmt entlockte es einem Newbie auch ein verzücktes Grinsen wenn jemand ein Fortran-
DDK bereitstellte oder jemand auf die bescheuerte Idee käme ein
DDK in Haskell zu schreiben. Allein, es stellt sich weiterhin die Sinnfrage.
Um mich selbst zu zitieren:
Schreibe ich ein Usermodeprogramm scheiße, kackt maximal das Programm ab - im gleichen Fall ist es beim Treiber das ganze System.
... und ja, es ist bereits schwer genug mit C bzw. C++ einen Treiber zu schreiben der auf allen zu unterstützenden System einwandfrei funktioniert. Wer _asm benutzt weiß, daß es u.U. sogar noch schwerer werden kann (es gibt tatsächlich Stellen wo man das wirklich braucht).
Und dann verrate ich noch ein kleines Geheimnis:
Der
DDK-Compiler ist nicht identisch mit dem im Visual Studio. Zwar stimmt es, daß bis zum 2000er
DDK der Programmierer den Compiler von VC6 zur Verfügung stellen mußte, dies ist aber seit dem ersten XP
DDK (das den Compiler und Linker enthielt) nicht mehr der Fall. Abgesehen von diversen Sachen die der Linker von z.B. VS 2005 macht, die nicht immer vorteilhaft für einen Treiber sind, gibt es einen sehr speziellen Grund, warum man den Compiler des
DDK benutzen sollte: FP Opcodes.
Jupp, im Kernelmode ist es dir
nicht (bis auf Ausnahmen die Prolog und Epilog haben) erlaubt Gleitkommaoperationen zu verwenden. Der Grund ist einfach: ein Treiber ist eine
DLL wird im Kontext eines Threads aufgerufen. Jeder Thread hat einen Kontext, der auch den Stand der FPU-Register usw. beinhaltet. Wenn du nun damit rumwerkelst ohne diesen Kontext vorher zu sichern und nachher wiederherzustellen, kann so gut wie alles passieren ...
Übrigens ist das einer der Gründe warum man DDKBUILD immer einem Projekt vorziehen sollte, wo der VS-Compiler benutzt wird (es sei denn es handelt sich um das
DDK von 2000 oder niedriger).
Mein Fazit für dich:
Klar geht es mit Delphi einen Treiber zu schreiben. Wenn du die paar Headerchen erstmal übersetzt hast, kannst du damit fortfahren die /GS-Funktionen in den Delphi-Linker einzubauen ...
Selbst Freepascal-Treiber finde ich fragwürdig, obwohl es der Linker dort noch eher hergibt, weil ich ihn notfalls ja anpassen könnte. Also laß es doch einfach und steige in die Treiberentwicklung direkt ein, wenn es dich interessiert - aber nicht mit Delphi.
Tip: stelle keine Fragen zum DDDK in Mailinglisten als NTDEV und NTFSD
