Windows service as KMDF interface

NTDEV
1

This is not exactly a driver question but your input will be appreciated.
My KMDF driver interface with user-mode applications is not straightforward. I’ve decided to write a Windows Service that will run in the background that will interface between the driver and the applications, to simplify the driver’s interface as seen from the app-writer perspective. The service should simply pass calles from an application to the driver. A call’s payload is under 1K Bytes.
I wander what will be the best implementation of the Application-Service communication. I was thinking of:

  1. Named Pipes
  2. RPC

Named Pipes are simple to implement but they require the Service to poll the incomming buffer. I’d really like it to be event driven.
RPC seems to be the right choice though I have no experience with it.

Your comments will be appreciated.

2

> RPC seems to be the right choice though I have no experience with it.

COM.

Unlike the plain C-style RPC, you have a framework called ATL for the server end.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Why a service? Why not an in process dll? Much simpler. If you go the service route, as max suggested, com (which ais over rpc) is a good way to go

d

debt from my phone

From: xxxxx@gmail.com
Sent: 4/24/2012 12:43 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Windows service as KMDF interface

This is not exactly a driver question but your input will be appreciated.
My KMDF driver interface with user-mode applications is not straightforward. I’ve decided to write a Windows Service that will run in the background that will interface between the driver and the applications, to simplify the driver’s interface as seen from the app-writer perspective. The service should simply pass calles from an application to the driver. A call’s payload is under 1K Bytes.
I wander what will be the best implementation of the Application-Service communication. I was thinking of:

  1. Named Pipes
  2. RPC

Named Pipes are simple to implement but they require the Service to poll the incomming buffer. I’d really like it to be event driven.
RPC seems to be the right choice though I have no experience with it.

Your comments will be appreciated.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

xxxxx@gmail.com wrote:

Named Pipes are simple to implement but they require the Service to poll the incomming buffer. I’d really like it to be event driven.

That’s not really true. Named pipes in Windows are basically
Microsoft’s re-invention of TCP/UDP sockets. You can do a blocking
ReadFile on a named pipe in a separate I/O thread. That’s just as good
as an event.

For that matter, sockets themselves might be a good solution.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Thank you guys for the quick & good replys:

> You can do a blocking
> ReadFile on a named pipe in a separate I/O thread. That’s just as good
> as an event.
This is probably what I need. I’ll read more about it.

> Why a service? Why not an in process dll …?
Well, the problem with my driver is that it’s interface is held for a long time by the application and the application is not necessary mine. Now, the driver is confugurable and for the configuration to be applied it needs to be disabled/enabled. To allow this, the application should register for receiving WM_DEVICECHANGE messages and to act correctly on them. This cannot be part of my interface. In addition, console applications cannot register for such notification.
I can, indeed create an interface DLL that will open a hidden window that will implement this functionality on behalf of the end-user’s application. But, this hidden window is actually an immitation of a service (running in session N) - so I preffer to use MS-given functionality, that is a (single) Windows Service running in session 0.

> you have a framework called ATL for the server
> sockets themselves might be a good solution
I’ll read about them. I have no knowledge of both.

Shaul

6

On 24-Apr-2012 19:25, Tim Roberts wrote:

Named pipes in Windows are basically
Microsoft’s re-invention of TCP/UDP sockets.

Except that the pipes existed before tcpip become common and netbios was
the dominant LAN protocol.

For that matter, sockets themselves might be a good solution.

Using sockets for IPC on Windows always scared me - because
of various “security” stuff hooking and filtering tcp/ip.

– pa

7

A console creating a hidden window in proc is not the equivalent of a service. You have to update the app to use the service interface, why not just require they register for notifications? Or better yet, your dll can create a hidden window and register for notifications as easily as the service. There is nothing wrong with a hidden window

d

debt from my phone

From: xxxxx@gmail.com
Sent: 4/24/2012 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows service as KMDF interface

Thank you guys for the quick & good replys:

> You can do a blocking
> ReadFile on a named pipe in a separate I/O thread. That’s just as good
> as an event.
This is probably what I need. I’ll read more about it.

