Handle Invalid error when trying to run a KMDF driver

Peter,

Yes by txtsetup. This soured two firms that were going to convert
almost everything to WDF, to saying that until there is a solution don’t use
the acronyms WDF, KMDF or UMDF in our presence.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
You mean drivers that need to be loaded in txtsetup I assume?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, February 27, 2008 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Handle Invalid error when trying to run a KMDF driver

One problem I don’t see how you will address with the co-installer approach
is the need for drivers to run at Windows installation time. I now have had
two different customers who jumped on the KMDF bandwagon and then discovered
after rewriting their drivers to KMDF that they could not use them as part
of an install. Since in both cases the drivers were needed for Windows to
work, both firms now have corporate edicts “NO WDF!!!”

This is frustrating, since I have just finished some new drivers for them
that otherwise would be perfect for KMDF, but need to be part of the
install.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
It’s a tempting idea … the problem is that it then ties all this new
device installation technology into specific versions of Windows. Sure your
driver package could state that it needs update Y but the code to understand
that is probably in update X which has to be applied first.

The only way to resolve the chicken-and-egg problem on downlevel versions of
Windows is to use the coinstaller. I’m hoping in the future we can make the
coinstaller a little more general purpose since the problems facing KMDF are
the same ones that face UMDF, WinUSB, and any other device technology we
release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation
packages - one for pre Win7 and another for Win7 to deal with a radical
change in the installation model. So we instead have to use a coinstaller.

-p


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

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Wednesday, February 27, 2008 9:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Handle Invalid error when trying to run
a KMDF driver

And would have resulted in a large body of MS kernel-mode
code which couldn’t be detected, serviced or blocked if a
major security vulnerability was found.

And while you might be kind enough to re-release your drivers
should such an issue be found I’m quite certain there are
many many other drivers that would never get re-released and
would just continue to propagate that flaw across the entire
ecosystem.

It is the same as using static version of CRT library or anything else.
If there is a vulnerability, it is the product which links this library
what is vulnerable and has to be updated. I don’t a real see difference
between kernel and user mode. Vulnerable code can run within a service
with sufficient privileges.

Yes, it is easier for you to update framework binaries this way. It is
also easier for you to non-intentionally break installed drivers using
it. I don’t say it is wrong; it is a tradeoff as usual. But there should
be a choice. The same as between static and dynamic CRT. There are good
reasons of both and it is producers’ decision what reasons are more
important for her.

Best regards,

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

We call them “marker files”. The coinstaller creates them. When a crash is reported back to MS we get a listing of the drivers directory (but no actual file contents) and they get stored in the backend. It gives us a listing of the WDF drivers installed on that machine.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, February 27, 2008 12:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

While were close to the subject, any idea of what a ‘.wdf’ file with a
size of 0 bytes that lives in ‘\Windows\System32\Drivers’ does. For
example, ‘msftwdf_kernel_01005_coninstaller_critical.wdf.’ They may be
unrelated to WDF, they may be malware; I have no idea. I just saw three
files like this ‘msft_…’ one one of my targets.

Thanks,

mm

Tim Roberts wrote:

Peter Wieland wrote:
> …
> The only way to resolve the chicken-and-egg problem on downlevel
> versions of Windows is to use the coinstaller. I’m hoping in the
> future we can make the coinstaller a little more general purpose since
> the problems facing KMDF are the same ones that face UMDF, WinUSB, and
> any other device technology we release out-of-band, but that’s my hope
> not a plan or a promise.
>
> We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.
>

Making it a statically linked library would have solved many of these
issues. If my driver is tested with KMDF 1.5, then it can use KMDF
forever, even if other drivers are using 1.7 and 1.9.

May I ask why the decision was made to call the helper wdf01000.sys,
instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
would have solved this problem, at the expense of 0.025c worth of disk
space.


NTDEV is sponsored by OSR

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

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

Thanks, Peter.

mm
Peter Wieland wrote:

We call them “marker files”. The coinstaller creates them. When a crash is reported back to MS we get a listing of the drivers directory (but no actual file contents) and they get stored in the backend. It gives us a listing of the WDF drivers installed on that machine.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, February 27, 2008 12:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

