windows services

NTDEV
1

Sorry if off-topic - but since someone mentioned “services”: I read they run
in a different “Windows Station” so cannot exchange windows messages with
visible apps. Does anyone know if “shared memory” using a mapped file object
still works between different Windows stations - I have a “background” app
I’d like to move to a service, but it must share memory space with a
realtime visible app.

Anyone suggest a better forum if this is too far off for taste?

----- Original Message -----
From: Roddy, Mark
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 1:36 PM
Subject: RE: [ntdev] Message Box for errors

The service application is trivial: templates exist in the VS
distribution in several programming languages; you just need to fill in
the blanks. The service could of course do the firmware download all on
its own and make the problem disappear.

2

Mike,

Have you considered RPC (or (D)COM)? This would atleast put you in a
postion to handle the security (validate the identity of / privleges of
client) issues. You would also avoid the non-sense of kernel object
namespaces on Terminal Services, etc. and perhaps be in a better position to
handle desktop switches, etc. The pattern you are apparently trying to
implement is a pretty common one (trusted service, not so trusted UI). The
RPC model (or COM) is often leveraged to solve it.

The ‘Desktop’ is the containment for Windows messages. It does not effect
lower (kernel) entities like file mappings, events, etc. Those are all
kernel handle objects and are not scoped to a desktop. That is a long way
to say yes to your question.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 9:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] windows services

Sorry if off-topic - but since someone mentioned “services”: I read they run
in a different “Windows Station” so cannot exchange windows messages with
visible apps. Does anyone know if “shared memory” using a mapped file object
still works between different Windows stations - I have a “background” app
I’d like to move to a service, but it must share memory space with a
realtime visible app.

Anyone suggest a better forum if this is too far off for taste?

----- Original Message -----
From: Roddy, Mark
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 1:36 PM
Subject: RE: [ntdev] Message Box for errors

The service application is trivial: templates exist in the VS
distribution in several programming languages; you just need to fill in
the blanks. The service could of course do the firmware download all on
its own and make the problem disappear.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

Hi Dave

Thanks for the informative reply. Actually I realise it is relevant to
driver development because I suppose services are possibly the missing link
between the user app and the kernel driver. Basically I have untrusted apps
that link with my DLL to share a lot of realtime data with my kernel driver
and I’m considering a “fairly trusted” service to sit between the two to
administer the system. The need for shared memory is so they can all see
realtime buffers at once, but something like RPC with the service may be
possible if the administrating service does not need to see the actual
realtime data…

I suppose its an issue in system design (as usual after most of it is
written - sigh)… Mike

From: David R. Cattley
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 2:31 PM
Subject: RE: [ntdev] windows services

Mike,

Have you considered RPC (or (D)COM)? This would atleast put you in a
postion to handle the security (validate the identity of / privleges of
client) issues. You would also avoid the non-sense of kernel object
namespaces on Terminal Services, etc. and perhaps be in a better position to
handle desktop switches, etc. The pattern you are apparently trying to
implement is a pretty common one (trusted service, not so trusted UI). The
RPC model (or COM) is often leveraged to solve it.

The ‘Desktop’ is the containment for Windows messages. It does not effect
lower (kernel) entities like file mappings, events, etc. Those are all
kernel handle objects and are not scoped to a desktop. That is a long way
to say yes to your question.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 9:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] windows services

Sorry if off-topic - but since someone mentioned “services”: I read they run
in a different “Windows Station” so cannot exchange windows messages with
visible apps. Does anyone know if “shared memory” using a mapped file object
still works between different Windows stations - I have a “background” app
I’d like to move to a service, but it must share memory space with a
realtime visible app.

Anyone suggest a better forum if this is too far off for taste?

----- Original Message -----
From: Roddy, Mark
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 1:36 PM
Subject: RE: [ntdev] Message Box for errors

The service application is trivial: templates exist in the VS
distribution in several programming languages; you just need to fill in
the blanks. The service could of course do the firmware download all on
its own and make the problem disappear.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

I don’t think it’s off topic since I’m currently taking a driver and
moving it’s functionality down to a service to avoid having to WHQL it,
which it probably could not pass. Actually the tasks we were performing in
the driver are better done at a level higher than a driver. Since our
buffers are built around smartcards, our buffer sizes remain fairly small,
with an occasional max of about 64k, our design implements named pipes for
inter-process communication (IPC).

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 8:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] windows services

Sorry if off-topic - but since someone mentioned “services”: I read they
run
in a different “Windows Station” so cannot exchange windows messages with
visible apps. Does anyone know if “shared memory” using a mapped file
object
still works between different Windows stations - I have a “background” app

I’d like to move to a service, but it must share memory space with a
realtime visible app.

Anyone suggest a better forum if this is too far off for taste?

----- Original Message -----
From: Roddy, Mark
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 1:36 PM
Subject: RE: [ntdev] Message Box for errors

The service application is trivial: templates exist in the VS
distribution in several programming languages; you just need to fill in
the blanks. The service could of course do the firmware download all on
its own and make the problem disappear.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

What you’re proposing is a fairly common, supported scenario. Driver
talks to service via file handles, apps talk to service via X, where X
varies.

