Re: WinXP 64-bit Virtual DMA_ADAPTER

On Oct 26, 9:15 pm, "Alexander Grigoriev" <al...@xxxxxxxxxxxxx> wrote:
Documentation is a kind of contract between OS kernel developer and a driver
developer. It describes what's the programmer obligations and what's the
OS's obligations. Such interface abstracts from any internal implementation
detail. An OS developer cannot promise not to change implementation, this is
not a part of contract, but there is a guarantee that interface will behave
the same. If you rely too heavily on the implementation beyound documented
interfaces (maybe reverse ingeneered), and it changes and breaks your
driver, you don't have anybody to blame but you.

<marli...@xxxxxxxxx> wrote in message

news:1193451358.457368.309350@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



The use of PortCls's WavePci base class with an _USB_ device is not
officially
supported at all. Note "Pci" suffix in base class name and "USB".

The driver is WHQL certified and runs trouble free under 32-bit 2k,
XP, Vista...for years. There is no reason why it this driver model
should not work...and it does work. Could the driver have been written
as AVStream? Sure. Would I like to do that? Sure. But then there are
the details of time and money. Unfortunately, my company did not gain
$30 Billion in market cap yesterday, so I need to deal with those time/
cost issues...

This is a hack, which you did once to save efforts on proper AVStream
implementation.

This is a hack to work around what I consider to be Verifier.exe bug.

And, as all hacks, it starts to show teeth sooner or later.

Since this problem is caused by Verifier...the hack has no effect in a
system that runs without Verifier. I am certain this will work trouble
free for years.

This is like writing a virtual storage device as SCSIPORT's miniport and
using
timer to enter ScsiPortNotification context, with also providing SCSIPORT
with
ISA bus type and fake hardware resources.

This is something like using improper lubricant oil for the car engine.
It
works first, then it ceases to work.

I am working around a Verifier bug. If your car has a dead battery, no
matter the quaility of oil you use, your engine will not start. It is
obvious there is a verifier bug....I don't think verifier is supposed
write into Special Pool. Ever.

I have to say...the lack of interest and support from MSFT is
infuriating.

Why MS should support the direct mis-use of their PortCls module?

"Misuse of their PortCls model?"? Then they should not have certified
it in the first place...I don't agree it is misuse. And one more
thing: Elias Yakub himself posted a recommendation about creating a
fake DMA_ADAPTER...you can find it here:
http://www.adras.com/IoGetDmaAdapter-for-a-root-enumerated-device-in-....

Why am I upset? If I was able to figure out and work around this
problem by disasembling and reading "Undocumented NT" books, I can
tell you anybody at MSFT with source access could have answered my
questions after 15 minutes of investigation, if they were interested.
That is what is so infuriating.

There is no doubt other people are going to run into this
issue...

After such a forum topic, people will go AVStream way and not PortCls way
for
USB audio, as it is properly required.

Anybody writing an audio driver should abosoultely use AVStream. But
there are a lot of people who have written drivers similar to
mine...and this issue will come up. And forget about PortCls...Anybody
who needs to create a virtual DMA_ADAPTER is at risk for having this
problem.

MSFT should not complain when the EU is constantly on their case about
opening up their source so ISV can be on an even playing field.

So what? this will not turn PortCls magically to a USB audio framework.

I am not asking for "magic". I am asking for support. I am asking for
information about why this problem is happening. And now I am asking
that Verifier be fixed so this bug does not happen. If I had the
source code for HalGetDmaAdapter() or related source, then I would not
have beg for support. Right? If MSFT wants a black box OS, then they
should offer support...that is all I am saying. If they don't want to
offer support, then should make their source code more easily
available.

Like I said above...In general, I like MSFT. I only write code for
Windows. And they do a lot of things right. But, that does not mean
they should not be criticized when they do things wrong....in this
case, non-existent support. And my point about the EU was to
illustrate that I am not the only person who feels this way.

Maxim, I have seen you post for years, and I, as well as many others
have the upmost respect for you and the time you have put in...no
doubt about it...but, on this, issue, I respectfully disagree.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@xxxxxxxxxxxxxxxxxxxx://www.storagecraft.com- Hide quoted text -

- Show quoted text -

Yes, I agree 100% with what you said, Alexander...But every time MS
releases a new OS or flavor of OS...they get to break the contract at
will. Why should XP-64's IoGetDmaAdapter() work differently than in
XP-32? It is not like I was hooking a system service in some ad-hoc
undocumentated and expecting it to work for all OS. I am using
IoGetDmaAdapter(): A documented function. I cannot think of a good
reason why it should work differently under 64. The whole reason for
the function is so that we don't have to worry about incompatabilities
wrt to DMA among the various OS.

Look, I am not complaining about about them breaking the
contract...there is a price for progress and I am sure there is a
technial reason why it is different under XP-64...or it is just an
oversight...no problem. I am just complaining that very often they are
unwilling to help. And it is not for lack of resources or knowledge.
It is for lack of will. MSFT could have saved me many, many hours of
time by just taking an interest in my question.

We are all on the same team in that we all want to write good code, as
efficiently and cheaply as possible. But, often MSFT is not a very
good team player.

.

Relevant Pages

  • Re: WinXP 64-bit Virtual DMA_ADAPTER
    ... Such interface abstracts from any internal ... driver, you don't have anybody to blame but you. ... system that runs without Verifier. ... If MSFT wants a black box OS, ...
    (microsoft.public.development.device.drivers)
  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... Separating an interface from its implementation reduces the ... whatever reason, it's unwilling to reveal to me. ... And `enforced data hiding' just slams ... Irrelevant for read-only inspection. ...
    (comp.lang.python)
  • RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
    ... kernel. ... A process has unity of interface. ... you cannot conjoin-clone and thread-clone repeatedly and variously from the ... If there is no reason to share, ...
    (Linux-Kernel)
  • Re: Create libFOO.a from libFOO.so?
    ... or crash when executed on arbitrary Linux system. ... the problem is that e.g. getpwuid() ... use undocumented/private/binary interface to libnss*, ... There is no reason this conversion can't be done reliably. ...
    (comp.unix.programmer)
  • Re: The Case for Multiple-Inheritance
    ... It's like a Java interface ... functionality into modules; ... Clearly there is a reason you aren't running a consultancy. ... Classes defined by composing modules is bad practice. ...
    (comp.lang.ruby)