While were close to the subject, any idea of what a ‘.wdf’ file with a
size of 0 bytes that lives in ‘\Windows\System32\Drivers’ does. For
example, ‘msftwdf_kernel_01005_coninstaller_critical.wdf.’ They may be
unrelated to WDF, they may be malware; I have no idea. I just saw three
files like this ‘msft_…’ one one of my targets.

Thanks,

mm

Tim Roberts wrote:
> Peter Wieland wrote:
>> …
>> The only way to resolve the chicken-and-egg problem on downlevel
>> versions of Windows is to use the coinstaller. I’m hoping in the
>> future we can make the coinstaller a little more general purpose since
>> the problems facing KMDF are the same ones that face UMDF, WinUSB, and
>> any other device technology we release out-of-band, but that’s my hope
>> not a plan or a promise.
>>
>> We’ve made the assumption that no one wants to have separate
>> installation packages - one for pre Win7 and another for Win7 to deal
>> with a radical change in the installation model. So we instead have
>> to use a coinstaller.
>>
> Making it a statically linked library would have solved many of these
> issues. If my driver is tested with KMDF 1.5, then it can use KMDF
> forever, even if other drivers are using 1.7 and 1.9.
>
> May I ask why the decision was made to call the helper wdf01000.sys,
> instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
> would have solved this problem, at the expense of 0.025c worth of disk
> space.
>


NTDEV is sponsored by OSR

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

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

As long as we’re relying on magical things we’ve imagined that don’t exist, we might as well have the computer call up and have a CD with WDF delivered to the user’s home in a golden carriage pulled by badgers wearing little white gloves and top hats. Then the badgers can install it for you, give you a quick mink massage and go on their way without even leaving footprints. Unfortunately no such feature exists in previous versions of Windows (and I think the legal risks associated with the badger delivery service would be too high for Win7) so we’re left with reality.

The input we have gotten around setup was overwhelmingly that driver package had to be able to carry its dependencies with it. It couldn’t rely on a service pack or WU update being on the machine. It couldn’t rely on them coming down over the network. It has to work without any user interaction or UI.

We have the resources to put together *one* setup method … this was the most requested scenario and functions in the other cases and so it’s the one we implemented. We have some ideas about how to streamline the installation but it’s not clear when we’ll be able to make those bubble up to the top of the list of all the things we’re being asked to do (from external and internal partners).

Don’t worry about the rant. Clearly it was my mistake for trying to answer your question. My apologies for sending you off the deep end.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 12:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:

It’s a tempting idea … the problem is that it then ties all this
new device installation technology into specific versions of Windows.
Sure your driver package could state that it needs update Y but the
code to understand that is probably in update X which has to be
applied first.

So you are telling me that in all of these Windows older driver
installers there is absolutely no mechanism to inform anybody that a
system component necessary for driver installation is missing?
Not even with a text message?

Come on, even then there could be a ‘stub’ that informs the user of the
fact. As we had (still have?) in Windows EXE files that tell you “This
program does not run in DOS mode.”.

And don’t underestimate the amount of install hassle ordinary Windows
users have become used to during all these years of “Windows
Experience”. YOu use an outdated version? OK, it will even be harder.

Or someone has to get a system architect to MS. Quick. Swap her for
someone from marketing - they are excellent and surely can spare one person.

We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.

People have become used to have separate drivers for Win16, Win32s,
Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
WinVista. Oh, and the 64 bit versions, of course.
So used that some of them who happen to be driver developers even deny
the possibility of writing one driver for everything from Win98 (with
limitations) up to Vista. :wink:

Great - I’m looking forward to a brave new world where every driver
package will even bigger than in earlier times because now not only a
bloated install program is delivered (to make sure the files are
actually found), but additionally with every WDF driver comes a
coinstaller. Well, the price of progress, I guess…

Sorry for ranting, but this reminds me painfully of a three-disk
installer for an external CD writer that would not run on NT4 with a
“file not found” message.
Luckily it was an old archive type that I managed to find an unpacker
for. Turns out that more 2 and 3/4 disks were actually the (compressed!)
install program.
The real driver consisted of one INF and two SYS files, totalling less
than 200kB. And of course someone had made a typo in the INF file, and
obviously forgot to test it on NT4.
The standard Windows device installer was absolutely happy taking the
INF/SYS from a subdirectory on a single 3.5" disk.