There are many, many ways to communicate between user-mode processes.
If your application protocol consists of mostly request/reply
transactions, then DCE RPC is well-suited for this, and in fact many
Windows services are implemented this way. DCOM is roughly the same
thing, but more objecty. It’s clearly got *enterprise*, as the folks
over at thedailywtf.com would say. If your application protocol is more
complex, then you can always pick and choose which Win32 communication
primitives make the most sense – shared memory, events, semaphores,
named pipes, mailslots, sockets… so many mechanisms.

Before you go down that route, though, consider whether it’s really
necessary. You’ll be adding another component to your design, which
makes testing more difficult, and generates a lot more combinations of
failure modes at run-time. I’m not saying “bad!” – I’m saying the
choice is a non-trivial design trade-off.

App->service->driver tends to be a good design when the service is
adding a lot of value to the system. Often the service is managing some
persistent information, or making policy decisions that cannot be made
in the untrusted client process, or needs to allow remote clients to
access the device as well as local ones. Since services have full
access to the Win32 API, they can do lots of things that are
excruciatingly painful or impossible in drivers, such as communicating
with databases, invoking other Win32 DLLs, etc. This is also a good
design when you need to define and enforce rather elaborate security
controls over what can be done with the device – i.e. you’ve got more
going on that just read/write and a few I/O controls.

App->driver tends to be a good design when, well, the above conditions
aren’t true. Only local apps need to talk to the device. The driver is
capable of defining and enforcing its own security policy and, hence,
can be trusted to talk directly to untrusted user-mode apps. The device
is relatively stateless – that is, little or no information needs to be
retained between device start/stop, usually just some configuration
parameters.

There’s a lot more to it than that, of course. Just keep in mind that
both choices are valid, and the best choice depends on what you’re
doing, and why. My preference leans toward app->driver, unless there’s
a demonstrable need for a service to mediate access to the device.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 7:10 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] windows services

Hi Dave

Thanks for the informative reply. Actually I realise it is relevant to
driver development because I suppose services are possibly the missing
link between the user app and the kernel driver. Basically I have
untrusted apps that link with my DLL to share a lot of realtime data
with my kernel driver and I’m considering a “fairly trusted” service to
sit between the two to administer the system. The need for shared memory
is so they can all see realtime buffers at once, but something like RPC
with the service may be possible if the administrating service does not
need to see the actual realtime data…

I suppose its an issue in system design (as usual after most of it is
written - sigh)… Mike

6

And as a variation on the theme, consider APP->userDLL->Driver. For custom
devices that don’t fit a standard model, having a user space DLL providing
the interface makes a lot of sense. You can hide the driver interface, so
that if in the future it needs a change such as a service or a different
interface you can easily do it.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Arlie Davis” wrote in message news:xxxxx@ntdev…
What you’re proposing is a fairly common, supported scenario. Driver
talks to service via file handles, apps talk to service via X, where X
varies.

There are many, many ways to communicate between user-mode processes.
If your application protocol consists of mostly request/reply
transactions, then DCE RPC is well-suited for this, and in fact many
Windows services are implemented this way. DCOM is roughly the same
thing, but more objecty. It’s clearly got enterprise, as the folks
over at thedailywtf.com would say. If your application protocol is more
complex, then you can always pick and choose which Win32 communication
primitives make the most sense – shared memory, events, semaphores,
named pipes, mailslots, sockets… so many mechanisms.

Before you go down that route, though, consider whether it’s really
necessary. You’ll be adding another component to your design, which
makes testing more difficult, and generates a lot more combinations of
failure modes at run-time. I’m not saying “bad!” – I’m saying the
choice is a non-trivial design trade-off.

App->service->driver tends to be a good design when the service is
adding a lot of value to the system. Often the service is managing some
persistent information, or making policy decisions that cannot be made
in the untrusted client process, or needs to allow remote clients to
access the device as well as local ones. Since services have full
access to the Win32 API, they can do lots of things that are
excruciatingly painful or impossible in drivers, such as communicating
with databases, invoking other Win32 DLLs, etc. This is also a good
design when you need to define and enforce rather elaborate security
controls over what can be done with the device – i.e. you’ve got more
going on that just read/write and a few I/O controls.

App->driver tends to be a good design when, well, the above conditions
aren’t true. Only local apps need to talk to the device. The driver is
capable of defining and enforcing its own security policy and, hence,
can be trusted to talk directly to untrusted user-mode apps. The device
is relatively stateless – that is, little or no information needs to be
retained between device start/stop, usually just some configuration
parameters.

There’s a lot more to it than that, of course. Just keep in mind that
both choices are valid, and the best choice depends on what you’re
doing, and why. My preference leans toward app->driver, unless there’s
a demonstrable need for a service to mediate access to the device.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 7:10 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] windows services

Hi Dave

Thanks for the informative reply. Actually I realise it is relevant to
driver development because I suppose services are possibly the missing
link between the user app and the kernel driver. Basically I have
untrusted apps that link with my DLL to share a lot of realtime data
with my kernel driver and I’m considering a “fairly trusted” service to
sit between the two to administer the system. The need for shared memory
is so they can all see realtime buffers at once, but something like RPC
with the service may be possible if the administrating service does not
need to see the actual realtime data…

