Did the behavior of obsolete API’s change from XP to Vista? Specifically, I am referring to HalTranslateBusAddress() and IoReportResourceUsage().
In general, do API’s marked as obsolete still function as originally intended, or do they return an error, or a NULL pointer, or maybe just crash? Is there any way of knowing the behavior, and if it has changed as the OS moves forward?
At least ExQueueWorkItem works fine, dunno on other obsolete APIs.
My binary built using NT4 DDK works fine on Vista, and it uses
ExQueueWorkItem.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Did the behavior of obsolete API’s change from XP to Vista? Specifically, I
am referring to HalTranslateBusAddress() and IoReportResourceUsage().
>
> In general, do API’s marked as obsolete still function as originally
intended, or do they return an error, or a NULL pointer, or maybe just crash?
Is there any way of knowing the behavior, and if it has changed as the OS moves
forward?
>
APIs that are listed as OBSOLETE may or may not work. HalTranslateBusAddress is an ancient function from back in NT V4 days, which is effectively supplanted by PnP’s IRP_MN_START_DEVICE processing.
Unless you have an ISA bus device, you want to stay away from the old-style interfaces. They were designed to work before the advent of PnP and in the modern world they can have “issues”
Peter
OSR
Yes, I understand the overall philosophy here, and know enough to avoid using these obsolete API’s in the future. What I am trying to do is understand the mechanism by which an existing “almost-WDM” driver for a PCI device could function successfully under XP while using obsolete API’s, yet fail under Vista. It seems that there may be different degrees of obsolescence.
In this case, it seems that HalTranslateBusAddress() returned a valid address under XP, but returns a NULL pointer under Vista. I know that obsolete functions are not guaranteed to work, but it would be valuable to have documentation which spells out the exact behavior (full, reduced, none, or error) under the various OS releases.
As Maxim stated above, his driver (built using NT4 DDK) still works fine under Vista, even though it calls ExQueueWorkItem(). The documentation for ExQueueWorkItem() and HalTranslateBusAddress() is the same – both merely state obsolete. How is one to know if it is really OK to continue using any given obsolete function, and when does it go from “use at your own risk” to “definitely will not work”?
ExQueueWorkItem is a particularly bad example. It’s still supported for use in some cases, it was supplanted by creation of a new “safer” variant, and it’s just not the kind of API that’s going to stop working – all it does is create a data structure and queue it to the work queues. It’d take a lot of O/S change for that to break, you know??
It seems to me that you’re intermingling two problems here: (a) What’s the general Windows policy around DDIs that are labeled as “obsolete” and (b) Why does your call to HalTranslateBusAddress fail.
Answering the general question (a) isn’t likely to help you with your specific question (b).
To answer the former question: The way I understand it if an obsolete function works, it works. If it doesn’t work, it doesn’t work. The cases to be most concerned about are using obsolete functions in a context that was never anticipated when the function was written. HalGetBusData is a good example of this: It was written before the advent of PnP, and doesn’t have any way of understanding that devices (and buses) can leave and arrive dynamically. Thus, there are cases where obsolete functions APPEAR to do the right thing, but in fact don’t work properly… or where they DO work in some cases, but don’t work in various corner cases.
To answer your specific question (“Why does HalTranslateBusAddress not work on Vista, when it used to work on XP”): You need to give us more information about how/where/when it’s failing for you. Does it ALWAYS fail? Only on a particular system? What kind of device are we talking about (PCI, PCIe, Cardbus)? What are you passing in when it works (if it ever does) and when it fails? Where are you getting the bus specific values (let me guess… HalGetBusData? Which I’ve just mentioned as a classic example of an API that’s clearly lived long beyond it’s intended lifetime)?
The best question yet is why don’t you get rid of this crufty old junk and write a proper driver for your device? There’s no such thing as an “almost-WDM” driver… that’s like being “almost pregnant”. I bet it’d take you less time to re-write your driver as a proper KMDF driver than to debug why DDIs that have been obsolete for 7 years have stopped working, and how to remedy that situation.
Peter
OSR
Well, the remedy is clear – rewrite the driver under KMDF.
I guess what I was trying to do is forensically analyze the exact mechanism of failure, but to your point, that effort is not productive towards an ultimate solution. But it would have satisfied my curiosity.
I do feel, however, that this ambiguity surrounding obsolescense of DDI’s is not a good thing. It allows situations such as our “almost-WDM” driver to exist in the first place, where the port to PnP / WDM was not done properly and fully in the first place, yet the driver still worked.
On the lighter side, your posting made for very enjoyable reading – I felt like I was reading a Peter Pontificates. It even motivated me to do a little Wikipedia research on the history of the term “crufty”. -
We can do that – It’s just not nearly as easy as it might sound.
Walk through the driver on both XP and Vista, function call by function call, to the point where the returned data is different. Tell us here on the list which functions are called, what data’s returned in each case, and where it differs. THEN we can PROBABLY tell you what’s changed.
Well, it’s a “damned if you do, damned if you don’t” situation, isn’t it? It’s not like with the introduction of PnP, Microsoft could say “The old DDIs that are obsolete have been removed” or “The old DDIs that are obsolete now return STATUS_YOU_SUCK” – People have legitimate needs to support old junk. It’s the propagation of that old junk faaaar into the new era that’s the problem.
To aid this problem, Microsoft added Deprecated Function Checking to the DDK back in, oh, the Windows XP DDK. This feature flags functions that have been deprecated, so at least a dev is made AWARE of the fact that some function they’re calling at some point potentially, maybe, someday, perhaps, will eventually be unsupported.
Bottom line: There’s no substitute for a competent engineer making informed decisions.
Peter
OSR
> ExQueueWorkItem is a particularly bad example. It’s still supported for use
in
some cases, it was supplanted by creation of a new “safer” variant,
Safer for PnP drivers only, for non-PnP things, addrefing a random device
object for the duration of the work item gives us nothing
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com