Now we will at least a single CD. Or DVD. Heck, now I know why BlueRay
had to be invented. (Grrrrrr!)

So much my 2cents of steam-off. No offense.


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

Peter Wieland wrote:

We’ve made the assumption that no one wants to have separate
installation packages - one for pre Win7 and another for Win7 to deal
with a radical change in the installation model. So we instead have
to use a coinstaller.

So this model is “future-proof”? Wow.
(Yes, only now it sank in that you were actually talking about Win7.)

Well, I imagine WDF will be a huge success. In my opinion it is
“condemned” to. (And that’s why I get frightened by the perspective of
installation collections with 134 drivers, where 105+ of them have
outdated WDF co-installers, and 29 of them have the same, current, WDF
co-installer in their package. Which in the end probably none gets
actually installed at all, because the latest overnight auto-update
installed the most current WDF anyway. Because it is important.)

Peter Wieland wrote:

As long as we’re relying on magical things we’ve imagined that don’t exist, we might as well have the computer call up and have a CD with WDF delivered to the user’s home in a golden carriage pulled by badgers wearing little white gloves and top hats. Then the badgers can install it for you, give you a quick mink massage and go on their way without even leaving footprints. Unfortunately no such feature exists in previous versions of Windows (and I think the legal risks associated with the badger delivery service would be too high for Win7) so we’re left with reality.

The input we have gotten around setup was overwhelmingly that driver package had to be able to carry its dependencies with it. It couldn’t rely on a service pack or WU update being on the machine. It couldn’t rely on them coming down over the network. It has to work without any user interaction or UI.

We have the resources to put together *one* setup method … this was the most requested scenario and functions in the other cases and so it’s the one we implemented. We have some ideas about how to streamline the installation but it’s not clear when we’ll be able to make those bubble up to the top of the list of all the things we’re being asked to do (from external and internal partners).

Don’t worry about the rant. Clearly it was my mistake for trying to answer your question. My apologies for sending you off the deep end.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 12:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:
> It’s a tempting idea … the problem is that it then ties all this
> new device installation technology into specific versions of Windows.
> Sure your driver package could state that it needs update Y but the
> code to understand that is probably in update X which has to be
> applied first.

So you are telling me that in all of these Windows older driver
installers there is absolutely no mechanism to inform anybody that a
system component necessary for driver installation is missing?
Not even with a text message?

Come on, even then there could be a ‘stub’ that informs the user of the
fact. As we had (still have?) in Windows EXE files that tell you “This
program does not run in DOS mode.”.

And don’t underestimate the amount of install hassle ordinary Windows
users have become used to during all these years of “Windows
Experience”. YOu use an outdated version? OK, it will even be harder.

Or someone has to get a system architect to MS. Quick. Swap her for
someone from marketing - they are excellent and surely can spare one person.

> We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.

People have become used to have separate drivers for Win16, Win32s,
Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
WinVista. Oh, and the 64 bit versions, of course.
So used that some of them who happen to be driver developers even deny
the possibility of writing one driver for everything from Win98 (with
limitations) up to Vista. :wink:

Great - I’m looking forward to a brave new world where every driver
package will even bigger than in earlier times because now not only a
bloated install program is delivered (to make sure the files are
actually found), but additionally with every WDF driver comes a
coinstaller. Well, the price of progress, I guess…

Sorry for ranting, but this reminds me painfully of a three-disk
installer for an external CD writer that would not run on NT4 with a
“file not found” message.
Luckily it was an old archive type that I managed to find an unpacker
for. Turns out that more 2 and 3/4 disks were actually the (compressed!)
install program.
The real driver consisted of one INF and two SYS files, totalling less
than 200kB. And of course someone had made a typo in the INF file, and
obviously forgot to test it on NT4.
The standard Windows device installer was absolutely happy taking the
INF/SYS from a subdirectory on a single 3.5" disk.

Now we will at least a single CD. Or DVD. Heck, now I know why BlueRay
had to be invented. (Grrrrrr!)

So much my 2cents of steam-off. No offense.


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

Peter:

