WDF co-installer v1.9 has dependencies on Vista OS.

NTDEV
21

We do support SxS for different versions of the framework. Right now this is limited to major version numbers (of which there is only 1, v1). One of our initial investigations during kmdf v1.0 was to see what the support story for minor versions would be (and touching back on the previous mention of the CLR), what support policies would need to be in place (such as never allow vx.y to bind to vx.y+1 or always force the new minor version or something in between) by allowing it. This was reviewed by our team and a whole bunch of other teams (like the windows architecture group and some CLR guys) and it was decided that it was too complicated and the additional flexibility was not worth the cost in terms of code, complexity to implement, and complexity to administer. KISS ruled, keeping only minor version in memory for any major version has kept the code simpler over time and made it easier to focus our efforts in other areas of the code.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, December 21, 2009 10:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

David R. Cattley wrote:

Is it difficult to change the KMDF loader behavior so that adding a driver
that installs 1.11 does not require a reboot if drivers are currently
running against 1.10? In other words, an explicit ‘make before break’
upgrade? The drivers presently bound to 1.10 could remain so bound until
they unload and reload, whereby the loader stub could bind them to the later
1.11 binary.

This would require some pretty obscure magic. It is certainly possible
to replace a driver binary while the driver is loaded (unlike a
user-mode executable), but new devices will continue to use the
in-memory version until it unloads. So, your driver that needs 1.11
would link to the loaded 1.10 KMDF until reboot.

Perhaps there are implementation details
that prevent having ‘side-by-side’ implementations loaded simultaneously
(and if so, that is too bad).

Barring magic, I think that is exactly the case.

It’s a tough situation. Given the desire to allow all KMDF-based
drivers to share in the benefits of the most recent library, there just
isn’t a good solution to this problem. They could have called the
driver “wdf01005.sys” and “wdf01007.sys” and “wdf01009.sys”, but that
means a driver using 1.5 would use 1.5 forever, which is exactly the
situation they were trying to avoid. (That’s also one of the arguments
against static linking.)

I guess they could have used the separate driver names, then updated all
of the binaries at once to the newest version. That would allow the
situation you describe, but it seems a little silly.

In the end, I think the “reboot” required problem is less of an issue
than we think. When a new KMDF comes out, there is a whole spate of
“not another reboot!” complaints, but as soon as the new library gets
spread around, it’s not a problem any more.

–
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

22

By default, you can swap user mode loaded binaries if you rename away the loaded file first.

  • S

-----Original Message-----
From: Tim Roberts
Sent: Monday, December 21, 2009 10:36
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

David R. Cattley wrote:
> Is it difficult to change the KMDF loader behavior so that adding a driver
> that installs 1.11 does not require a reboot if drivers are currently
> running against 1.10? In other words, an explicit ‘make before break’
> upgrade? The drivers presently bound to 1.10 could remain so bound until
> they unload and reload, whereby the loader stub could bind them to the later
> 1.11 binary.
>

This would require some pretty obscure magic. It is certainly possible
to replace a driver binary while the driver is loaded (unlike a
user-mode executable), but new devices will continue to use the
in-memory version until it unloads. So, your driver that needs 1.11
would link to the loaded 1.10 KMDF until reboot.

> Perhaps there are implementation details
> that prevent having ‘side-by-side’ implementations loaded simultaneously
> (and if so, that is too bad).
>

Barring magic, I think that is exactly the case.

It’s a tough situation. Given the desire to allow all KMDF-based
drivers to share in the benefits of the most recent library, there just
isn’t a good solution to this problem. They could have called the
driver “wdf01005.sys” and “wdf01007.sys” and “wdf01009.sys”, but that
means a driver using 1.5 would use 1.5 forever, which is exactly the
situation they were trying to avoid. (That’s also one of the arguments
against static linking.)

I guess they could have used the separate driver names, then updated all
of the binaries at once to the newest version. That would allow the
situation you describe, but it seems a little silly.

