The first chapter of Delphi-Driven development--the principle of realization

Delphi can not develop Windows driver (here the driver of course not refers to the VxD ^_^) has been the majority of Delphi fans concerned about the issue. Let's not say we can or can't, we'll start by looking at the technical issues that need to be solved to develop a driver with Delphi.
Delphi's linker is unable to generate Windows kernel-mode programs, so the driver cannot be generated directly with Delphi. M$ the linker is able to generate Windows kernel-mode programs, then whether you can use Delphi to generate the target file, and then use the m$ link it? To do this, you have to solve the following problems:
Delphi-generated target file is in OMF format, while m$ Link claims to support the OMF format of the target file, but the basic useless. The best way to convert the OMF format into COFF format, Elicz heroes omf2d just can solve this problem. Solve the problem of the target format, everything OK? It's far from easy. Before we go on, let's take a look at the famous DDDK.
DDDK (Delphi Driver Development Kit) is a toolkit for developing Windows Drivers with Delphi, released by the Hacker Defender Project team, and the latest version is the 0.0.4 version. DDDK is to use the common driver API with Delphi layer packaging placed in the DDDK unit, as follows:

UNIT DDDK; Interface Const   ntkernel= ' Ntoskrnl.exe '; ...... Procedure iocompleterequest (IRP:PIRP; Priorityboost:integer); stdcall;       Implementation Procedure krnliocompleterequest (IRP:PIRP; Priorityboost:integer); stdcall; external ntkernel  name  ' IoCompleteRequest '; Procedure iocompleterequest (IRP:PIRP; Priorityboost:integer);  stdcall;  begin    krnliocompleterequest (IRP, Priorityboost);   End; ...

then do the following with omf2d for the driver APIs that need to be introduced in Dddk.obj before each link to the driver file:
omf2d inc\dddk.obj /u- /[email  Protected] 2>nul the iocompleterequest in dddk.obj to [email protected], why do you do it? That's because import libraries such as Ntoskrnl.lib are in the COFF format, and the COFF format is named this way. After completing this step, you can call M$ link to link the target file to the driver file.
    This can generate the correct driver file, but the disadvantage is obvious. The driver API is packaged with Delphi, these Delphi-packaged functions are linked to the resulting driver file regardless of whether they are used, which increases the size of the drive file, and the efficiency of invoking the driver API via the Delphi wrapper function will also be affected. There is a link before each to use omf2d inc\dddk.obj /u- /[email protected] to convert the Delphi target file, both cumbersome and error prone. Is there a better way?
   omf2d's job is to convert the Delphi naming method into a COFF [email protected] format, with the default omf2d removing the leading underscore and @xx suffix, which can be/u_* Switch lets omf2d not remove the leading underline, if we have no @xx suffix import library, then the problem is much simpler. But m$ does not provide an import library without the @xx suffix, so let us do a bar ^_^, in fact, it is very simple, for example, we want to generate a Hal.dll import library, only need to edit a hal.def file as follows:

Library        hal. DLL Exports        ExAcquireFastMutex                          ExReleaseFastMutex                         ExTryToAcquireFastMutex                     halacquiredisplayownership                 HalAdjustResourceList                      halallprocessorsstarted        &NBSP, ....

You can then use the Link/lib/machine:ix86/def:hal.def/out:hal.lib command to generate the import library files that we need without the @xx suffix. With this file, plus I developed the rmcoff tools, things are much better. Let's start by using Delphi to develop a simple driver beeper.
This driver is from the Four-f Kmdkit in the beeper conversion, the goal of the program is to use the access port to voice the PC's speakers, the program through three ways to make the speaker sound, one is the direct access to the port, one is called Hal.dll Read_port_ Uchar and Write_port_uchar access ports, the third method is to call the Halmakebeep function of Hal.dll.