I suppose its an issue in system design (as usual after most of it is
written - sigh)… Mike

7

So in this scenario am I right that the userDLL runs on its own (started by
the first app) and can be linked to by each new app as it starts up - this
is like the DDK 1394 example I started with I assume. I had a problem with
understanding the data space in this model as the DLL seemed to have its own
unique data space - I couldn’t pass pointers into it from the apps. Is there
a way of doing this? That example also started the DLL using the infamous
rundll32 which for some reason fills me with horror as I don’t really
understand it and it has appeared in too many error messages in my past.
Should I learn to live with it? Thanks…Mike.

----- Original Message -----
From: Don Burn
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 3:54 PM
Subject: Re:[ntdev] windows services

And as a variation on the theme, consider APP->userDLL->Driver. For custom
devices that don’t fit a standard model, having a user space DLL providing
the interface makes a lot of sense. You can hide the driver interface, so
that if in the future it needs a change such as a service or a different
interface you can easily do it.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Arlie Davis” wrote in message news:xxxxx@ntdev…
What you’re proposing is a fairly common, supported scenario. Driver
talks to service via file handles, apps talk to service via X, where X
varies.

There are many, many ways to communicate between user-mode processes.
If your application protocol consists of mostly request/reply
transactions, then DCE RPC is well-suited for this, and in fact many
Windows services are implemented this way. DCOM is roughly the same
thing, but more objecty. It’s clearly got enterprise, as the folks
over at thedailywtf.com would say. If your application protocol is more
complex, then you can always pick and choose which Win32 communication
primitives make the most sense – shared memory, events, semaphores,
named pipes, mailslots, sockets… so many mechanisms.

Before you go down that route, though, consider whether it’s really
necessary. You’ll be adding another component to your design, which
makes testing more difficult, and generates a lot more combinations of
failure modes at run-time. I’m not saying “bad!” – I’m saying the
choice is a non-trivial design trade-off.

App->service->driver tends to be a good design when the service is
adding a lot of value to the system. Often the service is managing some
persistent information, or making policy decisions that cannot be made
in the untrusted client process, or needs to allow remote clients to
access the device as well as local ones. Since services have full
access to the Win32 API, they can do lots of things that are
excruciatingly painful or impossible in drivers, such as communicating
with databases, invoking other Win32 DLLs, etc. This is also a good
design when you need to define and enforce rather elaborate security
controls over what can be done with the device – i.e. you’ve got more
going on that just read/write and a few I/O controls.

App->driver tends to be a good design when, well, the above conditions
aren’t true. Only local apps need to talk to the device. The driver is
capable of defining and enforcing its own security policy and, hence,
can be trusted to talk directly to untrusted user-mode apps. The device
is relatively stateless – that is, little or no information needs to be
retained between device start/stop, usually just some configuration
parameters.

There’s a lot more to it than that, of course. Just keep in mind that
both choices are valid, and the best choice depends on what you’re
doing, and why. My preference leans toward app->driver, unless there’s
a demonstrable need for a service to mediate access to the device.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, June 28, 2006 7:10 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] windows services

Hi Dave

Thanks for the informative reply. Actually I realise it is relevant to
driver development because I suppose services are possibly the missing
link between the user app and the kernel driver. Basically I have
untrusted apps that link with my DLL to share a lot of realtime data
with my kernel driver and I’m considering a “fairly trusted” service to
sit between the two to administer the system. The need for shared memory
is so they can all see realtime buffers at once, but something like RPC
with the service may be possible if the administrating service does not
need to see the actual realtime data…

I suppose its an issue in system design (as usual after most of it is
written - sigh)… Mike

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

8

> I had a problem with understanding the data space in this model as the DLL

seemed to have its own unique data space - I couldn’t pass pointers into
it from the apps.
Just a reminder.
By default the DLL code (functions) are shared, but data is not.
You have to specifically make it shared, like in

#pragma data_seg(“.my_sh”) // shared variables
DWORD s_my_dword =0;
BYTE s_my_buf[4096];
#pragma data_seg() // end of shared
variables, “normal” data section starts/continues here
#pragma comment(linker, “-section:.my_sh,rws”) // THAT’s where you
you say (rws) that it’s shared and is readable/writable

Now all processes that happen to load this DLL will use the same s_my_dword
and s_my_buf.

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 11:21 AM
Subject: Re: Re:[ntdev] windows services