In the end, I think the “reboot” required problem is less of an issue
than we think. When a new KMDF comes out, there is a whole spate of
“not another reboot!” complaints, but as soon as the new library gets
spread around, it’s not a problem any more.

–
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

23

I should have been more careful to not imply (or even request) a particular
method of achieving the result but instead have been more clear about the
‘effect’.

The effect I was going for was that the decision to bind to the library
(driver), when made, would always pick the ‘latest’ version. That way, a
driver built against 1.10 would still use 1.11 if 1.11 were on the system at
the time it loaded.

I agree (Tim) that the entire thing is perhaps more work than worthwhile
since minor releases are infrequent.

Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, December 21, 2009 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

David R. Cattley wrote:

Is it difficult to change the KMDF loader behavior so that adding a driver
that installs 1.11 does not require a reboot if drivers are currently
running against 1.10? In other words, an explicit ‘make before break’
upgrade? The drivers presently bound to 1.10 could remain so bound until
they unload and reload, whereby the loader stub could bind them to the
later
1.11 binary.

This would require some pretty obscure magic. It is certainly possible
to replace a driver binary while the driver is loaded (unlike a
user-mode executable), but new devices will continue to use the
in-memory version until it unloads. So, your driver that needs 1.11
would link to the loaded 1.10 KMDF until reboot.

Perhaps there are implementation details
that prevent having ‘side-by-side’ implementations loaded simultaneously
(and if so, that is too bad).

Barring magic, I think that is exactly the case.

It’s a tough situation. Given the desire to allow all KMDF-based
drivers to share in the benefits of the most recent library, there just
isn’t a good solution to this problem. They could have called the
driver “wdf01005.sys” and “wdf01007.sys” and “wdf01009.sys”, but that
means a driver using 1.5 would use 1.5 forever, which is exactly the
situation they were trying to avoid. (That’s also one of the arguments
against static linking.)

I guess they could have used the separate driver names, then updated all
of the binaries at once to the newest version. That would allow the
situation you describe, but it seems a little silly.

In the end, I think the “reboot” required problem is less of an issue
than we think. When a new KMDF comes out, there is a whole spate of
“not another reboot!” complaints, but as soon as the new library gets
spread around, it’s not a problem any more.

–
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

24

> While static linking would solve some problems, it creates other

problems as well. This includes making patching any bugs in WDF much
harder and increasing the in-memory size of the kernel. While a single
driver statically linked will only add ~.5 MB, this can quickly add up
and there is a very real pressure to reduce the memory footprint of
windows, especially for netbooks and VM server environments.

With that being said we are investigating other ways that we can avoid
reboots and your feedback has certainly been heard.

Can I ask why KMDF seems to be in some sort of different category than other
driver run-time DLL’s like storport or ndis? Since as IHV’s, we don’t get
any control over what version of KMDF our driver will be executing under, I
don’t know why you just don’t roll it into a critical update and service
pack. If I have a storage or network driver, I don’t distribute a
coinstaller with my driver to update storport.sys or ndis.sys.

The argument against KMDF static linking as it increases memory footprint
seems valid. I think the argument in favor of KMDF static linking is a
concern over compatibility. Installing device B and having device A stop
working correctly is an ugly scenario.

Is there some reason you don’t do side-by-side KMDF versions, just like user
mode uses side-by-side DLL’s? It seems like you already have the ability to
dynamically choose the binding to a KMDF version at run-time. SxS KMDF would
mostly address the concern about expanding memory footprint, and the concern
about updates breaking drivers. SxS KMDF would need some sort of version
override capability to meet MSFT’s need to work around a broken driver. If
driver J normally used KMDF 1.7, but has a nasty bug MSFT wants to work
around, your could arrange for only driver J to bind to KMDF 1.9 (or 1.7.1
with special driver J fixes). SxS also solves the issue of I plug in a new
USB device, that requires 1.9, but 1.7 is in use, so a reboot would be
required.