> Why a service? Why not an in process dll …?
Well, the problem with my driver is that it’s interface is held for a long time by the application and the application is not necessary mine. Now, the driver is confugurable and for the configuration to be applied it needs to be disabled/enabled. To allow this, the application should register for receiving WM_DEVICECHANGE messages and to act correctly on them. This cannot be part of my interface. In addition, console applications cannot register for such notification.
I can, indeed create an interface DLL that will open a hidden window that will implement this functionality on behalf of the end-user’s application. But, this hidden window is actually an immitation of a service (running in session N) - so I preffer to use MS-given functionality, that is a (single) Windows Service running in session 0.

> you have a framework called ATL for the server
> sockets themselves might be a good solution
I’ll read about them. I have no knowledge of both.

Shaul

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

>>> you have a framework called ATL for the server

>> sockets themselves might be a good solution
I’ll read about them. I have no knowledge of both.

.NET Remoting is also an option.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

9

> A console creating a hidden window in proc is not the equivalent of a service.
Of course it is not. However, a process/window running in the background waiting for a call is similar to a service.

You have to update the app to use the service interface, why not just require
they register for notifications?
I’d love to have a simple interface conssisting of WritePacket(), OpenDev(), CloseDev() - requiring registration for both interface and handle then writing the correct disconnect/reconnect actions inside WndProc() is too much to ask from the App developper.
I’ve written a functioning app and I give it away but I dislike it.

Or better yet, your dll can create a hidden
window and register for notifications as easily as the service. There is nothing
wrong with a hidden window
This is what I first thought of. However, my driver allow up to 16 applications to open a handle to it. This may cause 16 instences of this DLL, each with it’s own disconnect/reconnect mechanism or forcing a singleton DLL (I don’t see how). Well, a Service is inherently a singleton and it can interact with both driver and applications.
Needless to say that I will have to write an interface DLL as you mentioned, that will handle the interface with the service (Via named pipe, I presume) that every app will have to load.
I see this service as part of the driver so it is assumed that the installer of the driver instals and starts this service.

10

I suppose it depends on what you are trying to optimize. The DLL’s code
pages will be shared by default and unless your interface requires massive
state, 16 copies of your working set are not likely to be much different
than the overhead of a process. On the other hand, if you use any IPC
mechanism to abstract the IOCTL interface, the call rate and throughput will
be much worse, but you might save a few hundred kilobytes of RAM. This
design does have the benefit / security hole that your service can be
accessed remotely from other computers, so if this is important to you,
choose wisely.

If you are looking for an IPC mechanism for a design like this, running a
named pipe server in the service is likely the way to go. Unless you need
to support non Windows clients, there is almost no benefit to using sockets
directly (pipes have low overhead) and message mode pipes are much simpler
and have nearly all the security features of RPC. Security will be
important for you because unlike the device interface, your service will not
have an ACL that the OS will verify for controlling access to your device
and relaying data or requests from a user process to a driver via a service
(that likely runs as local system) opens many opportunities for security
problems. Just remember to be careful and don’t pass NULL for the security
descriptor parameters.

wrote in message news:xxxxx@ntdev…

A console creating a hidden window in proc is not the equivalent of a
service.
Of course it is not. However, a process/window running in the background
waiting for a call is similar to a service.

You have to update the app to use the service interface, why not just
require
they register for notifications?
I’d love to have a simple interface conssisting of WritePacket(), OpenDev(),
CloseDev() - requiring registration for both interface and handle then
writing the correct disconnect/reconnect actions inside WndProc() is too
much to ask from the App developper.
I’ve written a functioning app and I give it away but I dislike it.

Or better yet, your dll can create a hidden
window and register for notifications as easily as the service. There is
nothing
wrong with a hidden window
This is what I first thought of. However, my driver allow up to 16
applications to open a handle to it. This may cause 16 instences of this
DLL, each with it’s own disconnect/reconnect mechanism or forcing a
singleton DLL (I don’t see how). Well, a Service is inherently a singleton
and it can interact with both driver and applications.
Needless to say that I will have to write an interface DLL as you mentioned,
that will handle the interface with the service (Via named pipe, I presume)
that every app will have to load.
I see this service as part of the driver so it is assumed that the installer
of the driver instals and starts this service.