> So in this scenario am I right that the userDLL runs on its own (started
> by the first app) and can be linked to by each new app as it starts up -
> this is like the DDK 1394 example I started with I assume. I had a problem
> with understanding the data space in this model as the DLL seemed to have
> its own unique data space - I couldn’t pass pointers into it from the
> apps. Is there a way of doing this? That example also started the DLL
> using the infamous rundll32 which for some reason fills me with horror as
> I don’t really understand it and it has appeared in too many error
> messages in my past. Should I learn to live with it? Thanks…Mike.
>
>
> ----- Original Message -----
> From: Don Burn
> Newsgroups: ntdev
> To: Windows System Software Devs Interest List
> Sent: Wednesday, June 28, 2006 3:54 PM
> Subject: Re:[ntdev] windows services
>
>
> And as a variation on the theme, consider APP->userDLL->Driver. For
> custom
> devices that don’t fit a standard model, having a user space DLL providing
> the interface makes a lot of sense. You can hide the driver interface, so
> that if in the future it needs a change such as a service or a different
> interface you can easily do it.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> “Arlie Davis” wrote in message news:xxxxx@ntdev…
> What you’re proposing is a fairly common, supported scenario. Driver
> talks to service via file handles, apps talk to service via X, where X
> varies.
>
> There are many, many ways to communicate between user-mode processes.
> If your application protocol consists of mostly request/reply
> transactions, then DCE RPC is well-suited for this, and in fact many
> Windows services are implemented this way. DCOM is roughly the same
> thing, but more objecty. It’s clearly got enterprise, as the folks
> over at thedailywtf.com would say. If your application protocol is more
> complex, then you can always pick and choose which Win32 communication
> primitives make the most sense – shared memory, events, semaphores,
> named pipes, mailslots, sockets… so many mechanisms.
>
> Before you go down that route, though, consider whether it’s really
> necessary. You’ll be adding another component to your design, which
> makes testing more difficult, and generates a lot more combinations of
> failure modes at run-time. I’m not saying “bad!” – I’m saying the
> choice is a non-trivial design trade-off.
>
> App->service->driver tends to be a good design when the service is
> adding a lot of value to the system. Often the service is managing some
> persistent information, or making policy decisions that cannot be made
> in the untrusted client process, or needs to allow remote clients to
> access the device as well as local ones. Since services have full
> access to the Win32 API, they can do lots of things that are
> excruciatingly painful or impossible in drivers, such as communicating
> with databases, invoking other Win32 DLLs, etc. This is also a good
> design when you need to define and enforce rather elaborate security
> controls over what can be done with the device – i.e. you’ve got more
> going on that just read/write and a few I/O controls.
>
> App->driver tends to be a good design when, well, the above conditions
> aren’t true. Only local apps need to talk to the device. The driver is
> capable of defining and enforcing its own security policy and, hence,
> can be trusted to talk directly to untrusted user-mode apps. The device
> is relatively stateless – that is, little or no information needs to be
> retained between device start/stop, usually just some configuration
> parameters.
>
> There’s a lot more to it than that, of course. Just keep in mind that
> both choices are valid, and the best choice depends on what you’re
> doing, and why. My preference leans toward app->driver, unless there’s
> a demonstrable need for a service to mediate access to the device.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Wednesday, June 28, 2006 7:10 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] windows services
>
> Hi Dave
>
> Thanks for the informative reply. Actually I realise it is relevant to
> driver development because I suppose services are possibly the missing
> link between the user app and the kernel driver. Basically I have
> untrusted apps that link with my DLL to share a lot of realtime data
> with my kernel driver and I’m considering a “fairly trusted” service to
> sit between the two to administer the system. The need for shared memory
> is so they can all see realtime buffers at once, but something like RPC
> with the service may be possible if the administrating service does not
> need to see the actual realtime data…
>
> I suppose its an issue in system design (as usual after most of it is
> written - sigh)… Mike
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

9

> visible apps. Does anyone know if “shared memory” using a mapped file object

still works between different Windows stations

Yes, it is, but I would use COM instead - more secure.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

10

> Thanks for the informative reply. Actually I realise it is relevant to

driver development because I suppose services are possibly the missing link
between the user app and the kernel driver.

No need. The user app can talk to the driver directly. Services are used if you
need the user mode code which runs regardless of who is logged on.

Also service is one of the 2 possible places to keep any global state. The
kernel mode driver itself is the second.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

No, such user DLLs have no global data space, they help in the following:

  • function-style wrappers around IOCTLs
  • function-style wrapper around CreateFile, which also encapsulates the
    name and the means of getting it (like PnP interfaces).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 7:21 PM
Subject: Re: Re:[ntdev] windows services