This is not exactly hard to believe. I’m just not sure how much size
matters here, as it were. That is, I can’t really think of any reason
why I would chose a smaller package (ibid) over being able to get one
package and know that I was good to go, I would be mighty unhappy in
many cases if a network connection were required, and finding out what
you’re missing only during install, unless you happen to know the
contents of every machine on which you will be installing, while you
read carefully the documentation for the driver installation, that must
be accurate, is the worst case, for me, at least.

Hagen:

This is absurd:

People have become used to have separate drivers for Win16, Win32s,
>Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
>WinVista. Oh, and the 64 bit versions, of course.
>So used that some of them who happen to be driver developers even deny
>the possibility of writing one driver for everything from Win98 (with
>limitations) up to Vista. :wink:

I gather you have the misfortune of supporting Win98, as you bring it up
a lot, if I am remembering correctly. You’re one of the few here that
does. Perhaps it’s possible that people merely don’t talk about Win98,
because they don’t care. Also, of the ten versions of Windows you
mentioned:

  1. Win16 is pretty clearly not something has any expectations about
    either way at this point.

  2. Win32s is something no one ever had any thoughts about at any point,
    and drivers really don’t have much to do with it.

  3. While there are some differences between all the Win95 family, not
    all that many people are concerned with any of these at this point, and
    I having trouble with the idea of anyone expecting a different driver
    for Win98 for Win98SE, at a minimum.

  4. You left of WinNT 3.51 & 4.0. There’s no reason to discuss them, as
    I can recall exactly one question on this list in three years about 4.0,
    but if you’re going to talk about Win32s, why not these, and the Itanium
    for that matter as well.

  5. Win2000 is still out there, but a lot of drivers that work on XP
    work in 2K as well.

  6. Win2K3 supports almost everything that XP does.

  7. XP is what the only thing that most people care about at the moment.

  8. Vista is indeed different, and those who use it no doubt expect a
    separate driver package.

  9. Also certainly true for 64-bit.

What I really don’t understand is given how outrageously awful
installation has always been, easily the worst feature of windows, and
that this is what causes a lot of issues today, and will continue to do
so tomorrow, why one earth would focus on driver package size. How does
this affect you? I mean, sure it takes longer to download, and if we
were talking about why is the WDK like 2GB sometimes because of DTM, or
that you have to download about 6 GB to create a partial checked build
(unless you already have imagex), I would heartily agree with you, and
add that the whole thing is made far worse by FTM, and that in some
cases if you don’t know to burn a lower speed, the OS iso’s don’t really
work. But how big can a driver really be? Bigger than necessary, sure,
but it doesn’t even chart.

mm

Peter Wieland wrote:

As long as we’re relying on magical things we’ve imagined that don’t exist, we might as well have the computer call up and have a CD with WDF delivered to the user’s home in a golden carriage pulled by badgers wearing little white gloves and top hats. Then the badgers can install it for you, give you a quick mink massage and go on their way without even leaving footprints. Unfortunately no such feature exists in previous versions of Windows (and I think the legal risks associated with the badger delivery service would be too high for Win7) so we’re left with reality.

The input we have gotten around setup was overwhelmingly that driver package had to be able to carry its dependencies with it. It couldn’t rely on a service pack or WU update being on the machine. It couldn’t rely on them coming down over the network. It has to work without any user interaction or UI.

We have the resources to put together *one* setup method … this was the most requested scenario and functions in the other cases and so it’s the one we implemented. We have some ideas about how to streamline the installation but it’s not clear when we’ll be able to make those bubble up to the top of the list of all the things we’re being asked to do (from external and internal partners).

Don’t worry about the rant. Clearly it was my mistake for trying to answer your question. My apologies for sending you off the deep end.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 12:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:
> It’s a tempting idea … the problem is that it then ties all this
> new device installation technology into specific versions of Windows.
> Sure your driver package could state that it needs update Y but the
> code to understand that is probably in update X which has to be
> applied first.

So you are telling me that in all of these Windows older driver
installers there is absolutely no mechanism to inform anybody that a
system component necessary for driver installation is missing?
Not even with a text message?

Come on, even then there could be a ‘stub’ that informs the user of the
fact. As we had (still have?) in Windows EXE files that tell you “This
program does not run in DOS mode.”.

And don’t underestimate the amount of install hassle ordinary Windows
users have become used to during all these years of “Windows
Experience”. YOu use an outdated version? OK, it will even be harder.