11

Named pipes are really first-class “devices” and as such can be created
asynchronously, and I/O Completion Port notification can also be used.
I’ve never polled a named pipe in nearly twenty years.
joe

xxxxx@gmail.com wrote:
> Named Pipes are simple to implement but they require the Service to poll
> the incomming buffer. I’d really like it to be event driven.

That’s not really true. Named pipes in Windows are basically
Microsoft’s re-invention of TCP/UDP sockets. You can do a blocking
ReadFile on a named pipe in a separate I/O thread. That’s just as good
as an event.

For that matter, sockets themselves might be a good solution.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

>This may cause 16 instences of this DLL

The DLL’s code and const data sections are remapped to all processes loading it, it is not an overhead.

And, if you go named pipes, you will need to implement marshalling yourself. Any purpose of this?

Use DCOM or .NET Remoting.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

>> A console creating a hidden window in proc is not the equivalent of a

> service.
Of course it is not. However, a process/window running in the background
waiting for a call is similar to a service.
******

Well, not quite. A service can be running at a different privilege level
and with a different loging ID than the client program, so there are some
significant differences.

****

> You have to update the app to use the service interface, why not just
> require
> they register for notifications?
I’d love to have a simple interface conssisting of WritePacket(),
OpenDev(), CloseDev() - requiring registration for both interface and
handle then writing the correct disconnect/reconnect actions inside
WndProc() is too much to ask from the App developper.
I’ve written a functioning app and I give it away but I dislike it.
*****

I didn’t realize in 2012 that people still cared about “WndProc”,
programming to the native Win32 API for GUI apps. Seems horribly quaint.

Modern native code should be written in MFC, because the native API is
about as much fun as writing in assembler.

Note that if you bundle all these operations into a DLL, the app
programmer should have a simple interface. I consider it a design error
to think about a direct
CreateFile/ReadFile…WriteFile…DeviceIoControl/CloseHandle as the only
acceptable form of interface to a device; it warps your design into being
“simple” when this may be inappropriate; your *interface* to the app
should be simple, but that does not suggest that the interface always be
written at the lowest level.

******

> Or better yet, your dll can create a hidden
> window and register for notifications as easily as the service. There is
> nothing
> wrong with a hidden window
This is what I first thought of. However, my driver allow up to 16
applications to open a handle to it. This may cause 16 instences of this
DLL, each with it’s own disconnect/reconnect mechanism or forcing a
singleton DLL (I don’t see how). Well, a Service is inherently a singleton
and it can interact with both driver and applications.
Needless to say that I will have to write an interface DLL as you
mentioned, that will handle the interface with the service (Via named
pipe, I presume) that every app will have to load.
I see this service as part of the driver so it is assumed that the
installer of the driver instals and starts this service.
****

Seems an odd limitation. Why 16? But what’s this got to do with a DLL?
I don’t even see why there is a concept of a “singleton DLL”. I’m not
even sure that that means!

Named pipes have one advantage over sockets: named pipes can have security
ACLs attached, thus limiting who can connect. If you implement using
sockets, you have to provide your own security mechanisms. Note that if
you use named pipes or sockets, anyone on the network can access the
pipe/port. I think (but am not certain) there is a way to set an ACL to
limit connections to the currently-logged-in local user (someone who is an
expert in ACLs can verify or refute this idea). Or, if you want network
users to have access remotely, that’s fine, too. If you use a named pipe,
you won’t be accessible from machines outside your domain, which may be a
Good Thing or a Bad Thing depending on your goals.