> So in this scenario am I right that the userDLL runs on its own (started by
> the first app) and can be linked to by each new app as it starts up - this
> is like the DDK 1394 example I started with I assume. I had a problem with
> understanding the data space in this model as the DLL seemed to have its own
> unique data space - I couldn’t pass pointers into it from the apps. Is there
> a way of doing this? That example also started the DLL using the infamous
> rundll32 which for some reason fills me with horror as I don’t really
> understand it and it has appeared in too many error messages in my past.
> Should I learn to live with it? Thanks…Mike.
>
>
> ----- Original Message -----
> From: Don Burn
> Newsgroups: ntdev
> To: Windows System Software Devs Interest List
> Sent: Wednesday, June 28, 2006 3:54 PM
> Subject: Re:[ntdev] windows services
>
>
> And as a variation on the theme, consider APP->userDLL->Driver. For custom
> devices that don’t fit a standard model, having a user space DLL providing
> the interface makes a lot of sense. You can hide the driver interface, so
> that if in the future it needs a change such as a service or a different
> interface you can easily do it.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> “Arlie Davis” wrote in message news:xxxxx@ntdev…
> What you’re proposing is a fairly common, supported scenario. Driver
> talks to service via file handles, apps talk to service via X, where X
> varies.
>
> There are many, many ways to communicate between user-mode processes.
> If your application protocol consists of mostly request/reply
> transactions, then DCE RPC is well-suited for this, and in fact many
> Windows services are implemented this way. DCOM is roughly the same
> thing, but more objecty. It’s clearly got enterprise, as the folks
> over at thedailywtf.com would say. If your application protocol is more
> complex, then you can always pick and choose which Win32 communication
> primitives make the most sense – shared memory, events, semaphores,
> named pipes, mailslots, sockets… so many mechanisms.
>
> Before you go down that route, though, consider whether it’s really
> necessary. You’ll be adding another component to your design, which
> makes testing more difficult, and generates a lot more combinations of
> failure modes at run-time. I’m not saying “bad!” – I’m saying the
> choice is a non-trivial design trade-off.
>
> App->service->driver tends to be a good design when the service is
> adding a lot of value to the system. Often the service is managing some
> persistent information, or making policy decisions that cannot be made
> in the untrusted client process, or needs to allow remote clients to
> access the device as well as local ones. Since services have full
> access to the Win32 API, they can do lots of things that are
> excruciatingly painful or impossible in drivers, such as communicating
> with databases, invoking other Win32 DLLs, etc. This is also a good
> design when you need to define and enforce rather elaborate security
> controls over what can be done with the device – i.e. you’ve got more
> going on that just read/write and a few I/O controls.
>
> App->driver tends to be a good design when, well, the above conditions
> aren’t true. Only local apps need to talk to the device. The driver is
> capable of defining and enforcing its own security policy and, hence,
> can be trusted to talk directly to untrusted user-mode apps. The device
> is relatively stateless – that is, little or no information needs to be
> retained between device start/stop, usually just some configuration
> parameters.
>
> There’s a lot more to it than that, of course. Just keep in mind that
> both choices are valid, and the best choice depends on what you’re
> doing, and why. My preference leans toward app->driver, unless there’s
> a demonstrable need for a service to mediate access to the device.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Wednesday, June 28, 2006 7:10 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] windows services
>
> Hi Dave
>
> Thanks for the informative reply. Actually I realise it is relevant to
> driver development because I suppose services are possibly the missing
> link between the user app and the kernel driver. Basically I have
> untrusted apps that link with my DLL to share a lot of realtime data
> with my kernel driver and I’m considering a “fairly trusted” service to
> sit between the two to administer the system. The need for shared memory
> is so they can all see realtime buffers at once, but something like RPC
> with the service may be possible if the administrating service does not
> need to see the actual realtime data…
>
> I suppose its an issue in system design (as usual after most of it is
> written - sigh)… Mike
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

> By default the DLL code (functions) are shared, but data is not.

You have to specifically make it shared, like in

#pragma data_seg(“.my_sh”) // shared variables

Extremely unstable solution for global data.

Used widely in Win9x, and that’s why (one of the most important cases) this OS
is so unstable.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

13

It doesn’t address Mike’s concern that he has to run his DLL in RunDLL.
The answer is, no, you don’t have to run it in RunDLL. The common model is
that it’s a part of your own process, not a part of a different process.
RunDLL is way to run a DLL that includes a GUI, but doesn’t need a full
app. Unless you specifically need to run it in a separate process, you
don’t need to worry about RunDLL.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

“sh_alex”
net> To
Sent by: “Windows System Software Devs
bounce-255139-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
Re: Re:[ntdev] windows services
06/28/2006 09:39
AM

Please respond to
“Windows System
Software Devs
Interest List”
com>

> I had a problem with understanding the data space in this model as the
DLL
> seemed to have its own unique data space - I couldn’t pass pointers into
> it from the apps.
Just a reminder.
By default the DLL code (functions) are shared, but data is not.
You have to specifically make it shared, like in

#pragma data_seg(“.my_sh”) // shared variables
DWORD s_my_dword =0;
BYTE s_my_buf[4096];
#pragma data_seg() // end of shared
variables, “normal” data section starts/continues here
#pragma comment(linker, “-section:.my_sh,rws”) // THAT’s where you
you say (rws) that it’s shared and is readable/writable

Now all processes that happen to load this DLL will use the same s_my_dword

and s_my_buf.

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 11:21 AM
Subject: Re: Re:[ntdev] windows services

> So in this scenario am I right that the userDLL runs on its own (started
> by the first app) and can be linked to by each new app as it starts up -
> this is like the DDK 1394 example I started with I assume. I had a
problem
> with understanding the data space in this model as the DLL seemed to have

> its own unique data space - I couldn’t pass pointers into it from the
> apps. Is there a way of doing this? That example also started the DLL
> using the infamous rundll32 which for some reason fills me with horror as

> I don’t really understand it and it has appeared in too many error
> messages in my past. Should I learn to live with it? Thanks…Mike.
>

14

And this is a massive security hole. Any app can load the DLL and then
get access to these variables. If there is protected content in your
shared data, this is not the recommended route to go.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sh_alex
Sent: Wednesday, June 28, 2006 8:40 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] windows services

I had a problem with understanding the data space in this model as the

DLL seemed to have its own unique data space - I couldn’t pass
pointers into it from the apps.
Just a reminder.
By default the DLL code (functions) are shared, but data is not.
You have to specifically make it shared, like in

