Treiber Handling

[nanix]

Okay so should i use 32 bit with delphi and FPC for 64 or FPC for both.

What do you advise?

[cookie22]

doesn't matter if both work, does it?

[nanix]

Yes that is true but how would it look in lazarus the make file?

in delphi i now use this..

Delphi-Quellcode:

bin\dcc32 -UC:\test1\include -B -CG -JP -$A-,C-,D-,G-,H-,I-,L-,P-,V-,W+,Y- -O+ driver.pas
bin\rmcoff2 driver.obj
bin\link /NOLOGO /ALIGN:32 /BASE:0x10000 /SUBSYSTEM:NATIVE /DRIVER /LIBPATH:C:\test1\lib /ENTRY:DriverEntry ntoskrnl.lib hal.lib win32k.lib ntdll.lib ntutils.lib /out:driver.sys driver.obj

Does FPC/lazarus compile only for normal x64 becouse there is IA x64 and AMD x64

[JamesTKirk]

Zitat von nanix:

Yes that is true but how would it look in lazarus the make file?

in delphi i now use this..

Delphi-Quellcode:

bin\dcc32 -UC:\test1\include -B -CG -JP -$A-,C-,D-,G-,H-,I-,L-,P-,V-,W+,Y- -O+ driver.pas
bin\rmcoff2 driver.obj
bin\link /NOLOGO /ALIGN:32 /BASE:0x10000 /SUBSYSTEM:NATIVE /DRIVER /LIBPATH:C:\test1\lib /ENTRY:DriverEntry ntoskrnl.lib hal.lib win32k.lib ntdll.lib ntutils.lib /out:driver.sys driver.obj

You may try this (it's a suggestion and not tested):

Code:

fpc -FuC:\test1\include -Mdelphi driver.pas
bin\rmcoff2 driver.o
bin\link /NOLOGO /ALIGN:32 /BASE:0x10000 /SUBSYSTEM:NATIVE /DRIVER /LIBPATH:C:\test1\lib /ENTRY:DriverEntry ntoskrnl.lib hal.lib win32k.lib ntdll.lib ntutils.lib /out:driver.sys driver.obj

I don't know what options link needs to link a 64-bit file. Perhaps

Code:

/ALIGN:64

is enough.
For compiling 64-bit code you also need the 64-bit version of FPC. You can then define the target plattform with

Code:

-Pi386

for 32-bit and

Code:

-Px86_64

for 64-bit.

I currently don't know how to define the switches (after -$ in your code) in the command line, so you might need to define these in your code like this (example for H-):
{$H-}

Zitat von nanix:

Does FPC/lazarus compile only for normal x64 becouse there is IA x64 and AMD x64

Currently FPC only supports AMD x86.

Note: IA x64 is something completly different to normal 64-bit found on common processors (including Intel processors). So AMD x86 is normally sufficient!

Regards,
Sven

[nanix]

Thank you for your information.I am a bit amazed that i am the only one that figured this out

The driver itself has about 3000 lines of code.


Also James what do you think about adding dbpring on exceptions and errors.This would make debuging much easier.Becouse you can then inspect the driver.See whats going on in realtime.

Regards,
nanix

[JamesTKirk]

Zitat von nanix:

Thank you for your information.I am a bit amazed that i am the only one that figured this out

Perhaps that's because noone else (in this forum) is using the kit you are using

Zitat von nanix:

Also James what do you think about adding dbpring on exceptions and errors.This would make debuging much easier.Becouse you can then inspect the driver.See whats going on in realtime.

That's basically the purpose of DbgPrint If possible I'll try to implement the stack trace feature of Free Pascal, which allows you to find the unit and line where an exception occured. (That will be very handy when used with DbgPrint )

I don't know how well the Delphi kernel mode handles exceptions, but in the case of my port I've not yet enabled the interaction with system exceptions (like Access Violation, Div By Zero, etc.), but exceptions that are thrown by Pascal code (with raise) are handled if there is a surrounding except block. One should nevertheless catch all exceptions because the result of not doing this might be an infamous BSOD

Regards,
Sven

[nanix]

Ah yes James but how are you going to see which line it was if you get an BSOD fast.I think ill add some kind of dump soon as it happens it will dump it to the HDD even before BSOD happens.

[JamesTKirk]

The kernel already creates a dump for you if you enable that (you can sometimes see the progress of saving it on the bottom of a BSOD) and WinDbg can extract the last DbgPrint messages for you out of this dump. That's one of those parts the guys at Microsoft did well

A note about BSODs: The kernel still runs when a BSOD occurs, that's the reason why it can print to the screen and dump the memory. You can also connect to a NT machine via Null Modem cable and activate the built in kernel debugger. This debugger is also activated when a BSOD occurs, so you can debug around (you might need a debug build of Windows to be able to use the kernel debugger, though)

Regards,
Sven