Several notes: DLL code is common to all instances of the DLL (in
general…you can force weird exceptions), so the memory footprint is
smaller than 16x the memory footprint of one DLL. The unshared data
segment(s) are private, but usually there is only one, and usually it is
small, so the private space rarely exceeds one page (not counting any
dynamic allocation the DLL might do). But you have to think of this in
terms of REAL machines, not PDP-11s; 16 instances of n pages, for small
values of n, such as 1, is a meaninglessly small piece of a 2GB…4GB…16GB
physical space, and an irrelevant amount of a 2GB virtual address space.
So don’t try to optimize a nonexistent problem by imposing silly
constraints such as “code size” or “memory footprint”. Until your DLL
starts to be a megabyte or so in size, it is an irrelevant consideration.
Do the arithmetic; don’t believe what you were taught (I find that many
people today have learned from people [or books written by people] who
learned to program on the PDP-11, and therefore have inherited all the
irrelevant habits that were critical for survival when you had 64K bytes
of address space).

*****

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

14

Marshalling in this case is trivial. Have a message mode pipe for each
IOCTL. The code takes the buffer read from the pipe and directly passes it
to the driver as input. When the driver returns, take whatever output is in
the buffer and write it to the pipe. No parsing, arithmetic or other logic
is required because message mode pipes always deliver complete messages in a
single call. The big issues with this design are security and performance.
Neither of which get any better with any other IPC choice because you are
always going to be proxying your calls from a program in one security
context via a program in another one and you are always going to have the
overhead of copying data and signalling between processes.

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

This may cause 16 instences of this DLL

The DLL’s code and const data sections are remapped to all processes loading
it, it is not an overhead.

And, if you go named pipes, you will need to implement marshalling yourself.
Any purpose of this?

Use DCOM or .NET Remoting.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

Wow, you did send me reading then re-reading. I did get much useful information although some of it is a little, hmm, amotional.
Named Pipes seems to be secure enough for me. I want to limit the right to write data to the driver via the pipe to local accounts, and this seems to be feasable.
Now to the dispute between DLLs and Service. First, it seems to me that the advantages of one over the other are not overwhelming.
NTDEV says that “if you use any IPC mechanism to abstract the IOCTL interface, the call rate and throughput will be much worse” which is an important input. How can I verify this clame (appart from writing both solutions just for comparison)? Since I need the driver to be accessible for local accounts only, DLL seems to be a good choice.
Joseph M. Newcomer says: “I didn’t realize in 2012 that people still cared about “WndProc”, programming to the native Win32 API for GUI apps. Seems horribly quaint.”
I aggree. I used this as an example to what I should NOT require. MFC might simplify things but I need an interface layer (Service or DLL) to shield the application writer from these details.
In addition: “Seems an odd limitation. Why 16? But what’s this got to do with a DLL?
I don’t even see why there is a concept of a “singleton DLL”. I’m not
even sure that that means!”
Sixteen is the maximum number of joysticks supported by Windows (Up from 2 in Windows 95).
As for Singleton DLL. I find it neater (whatever this means) to have a single User-mode interface module for a KMDF driver. This can be a single instance of DLL or a service which is single by design.

At this point I tend to write a Service that will serve as a Named Pipes server. It will enforce some security policy and will be installed when the driver is installed. If I find that this architecture imposes noticeable delay on the data - I will switch into DLL.

Thank you guys!

16

I missed the last post by NTDEV but I think it is clear now that the main possible issue with Piping is performence.
BTW, my Chrome does not check spelling on this forum’s edit box. So, sorry for that…

17

> Wow, you did send me reading then re-reading. I did get much useful

information although some of it is a little, hmm, amotional.
Named Pipes seems to be secure enough for me. I want to limit the right to
write data to the driver via the pipe to local accounts, and this seems to
be feasable.
Now to the dispute between DLLs and Service. First, it seems to me that
the advantages of one over the other are not overwhelming.
NTDEV says that “if you use any IPC mechanism to abstract the IOCTL
interface, the call rate and throughput will be much worse” which is an
important input. How can I verify this clame (appart from writing both
solutions just for comparison)? Since I need the driver to be accessible
for local accounts only, DLL seems to be a good choice.
Joseph M. Newcomer says: “I didn’t realize in 2012 that people still cared
about “WndProc”, programming to the native Win32 API for GUI apps. Seems
horribly quaint.”
I aggree. I used this as an example to what I should NOT require. MFC
might simplify things but I need an interface layer (Service or DLL) to
shield the application writer from these details.
In addition: “Seems an odd limitation. Why 16? But what’s this got to do
with a DLL?
I don’t even see why there is a concept of a “singleton DLL”. I’m not
even sure that that means!”
Sixteen is the maximum number of joysticks supported by Windows (Up from 2
in Windows 95).
As for Singleton DLL. I find it neater (whatever this means) to have a
single User-mode interface module for a KMDF driver. This can be a single
instance of DLL or a service which is single by design.

