views:

438

answers:

3

I've always heard that Delphi can do almost anything C++ can do...except write Windows drivers. Is this correct, and if so, why is that?

I recently read a blog post online that may indicate a possible solution for writing drivers with Delphi, but it's 3 years old and I don't know how accurate this information is.

So, with the latest version of Delphi (2010), would it be technically possible to write a Windows driver?

+5  A: 

You can write a Windows driver in any language that compiles down to a DLL in PE format, that has no external dependencies (other than those approved for loading in the kernel), can call functions with STDCALL linkage, and export functions with STDCALL linkage.

The no-unapproved-external-dependencies is going to be the hard part I would think. :)

John Knoeller
Good point about no unapproved-external-dependencies, John (+1). My knee-jerk reaction was "of course". But OP will have trouble because Delphi wil provide _winmain()
Mawg
It also has to support function pointers, because a `DRIVER_OBJECT` that doesn't point to any of the driver's functions isn't very useful. And some of the PE header fields have to be set to special values (though I suppose that could be fixed after linking).
bk1e
@bk1e: good point. In theory the linker could also fill in parts of the DRIVER_OBJECT, but language supported function pointers would be _so_ much cleaner.
John Knoeller
Even the System unit and SysInit that are ALWAYS included in the generated module, some external symbols are used that are not usuable within a kernel. Eg it is quite a feat to get Delphi generated code support the external dependency requirement.
Ritsaert Hornstra
Actually, Delphi *does* support function pointers.
PhiS
@PhiS: I wasn't suggesting that it didn't, just that you could (in theory) get it to work even if it didn't.
John Knoeller
+8  A: 

It may be technically possible to write some drivers with Delphi, but as far as a general answer goes, I'd say: you can't easily write drivers with Delphi.

First, there's a difference between user-mode driver (UMDF) drivers and kernel-mode (KMDF) drivers. UMDF drivers should be possible with Delphi. KMDF drivers aren't easily possible though, because

1) Delphi's linker can't produce them and

2) Delphi's object file format is different from the COFF format the Microsoft linker uses by default.

3) Delphi's RTL makes the assumption it lives in user-mode and may do certain things that one shouldn't do in kernel-land (I think e.g. of the way exceptions are handled; also different memory management), so you'd have to be very careful on which RTL functions are safe to use. There are also difficulties with System and SysInit units (see the comment by Ritsaert Hornstra to another answer here).

I'm not saying these aren't problems that cannot be overcome (cf. the post you link to) if you're really dedicated, but it won't be straightforward.

Secondly, KMDF drivers (I don't know about UMDF, actually - can anyone comment?) for Win64 have to be in 64-bit code. Since currently, there is no 64-bit Delphi compiler, writing them is a definite no-no.

PhiS
+1, all good points. In addition to that being able to create a driver with Delphi would still leave you without a way to properly debug it - Delphi can't do it itself, nor does it create debug symbols in a format one of the MS debuggers can use. So what would be the point really of overcoming these problems?
mghie
The 64 bit driver requirement is actually a requirement of the Vista/Windows 7 logo program. It applies not to the driver per se, but to the device.
MSalters
This is exactly the information I was looking for. Thank you!
Mick
+1  A: 

I agree with both previous answers. I've actually done it in a special case: A print monitor. It's a special case of driver that runs in user mode, and I could write one in Delphi. There was definitely some benefits in using Delphi there.

But the last pitfall that wasn't mentioned yet (I think) is that you need to translate zillions of complex structures and macros from DDK header files. Translating some convoluted macros, in particular, can be very tricky.

filofel