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