Jan

25

I answered your SxS question in a previous reply. KMDF is different than storport or NDIS in that it goes downlevel, the typicaly port drivers do not. So that places the onus on the dev to create a driver that is backwards compat with previous versions. Letting KMDF install downlevel allows the dev to program to one model and the onus is on the kmdf team to make sure a new framework is upwards compatible

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, December 21, 2009 2:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

While static linking would solve some problems, it creates other
problems as well. This includes making patching any bugs in WDF much
harder and increasing the in-memory size of the kernel. While a single
driver statically linked will only add ~.5 MB, this can quickly add up
and there is a very real pressure to reduce the memory footprint of
windows, especially for netbooks and VM server environments.

With that being said we are investigating other ways that we can avoid
reboots and your feedback has certainly been heard.

Can I ask why KMDF seems to be in some sort of different category than other
driver run-time DLL’s like storport or ndis? Since as IHV’s, we don’t get
any control over what version of KMDF our driver will be executing under, I
don’t know why you just don’t roll it into a critical update and service
pack. If I have a storage or network driver, I don’t distribute a
coinstaller with my driver to update storport.sys or ndis.sys.

The argument against KMDF static linking as it increases memory footprint
seems valid. I think the argument in favor of KMDF static linking is a
concern over compatibility. Installing device B and having device A stop
working correctly is an ugly scenario.

Is there some reason you don’t do side-by-side KMDF versions, just like user
mode uses side-by-side DLL’s? It seems like you already have the ability to
dynamically choose the binding to a KMDF version at run-time. SxS KMDF would
mostly address the concern about expanding memory footprint, and the concern
about updates breaking drivers. SxS KMDF would need some sort of version
override capability to meet MSFT’s need to work around a broken driver. If
driver J normally used KMDF 1.7, but has a nasty bug MSFT wants to work
around, your could arrange for only driver J to bind to KMDF 1.9 (or 1.7.1
with special driver J fixes). SxS also solves the issue of I plug in a new
USB device, that requires 1.9, but 1.7 is in use, so a reboot would be
required.

Jan

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

26

I would suggest searching the NTDEV archives. Many of the “why didn’t you do X” questions are answered on a semi-annual basis.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, December 21, 2009 2:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

I answered your SxS question in a previous reply. KMDF is different than storport or NDIS in that it goes downlevel, the typicaly port drivers do not. So that places the onus on the dev to create a driver that is backwards compat with previous versions. Letting KMDF install downlevel allows the dev to program to one model and the onus is on the kmdf team to make sure a new framework is upwards compatible

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, December 21, 2009 2:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

While static linking would solve some problems, it creates other
problems as well. This includes making patching any bugs in WDF much
harder and increasing the in-memory size of the kernel. While a
single driver statically linked will only add ~.5 MB, this can quickly
add up and there is a very real pressure to reduce the memory
footprint of windows, especially for netbooks and VM server environments.

With that being said we are investigating other ways that we can avoid
reboots and your feedback has certainly been heard.

Can I ask why KMDF seems to be in some sort of different category than other driver run-time DLL’s like storport or ndis? Since as IHV’s, we don’t get any control over what version of KMDF our driver will be executing under, I don’t know why you just don’t roll it into a critical update and service pack. If I have a storage or network driver, I don’t distribute a coinstaller with my driver to update storport.sys or ndis.sys.

The argument against KMDF static linking as it increases memory footprint seems valid. I think the argument in favor of KMDF static linking is a concern over compatibility. Installing device B and having device A stop working correctly is an ugly scenario.

