Jump to content

Port from XP to Win7 due to Deprecated Calls


bsinkovic

Recommended Posts

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

Link to comment
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...