#pragma data_seg(“.my_sh”) // shared variables
DWORD s_my_dword =0;
BYTE s_my_buf[4096];
#pragma data_seg() // end of shared
variables, “normal” data section starts/continues here
#pragma comment(linker, “-section:.my_sh,rws”) // THAT’s where
you
you say (rws) that it’s shared and is readable/writable

Now all processes that happen to load this DLL will use the same
s_my_dword and s_my_buf.

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 11:21 AM
Subject: Re: Re:[ntdev] windows services

> So in this scenario am I right that the userDLL runs on its own
(started
> by the first app) and can be linked to by each new app as it starts up
-
> this is like the DDK 1394 example I started with I assume. I had a
problem
> with understanding the data space in this model as the DLL seemed to
have
> its own unique data space - I couldn’t pass pointers into it from the
> apps. Is there a way of doing this? That example also started the DLL
> using the infamous rundll32 which for some reason fills me with horror
as
> I don’t really understand it and it has appeared in too many error
> messages in my past. Should I learn to live with it? Thanks…Mike.
>
>
> ----- Original Message -----
> From: Don Burn
> Newsgroups: ntdev
> To: Windows System Software Devs Interest List
> Sent: Wednesday, June 28, 2006 3:54 PM
> Subject: Re:[ntdev] windows services
>
>
> And as a variation on the theme, consider APP->userDLL->Driver. For
> custom
> devices that don’t fit a standard model, having a user space DLL
providing
> the interface makes a lot of sense. You can hide the driver
interface, so
> that if in the future it needs a change such as a service or a
different
> interface you can easily do it.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> “Arlie Davis” wrote in message
news:xxxxx@ntdev…
> What you’re proposing is a fairly common, supported scenario. Driver
> talks to service via file handles, apps talk to service via X, where X
> varies.
>
> There are many, many ways to communicate between user-mode processes.
> If your application protocol consists of mostly request/reply
> transactions, then DCE RPC is well-suited for this, and in fact many
> Windows services are implemented this way. DCOM is roughly the same
> thing, but more objecty. It’s clearly got enterprise, as the folks
> over at thedailywtf.com would say. If your application protocol is
more
> complex, then you can always pick and choose which Win32 communication
> primitives make the most sense – shared memory, events, semaphores,
> named pipes, mailslots, sockets… so many mechanisms.
>
> Before you go down that route, though, consider whether it’s really
> necessary. You’ll be adding another component to your design, which
> makes testing more difficult, and generates a lot more combinations of
> failure modes at run-time. I’m not saying “bad!” – I’m saying the
> choice is a non-trivial design trade-off.
>
> App->service->driver tends to be a good design when the service is
> adding a lot of value to the system. Often the service is managing
some
> persistent information, or making policy decisions that cannot be made
> in the untrusted client process, or needs to allow remote clients to
> access the device as well as local ones. Since services have full
> access to the Win32 API, they can do lots of things that are
> excruciatingly painful or impossible in drivers, such as communicating
> with databases, invoking other Win32 DLLs, etc. This is also a good
> design when you need to define and enforce rather elaborate security
> controls over what can be done with the device – i.e. you’ve got more
> going on that just read/write and a few I/O controls.
>
> App->driver tends to be a good design when, well, the above conditions
> aren’t true. Only local apps need to talk to the device. The driver
is
> capable of defining and enforcing its own security policy and, hence,
> can be trusted to talk directly to untrusted user-mode apps. The
device
> is relatively stateless – that is, little or no information needs to
be
> retained between device start/stop, usually just some configuration
> parameters.
>
> There’s a lot more to it than that, of course. Just keep in mind that
> both choices are valid, and the best choice depends on what you’re
> doing, and why. My preference leans toward app->driver, unless
there’s
> a demonstrable need for a service to mediate access to the device.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Wednesday, June 28, 2006 7:10 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] windows services
>
> Hi Dave
>
> Thanks for the informative reply. Actually I realise it is relevant to
> driver development because I suppose services are possibly the missing
> link between the user app and the kernel driver. Basically I have
> untrusted apps that link with my DLL to share a lot of realtime data
> with my kernel driver and I’m considering a “fairly trusted” service
to
> sit between the two to administer the system. The need for shared
memory
> is so they can all see realtime buffers at once, but something like
RPC
> with the service may be possible if the administrating service does
not
> need to see the actual realtime data…
>
> I suppose its an issue in system design (as usual after most of it is
> written - sigh)… Mike
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

15

Sorry for not jumping back in earlier. As several people have noted no you
do not run the DLL in a seperate application, this is an encapsulation of
your drivers interface only. I would not use the shared memory segment
since it is a security hole, and it does not work across sessions.