Is there some reason you don’t do side-by-side KMDF versions, just like user mode uses side-by-side DLL’s? It seems like you already have the ability to dynamically choose the binding to a KMDF version at run-time. SxS KMDF would mostly address the concern about expanding memory footprint, and the concern about updates breaking drivers. SxS KMDF would need some sort of version override capability to meet MSFT’s need to work around a broken driver. If driver J normally used KMDF 1.7, but has a nasty bug MSFT wants to work around, your could arrange for only driver J to bind to KMDF 1.9 (or 1.7.1 with special driver J fixes). SxS also solves the issue of I plug in a new USB device, that requires 1.9, but 1.7 is in use, so a reboot would be required.

Jan

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

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

27

All,

I’ve been testing on Vista (clean installation) with any driver that has WDF co-installer for example v1.5 and then updating to v1.7, and no issues (neither reboot nor installation troubles).

On the other hand, in a clean Vista installation when any driver that comes along with co-installer v1.9 is installed, then a need to reboot (if windows update is enabled) is a must. If windows update is disabled, the driver with co-installer v1.9 cannot be properly installed…

I think this an ugly scenario… so I don’t know if it’s going to be fixed within a next SP.

Could you MS guys answer this one?

Thanks,

Ismael

28

The only mechanism we can use to put the new framework bits on a machine is through the Windows component servicing system, which relies on the Windows Update service. If the service is disabled then OS updates, like the one for WDF 1.9, cannot be installed.

You don’t have a problem with 1.5 or 1.7 drivers because WDF 1.7 is already installed in Vista. Upgrading to 1.9 though requires the update service.

There are currently no plans to change this.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Monday, December 21, 2009 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

All,

I’ve been testing on Vista (clean installation) with any driver that has WDF co-installer for example v1.5 and then updating to v1.7, and no issues (neither reboot nor installation troubles).

On the other hand, in a clean Vista installation when any driver that comes along with co-installer v1.9 is installed, then a need to reboot (if windows update is enabled) is a must. If windows update is disabled, the driver with co-installer v1.9 cannot be properly installed…

I think this an ugly scenario… so I don’t know if it’s going to be fixed within a next SP.

Could you MS guys answer this one?

Thanks,

Ismael

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

29

Can you send us the snippets from %windir%\setupact.log that correspond to an update from 1.5 to 1.7 in vista, where you see no reboot?

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Monday, December 21, 2009 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

All,

I’ve been testing on Vista (clean installation) with any driver that has WDF co-installer for example v1.5 and then updating to v1.7, and no issues (neither reboot nor installation troubles).

On the other hand, in a clean Vista installation when any driver that comes along with co-installer v1.9 is installed, then a need to reboot (if windows update is enabled) is a must. If windows update is disabled, the driver with co-installer v1.9 cannot be properly installed…

I think this an ugly scenario… so I don’t know if it’s going to be fixed within a next SP.

Could you MS guys answer this one?

Thanks,

Ismael

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

30

We already did. Why is the WU service disabled?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Monday, December 21, 2009 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

All,

I’ve been testing on Vista (clean installation) with any driver that has WDF co-installer for example v1.5 and then updating to v1.7, and no issues (neither reboot nor installation troubles).

On the other hand, in a clean Vista installation when any driver that comes along with co-installer v1.9 is installed, then a need to reboot (if windows update is enabled) is a must. If windows update is disabled, the driver with co-installer v1.9 cannot be properly installed…

I think this an ugly scenario… so I don’t know if it’s going to be fixed within a next SP.

Could you MS guys answer this one?

Thanks,

Ismael

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

31

>> We already did. Why is the WU service disabled?

Answer: Some administrators just don’t want to have it enabled…
I can say that by default Vista installation has WU enabled, Although: Why on Win 7 if WU is disabled, no installation failure happens? I know that con-installer v1.9 is in the system already, but then if another v1.9+1 comes up, the same error will happen if WU is disabled?

32

I thought you were able to have WU not update from the web by a configuration setting that was not outright disabling the service. Like pewter said, WU is used for more than online downloads, WU is necessary to service windows in general. My guess as to why WU is disabled on win7 by default is that it is automatically turned on when the service engine starts and is otherwise in the state you see when no update is occurring

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Monday, December 21, 2009 2:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