Or someone has to get a system architect to MS. Quick. Swap her for
someone from marketing - they are excellent and surely can spare one person.

> We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.

People have become used to have separate drivers for Win16, Win32s,
Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
WinVista. Oh, and the 64 bit versions, of course.
So used that some of them who happen to be driver developers even deny
the possibility of writing one driver for everything from Win98 (with
limitations) up to Vista. :wink:

Great - I’m looking forward to a brave new world where every driver
package will even bigger than in earlier times because now not only a
bloated install program is delivered (to make sure the files are
actually found), but additionally with every WDF driver comes a
coinstaller. Well, the price of progress, I guess…

Sorry for ranting, but this reminds me painfully of a three-disk
installer for an external CD writer that would not run on NT4 with a
“file not found” message.
Luckily it was an old archive type that I managed to find an unpacker
for. Turns out that more 2 and 3/4 disks were actually the (compressed!)
install program.
The real driver consisted of one INF and two SYS files, totalling less
than 200kB. And of course someone had made a typo in the INF file, and
obviously forgot to test it on NT4.
The standard Windows device installer was absolutely happy taking the
INF/SYS from a subdirectory on a single 3.5" disk.

Now we will at least a single CD. Or DVD. Heck, now I know why BlueRay
had to be invented. (Grrrrrr!)

So much my 2cents of steam-off. No offense.


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

(Sorry about the empty quote before - I need to use “rewrap”, don’t have
a shortcut for it, and accidentally clicked “send”. :frowning: )

Peter Wieland wrote:

The input we have gotten around setup was overwhelmingly that driver
package had to be able to carry its dependencies with it.

It couldn’t rely on a service pack or WU update being on the machine.
It couldn’t rely on them coming down over the network. It has to
work without any user interaction or UI.

OK. With this pretext the only solution is “carry everything with you”.
Fair enough.

As Ilias already pointed out, the installer itself is actually very
small, but then of course we do need the framework.
And I also see that with the ability to install by device-plugin on a
non-WDF-preinstalled system the WDF basically has to be in the package.

It’s of course a philosophy thing as well – is something as WDF an
important, “standalone” core system component? - see, its integrated in
Vista! Then an installer for older systems can come on the same disk as
the driver, but usually will be present with the latest SP on most
systems. Analog to DirectX. Or like USB2.0 support for WinXP which IIRC
needs SP2.
Or is WDF “just” a helper component for UMDF/KMDF drivers that you
basically bundle with your drivers, that’s self-determining its most
current version and that you then basically can forget about?

Of course - at least for me it is obvious why - you do not want to go
for statically linked libraries. And I also assume you don’t want to
have several versions of WDF to coexist on one machine (which is a good
thing).

Don’t worry about the rant. Clearly it was my mistake for trying to
answer your question. My apologies for sending you off the deep end.

I would very much regret if you feel it was a mistake to have tried
answering my question. My apologies if you felt personally attacked - it
is clearly not meant this way, and I do appreciate the chance to discuss
these maters and to learn about the background and the “why” of things.
(Of which thanks to your answer I’m doing quite a substantial amount in
this thread!)

Hagen,
I didn’t understand the point that you’re trying to raise with this email.

KMDF supports all operating systems from Windows 2000 to Windows Vista (both client and server editions). The latest auto-update that you mentioned exists only in Vista. How about the previous operating systems? We need to coinstaller to update Windows 2000 to the latest version of KMDF, because many driver developers are still writing drivers for Windows 2000. There is no latest auto-update for that OS (or for XP, etc). The same coinstaller makes sure that the framework will be installed in all supported OS versions. So, the update package has to be included.

Also, it doesn’t matter if a driver is shipped with an “outdated” (as you mention it) coinstaller. If the driver is installed in a system, which has a newer version of the framework (either UMDF or KMDF), then the driver automatically gets the benefits (stability, bug fixes, support, etc) that comes with the latest version.

So, what exactly is the problem here?

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 1:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:

We’ve made the assumption that no one wants to have separate
installation packages - one for pre Win7 and another for Win7 to deal
with a radical change in the installation model. So we instead have
to use a coinstaller.

So this model is “future-proof”? Wow.
(Yes, only now it sank in that you were actually talking about Win7.)

