Writing device driver for windows using Delphi is almost impossible since Delphi can't produce .sys files. Is it the same case for FPC? Can FPC produce .sys file and write device drivers for any OSes (not just windows)? TIA.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bisma Jayadi wrote

Writing device driver for windows using Delphi is almost impossible since Delphi can't produce .sys files. Is it the same case for FPC? Can FPC produce .sys file and write device drivers for any OSes (not just windows)? TIA.

Well. FPC can be used to write an operating system, so writing a device driver is in theory possible.

Mostly, this would mean writing an RTL which runs inside a kernel, which means writing routines to handle IO and routines to handle memory management from the kernel interfaces.

I think for Unix-type interfaces that would be enough. For Windows, there is the additional problem of producing a .sys file, which would mean some changes to the internal linker.

Michael.

And it would mean writing a C to Pascal conversion of an ever changing kernel interface.

I think for Unix-type interfaces that would be enough.

No. Especially with a Linux 2.6 kernel where you are supposed to link with some "kernel object" file and an ever changing binary interface mostly defined as C-macros.

At least you need an additional C-wrapper or you're really lost.

For Windows, there is the additional problem of producing a .sys file, which would mean some changes to the internal linker.

In which way are they special? I don't have a working "objdump" here, so I can't say in which they are different from the "normal" executable files on Windows. I mean, they're still called .sys but other than in the old DOS-days they're also PE-executables or whatever they're called. ;)

Vinzent.

Vinzent Hoefler wrote

And it would mean writing a C to Pascal conversion of an ever changing kernel interface.

All interfaces change when a new version is released, that´s no reason not to write pascal bindings for them. We have different pascal bindings for Qt 2, 3 and 4, for example.

What really doesn´t help is that the windows driver world is huge. really vast. There are dozens of different driver types, and some tipes only work on some versions of windows.

> For Windows, > there is the additional problem of producing a .sys file, which would > mean some changes to the internal linker.

Another (maybe easier) option is to use the microsoft assembler and linker that come with the ddk.

Well, I was not talking about justified "architectural" changes (like those from 2.4 to 2.6), but rather about those deliberate changes of the Linux driver ABI sometimes from kernel patch to kernel patch where important structures get reordered and such stuff. Without the actual C macros you are lost. And yes, it's done on purpose to discourage the use of binary only drivers. Additionally it discourages the use of other languages than C when writing device drivers. I did one in Ada a couple of years ago, but trying that these days would be close to suicide or at least get you to the madhouse. ;)

Vinzent.

The solution is rather simple, it seems to me: write a small C driver stub which exposes a uniform interface. All you need to do is recompile this driver stub, and you're all set: the stuff that links to this stub will still function. I think the paragon filesystem driver works like this, and I would not be surprised if the vmware modules and nvidea drivers work like this too.

Could be too naive to be true, of course.

Michael.

Michael Van Canneyt wrote

The solution is rather simple, it seems to me: write a small C driver stub which exposes a uniform interface.

Yes. Of course, apart from the fact that this portion of code can get rather large depending on the structures and functionalities needed.

Once you've done that, it's a piece of cake to write the rest of the driver. ;) And while you're at it, you don't switch compilers anymore.

Vinzent.

Well. FPC can be used to write an operating system, so writing a device driver is in theory possible.

Is there any tutorials or wikis or how-tos out there that describe how to write a device driver using FPC? At least for windows platform. TIA.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bisma Jayadi wrote

Is there any tutorials or wikis or how-tos out there that describe how to write a device driver using FPC? At least for windows platform. TIA.

What kind of windows driver? First choose that. There are lot´s and lot´s of types of windows drivers.

I´ve already seen a framework to write VXD drivers using Delphi, but that will be of no use if you don´t want a VxD but another type of driver.

What kind of windows driver? First choose that. There are lot´s and lot´s of types of windows drivers.

Device driver for a custom hardware connected through USB port.

I´ve already seen a framework to write VXD drivers using Delphi, but that will be of no use if you don´t want a VxD but another type of driver.

This is my first time writing a device driver, so I don't really understand what are the differences between .vxd and .sys driver type. Most important is, I want to write it using pascal language and avoid as much as possible to use C. I think I need to learn more about this and come back here later with more precise questions.

Thanks.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Hello Felipe,

you wrote

What really doesn´t help is that the windows driver world is huge. really vast. There are dozens of different driver types, and some tipes only work on some versions of windows.

Well, not dozens. There are, basically:

user-mode drivers - conventional DLL's with specific interfaces. These can be written in anything and compiled by anything, as long as calling conventions are met.

Virtual device drivers (VxD) - kernel-mode LE modules used in Win9x. History. Forget that these ever existed.

NT-style drivers (sys) - kernel-mode PE modules with some specific sections and specific exported functions. History, but still will work if you run them on Win2k and XP (should work on Win98 SE too). These are the easiest kernel-mode drivers to write, so they are often used for home-made hardware.

WDM drivers - basically NT-style drivers with yet even more specific interfaces :) Invented to support plug-and-play, load-on-demand, things like these.

That's all for now. But I believe they already introduced something new in Vista.

Bisma Jayadi wrote

> What kind of windows driver? First choose that. There are lot´s and > lot´s of types of windows drivers. Device driver for a custom hardware connected through USB port.

Ok, this will depend on the chip you used on your device for USB. Most of the chips comes with a SDK and drivers, so it's as simple as a DLL use.
Of course, some chips have better SDK than others.

vxd were the virtual device drivers for windows up to 98/Me. Since 2000 and XP, it's not working anymore.
Most of the blue screens in these times were bad VxD ;o)

Marc Pertron wrote

Ok, this will depend on the chip you used on your device for USB. Most of the chips comes with a SDK and drivers, so it's as simple as a DLL use. Of course, some chips have better SDK than others.

Which usb interface chips do you know?

I´ve been using FT8U245BM from http://www.ftdichip.com/

It does a good job, but knowing others is always good =)

thanks,

World seems small, i used the same, but it's not "real usb", but i agree that it will be enough for 95% of the uses.
I also have used Quancom products for opto I/O.
The book "USB Design by example" is also quite good (source code included on CD with various examples, in VB and VC++, but it was for windows 98)
Hope it will help you ;o)

Have you had a look at "libusb-w32" (or similar spelling) at sourceforge?

If that thing works for you it'll be very easy, open the device via the dll functions and you got a channel you can use for whatever protocoll your hardware implements.

I'm using boards having Phillips PDIUSB12 chips for coupling AVR micros but it does not work flawlessly, but it's woth trying.

And there is a linux version, too. This would make your hardware cross platform, if it works ...

HTH,
Marc

En/na Bisma Jayadi ha escrit:

> What kind of windows driver? First choose that. There are lot´s and > lot´s of types of windows drivers. Device driver for a custom hardware connected through USB port.

I'm currently writing an "usermode" device driver for an USB device (a voip phone) using libusb (a c library) under linux. There's a pascal unit with the translated headers (don't remember where but google is your friend) and it's working quite well, there should also be a windows version of the library.
The only downside it that the current (quite old) version of the library doesn't do asynch i/o. With my device I can use 2 threads (one for writing and one for reading) but it's not guaranteed to work in every case. http://libusb.sourceforge.net

Bye

just to chime in here, libusb is probably the easiest way to go here. we've been using the ftdi and cypress chips under windows and linux with (almost) the same code (pascal and c). got them to work on arm, too :)

have a look at the libusb mailing list, as they're going through some api changes now. i'm hopeful for the asynchronous io.

good luck
henry