inf files versus dynamic loading of drivers

NTDEV
1

hi

I am taking over a simple driver that does simple I/O. This driver doesn’t use an inf file to install. Instead it has an application associated with it that manages it. This app actually uses Service Control Manager calls to install and uninstall the driver, etc.

My gut feel on this is that this adds unnecessary layers of abstraction and more things to go wrong with all the installing and uninstalling going on.

Just curious about what you have done…and if you had any strong thoughts one way or the other.

I was thinking of just putting together a (null) inf file and have it loaded once during boot-up automatically. (I haven’t put one of these inf files together before, but I know there is a sample somewhere in the DDK.)

thanks

2

S. Drasnin wrote:

I am taking over a simple driver that does simple I/O. This driver
doesn’t use an inf file to install. Instead it has an application
associated with it that manages it. This app actually uses Service
Control Manager calls to install and uninstall the driver, etc.

My gut feel on this is that this adds unnecessary layers of
abstraction and more things to go wrong with all the installing and
uninstalling going on.

Just curious about what you have done…and if you had any strong
thoughts one way or the other.

I was thinking of just putting together a (null) inf file and have it
loaded once during boot-up automatically. (I haven’t put one of these
inf files together before, but I know there is a sample somewhere in
the DDK.)

“Unnecessary layers of abstraction”? The service control manager calls
do almost nothing. They manipulate a few settings in the registry, and
they cause the driver to be loaded. These are not complicated and
heavyweight operations. Remember that, prior to Windows 2000, ***ALL***
NT drivers were loaded via the service control manager. This is a
process that is well-tested and well-understood.

The advantage of SCM is that you can control the lifetime, rather than
forcing the driver to be loaded at boot and live until shutdown.

If you have a PnP event that can trigger the device, then an INF is
clearly the way to go. If not, then there is nothing wrong with using SCM.

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

3

Thanks - I didn’t know that about Windows 2000. I always thought people have always been suffering with putting together inf files.

I think an issue with the Service Control Manager calls is they require administrative privileges.
So, if a user logged into the PC didn’t have administrative privileges the calls would fail.

I haven’t looked at how easy it is to get around the privilege issue, but that seems to be the biggest issue.
(These particular apps can be run by anyone.)

That issue alone seems like a good reason to put together a null inf file.

Also, the function of the driver is such that it needs to be loaded always. The app should always be running and should never go away. No reason for it to be unloaded and reloaded multiple times.

Do you still disagree? (I do want to make sure I do the right thing.)

thanks very much for the input…

----- Original Message -----
From: Tim Robertsmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: June 21, 2006 8:59 AM
Subject: Re: [ntdev] inf files versus dynamic loading of drivers

S. Drasnin wrote:

>
> I am taking over a simple driver that does simple I/O. This driver
> doesn’t use an inf file to install. Instead it has an application
> associated with it that manages it. This app actually uses Service
> Control Manager calls to install and uninstall the driver, etc.
>
> My gut feel on this is that this adds unnecessary layers of
> abstraction and more things to go wrong with all the installing and
> uninstalling going on.
>
> Just curious about what you have done…and if you had any strong
> thoughts one way or the other.
>
> I was thinking of just putting together a (null) inf file and have it
> loaded once during boot-up automatically. (I haven’t put one of these
> inf files together before, but I know there is a sample somewhere in
> the DDK.)

“Unnecessary layers of abstraction”? The service control manager calls
do almost nothing. They manipulate a few settings in the registry, and
they cause the driver to be loaded. These are not complicated and
heavyweight operations. Remember that, prior to Windows 2000, ALL
NT drivers were loaded via the service control manager. This is a
process that is well-tested and well-understood.

The advantage of SCM is that you can control the lifetime, rather than
forcing the driver to be loaded at boot and live until shutdown.

If you have a PnP event that can trigger the device, then an INF is
clearly the way to go. If not, then there is nothing wrong with using SCM.

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

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

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

4

S. Drasnin wrote:

Thanks - I didn’t know that about Windows 2000. I always thought
people have always been suffering with putting together inf files.

I think an issue with the Service Control Manager calls is they
require administrative privileges.
So, if a user logged into the PC didn’t have administrative privileges
the calls would fail.