> We already did. Why is the WU service disabled?

Answer: Some administrators just don’t want to have it enabled…
I can say that by default Vista installation has WU enabled, Although: Why on Win 7 if WU is disabled, no installation failure happens? I know that con-installer v1.9 is in the system already, but then if another v1.9+1 comes up, the same error will happen if WU is disabled?

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

33

You can, at least here (quite possibly other settings are required):

[GPEDIT.MSC]

Administrative Templates\Windows Components\Windows Update
Specify Intranet Microsoft Update Service Location

mm

34

My bad; I think you were talking about something else.

mm

35

>> My guess as to why WU is disabled on win7 by default …

Doron,

On Win-7, WU is not disabled by default… If you disable and stop the service, you won’t face the reboot issue and the driver installation with co-inst v1.9 goes fine…

My question is: will the reboot issue appear again on Win-7 if te co-inst v1.9 is updated? Also, will the installation fail if I disable WU?

36

Is it possible to send us the snippet from %windir%\setupact.log that shows an update from KMDF 1.5 to KMDF 1.7 in Vista, where you have disabled the Windows Update service and there is no reboot?

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Monday, December 21, 2009 3:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

> My guess as to why WU is disabled on win7 by default …

Doron,

On Win-7, WU is not disabled by default… If you disable and stop the service, you won’t face the reboot issue and the driver installation with co-inst v1.9 goes fine…

My question is: will the reboot issue appear again on Win-7 if te co-inst v1.9 is updated? Also, will the installation fail if I disable WU?

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

37

iduron@ti.com wrote:

On Win-7, WU is not disabled by default… If you disable and stop the service, you won’t face the reboot issue and the driver installation with co-inst v1.9 goes fine…

Of course it does. It’s not that complicated to understand why, is it?
Windows 7 INCLUDES 1.9. The co-installer doesn’t have to do anything at
all. It checks the current version, finds that it is OK, and exits
silently.

My question is: will the reboot issue appear again on Win-7 if te co-inst v1.9 is updated?

Absolutely. This situation is not as complicated as you seem to want to
make it. I don’t understand why you’ve had to ask this four times and
still seem so confused. If you install a driver package that has a
version of KMDF newer than the one currently running, a reboot is
required. Otherwise, the co-installer takes no action at all. It is a
very simple rule.

Also, will the installation fail if I disable WU?

If an upgrade is needed, then the Windows Update service is required,
and a reboot is required.

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

38

Tim,

I’m just trying to point a future issue that may happen on Win-7. Just omit my comments if you are OK dealing with undesired reboots…

Also, I don’t want to make this more complicated. If I posted my comments here was in order to find help.

I do understand the update mechanism (not very easy to accept for a user, but I also deal with a reboot)

Thanks for you remarks anyway :slight_smile:

Regards,

Ismael

39

>> Is it possible to send us the snippet from %windir%\setupact.log that shows an

>update from KMDF 1.5 to KMDF 1.7 in Vista, where you have disabled the Windows
>Update service and there is no reboot?

Ilias,

I’ll send them shortly.

Thanks for the help,

Ismael

40

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Monday, December 21, 2009 6:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies
on Vista OS.

While static linking would solve some problems, it creates
other problems as well. This includes making patching any
bugs in WDF much harder

Well, I still believe it should be driver developer’s decision when his
driver should be patched but it was discussed in the past as Peter W.
pointed out.

and increasing the in-memory size of
the kernel. While a single driver statically linked will
only add ~.5 MB, this can quickly add up and there is a very
real pressure to reduce the memory footprint of windows,
especially for netbooks and VM server environments.

This part is interesting. My old WDM driver release binary size is about
50 kB. Do you want to say WDF driver would be 10 times larger?

Best regards,

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