Mailing list (newsgroup) changed because this is reasonably on topic for
NTDEV, but is pretty far afield of NTFSD.
I can’t speak for the OP, but in our case, it was to isolate
device-independent behavior from device-dependent behaviour. I suppose you
could say we had created our own private bus driver interface. The main
reason for doing it with a DLL instead of a driver is that a DLL is
inherently portable across OS’es, and a driver is not. In our case, we
specifically limited the DLL to the exports provided by our private
interface, so we were portable to other OS’es that implemented the private
API. Since our architecture was originally designed to carry the DLL inside
of the device, it was the right architecture for that particular
application. I’m not saying that it was the best architecture for what I
was doing with it (it most certainly wasn’t) but it did work.
Before I get tarred and feathered, let me say that I don’t advocate doing
this in a driver that would ever land on a system that someone depends on,
whether it’s an enterprise server, or my mother-in-law’s e-mail machine. I
used it as a research tool.
I’m actually quite curious to know what the OP wants to do with it?
Related question, with a bit of a twist. How would you architect the
following?
You have a bunch of disparate PCI devices that are all of the same general
class, to which you want to do the same things across them all. Sounds like
a port-miniport model, right? Did I mention that it needs to be portable to
other OS’es? What if you find that, within Windows, anyway, the SCSI
miniport does 90% of what you need, and about 10% is device specific?
-
Do you write N different miniports, linking in the 90% as a common lib?
You need to define the API between the common code and the device-specific
module anyway. How do you support a new device if the vendor doesn’t want
to reveal the IP necessary to twiddle his bits in the way you want to? Hand
him the common lib (with source) and API and ask him to give you the binary
of a miniport? He could give back a lib for the highly likely occasion that
the common module would need bugs fixed. -
Or do you define an API for the device-specific 10% and write a DLL and
load it at init time? Now if you need to add support for a new PCI device,
you ask the vendor to write the DLL to the API and you’re ready to go?
Since it’s a DLL, you can have a user-mode test harness to do a lot of
debugging and validation before you ever have to stuff it into the kernel.
Seems like it makes the vendor’s job a lot easier. -
Or do you create a mini-driver along the same model? This seems like
the most robust way, but rolling your own mini-driver interface isn’t well
documented.
Not that I’ve done any of these, or that I am necessarily going to do any of
them, but the question has come up in a test/diag environment. I wonder how
we are going to answer it? 
Phil
“Ravisankar Pudipeddi” wrote in message
news:xxxxx@ntfsd…
What exactly would be the point of dynamically loading & calling a DLL
which was written to be run in user-mode, which may or may not
statically link to other user-mode DLLs, when there’s a perfectly
straightforward way to export kernel APIs via a driver?
I’m just trying to find out the motivation, it may help to know what the
purpose is.
Ravi