Installing an unsigned PnP driver with an INF file also requires
administrative privileges, but just once.

I haven’t looked at how easy it is to get around the privilege issue,
but that seems to be the biggest issue.
(These particular apps can be run by anyone.)

That issue alone seems like a good reason to put together a null inf
file.

Also, the function of the driver is such that it needs to be loaded
always. The app should always be running and should never go away. No
reason for it to be unloaded and reloaded multiple times.

In that case, then I think either solution is workable. Using an INF
would allow the device to show up in Device Manager, which can be a benefit.

Do you still disagree? (I do want to make sure I do the right thing.)

Really, whether I agree or not is mostly irrelevant. I’m pointing out
possible flawed assumptions, not stamping my foot and insisting you do
things my way. Either approach would work, and you have to use the one
that makes sense to you and satisfies your constraints.

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

5

Given that you have an application that is always running and never goes
away, which wants to load a driver which never goes away, why not simply
make the application a service existing in a LocalXxxx context? Given the
right context, the application, as a service, will have the privileges it
needs to load the driver…

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Wednesday, June 21, 2006 2:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] inf files versus dynamic loading of drivers

Thanks - I didn’t know that about Windows 2000. I always thought people
have always been suffering with putting together inf files.

I think an issue with the Service Control Manager calls is they require
administrative privileges.

So, if a user logged into the PC didn’t have administrative privileges the
calls would fail.

I haven’t looked at how easy it is to get around the privilege issue, but
that seems to be the biggest issue.

(These particular apps can be run by anyone.)

That issue alone seems like a good reason to put together a null inf file.

Also, the function of the driver is such that it needs to be loaded
always. The app should always be running and should never go away. No
reason for it to be unloaded and reloaded multiple times.

Do you still disagree? (I do want to make sure I do the right thing.)

thanks very much for the input…

----- Original Message -----

From: Tim mailto:xxxxx Roberts

To: Windows System Software Devs Interest List
mailto:xxxxx

Sent: June 21, 2006 8:59 AM

Subject: Re: [ntdev] inf files versus dynamic loading of drivers

S. Drasnin wrote:

>
> I am taking over a simple driver that does simple I/O. This driver
> doesn’t use an inf file to install. Instead it has an application
> associated with it that manages it. This app actually uses Service
> Control Manager calls to install and uninstall the driver, etc.
>
> My gut feel on this is that this adds unnecessary layers of
> abstraction and more things to go wrong with all the installing and
> uninstalling going on.
>
> Just curious about what you have done…and if you had any strong
> thoughts one way or the other.
>
> I was thinking of just putting together a (null) inf file and have it
> loaded once during boot-up automatically. (I haven’t put one of these
> inf files together before, but I know there is a sample somewhere in
> the DDK.)

“Unnecessary layers of abstraction”? The service control manager calls
do almost nothing. They manipulate a few settings in the registry, and
they cause the driver to be loaded. These are not complicated and
heavyweight operations. Remember that, prior to Windows 2000, ALL
NT drivers were loaded via the service control manager. This is a
process that is well-tested and well-understood.

The advantage of SCM is that you can control the lifetime, rather than
forcing the driver to be loaded at boot and live until shutdown.

If you have a PnP event that can trigger the device, then an INF is
clearly the way to go. If not, then there is nothing wrong with using
SCM.

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

—
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</mailto:xxxxx></mailto:xxxxx>

6

Thanks for the info. I asked if you disagreed in case you thought of something else I missed - I wasn’t necessarily going to follow what you said (I’d put a wink here but then my mail will be rejected).

So I found if I go the inf route I just need a root bus inf and there is sample code in the DDK (setup\install) demonstrating that.
I think either way will work - I just need to see how the overall setup programs will work.

thanks

----- Original Message -----
From: Tim Robertsmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: June 21, 2006 1:10 PM
Subject: Re: [ntdev] inf files versus dynamic loading of drivers

S. Drasnin wrote:

> Thanks - I didn’t know that about Windows 2000. I always thought
> people have always been suffering with putting together inf files.
>
> I think an issue with the Service Control Manager calls is they
> require administrative privileges.
> So, if a user logged into the PC didn’t have administrative privileges
> the calls would fail.

Installing an unsigned PnP driver with an INF file also requires
administrative privileges, but just once.