Unit beeper; Interface Uses Windows, DDDK, Hal; function _driverentry (driverobject:pdriverobject; registrypath:punicodestring): NTSTATUS; stdcall; Implementation Const Timer_frequency:dword = 1193167; {1,193,167 Hz} Octave:dword = 2; {Octave Multiplier} Pitch_c:dword = 523; {c-523,25 Hz} Pitch_cs:dword = 554; {C #-554,37 Hz} Pitch_d:dword = 587; {d-587,33 Hz} Pitch_ds:dword = 622; {d#-622,25 Hz} Pitch_e:dword = 659; {e-659,25 Hz} Pitch_f:dword = 698; {f-698,46 Hz} Pitch_fs:dword = 740; {F #-739,99 Hz} Pitch_g:dword = 784; {g-783,99 Hz} Pitch_gs:dword = 831; {g#-830,61 Hz} Pitch_a:dword = 880; {a-880,00 Hz} Pitch_as:dword = 988; {b-987,77 Hz} Pitch_h:dword = 1047; {h-1046,50 Hz} {We is going to play c-major chord} Delay:dword = $18000000; {for my ~800mhz box} Tone_1:dword = 1141; Tone_2:dword = 905; Tone_3:dword = 1568; {for halmakebeep} Status_device_configuration_error:dword = $00c0000182; Procedure MakeBeep1 (Dwpitch:dword); stdcall; Assembler; Asm Cli mov al, 10110110b Out 43h, AL mov eax, Dwpitch Out 42H, AL mov al, ah Out 42H, AL {Turn Speaker on} In Al, 61h Or AL, 11b Out 61h, AL STi Push EAX mov eax, DELAY @@1: Dec eax JNZ @@1 Pop eax Cli {Turn Speaker OFF} In Al, 61h And Al, 11111100b Out 61h, AL STi End Procedure MakeBeep2 (Dwpitch:dword); stdcall; Var Dwport, I:dword; Begin Asm Cli End Write_port_uchar (Puchar ($43), $b 6); Write_port_uchar (Puchar ($42), Dwpitch and $FF); Write_port_uchar (Puchar ($42), ((Dwpitch shr 8) and $FF)); Dwport: = Read_port_uchar (Puchar ($61)); Dwport: = Dwport or 3; Write_port_uchar (Puchar ($61), dwport); Asm STi End For I: = 1 to DELAY do Begin End Asm Cli End {Turn Speaker OFF} Dwport: = Read_port_uchar (Puchar ($61)); Dwport: = Dwport and $FC; Write_port_uchar (Puchar ($61), dwport); Asm STi End End function _driverentry (driverobject:pdriverobject; registrypath:punicodestring): NTSTATUS; stdcall; Var I:integer; Begin MAKEBEEP1 (tone_1); MAKEBEEP2 (tone_2); Halmakebeep (Tone_3); For I: = 1 to DELAY do Begin End Halmakebeep (0); Result: = Status_device_configuration_error; End End.

Unit hal; Interface uses      windows; Const      NtHal =  ' Hal.dll '; Function halmakebeep (Frequency: ulong):boolean; stdcall; Function read_port_uchar (Port:puchar):uchar; stdcall; Procedure write_port_uchar (Port: puchar; value: uchar);  stdcall;  Implementation Function halmakebeep (frequency: ulong): boolean; stdcall; external  NtHal name  ' _halmakebeep '; Function read_port_uchar (Port:puchar):uchar; stdcall; external nthal name  ' _ Read_port_uchar '; Procedure write_port_uchar (Port: puchar; value: uchar);  stdcall; external  NtHal name  ' _write_port_uchar '; End.

1. Use Dcc32–u. \include-b-cg-jp-$A-,c-,d-,g-,h-,i-,l-,p-,v-,w+,y-beeper.pas generate the destination file (here: \inc is my directory to save the relevant Delphi unit files, your may not be this directory yo)
2. Use Rmcoff beeper.obj to process the relevant symbols of the Delphi target file and convert the target file from OMF format to COFF format so that it can be linked by m$ link
3. Use Link/nologo/align:32/base:0x10000/subsystem:native/driver/entry:driverentry. \lib\hal.lib Beeper.obj/out:beeper.sys generates the final driver file. After performing the above steps, a Beeper.sys file will be generated in your directory. Copy it to Kmdkit's beeper directory, load it with its SCP file, and the sound of the PC horn is really crisp, proving that our Delphi driver is correct. The Beeper.sys generated by this method is only 1376 bytes, which is hundreds of bytes larger than the Beeper.sys of the Kmdkit assembly code, and the Beeper.sys generated by DDDK is more than 3 K.
It is not easy to finish so many words, this tutorial is here, Next we will use Delphi to do a more interesting stuff.

http://blog.csdn.net/sustzw/article/details/6722250

The first chapter of Delphi-Driven development--the principle of realization