The primary reason I advocate a user DLL is allows you to provide a clean
interface for the user application, while hiding the driver’s interface. As
was noted this means things like PnP device identification which can be a
large amount of code is not dumped into the driver. It also means that
interfaces where the application wants to do things like pass a block of
pointers, can be rationalized in user space to a single block of input data
for an IOCTL rather than opening the security holes that a pointer from user
space to the kernel can bring. Finally, you may find in the future there is
a better way to accomplish things than a driver, and having a wrapper DLL
means the applications do not have to change.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Mike Kemp” wrote in message news:xxxxx@ntdev…
> So in this scenario am I right that the userDLL runs on its own (started
> by the first app) and can be linked to by each new app as it starts up -
> this is like the DDK 1394 example I started with I assume. I had a problem
> with understanding the data space in this model as the DLL seemed to have
> its own unique data space - I couldn’t pass pointers into it from the
> apps. Is there a way of doing this? That example also started the DLL
> using the infamous rundll32 which for some reason fills me with horror as
> I don’t really understand it and it has appeared in too many error
> messages in my past. Should I learn to live with it? Thanks…Mike.
>
>
> ----- Original Message -----
> From: Don Burn
> Newsgroups: ntdev
> To: Windows System Software Devs Interest List
> Sent: Wednesday, June 28, 2006 3:54 PM
> Subject: Re:[ntdev] windows services
>
>
> And as a variation on the theme, consider APP->userDLL->Driver. For
> custom
> devices that don’t fit a standard model, having a user space DLL providing
> the interface makes a lot of sense. You can hide the driver interface, so
> that if in the future it needs a change such as a service or a different
> interface you can easily do it.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> “Arlie Davis” wrote in message news:xxxxx@ntdev…
> What you’re proposing is a fairly common, supported scenario. Driver
> talks to service via file handles, apps talk to service via X, where X
> varies.
>
> There are many, many ways to communicate between user-mode processes.
> If your application protocol consists of mostly request/reply
> transactions, then DCE RPC is well-suited for this, and in fact many
> Windows services are implemented this way. DCOM is roughly the same
> thing, but more objecty. It’s clearly got enterprise, as the folks
> over at thedailywtf.com would say. If your application protocol is more
> complex, then you can always pick and choose which Win32 communication
> primitives make the most sense – shared memory, events, semaphores,
> named pipes, mailslots, sockets… so many mechanisms.
>
> Before you go down that route, though, consider whether it’s really
> necessary. You’ll be adding another component to your design, which
> makes testing more difficult, and generates a lot more combinations of
> failure modes at run-time. I’m not saying “bad!” – I’m saying the
> choice is a non-trivial design trade-off.
>
> App->service->driver tends to be a good design when the service is
> adding a lot of value to the system. Often the service is managing some
> persistent information, or making policy decisions that cannot be made
> in the untrusted client process, or needs to allow remote clients to
> access the device as well as local ones. Since services have full
> access to the Win32 API, they can do lots of things that are
> excruciatingly painful or impossible in drivers, such as communicating
> with databases, invoking other Win32 DLLs, etc. This is also a good
> design when you need to define and enforce rather elaborate security
> controls over what can be done with the device – i.e. you’ve got more
> going on that just read/write and a few I/O controls.
>
> App->driver tends to be a good design when, well, the above conditions
> aren’t true. Only local apps need to talk to the device. The driver is
> capable of defining and enforcing its own security policy and, hence,
> can be trusted to talk directly to untrusted user-mode apps. The device
> is relatively stateless – that is, little or no information needs to be
> retained between device start/stop, usually just some configuration
> parameters.
>
> There’s a lot more to it than that, of course. Just keep in mind that
> both choices are valid, and the best choice depends on what you’re
> doing, and why. My preference leans toward app->driver, unless there’s
> a demonstrable need for a service to mediate access to the device.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Wednesday, June 28, 2006 7:10 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] windows services
>
> Hi Dave
>
> Thanks for the informative reply. Actually I realise it is relevant to
> driver development because I suppose services are possibly the missing
> link between the user app and the kernel driver. Basically I have
> untrusted apps that link with my DLL to share a lot of realtime data
> with my kernel driver and I’m considering a “fairly trusted” service to
> sit between the two to administer the system. The need for shared memory
> is so they can all see realtime buffers at once, but something like RPC
> with the service may be possible if the administrating service does not
> need to see the actual realtime data…
>
> I suppose its an issue in system design (as usual after most of it is
> written - sigh)… Mike
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

16

Mike Kemp wrote:

… That example also started the DLL using the infamous rundll32
which for some reason fills me with horror as I don’t really
understand it and it has appeared in too many error messages in my
past. Should I learn to live with it?

Do not be afraid of rundll32.exe. Rundll32 is your friend. It is a
very simple program, serving a very specific task, which can actually be
understood rather well just by tracing the disassembly in a debugger.
It does a LoadLibrary, it does a GetProcAddress, and it calls the entry
point with four parameters, including a pointer to the remainder of the
command line.

The reason it causes confusion is because people think it does a lot
more than it does. It does not parse the parameters. People have tried
this, for example:
rundll32 myfancy.dll,MyFancyEntryPoint 0,3,0x9123
thinking that it will turn those three numbers into three parameters.
Not so. Rundll32 calls the entry point with the same four parameters
that WinMain gets. The tail of the command line (“0,3,0x9124”) is
passed as a string as the third parameter.

“But wait”, you say. “I’ve seen rundll32 used to call entry points that
don’t match that signature, and that don’t even expect 4 parameters!”
True. Rundll32 disables the error mode, so that even if a stack fault
occurs when the function returns, you don’t see it. The process is
terminated, but you don’t care because your function has done its duty.

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

17

Thanks, one and all. Great food for thought. I think I feel a plan B coming
on…Mike