> I haven’t looked at how easy it is to get around the privilege issue,
> but that seems to be the biggest issue.
> (These particular apps can be run by anyone.)
>
> That issue alone seems like a good reason to put together a null inf
> file.
>
> Also, the function of the driver is such that it needs to be loaded
> always. The app should always be running and should never go away. No
> reason for it to be unloaded and reloaded multiple times.

In that case, then I think either solution is workable. Using an INF
would allow the device to show up in Device Manager, which can be a benefit.

> Do you still disagree? (I do want to make sure I do the right thing.)

Really, whether I agree or not is mostly irrelevant. I’m pointing out
possible flawed assumptions, not stamping my foot and insisting you do
things my way. Either approach would work, and you have to use the one
that makes sense to you and satisfies your constraints.

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

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

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

7

S. Drasnin wrote:

Thanks for the info. I asked if you disagreed in case you thought of
something else I missed - I wasn’t necessarily going to follow what
you said (I’d put a wink here but then my mail will be rejected).

So I found if I go the inf route I just need a root bus inf and there
is sample code in the DDK (setup\install) demonstrating that.
I think either way will work - I just need to see how the overall
setup programs will work.

I think that’s exactly correct.

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

8

Keep in mind that old-style drivers loaded from SCM will prevent power change operations from happening, if I recall correctly. This is because they have no PnP interface, so can’t vote on whether a shutdown would be “safe”, nor can they condition the hardware for shutdown. If this is a PC that always stays up this isn’t a problem. If this is a battery operated laptop that needs to go into low power modes and sleep modes, this might be a BIG problem.

Using an INF file can get around this, but you also have to convert the driver to a PnP structure, which is very much NOT the most trivial programming operation in the world. I’d personally only want to do this if it was absolutely necessary, and then I’d consider rewriting the driver from scratch, probably in KMDF these days.

I think you can use an INF to install a legacy driver also, if you can figure out the magic incantations. I personally wouldn’t bother.

BTW, note that you don’t have to load and unload the driver with SCM on every invocation of your application. If you load the driver once and don’t unload it, it will be there forever more, ready to be used when your app starts and opens it. So you could have a litlte one-line application program that does nothing but call the standard function ripped out of the DDK example that loads a driver. You need admin privs to run that one app during install time. But then your normal app just opens the driver like any other file, and doesn’t need any magic privs (at least as far as opening the driver is concerned).

Loren

9

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Loren Wilton[SMTP:xxxxx@earthlink.net]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, June 22, 2006 4:08 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] inf files versus dynamic loading of drivers

Keep in mind that old-style drivers loaded from SCM will prevent power change operations from happening, if I recall correctly.

Sorry, this is nonsense. Accidentally, I’m just testing suspend on the computer with two legacy drivers loaded (at least). One is virtual disk driver and one IFS filter. No problem with power transitions, of course.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

10

I think the restriction only takes affect if a driver tries to claim hw
resources using the obsolete HAL APIs (at least it used to work this
way).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, June 21, 2006 8:22 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] inf files versus dynamic loading of drivers

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Loren Wilton[SMTP:xxxxx@earthlink.net]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, June 22, 2006 4:08 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] inf files versus dynamic loading of drivers

Keep in mind that old-style drivers loaded from SCM will prevent power
change operations from happening, if I recall correctly.

Sorry, this is nonsense. Accidentally, I’m just testing suspend on the
computer with two legacy drivers loaded (at least). One is virtual disk
driver and one IFS filter. No problem with power transitions, of course.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

11

>I think an issue with the Service Control Manager calls is they require

administrative privileges.
So, if a user logged into the PC didn’t have administrative privileges the
calls
would fail.

Correct, no one can install a driver to the OS without the admin privileges.

Do the SCM work from the installer, not from the app, and require the installer
to run as admin (a normal requirement).

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

12

>Sorry, this is nonsense. Accidentally, I’m just testing suspend on the
computer

with two legacy drivers loaded (at least). One is virtual disk driver and one
IFS
filter. No problem with power transitions, of course.

Correct. It is not the fact of having the non-PnP driver which fails power
management, but calling the non-PnP hardware-related routines like
HalAssignSlotResources.

The hardware drivers must be PnP from w2k up, not so on software-only kernel
modules.

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