Porting Win2k/WinXP drivers -> Win98SE/ME

Hello everyone,

I’m developing set of device drivers for Win2k and WinXp. This driver-set basically has a bus driver and two child device drivers on top of it. One of the child device drivers is a NDIS-driver. We also have old set of device drivers for the same HW (working for all platforms but they are not even close to be WHQL-complient. Original plan was to keep to a separate driver sets, old ones for Win9x-family and the new WHQL-complient for Win2k/WinXp. UI would handle the differences in communications mode. Due to re-architecting needs at user-level code because of the new drivers, it was proposed that those WHQL-complient drivers could “easily” be ported to Win98SE/Me (so the same UI code could be used in all OSes).

Generally, I’m very much against transferring complexity from user-land to kernel-mode just because it can be done and it would make user-land code easier (thus making kernel-code more complex). In this case I wouldn’t worry about it too much as I would not be doing the port but as I’m curious soul and like to learn new things. I would like to get some input on this before saying “no” to whole idea. I have read the Walter Oney’s book and it covers a bit on this subject but I guess what I’m really looking for is some comments from people who are really had to deal with cases like this.

Is this really a trivial task to do? This is all that I know at the moment (I ported one WDM driver to Me sometime ago):

  • NDIS-WDM device drivers don’t work the same in Win2k and Win2k (all packets need to be indicated in the context of NDIS-library thread)
  • Some PnP-IRPs work differently (well, they work the same but what you set to status and information field when IRP is completed varies).
  • WMI is not available
  • Power-management IRPs works little differently

Any other things that what will work and what won’t? How about user-land notifications by OS (device arrival and etc.), will they work?

  • Mikko

You can port a Win2K/XP bus driver to 98/Me, I have done this personally.
You can make a single NDIS/WDM miniport that works on 2000/Me/98 and I
assume XP, I have worked on one of these. WMI is available natively on Me,
but you have to install it on 98 from here:

http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/MSDN-FILES/027/001/576/msdncompositedoc.xml

Power is a big hassle, and it took me a while to get it straight for all
platforms in our bus driver support in WinDK. One reason it was such a
hassle for us is I decided to follow the ‘OnNow’ power management
specification from Microsoft for our bus driver support. We already follow
it for our devices. So our typical WinDK device drivers power themselves
down by default when there are no handles open to them and then power up
when/if a handle is opened, (you can shut this off easily in WinDK BTW or
use selective suspend for USB if supported). Further, then the bus powers
itself down when no children are powered up. Problem is 2000/XP will allow
a child to power itself up when the parent is powered down. 98/Me will not.
Anyway, some fun gymnastics, but it all works, and I am the only one on the
planet I know of to follow that stupid specification and get it to work for
a bus driver and its child FDO drivers across 98/Me/2000/XP :slight_smile:

One huge problem that you will have is if this bus driver is to operate on
top of a PCI device that needs to split resources amonst its child drivers.
If the separate operations of the device are broken out into separate
functions on the PCI device, which they never are, then no problems.
However, if you need to split the resources of a single PCI function card,
you will have a good bit more trouble.

If this is a PCI card, also you won’t need an NDIS/WDM miniport as a normal
NDIS miniport will do. As for indicating packets in the NDIS context, you
can use a timer DPC to get to the correct context if memory serves. I
remember that issue, but its been a couple of years, so I don’t remember it
exactly, but its solvable.

All in all, its doable, but it ain’t trivial.


Bill McKenzie

wrote in message news:xxxxx@ntdev…

Hello everyone,

I’m developing set of device drivers for Win2k and WinXp. This driver-set
basically has a bus driver and two child device drivers on top of it. One of
the child device drivers is a NDIS-driver. We also have old set of device
drivers for the same HW (working for all platforms but they are not even
close to be WHQL-complient. Original plan was to keep to a separate driver
sets, old ones for Win9x-family and the new WHQL-complient for Win2k/WinXp.
UI would handle the differences in communications mode. Due to
re-architecting needs at user-level code because of the new drivers, it was
proposed that those WHQL-complient drivers could “easily” be ported to
Win98SE/Me (so the same UI code could be used in all OSes).

Generally, I’m very much against transferring complexity from user-land to
kernel-mode just because it can be done and it would make user-land code
easier (thus making kernel-code more complex). In this case I wouldn’t worry
about it too much as I would not be doing the port but as I’m curious soul
and like to learn new things. I would like to get some input on this before
saying “no” to whole idea. I have read the Walter Oney’s book and it covers
a bit on this subject but I guess what I’m really looking for is some
comments from people who are really had to deal with cases like this.

Is this really a trivial task to do? This is all that I know at the moment
(I ported one WDM driver to Me sometime ago):
- NDIS-WDM device drivers don’t work the same in Win2k and Win2k (all
packets need to be indicated in the context of NDIS-library thread)
- Some PnP-IRPs work differently (well, they work the same but what you set
to status and information field when IRP is completed varies).
- WMI is not available
- Power-management IRPs works little differently

Any other things that what will work and what won’t? How about user-land
notifications by OS (device arrival and etc.), will they work?

- Mikko

Thanks for the quick response!

I elaborate this little bit further. The device is sitting on the top of PCMCIA-bus and all the HW-manipulation is done via bus-driver through IRPs or direct function calls. I wish that the card would be multifunctional but it is not :frowning:

As you said, it is doable but not trivial. I didn’t quite catch the point if it is recommended or not (doing things inuser-land vs. kernel-mode)? At least the NDIS-driver would need to have a couple of “#if WIN98”…

  • Mikko

-----Original Message-----
From: ext Bill McKenzie [mailto:xxxxx@bsquare.com]
Sent: 15. maaliskuuta 2002 9:43
To: NT Developers Interest List
Subject: [ntdev] Re: Porting Win2k/WinXP drivers -> Win98SE/ME

You can port a Win2K/XP bus driver to 98/Me, I have done this personally.
You can make a single NDIS/WDM miniport that works on 2000/Me/98 and I
assume XP, I have worked on one of these. WMI is available natively on Me,
but you have to install it on 98 from here:

http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/MSDN-FILES/027/001/576/msdncompositedoc.xml

Power is a big hassle, and it took me a while to get it straight for all
platforms in our bus driver support in WinDK. One reason it was such a
hassle for us is I decided to follow the ‘OnNow’ power management
specification from Microsoft for our bus driver support. We already follow
it for our devices. So our typical WinDK device drivers power themselves
down by default when there are no handles open to them and then power up
when/if a handle is opened, (you can shut this off easily in WinDK BTW or
use selective suspend for USB if supported). Further, then the bus powers
itself down when no children are powered up. Problem is 2000/XP will allow
a child to power itself up when the parent is powered down. 98/Me will not.
Anyway, some fun gymnastics, but it all works, and I am the only one on the
planet I know of to follow that stupid specification and get it to work for
a bus driver and its child FDO drivers across 98/Me/2000/XP :slight_smile:

One huge problem that you will have is if this bus driver is to operate on
top of a PCI device that needs to split resources amonst its child drivers.
If the separate operations of the device are broken out into separate
functions on the PCI device, which they never are, then no problems.
However, if you need to split the resources of a single PCI function card,
you will have a good bit more trouble.

If this is a PCI card, also you won’t need an NDIS/WDM miniport as a normal
NDIS miniport will do. As for indicating packets in the NDIS context, you
can use a timer DPC to get to the correct context if memory serves. I
remember that issue, but its been a couple of years, so I don’t remember it
exactly, but its solvable.

All in all, its doable, but it ain’t trivial.


Bill McKenzie

wrote in message news:xxxxx@ntdev…

Hello everyone,

I’m developing set of device drivers for Win2k and WinXp. This driver-set
basically has a bus driver and two child device drivers on top of it. One of
the child device drivers is a NDIS-driver. We also have old set of device
drivers for the same HW (working for all platforms but they are not even
close to be WHQL-complient. Original plan was to keep to a separate driver
sets, old ones for Win9x-family and the new WHQL-complient for Win2k/WinXp.
UI would handle the differences in communications mode. Due to
re-architecting needs at user-level code because of the new drivers, it was
proposed that those WHQL-complient drivers could “easily” be ported to
Win98SE/Me (so the same UI code could be used in all OSes).

Generally, I’m very much against transferring complexity from user-land to
kernel-mode just because it can be done and it would make user-land code
easier (thus making kernel-code more complex). In this case I wouldn’t worry
about it too much as I would not be doing the port but as I’m curious soul
and like to learn new things. I would like to get some input on this before
saying “no” to whole idea. I have read the Walter Oney’s book and it covers
a bit on this subject but I guess what I’m really looking for is some
comments from people who are really had to deal with cases like this.

Is this really a trivial task to do? This is all that I know at the moment
(I ported one WDM driver to Me sometime ago):
- NDIS-WDM device drivers don’t work the same in Win2k and Win2k (all
packets need to be indicated in the context of NDIS-library thread)
- Some PnP-IRPs work differently (well, they work the same but what you set
to status and information field when IRP is completed varies).
- WMI is not available
- Power-management IRPs works little differently

Any other things that what will work and what won’t? How about user-land
notifications by OS (device arrival and etc.), will they work?

- Mikko


You are currently subscribed to ntdev as: xxxxx@nokia.com
To unsubscribe send a blank email to %%email.unsub%%

Its your call. For me I have WinDK to use which takes care of a large part
of the work on the bus driver end. The NDIS stuff is always a pain. But, if
it were me, I would probably force the one kernel code base approach just
for pure maintainability. Lot of factors here though, can’t make that call
for you.


Bill McKenzie

wrote in message news:xxxxx@ntdev…

Thanks for the quick response!

I elaborate this little bit further. The device is sitting on the top of
PCMCIA-bus and all the HW-manipulation is done via bus-driver through IRPs
or direct function calls. I wish that the card would be multifunctional but
it is not :frowning:

As you said, it is doable but not trivial. I didn’t quite catch the point if
it is recommended or not (doing things inuser-land vs. kernel-mode)? At
least the NDIS-driver would need to have a couple of “#if WIN98”…

- Mikko

-----Original Message-----
From: ext Bill McKenzie [mailto:xxxxx@bsquare.com]
Sent: 15. maaliskuuta 2002 9:43
To: NT Developers Interest List
Subject: [ntdev] Re: Porting Win2k/WinXP drivers -> Win98SE/ME

You can port a Win2K/XP bus driver to 98/Me, I have done this personally.
You can make a single NDIS/WDM miniport that works on 2000/Me/98 and I
assume XP, I have worked on one of these. WMI is available natively on Me,
but you have to install it on 98 from here:

http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/MSDN-FILES/027/001/576/msdncompositedoc.xml

Power is a big hassle, and it took me a while to get it straight for all
platforms in our bus driver support in WinDK. One reason it was such a
hassle for us is I decided to follow the ‘OnNow’ power management
specification from Microsoft for our bus driver support. We already follow
it for our devices. So our typical WinDK device drivers power themselves
down by default when there are no handles open to them and then power up
when/if a handle is opened, (you can shut this off easily in WinDK BTW or
use selective suspend for USB if supported). Further, then the bus powers
itself down when no children are powered up. Problem is 2000/XP will allow
a child to power itself up when the parent is powered down. 98/Me will not.
Anyway, some fun gymnastics, but it all works, and I am the only one on the
planet I know of to follow that stupid specification and get it to work for
a bus driver and its child FDO drivers across 98/Me/2000/XP :slight_smile:

One huge problem that you will have is if this bus driver is to operate on
top of a PCI device that needs to split resources amonst its child drivers.
If the separate operations of the device are broken out into separate
functions on the PCI device, which they never are, then no problems.
However, if you need to split the resources of a single PCI function card,
you will have a good bit more trouble.

If this is a PCI card, also you won’t need an NDIS/WDM miniport as a normal
NDIS miniport will do. As for indicating packets in the NDIS context, you
can use a timer DPC to get to the correct context if memory serves. I
remember that issue, but its been a couple of years, so I don’t remember it
exactly, but its solvable.

All in all, its doable, but it ain’t trivial.


Bill McKenzie

wrote in message news:xxxxx@ntdev…

Hello everyone,

I’m developing set of device drivers for Win2k and WinXp. This driver-set
basically has a bus driver and two child device drivers on top of it. One of
the child device drivers is a NDIS-driver. We also have old set of device
drivers for the same HW (working for all platforms but they are not even
close to be WHQL-complient. Original plan was to keep to a separate driver
sets, old ones for Win9x-family and the new WHQL-complient for Win2k/WinXp.
UI would handle the differences in communications mode. Due to
re-architecting needs at user-level code because of the new drivers, it was
proposed that those WHQL-complient drivers could “easily” be ported to
Win98SE/Me (so the same UI code could be used in all OSes).

Generally, I’m very much against transferring complexity from user-land to
kernel-mode just because it can be done and it would make user-land code
easier (thus making kernel-code more complex). In this case I wouldn’t worry
about it too much as I would not be doing the port but as I’m curious soul
and like to learn new things. I would like to get some input on this before
saying “no” to whole idea. I have read the Walter Oney’s book and it covers
a bit on this subject but I guess what I’m really looking for is some
comments from people who are really had to deal with cases like this.

Is this really a trivial task to do? This is all that I know at the moment
(I ported one WDM driver to Me sometime ago):
- NDIS-WDM device drivers don’t work the same in Win2k and Win2k (all
packets need to be indicated in the context of NDIS-library thread)
- Some PnP-IRPs work differently (well, they work the same but what you set
to status and information field when IRP is completed varies).
- WMI is not available
- Power-management IRPs works little differently

Any other things that what will work and what won’t? How about user-land
notifications by OS (device arrival and etc.), will they work?

- Mikko


You are currently subscribed to ntdev as: xxxxx@nokia.com
To unsubscribe send a blank email to %%email.unsub%%