Well, I imagine WDF will be a huge success. In my opinion it is
“condemned” to. (And that’s why I get frightened by the perspective of
installation collections with 134 drivers, where 105+ of them have
outdated WDF co-installers, and 29 of them have the same, current, WDF
co-installer in their package. Which in the end probably none gets
actually installed at all, because the latest overnight auto-update
installed the most current WDF anyway. Because it is important.)


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

Martin O’Brien wrote:

I gather you have the misfortune of supporting Win98, as you bring it
up a lot, if I am remembering correctly. You’re one of the few here
that does. Perhaps it’s possible that people merely don’t talk about
Win98, because they don’t care. Also, of the ten versions of Windows
you mentioned:

  1. Win16 is pretty clearly not something has any expectations about
    either way at this point.

  2. Win32s is something no one ever had any thoughts about at any
    point, and drivers really don’t have much to do with it.

  3. While there are some differences between all the Win95 family, not
    all that many people are concerned with any of these at this point,
    and I having trouble with the idea of anyone expecting a different
    driver for Win98 for Win98SE, at a minimum.

  4. You left of WinNT 3.51 & 4.0. There’s no reason to discuss them,
    as I can recall exactly one question on this list in three years about
    4.0, but if you’re going to talk about Win32s, why not these, and the
    Itanium for that matter as well.

  5. Win2000 is still out there, but a lot of drivers that work on XP
    work in 2K as well.

  6. Win2K3 supports almost everything that XP does.

  7. XP is what the only thing that most people care about at the moment.

  8. Vista is indeed different, and those who use it no doubt expect a
    separate driver package.

  9. Also certainly true for 64-bit.

My experience is somewhat different. I do have clients that are still
interested in Win98. I find that I need one driver package for
98/SE/ME, one for 2K/XP/2003/Vista32, and one for Vista64. For
multimedia work, NT4 is kind of the poor stepchild, and never gets
considered.

I certainly do not expect to deliver separate binaries for XP and Vista32.


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

Martin O’Brien wrote:

I gather you have the misfortune of supporting Win98, as you bring it
up a lot, if I am remembering correctly.

(a) Actually I am absolutely amazed that with WDM it is actually
possible to make one driver package that supports a huge amount of
Windows versions. It’s impressive.

(b) Win98 serves as an example that at some point you either have to
“drop support” for something, or you will have to cater for it.
If e.g. someone asks which technology to use, and everybody chimes in
“WDF”, IMO it just has to be stated what it can *not* be used for.

With all the hot new technologies knocking at the doorstep it is also
very easy to forget about maintenance of an existing customer base (or
devices running a standard Windows but still “embedded” somewhere in a
use case).

In one year I’ll move use WinME as an example instead, OK? Or should I
go to NT4? Win2K would not hit the point as it *is* actually supported
by WDF. :wink:

[Win versions]

IIRC, KMDF is available from Win2000. UMDF from WinXP.

WDF is included with Vista. So in my humble opinion one possible option
to go for would have been to say “new drivers using WDF need some
minimum WDF version to be installed”.

In my opinion people used to these old OS versions could be able to
understand that in order to use a brand-new driver they needed an
upgrade first.

What I really don’t understand is given how outrageously awful
installation has always been, easily the worst feature of windows,
and that this is what causes a lot of issues today, and will continue
to do so tomorrow, why one earth would focus on driver package size.

I am not concerned about the package size of the individual driver - if
it is feature packaged, fine, ok, then make good use of your x megabyte
package.
But I am a bit sad about the prospect of having to bundle WDF for all
new drivers to come, for years to com, and almost none of these
installation packages will actually be used.
Multiply this by the amount of archives, backups, etc.

Some applications need DirectX Y.x or NET2.0 these days. With the very
same argument everybody should as well bundle these inside their install
packages. It is easier, and space doesn’t matter anymore.

The little extra wrapper on this bar of chocolate does not matter. But
if you distribute billions of it there will be a considerable amount of
waste.

But how big can a driver really be? Bigger than necessary, sure, but
it doesn’t even chart.

Ever tried to download a vital driver via a cell phone connection?

That anyone still supports much in the way of 95, et. c. is indeed not
what I was expecting, and the new video driver model is the only reason
I broke Vista out separately, but I suppose that is a very, very small
group as well, that doesn’t even really have to support it necessarily,
so I see what you’re saying, if I’ve understood you correctly.

