Delphi всемогущий

Ms-Rem

Хакер, номер #080, стр. 080-112-6

implementation

function DbgPrint(Str: PChar): cardinal; cdecl; external 'ntoskrnl.exe' name '_DbgPrint';

function DriverEntry(DriverObject, RegistryPath: pointer): integer;

begin

DbgPrint('Hello World!');

Result := -1;

end;

end.

Файл make.bat:

dcc32.exe -JP -$A-,B-,C-,D-,G-,H-,I-,J-,L-,M-,O+,P-,Q-,R-,T-,U-,V-,W+,X+,Y- Driver.pas

link.exe /DRIVER /ALIGN:32 /BASE:0x10000 /SUBSYSTEM:NATIVE /FORCE:UNRESOLVED /ENTRY:DriverEntry$qqspvt1 Driver.obj ntoskrnl.lib /out:Driver.sys

Для компиляции нам понадобится файл ntoskrnl.lib из DDK. Мы получим драйвер размером в килобайт, который выводит сообщение «Hello World» в отладочную консоль и возвращает ошибку, а потому не остается в памяти и не требует определения функции DriverUnload. Для запуска драйвера используй KmdManager от Four-F. Увидеть результаты его работы можно в софтайсе или DbgView.

Главная проблема, из-за которой на Delphi нельзя писать полноценные драйвера, - отсутствие DDK. Для написания драйверов нужны заголовочные файлы на API-ядра и описания большого количества системных структур. Все это богатство есть только для С (от Microsoft) и для MASM32 (от Four-F). Есть слух, что DDK для паскаля уже существует, но автор продает его за деньги и сильно этот факт не афиширует. Думаю, когда-нибудь все-таки найдутся энтузиасты, которые перепишут DDK на паскаль и выложат для всеобщего использования. Другой проблемой является то, что большинство примеров, связанных с системным программированием, написаны на си, поэтому на каком бы языке ты ни писал свои программы, си знать придется. Это, конечно, не означает, что придется изучать С++ в полном его объеме. Для понимания системных программ хватит базовых знаний синтаксиса, все остальное же используется только в прикладных программах, которые нас совершенно не интересуют.

[переносимость кода]

При программировании на стандартных Delphi компонентах, кроме кучи недостатков, мы получаем одно достоинство - некоторую переносимость кода. Если программа использует только возможности языка, но не возможности системы, то она будет легко компилироваться в Kilix и работать в Linux. Вся проблема в том, что без использования возможностей системы мы получим настоящее глюкалово, тяжелую и неэффективную программу. Тем не менее, при написании серьезных программ по вышеописанным методикам, все-таки хочется иметь некоторую независимость от системы. Получить ее очень просто - достаточно писать код, не использующий ни API-функций, ни возможностей языка вообще. В некоторых случаях это совершенно невозможно (например, в играх), но иногда функции системы абсолютно не нужны (например, в математических алгоритмах). В любом случае, следует четко разделять машинно-зависимую и машинно-независимую (если такая есть) части кода. При соблюдении вышеописанных правил машинно-независимая часть будет совместима на уровне исходных текстов с любой системой, для которой есть компилятор паскаля (а он есть даже для PIC-контроллеров). Независимый от API код можно смело компилировать в DLL и использовать, например, в драйвере режима ядра. Также такую DLL не составит труда использовать и в других ОС. Для этого нужно просто посекционно отмапить DLL в адресное пространство процесса, настроить релоки и смело пользоваться ее функциями. Осуществляющий это код на паскале занимает около 80 строк. Если же DLL все-таки использует некоторые API-функции, то их наличие можно проэмулировать, заполнив таблицу импорта DLL адресами заменяющих их функций в своей программе.