At this point I tend to write a Service that will serve as a Named Pipes
server. It will enforce some security policy and will be installed when
the driver is installed. If I find that this architecture imposes
noticeable delay on the data - I will switch into DLL.

Thank you guys!

*****
Where are you going to put this “single” DLL? A DLL can live in only one
process context; if you have 16 processes using the device, there will be
logically 16 copies of the DLL. Note that in general code pages are
shared, and typically there is only one page of private data, so the
memory footprint is not worthy of discussion. Note also that each DLL
lives in its own private universe. If you wish to share information among
the DLL instances, you must create a shared-data-segment DLL or use a
memory-mapped file (it can be just a memory-mapping, non-file, but that’s
a whole weird discussion on its own). The data in this shared segment is
subject to concurrency issues and therefore locking must be provided, and
robustness in the locking (you can’t use a CRITICAL_SECTION; it *must* be
a named Mutex, and that’s a whole other discussion, too). You cannot use
certain library functions to create and manage data in this shared
segment, such as std::string, std::vector, CString, CArray, etc.
because They Do Not Play Well With Shared Memory (in the case of std::
functions, you can provide your own allocator, but that is a whole new can
of worms and is best avoided). In general, shared-segment DLLs should be
avoided if possible, only because they add new levels of complexity and
new opportunities for catastrophic failure to an app. So try to stick
with plain-vanilla DLLs (in my Systems Programming course I have a
four-hour lecture on the ins and outs of DLLs, so it is not something to
tackle lightly). In general, if you can avoid using any shared state at
the app level, your job is simpler. Key here is that you need to think
first and foremost of functionality, then ease of coding, and somewhere,
about sixty or seventy levels of priority lower, memory footprint.
Functionality can include performance, but pre-optimizing a problem is
rarely a good idea. Advice about “X is slower than Y” matter only if you
have a LOT of communication traffic between X and Y. I once had an app
which for complex historical reasons had to communicate heavily with
another app. I used PostMessage calls, and if a string had to be sent, I
sent it 4 bytes (and it was an 8-bit app) at a time. The customer called
me and said “We have a sale, but the end user requires that we handle 400
incoming messages per second”. OK, I thought, now we’re doomed because of
my slow communication. So I wrote a simulator that generated message
traffic. I saturated my network with six machines sending messages, and
the app peaked at ~1400 messages per second. So I could have spent weeks
rewriting the code when there was no problem at all. It all depends on
the data rates you need, and the simplest implementation that supports the
data rates is the right one. Everything else is usually irrelevant detail
(such as memory footprint).
joe

>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

18

Joseph M. Newcomer, I read your post very carefully. I don’t care about memory footprint. It’s at least 15 years that I don’t (As long as its not some Real-time firmware). I’m too young to have memories from the PDP11 era. I’m a VAX780 guy. Now seriously, I cannot compete with your expertese. I do have a DLL that I wrote 5 years ago, used by about 300K users, that has a shared piece of memory (memory-mapped file) and is OK but I aggree that it is preferable to keep your design as simple as possible.
Thank you very much for your enlightning input. I find it useful indeed.

19

I’m sure that on any reasonable hardware, you won’t see any noticeable delay
on an unloaded system. I still HIGHLY recommend that you don’t use a
service to proxy access to your joysticks. It adds an unnecessary layer of
complexity and introduces many additional points of failure. An interface
abstraction DLL will be less code to write, more secure by default and
perform better as well as being more natural for your clients to use (unless
you provide an interface abstraction DLL for them to use when accessing your
pipe server too). I think that you are getting hung up on design concepts
and not looking at the big picture.