mm

Tim Roberts wrote:

Martin O’Brien wrote:
>
> I gather you have the misfortune of supporting Win98, as you bring it
> up a lot, if I am remembering correctly. You’re one of the few here
> that does. Perhaps it’s possible that people merely don’t talk about
> Win98, because they don’t care. Also, of the ten versions of Windows
> you mentioned:
>
> 1. Win16 is pretty clearly not something has any expectations about
> either way at this point.
>
> 2. Win32s is something no one ever had any thoughts about at any
> point, and drivers really don’t have much to do with it.
>
> 3. While there are some differences between all the Win95 family, not
> all that many people are concerned with any of these at this point,
> and I having trouble with the idea of anyone expecting a different
> driver for Win98 for Win98SE, at a minimum.
>
> 4. You left of WinNT 3.51 & 4.0. There’s no reason to discuss them,
> as I can recall exactly one question on this list in three years about
> 4.0, but if you’re going to talk about Win32s, why not these, and the
> Itanium for that matter as well.
>
> 4. Win2000 is still out there, but a lot of drivers that work on XP
> work in 2K as well.
>
> 5. Win2K3 supports almost everything that XP does.
>
> 6. XP is what the only thing that most people care about at the moment.
>
> 7. Vista is indeed different, and those who use it no doubt expect a
> separate driver package.
>
> 8. Also certainly true for 64-bit.

My experience is somewhat different. I do have clients that are still
interested in Win98. I find that I need one driver package for
98/SE/ME, one for 2K/XP/2003/Vista32, and one for Vista64. For
multimedia work, NT4 is kind of the poor stepchild, and never gets
considered.

I certainly do not expect to deliver separate binaries for XP and Vista32.

Hagen Patzke wrote:

In my opinion people used to these old OS versions could be able to
understand that in order to use a brand-new driver they needed an
upgrade first.

Apparently, you have never worked in a company that makes retail
products. When you sell a commodity web camera, you simply do not have
the luxury of dictating to your users that they must upgrade their
operating system before installing it. Grandma and Grandpa don’t even
know that they HAVE an operating system. I can’t tell you how many
times I’ve asked “What operating system are you running?” only to be
told “I’m running Office 2000.”

Further, you aren’t going to want to be the one who stands in front of
the vice president of marketing and tells her that she has to remove 98
from the list of operating systems in the marketing material.


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

top hats?? TOP HATS??

I’m all for those badgers, AND the little white gloves, but there’s absolutely no need for top hats. They take up too much room, and they’re inappropriate in Windows for Workgroups environments (where we all know, baseball caps must be worn. But that may have changed because it’s a long time since I looked at it).

I DO so enjoy Peter Wieland.

In all seriousness, though… a statically linked option would be really helpful. I know the reason it wasn’t chosen, but it would eliminate (a) the reboot problem, and (b) the legitimate (and not inconsiderable) fear in the community over running a driver with an up-rev version of the Framework with which the driver in question has never been tested.

I, for one, would really hate to be the KMDF test lead that has to sign off that every driver that was working with KMDF V1.1 will work properly (out of the box, and without any changes) using KMDF V1.7 – That responsibility would scare me to death. The reason it scares me so is that I can’t see a way that I could even KNOW for certain it’s true. I can know if it’s NOT true, but…

Peter
OSR

Ilias Tsigkogiannis wrote:

KMDF supports all operating systems from Windows 2000 to Windows
Vista (both client and server editions).

Yes, and IIRC, UMDF supports WinXP up to Vista. (Correct?)

The latest auto-update that you mentioned exists only in Vista. How
about the previous operating systems?

AFAIK, Windows XP has got an update mechanism, too. At least the XP on
my desktop computer keeps telling me regularly it wants to download and
install something. True, certainly not as sophisticated as Vista.

Also, it doesn’t matter if a driver is shipped with an “outdated” (as
you mention it) coinstaller. If the driver is installed in a system,
which has a newer version of the framework (either UMDF or KMDF),
then the driver automatically gets the benefits (stability, bug
fixes, support, etc) that comes with the latest version.

