Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Port from XP to Win7 due to Deprecated Calls

- - - - -

  • Please log in to reply
No replies to this topic


  • Member
  • 1 posts
  • Joined 14-May 12
  • OS:XP Pro x86
  • Country: Country Flag
Please forgive the length of this post, but I feel it necessary to fully describe the problem I'm facing.
I am really just looking to see if the solutions I mention are feasible, and which might be best,
based on the constraints I am working under....

I am currently tasked with porting some Windows Device Drivers from an XP environment to
a Windows 7 environment. I have no previous driver development experience, so this is fairly new to me.
Originally, these drivers were developed for Windows NT - they happened to work on XP also, and as time
progressed, no update to them was ever made. However, some of the HAL calls
(HalGetBusData, HalTranslateBusAddress, etc.) have been deprecated, and these must now be replaced or the drivers
will not work in the newer Windows 7 environment. The drivers were written in the WDM model for
non-Plug and Play. I am trying to convert them to the WDF model, preferably using PnP.

The architecture is this: There are 10 identical drivers which represent the 10 slots that a variety of
proprietary PCI I/O cards can plug into. The BusDataType Bus/Slot address for each "physical slot" is known, so it used
to be a simple matter for a driver to make a HalGetBusData() call to see if a device was present at its particular slot,
and read what the configuration data was for that device. Each driver was paired with the device in its slot. There
can be any number of I/O cards in the system (up to 10) and any type of card can be plugged in any slot.

It is crucial to keep this basic architecture. The user application code is written to communicate to the
drivers expecting this setup. It would require major surgery in the application code to try to change this.
Also, as in everything, time is of the essence, so I cannot afford too much time for this port.

I would think that it would not be that difficult to keep the driver/device arrangement as is, and just
modernize the drivers by using the WDF. However, if I try to use Plug and Play, at bootup all the possible devices
(7 possible I/O cards, listed in the .INF file) are all assigned to the first driver loaded - that is, EvtDeviceAdd()
will be called by the system, and create a device object for each device found in the system, and assign them to the
first driver loaded. With the old drivers, each driver knew its physical slot, and was then able to use
IoCreateDevice() to create a device object for the device found at that slot - an EvtDeviceAdd() callback was not used.
Each driver had a single "Driver Object"/"Device Object" pair. The application code knew this, and communicated to the
I/O devices using this arrangement. (Question: Is it possible to use the WDF PnP model to "assign" a single device in a
known slot, to a driver? Remember, the drivers are based on the slot, not device. In other words, a driver can be attached
to any device in its slot. We just need to know that deviceX is in slotA - only one device per driver. Can this be
done by some .INF file manipulation - i.e. would multiple .INF files in an install work? How would this be done? If a device
in the .INF file causes the EvtDeviceAdd() function of a currently loaded driver to be called, can the device be interrogated
to see if it's in the correct slot for that driver, and either be accepted, or rejected if it is not, and hopefully be selected
by another driver until it matches the driver that is meant for that device's slot?)

There is the possibility of using WDF, non-Plug and Play - there is an example in the WDK, but it seems to be for
virtual files, etc., and not real-world devices - it uses an IRP_MN_QUERY_INTERFACE to get device info from the Bus Object.
Also, it is basically screamed all over the net - Use WDF, PnP!!!!!!!!

So basically, I need to know if a device is in a slot that is "assigned" to a driver (one of 10 drivers), and then assign a
device object in this driver to that device - that's it....one device assigned to one driver, based on the slot that it
is in.

In any event, does anyone have a good suggestion for me, as to what might be the correct path to go down for such an
application? Which, given the description of the problem, might be the best method to do what I am attempting to do,
(i.e. WDF-PnP, WDF-non-PnP, or something else)? If so, could you also please point me to any good examples? The WDK seems to
come close in some regards, but is lacking enough to keep me searching.... Does the Bus Interface method (WDF non-PnP) sound feasible?

Thanks in advance,

Bob Sinkovic
Senior Software Engineer

How to remove advertisement from MSFN

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users