In the real world, you are going to have some number of application
instances (processes) each of which is trying to access either (a) a shared
instance of your driver or (b) a dedicated instance of your driver. The
choice between a & b depends on your driver design and whether it functions
more like a com port, where there are a fixed number installed in your
system, each with a unique name, and each opened exclusively or more like a
file where many handles can be opened on the same thing as long as the
sharing does not conflict. Proxying only makes sense with model c (the one
I didn’t list, because if you control the driver and expect multiple
clients, you would never expose a single exclusive interface). So assuming
model a, consider the data and control flow for the DLL model versus the
service model

DLL model

  1. find device instances installed in this machine
  2. try to open each one until one succeeds (if all fail, then all of the
    hardware resources are in use by other processed)
  3. send an IOCTL
  • your driver will likely lock pages and queue this request; a memory
    copy may or may not occur
  1. wait for IOCTL completion using any of the standard IO processing models
    (blocking / sync, polling / select, IOCP)
  2. repeat 3 & 4 as many times as needed
  3. close the device handle

pipe server model

  1. open a pipe to the server (may fail because the server is not running,
    lack of resource, or security)
  2. send a command to the pipe server (IIRC at least two memory copies +
    UM/KM switches + thread context switches or multi-core execution)
  3. pipe server reads command from pipe and sends it to KM via IOCTL (another
    UM/KM switch)
  • your driver will likely lock pages (in the service process context)
    and queue this request; a memory copy may or may not occur
  1. the service waits form IOCTL completion. It must use blocking IO because
    the trivial pipe interface cannot handle out of order responses
  2. the IOCTL completes and the pipe server sends the result back to the
    client (again memory copies, UM/KM switches etc.)
  3. the process reads the result from the pipe and does something with it
  4. repeat steps 2 thru 6 as needed
  5. close the pipe

It should be obvious why the pipe server method will perform much worse

wrote in message news:xxxxx@ntdev…

Wow, you did send me reading then re-reading. I did get much useful
information although some of it is a little, hmm, amotional.
Named Pipes seems to be secure enough for me. I want to limit the right to
write data to the driver via the pipe to local accounts, and this seems to
be feasable.
Now to the dispute between DLLs and Service. First, it seems to me that the
advantages of one over the other are not overwhelming.
NTDEV says that “if you use any IPC mechanism to abstract the IOCTL
interface, the call rate and throughput will be much worse” which is an
important input. How can I verify this clame (appart from writing both
solutions just for comparison)? Since I need the driver to be accessible for
local accounts only, DLL seems to be a good choice.
Joseph M. Newcomer says: “I didn’t realize in 2012 that people still cared
about “WndProc”, programming to the native Win32 API for GUI apps. Seems
horribly quaint.”
I aggree. I used this as an example to what I should NOT require. MFC might
simplify things but I need an interface layer (Service or DLL) to shield the
application writer from these details.
In addition: “Seems an odd limitation. Why 16? But what’s this got to do
with a DLL?
I don’t even see why there is a concept of a “singleton DLL”. I’m not
even sure that that means!”
Sixteen is the maximum number of joysticks supported by Windows (Up from 2
in Windows 95).
As for Singleton DLL. I find it neater (whatever this means) to have a
single User-mode interface module for a KMDF driver. This can be a single
instance of DLL or a service which is single by design.

At this point I tend to write a Service that will serve as a Named Pipes
server. It will enforce some security policy and will be installed when the
driver is installed. If I find that this architecture imposes noticeable
delay on the data - I will switch into DLL.

Thank you guys!

20

On x86, it’s doable if all processes load the dll to the numerically
identical base address if they are not loaded to preferred address. Const
needs relocation which is patching .text section here and there with values
derived from load base and records in the relocation record. On amd64,
although rip-base addressing is made good use of but still can’t get rid of
base relocation.

On Tue, Apr 24, 2012 at 8:27 PM, Maxim S. Shatskih
wrote:

> >This may cause 16 instences of this DLL
>
> The DLL’s code and const data sections are remapped to all processes
> loading it, it is not an overhead.
>
> And, if you go named pipes, you will need to implement marshalling
> yourself. Any purpose of this?
>
> Use DCOM or .NET Remoting.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>