Yes, you are right - from an in-system perspective, nothing bad will
happen if a newly installed driver brings its own, “older” WDF version.

From an outside-system perspective, this unused, bundled “older” WDF
version is wasted space/bandwidth/time.

So, what exactly is the problem here?

The law of big numbers: n WDF drivers bring n times a WDF install
package with it, which in a high percentage of all install cases will
not be installed.
These n WDF drivers will be on product CDs, driver websites, magazine
CDs, self-made “work” install CDs, on backups, tapes, harddisks, etc.

Look at n for n >> 1000. Plus multiple driver versions (n >> 10000).

As I perceive WDF (both KMDF and UMDF) as a very important and valuable
system upgrade, I wonderend why it was not treated it as part of the
system like printing, GDI, or like a central library like MFC (or one of
the core system DLLs if you like).

Of course “we decided to include WDF so it can automagically install
pain-free on older systems” is a valid design decision!

The question is if it is necessary and beneficial to bundle the
framework with every single WDF driver - for years to come.

IIRC, for USB2.0 support on WinXP, its SP2 needs to be installed.

I wondered why not a similar setup was used, or a WDF installer for
Win2000 and WinXP? And you install the latest “WDF support” when a
driver needs it.

Analogies are DirectX and .NET - they are not bundled with the install
packages of the applications that use them. If you want to install
an application that needs them, you’re kindly informed what is missing.
Even if their distributions are included on the product CD, you can skip
these versions and go for a newer version (e.g. on a different CD, or
you could even download the latest version).

> Hagen Patzke wrote:

> In my opinion people used to these old OS versions could be able to
> understand that in order to use a brand-new driver they needed an
> upgrade first.

Tim Roberts wrote:

Apparently, you have never worked in a company that makes retail
> products.

No, not retail. Luckily. I think I do understand.

Further, you aren’t going to want to be the one who stands in front
of the vice president of marketing and tells her that she has to
remove 98 from the list of operating systems in the marketing
material.

Sorry, this was bad wording: not an OS upgrade, but e.g. a “WDF upgrade
package”, like you need DirectX to run some games, or NET 2.0 for some
applications, or (IIRC) SP2 for XP for USB2.0 support.

On older systems you very often need an installer anyway, and IMHO that
installer could also run a WDF pre-installation from the same product CD
or driver package.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 3:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Analogies are DirectX and .NET - they are not bundled with the install
packages of the applications that use them. If you want to install
an application that needs them, you’re kindly informed what is missing.
Even if their distributions are included on the product CD, you can skip
these versions and go for a newer version (e.g. on a different CD, or
you could even download the latest version).

[Ilias]
As you said… they are APPLICATIONS! We are talking about DRIVERS! There is a difference between these 2.
Let’s say that somebody buys a new device (keyboard/mouse/usb stick… it doesn’t matter), plugs it in and gets a message saying “sorry, however Windows doesn’t support your keyboard. Please go to www.microsoft.com/foo/bar, download our KMDF installer and try again”.

How happy do you think that this person would be? Especially now that he has to use his computer with a non-working keyboard/mouse?

Ilias

Tim Roberts wrote:

My experience is somewhat different. I do have clients that are still
interested in Win98. I find that I need one driver package for
98/SE/ME, one for 2K/XP/2003/Vista32, and one for Vista64. For
multimedia work, NT4 is kind of the poor stepchild, and never gets
considered.

Reminds me of the fact that my Dad still has WinME on his computer.

Now he is interested in one of the new flat rate offers for national
phone and internet access, and I discussed with him that he will want a
faster computer with a more recent OS once he’s got hi-speed internet
access.

Probably I’ll make sure he gets Vista32. If the “projected average use
time” is eight years it has to be the most recent OS we can get now. :slight_smile:

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 27, 2008 11:40 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Handle Invalid error when trying to run
a KMDF driver

I certainly do not expect to deliver separate binaries for XP
and Vista32.

We have separate install package per every OS version including XP and
Vista32. The reason is simple: driver signing. I’m not sure if it is
possible to have one .cat file for more OSes but even if it is, we don’t
want it. We’d have to always sign for all OSes at once. It is painful
and time consuming process and sometimes we need a new signature for one
OS quickly. In turn, our install packages for XP and Vista32 can contain
different versions of the same driver.

Best regards,

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