----- Original Message -----
From: xxxxx@seagate.com
To: Windows System Software Devs Interest List
Sent: Wednesday, June 28, 2006 4:57 PM
Subject: Re: Re:[ntdev] windows services

It doesn’t address Mike’s concern that he has to run his DLL in RunDLL.
The answer is, no, you don’t have to run it in RunDLL. The common model is
that it’s a part of your own process, not a part of a different process.
RunDLL is way to run a DLL that includes a GUI, but doesn’t need a full
app. Unless you specifically need to run it in a separate process, you
don’t need to worry about RunDLL.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

“sh_alex”
net> To
Sent by: “Windows System Software Devs
bounce-255139-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
Re: Re:[ntdev] windows services
06/28/2006 09:39
AM

Please respond to
“Windows System
Software Devs
Interest List”
com>

> I had a problem with understanding the data space in this model as the
DLL
> seemed to have its own unique data space - I couldn’t pass pointers into
> it from the apps.
Just a reminder.
By default the DLL code (functions) are shared, but data is not.
You have to specifically make it shared, like in

#pragma data_seg(“.my_sh”) // shared variables
DWORD s_my_dword =0;
BYTE s_my_buf[4096];
#pragma data_seg() // end of shared
variables, “normal” data section starts/continues here
#pragma comment(linker, “-section:.my_sh,rws”) // THAT’s where you
you say (rws) that it’s shared and is readable/writable

Now all processes that happen to load this DLL will use the same s_my_dword

and s_my_buf.

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 11:21 AM
Subject: Re: Re:[ntdev] windows services

> So in this scenario am I right that the userDLL runs on its own (started
> by the first app) and can be linked to by each new app as it starts up -
> this is like the DDK 1394 example I started with I assume. I had a
problem
> with understanding the data space in this model as the DLL seemed to have

> its own unique data space - I couldn’t pass pointers into it from the
> apps. Is there a way of doing this? That example also started the DLL
> using the infamous rundll32 which for some reason fills me with horror as

> I don’t really understand it and it has appeared in too many error
> messages in my past. Should I learn to live with it? Thanks…Mike.
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

18

> It doesn’t address Mike’s concern that he has to run his DLL in RunDLL.

The answer is, no, you don’t have to run it in RunDLL.
That’s why I reminded what I reminded.

It is a way to go under some (special) circumstances, but I said only what I
said: how it’s done, if need be.

Yes, it automatically creates a security hole, and I’d add that synching
this stuff (several apps - one driver) adds to the trouble.

What I would do and recommend, as opposed to remind, and the OP will decide
if it’s applicable, is what is always recommended on this list: asynch IOCTL
from the user app, “inverted” call scheme.

In this case a DLL still has its place but only as a
(replaceable/modifiable) wrapper over IOCTLs, not as a keeper of any data.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 28, 2006 11:57 AM
Subject: Re: Re:[ntdev] windows services

> It doesn’t address Mike’s concern that he has to run his DLL in RunDLL.
> The answer is, no, you don’t have to run it in RunDLL. The common model
> is
> that it’s a part of your own process, not a part of a different process.
> RunDLL is way to run a DLL that includes a GUI, but doesn’t need a full
> app. Unless you specifically need to run it in a separate process, you
> don’t need to worry about RunDLL.
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
>
>
>
> “sh_alex”
> > net> To
> Sent by: “Windows System Software Devs
> bounce-255139-643 Interest List”
> xxxxx@lists.osr.com
> No Phone Info cc
> Available
> Subject
> Re: Re:[ntdev] windows services
> 06/28/2006 09:39
> AM
>
>
> Please respond to
> “Windows System
> Software Devs
> Interest List”
> > com>
>
>
>
>
>
>
>> I had a problem with understanding the data space in this model as the
> DLL
>> seemed to have its own unique data space - I couldn’t pass pointers into
>> it from the apps.
> Just a reminder.
> By default the DLL code (functions) are shared, but data is not.
> You have to specifically make it shared, like in
>
> #pragma data_seg(“.my_sh”) // shared variables
> DWORD s_my_dword =0;
> BYTE s_my_buf[4096];
> #pragma data_seg() // end of shared
> variables, “normal” data section starts/continues here
> #pragma comment(linker, “-section:.my_sh,rws”) // THAT’s where you
> you say (rws) that it’s shared and is readable/writable
>
> Now all processes that happen to load this DLL will use the same
> s_my_dword
>
> and s_my_buf.
>
>
> ----- Original Message -----
> From: “Mike Kemp”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, June 28, 2006 11:21 AM
> Subject: Re: Re:[ntdev] windows services
>
>
>> So in this scenario am I right that the userDLL runs on its own (started
>> by the first app) and can be linked to by each new app as it starts up -
>> this is like the DDK 1394 example I started with I assume. I had a
> problem
>> with understanding the data space in this model as the DLL seemed to have
>
>> its own unique data space - I couldn’t pass pointers into it from the
>> apps. Is there a way of doing this? That example also started the DLL
>> using the infamous rundll32 which for some reason fills me with horror as
>
>> I don’t really understand it and it has appeared in too many error
>> messages in my past. Should I learn to live with it? Thanks…Mike.
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer