How to develop drivers that are not well documented in WDK?

I’m just curious about this: how one could develop drivers that are not documented in WDK. I’m saying something like USB 3.0 host controller (xHCI). Documents regarding what interfaces must be supported, what kind of PDO/FDO should be created are nowhere to be found (at least for me). But we did find many company (NEC, AMD, Asmedia, etc.) are deliverying their own USB host driver. Could anyone here give me some light on this? I’d appreciate it very much.

On 11/17/2011 10:45 AM, xxxxx@yeah.net wrote:

I’m just curious about this: how one could develop drivers that are
not documented in WDK.

Either work really closely with Microsoft, hire someone who does, or
reverse-engineer the OS.

Problem with reverse engineering: any future “Windows Update” can easily
break your driver, so it’s a ticking time-bomb on the system.

There are two aspects to this question: (1) The driver architecture itself and (2) How you could create a new driver that would successfully replace an existing Microsoft driver within an existing Windows device branch. These are two very different things.

In terms of the driver architecture itself, this isn’t a big deal. Writing an xHCI driver shouldn’t be hard… it’s just a bus master DMA device on a backplane bus. Writing drivers for such a device is quite well documented. The xHCI spec is readily available… so it should be relatively straight forward.

In terms of successfully substituting your driver for the standard Windows driver in the device tree so that “everything just works” that’s another thing entirely. While you *could* do this by partnering with Microsoft as Mr. Patzke suggested (assuming you could find somebody at Microsoft who was willing), that could be “difficult.” But is that *really* necessary? If you think about it, EXCEPT for the interactions with the USB Hub driver, the vast majority of the upper-edge of the USB HCD + HUB driver suite is documented and rather well known. Assuming you’re willing to write your own hub driver as well as HCD, it *should* be quite straight-forward to get something that works in about 80% or 90% of the use cases. After that, the job becomes trial-and-error… exactly how closely do you want your HCD + hub driver to resemble the in-box MSFT solution.

Now… Don’t assume that because I said the job should be “quite straight forward” that it’s one that can be done easily by somebody without a good deal of Windows OS and driver experience. This is no project for a noob. And, with all due respect, the fact that you’re asking how to do this – while commendable – is indeed an indicator of the fact that you’re not exactly an expert in this space. And I would thus not recommend you undertake this project without engaging expert help.

Peter
OSR

At 2011-11-17 20:30:14,“Hagen Patzke” wrote:
>On 11/17/2011 10:45 AM, xxxxx@yeah.net wrote:
>> I’m just curious about this: how one could develop drivers that are
>> not documented in WDK.
>
>Either work really closely with Microsoft, hire someone who does, or
>reverse-engineer the OS.

I don’t think company like AMD would develop and release that important drivers, say USB host drivers, by a totally reverse engineering based approach.

The only possible choice among the three you mentioned would be “work closely with MS”. If this is true, I think that’s really double standard. On the one hand, MS tells their developer not trying to product driver types beyond WDK classification. On the other hand, they open propriatary interfaces to some specific company (for $). Well, Windows is proprietary to Microsoft, and of course they can take the liberty of opening their documents or OS interfaces to anyone they like. Frustrating!

Anyway, thanks for your reply again.

At 2011-11-17 22:13:26,xxxxx@osr.com wrote:

There are two aspects to this question: (1) The driver architecture itself and (2) How you could create a new driver that would successfully replace an existing Microsoft driver within an existing Windows device branch. These are two very different things.

In terms of the driver architecture itself, this isn’t a big deal. Writing an xHCI driver shouldn’t be hard… it’s just a bus master DMA device on a backplane bus. Writing drivers for such a device is quite well documented. The xHCI spec is readily available… so it should be relatively straight forward.

In terms of successfully substituting your driver for the standard Windows driver in the device tree so that “everything just works” that’s another thing entirely. While you *could* do this by partnering with Microsoft as Mr. Patzke suggested (assuming you could find somebody at Microsoft who was willing), that could be “difficult.” But is that *really* necessary? If you think about it, EXCEPT for the interactions with the USB Hub driver, the vast majority of the upper-edge of the USB HCD + HUB driver suite is documented and rather well known. Assuming you’re willing to write your own hub driver as well as HCD, it *should* be quite straight-forward to get something that works in about 80% or 90% of the use cases. After that, the job becomes trial-and-error… exactly how closely do you want your HCD + hub driver to resemble the in-box MSFT solution.

Now… Don’t assume that because I said the job should be “quite straight forward” that it’s one that can be done easily by somebody without a good deal of Windows OS and driver experience. This is no project for a noob. And, with all due respect, the fact that you’re asking how to do this – while commendable – is indeed an indicator of the fact that you’re not exactly an expert in this space. And I would thus not recommend you undertake this project without engaging expert help.

Peter
OSR

Hi Peter,

Thanks for your detailed explanation. It’s could be helpful to me. However, I still think there are many things in Windows which is just “specified by Microsoft”. No reason, no logic. For example, what the hardware ID string a specific bus should populate for its child device? Maybe it’s not hard to write a architecturely correct PCI bus driver, but it’s really hard to know what’s the rule Windows inbox PCI bus obey in setting hardware IDs. There are numerous such problems.
Recently I bought a new PC with a third party USB host driver installed. After some google work I found many company had developed their own USB drivers, among which there is big guy like AMD as well as some nobodies. So I guess there must be some “standard” way to achieve this. Someone in this mail list told me that they may “work closely with MS”. Possiblely.

I think you are trivializing the scope of implementing a functional
usb port driver. Yes the lower edge interface to the hardware is
straightforward, but the upper edge undocumented port driver interface
is not. Without access to source code, this is a reverse engineering
project that is likely to take many man-months of effort to get right.

On the other hand I wonder why anyone would implement a windows xhci
controller when the market for that is going to be a rather narrow
window quickly closed by win8 and most likely some service pack update
for win7.

Mark Roddy

On Thu, Nov 17, 2011 at 9:13 AM, wrote:
>


>
> There are two aspects to this question: (1) The driver architecture itself and (2) How you could create a new driver that would successfully replace an existing Microsoft driver within an existing Windows device branch. ?These are two very different things.
>
> In terms of the driver architecture itself, this isn’t a big deal. ?Writing an xHCI driver shouldn’t be hard… it’s just a bus master DMA device on a backplane bus. ?Writing drivers for such a device is quite well documented. ?The xHCI spec is readily available… so it should be relatively straight forward.
>
> In terms of successfully substituting your driver for the standard Windows driver in the device tree so that “everything just works” that’s another thing entirely. ?While you could do this by partnering with Microsoft as Mr. Patzke suggested (assuming you could find somebody at Microsoft who was willing), that could be “difficult.” ? But is that really necessary? ?If you think about it, EXCEPT for the interactions with the USB Hub driver, the vast majority of the upper-edge of the USB HCD + HUB driver suite is documented and rather well known. ?Assuming you’re willing to write your own hub driver as well as HCD, it should be quite straight-forward to get something that works in about 80% or 90% of the use cases. ?After that, the job becomes trial-and-error… exactly how closely do you want your HCD + hub driver to resemble the in-box MSFT solution.
>
> Now… Don’t assume that because I said the job should be “quite straight forward” that it’s one that can be done easily by somebody without a good deal of Windows OS and driver experience. ?This is no project for a noob. ?And, with all due respect, the fact that you’re asking how to do this – while commendable – is indeed an indicator of the fact that you’re not exactly an expert in this space. ?And I would thus not recommend you undertake this project without engaging expert help.
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

At 2011-11-17 23:33:17,“Mark Roddy” wrote:
>I think you are trivializing the scope of implementing a functional
>usb port driver. Yes the lower edge interface to the hardware is
>straightforward, but the upper edge undocumented port driver interface
>is not. Without access to source code, this is a reverse engineering
>project that is likely to take many man-months of effort to get right.
>
>On the other hand I wonder why anyone would implement a windows xhci
>controller when the market for that is going to be a rather narrow
>window quickly closed by win8 and most likely some service pack update
>for win7.
>
>Mark Roddy

Last year USB3.0 is $3/chip, this year it’s $1/chip. After win8 release it’s likely to be under $0.5/chip.
Last year nearly all USB3.0 PCs are equiped with NEC’s chip. This year there are 5-6 mainstream company on board. After win8 release, I guess we can see Intel & AMD alive only.

wind_lee wrote:

At 2011-11-17 23:33:17,“Mark Roddy” wrote: >
> >On the other hand I wonder why anyone would implement a windows xhci
> >controller when the market for that is going to be a rather narrow
> >window quickly closed by win8 and most likely some service pack update >for win7.
> > >Mark Roddy
> Last year USB3.0 is $3/chip, this year it’s $1/chip. After win8 release it’s likely to be under $0.5/chip.
> Last year nearly all USB3.0 PCs are equiped with NEC’s chip. This year there are 5-6 mainstream company on board. After win8 release, I guess we can see Intel & AMD alive only.

All of that is true, but you have missed Mark’s point. The USB 3.0
market has been held back because there is no support from Microsoft.
Each company has had to produce their own driver stack (not just one
driver!), at considerable expense, and we have no idea what rules they
followed. There are no APIs, no interfaces, no guidelines. It’s the
wild, wild west.

Once Win 8 releases, with its (presumed) USB 3.0 support, that situation
ends instantly. All of the xHCI controller hardware will be supported
by Microsoft’s driver, and the market for xHCI host controller drivers
is eliminated. Going through the significant investment to create a
driver that will have a lifespan measured in months seems like an unwise
marketing decision.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

wind_lee wrote:

I don’t think company like AMD would develop and release that
important drivers, say USB host drivers, by a totally reverse
engineering based approach.

Then I’m afraid you are rather naïve. It is done all the time, because
there often is no alternative. AMD just needs to ship hardware. They
aren’t particularly interested in establishing driver standards. They
just need the stuff to work.

The only possible choice among the three you mentioned would be “work
closely with MS”. If this is true, I think that’s really double
standard. On the one hand, MS tells their developer not trying to
product driver types beyond WDK classification.

Where have you seen that? The WDK does contain samples for some driver
types, but no one ever told you not to develop others.

On the other hand, they open propriatary interfaces to some specific
company (for $).

No one ever said they wanted money for it. For example, if you want to
build a WDDM display driver, for all practical purposes, you need to
have a team in Redmond who can walk down the hall and chat with the
Microsoft developers. There are no additional products to buy, and they
won’t charge you to have your team there, but you need the brainpower.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Well, in fact, that’s why I post this thread originally. I guess USB3.0 host driver didn’t consume large amounts of resources of the vendors. They must have some channel to get a documented Windows USB architecture spec., if not the code sample directly. As some very small company can also build such drivers, the “channel” looks fairly reasonable in price.

At 2011-11-18 01:24:24,“Tim Roberts” wrote:
>wind_lee wrote:
>>
>> At 2011-11-17 23:33:17,“Mark Roddy” wrote: >
>> >On the other hand I wonder why anyone would implement a windows xhci
>> >controller when the market for that is going to be a rather narrow
>> >window quickly closed by win8 and most likely some service pack update >for win7.
>> > >Mark Roddy
>> Last year USB3.0 is $3/chip, this year it’s $1/chip. After win8 release it’s likely to be under $0.5/chip.
>> Last year nearly all USB3.0 PCs are equiped with NEC’s chip. This year there are 5-6 mainstream company on board. After win8 release, I guess we can see Intel & AMD alive only.
>
>All of that is true, but you have missed Mark’s point. The USB 3.0
>market has been held back because there is no support from Microsoft.
>Each company has had to produce their own driver stack (not just one
>driver!), at considerable expense, and we have no idea what rules they
>followed. There are no APIs, no interfaces, no guidelines. It’s the
>wild, wild west.
>
>Once Win 8 releases, with its (presumed) USB 3.0 support, that situation
>ends instantly. All of the xHCI controller hardware will be supported
>by Microsoft’s driver, and the market for xHCI host controller drivers
>is eliminated. Going through the significant investment to create a
>driver that will have a lifespan measured in months seems like an unwise
>marketing decision.
>
>–
>Tim Roberts, xxxxx@probo.com
>Providenza & Boekelheide, Inc.
>
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

wind_lee wrote:

Well, in fact, that’s why I post this thread originally. I guess
USB3.0 host driver didn’t consume large amounts of resources of the
vendors. They must have some channel to get a documented Windows USB
architecture spec., if not the code sample directly.

I doubt it. Indeed, I doubt the existence of a “documented Windows USB
architecture spec,” except as a PowerPoint spreadsheet on some
developer’s laptop. Perhaps I am too cynical.

It is possible, I suppose, that these companies have a Windows source
license – such a thing is available – but it’s not clear to me that it
would be legal to build a driver based on that information.

As some very small company can also build such drivers, the
“channel” looks fairly reasonable in price.

What very small company? I think you’ll find that there are only 2
(maybe 3) USB 3.0 driver stacks for Windows in the world today.
Everyone else is just repackaging one of those.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

There are license agreements to take parts of Windows and develop code
based on them, even when you are not a full source licensee. I know of
a firm that years ago, developed a display driver based on the remote
desktop technology, that could be used to boot a headless server.
There is a cost for these licenses, and I got the impression it helped
if you found folks in Microsoft to be your advocate.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Tim Roberts” wrote in message news:xxxxx@ntdev:

> wind_lee wrote:
> > Well, in fact, that’s why I post this thread originally. I guess
> > USB3.0 host driver didn’t consume large amounts of resources of the
> > vendors. They must have some channel to get a documented Windows USB
> > architecture spec., if not the code sample directly.
>
> I doubt it. Indeed, I doubt the existence of a “documented Windows USB
> architecture spec,” except as a PowerPoint spreadsheet on some
> developer’s laptop. Perhaps I am too cynical.
>
> It is possible, I suppose, that these companies have a Windows source
> license – such a thing is available – but it’s not clear to me that it
> would be legal to build a driver based on that information.
>
> > As some very small company can also build such drivers, the
> > “channel” looks fairly reasonable in price.
>
> What very small company? I think you’ll find that there are only 2
> (maybe 3) USB 3.0 driver stacks for Windows in the world today.
> Everyone else is just repackaging one of those.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

>What very small company? I think you’ll find that there are only 2

(maybe 3) USB 3.0 driver stacks for Windows in the world today.
Everyone else is just repackaging one of those.

That’s relief. It’s very possible they could buy a software license from the 3rd party if there is a pure software design house who develop USB stack.

> > As some very small company can also build such drivers, the “channel”

> looks fairly reasonable in price.

What very small company? I think you’ll find that there are only 2 (maybe 3)
USB 3.0 driver stacks for Windows in the world today.
Everyone else is just repackaging one of those.

Typically VLSI CHIP designer companies create the drivers, and then many companies make BOARDS/SYSTEMS with those chips, with the driver licensed along with the chip. To design a moderately complex VLSI chip and get it into volume production I believe costs a bunch of million dollars. Spending $500K (or more) is just part of the cost to make a chip usable on Windows. If the cost to design, debug, and get into manufacturing of a chip was $5M and a decent driver cost $500K, that’s only 10% of the total product engineering cost spent on driver development.

Peter’s comments about making a driver for a new random device not being so hard vs making a driver that deeply integrates with windows as a standard device class being more difficult is good wisdom.

Jan

Well.I think “wild” is a bit strong.

USB3 stacks (software and hardware) must be independently certified by USBIF
to have USB logo. Hardware and software are tested using various topologies
as well as against hundreds of the most popular devices on the market. They
are tested for USB3.0 and USB2.0 compatibility. A single certification
process takes weeks.

USBIF, motherboard manufacturers as well as host controller manufacturers
are taking USB2.0 compatibility very seriously (in part due to strict USBIF
requirements).

So it is not a free-for-all as suggested by “wild west” comment. Having said
that, developing a USB 3.0 stack that can pass all the certification is,
indeed, very difficult.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of wind_lee
Sent: Thursday, November 17, 2011 9:42 AM
To: Windows System Software Devs Interest List
Subject: Re:Re: [ntdev] How to develop drivers that are not well documented
in WDK?

Well, in fact, that’s why I post this thread originally. I guess USB3.0 host
driver didn’t consume large amounts of resources of the vendors. They must
have some channel to get a documented Windows USB architecture spec., if not
the code sample directly. As some very small company can also build such
drivers, the “channel” looks fairly reasonable in price.

At 2011-11-18 01:24:24,“Tim Roberts” wrote:
>wind_lee wrote:
>>
>> At 2011-11-17 23:33:17,“Mark Roddy” wrote: >
>> >On the other hand I wonder why anyone would implement a windows xhci
>> >controller when the market for that is going to be a rather narrow
>> >window quickly closed by win8 and most likely some service pack update
>for win7.
>> > >Mark Roddy
>> Last year USB3.0 is $3/chip, this year it’s $1/chip. After win8 release
it’s likely to be under $0.5/chip.
>> Last year nearly all USB3.0 PCs are equiped with NEC’s chip. This year
there are 5-6 mainstream company on board. After win8 release, I guess we
can see Intel & AMD alive only.
>
>All of that is true, but you have missed Mark’s point. The USB 3.0
>market has been held back because there is no support from Microsoft.
>Each company has had to produce their own driver stack (not just one
>driver!), at considerable expense, and we have no idea what rules they
>followed. There are no APIs, no interfaces, no guidelines. It’s the
>wild, wild west.
>
>Once Win 8 releases, with its (presumed) USB 3.0 support, that situation
>ends instantly. All of the xHCI controller hardware will be supported
>by Microsoft’s driver, and the market for xHCI host controller drivers
>is eliminated. Going through the significant investment to create a
>driver that will have a lifespan measured in months seems like an unwise
>marketing decision.
>
>–
>Tim Roberts, xxxxx@probo.com
>Providenza & Boekelheide, Inc.
>
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I must add that even WITH full source access, this is no easy task. Getting to the 80-90% isn’t too bad, but that last 10% is quite a tough challenge!

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, November 17, 2011 6:13 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to develop drivers that are not well documented in WDK?

There are two aspects to this question: (1) The driver architecture itself and (2) How you could create a new driver that would successfully replace an existing Microsoft driver within an existing Windows device branch. These are two very different things.

In terms of the driver architecture itself, this isn’t a big deal. Writing an xHCI driver shouldn’t be hard… it’s just a bus master DMA device on a backplane bus. Writing drivers for such a device is quite well documented. The xHCI spec is readily available… so it should be relatively straight forward.

In terms of successfully substituting your driver for the standard Windows driver in the device tree so that “everything just works” that’s another thing entirely. While you *could* do this by partnering with Microsoft as Mr. Patzke suggested (assuming you could find somebody at Microsoft who was willing), that could be “difficult.” But is that *really* necessary? If you think about it, EXCEPT for the interactions with the USB Hub driver, the vast majority of the upper-edge of the USB HCD + HUB driver suite is documented and rather well known. Assuming you’re willing to write your own hub driver as well as HCD, it *should* be quite straight-forward to get something that works in about 80% or 90% of the use cases. After that, the job becomes trial-and-error… exactly how closely do you want your HCD + hub driver to resemble the in-box MSFT solution.

Now… Don’t assume that because I said the job should be “quite straight forward” that it’s one that can be done easily by somebody without a good deal of Windows OS and driver experience. This is no project for a noob. And, with all due respect, the fact that you’re asking how to do this – while commendable – is indeed an indicator of the fact that you’re not exactly an expert in this space. And I would thus not recommend you undertake this project without engaging expert help.

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

At 2011-11-18 01:30:17,“Tim Roberts” wrote:
>wind_lee wrote:
>>
>> I don’t think company like AMD would develop and release that
>> important drivers, say USB host drivers, by a totally reverse
>> engineering based approach.
>
>Then I’m afraid you are rather na?ve. It is done all the time, because
>there often is no alternative. AMD just needs to ship hardware. They
>aren’t particularly interested in establishing driver standards. They
>just need the stuff to work.

Although arguing if AMD would design a production level driver totally based on reverse-engineering approach is nonsense, I still want to say, it’s pretty tough for me to imagine that AMD’s project manager go to their engineer’s cubicle and say: “We need a USB driver stack. We have no resource for you to reference and we know neither you do. So please just go studying how Microsoft implments it and duplicate one for me.”

>> The only possible choice among the three you mentioned would be “work
>> closely with MS”. If this is true, I think that’s really double
>> standard. On the one hand, MS tells their developer not trying to
>> product driver types beyond WDK classification.
>
>Where have you seen that? The WDK does contain samples for some driver
>types, but no one ever told you not to develop others.

So why the WDK came into being? Undocumented is not recommended, this is the Windows’ philosophy, isn’t it?

>> On the other hand, they open propriatary interfaces to some specific
>> company (for $).
>
>No one ever said they wanted money for it. For example, if you want to
>build a WDDM display driver, for all practical purposes, you need to
>have a team in Redmond who can walk down the hall and chat with the
>Microsoft developers. There are no additional products to buy, and they
>won’t charge you to have your team there, but you need the brainpower.

Well, maybe I’m wrong. But from my experience, if you pay $400 to MS for a one year technet subscription, you can ask 2 questions regarding Microsoft products’ usage. If you pay $1200 to take part in a logo fest event, you may have the chance to get some detailed idea on how some of the winqual test items work. And now, you are implying that if I want to know something undocumented about Windows kernel, all things I need to do is just going down there to the Redmond.

To answer your question specifically…

It is possible to develop a USB Host Controller driver for Windows by using
only the DDK documentation and the DDK include files from which you can
learn a lot about how the USB stack works. Having been a major contributor
to such a driver, I know it is possible, although it is difficult. I would
not, however, characterize doing so as “reverse engineering” because all the
information is publically available. Using a combination of publicly
available documentation and header files, as well as proper software and
hardware tools, it can be done, and has been done by more than one company.
It is, however, a huge task.

Like with any other programming project, you have understand the problems
that need to be solved and then develop a plan to solve them. Then, you need
to develop a plan for how to test such a stack. Certainly, you are not going
to find a “sample USB Host Controller driver” in the DDK. It just means you
have to understand how such a stack *would* work, and then write code to
solve those problems.

Many programmers such as myself, do not look at these questions as problems,
but as challenges that are satisfying to resolve. If your team has such a
mindset, it can be done. If your team is just trying to get a stack done as
fast as possible without appreciating the challenges, the task will be
difficult.

In my case, of course, we had a team of people that had different expertise
and who each contributed to the solutions of many challenges we faced.

Sam Tertzakian
www.zorsoft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yeah.net
Sent: Thursday, November 17, 2011 7:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to develop drivers that are not well documented in
WDK?

At 2011-11-18 01:30:17,“Tim Roberts” wrote:
>wind_lee wrote:
>>
>> I don’t think company like AMD would develop and release that
>> important drivers, say USB host drivers, by a totally reverse
>> engineering based approach.
>
>Then I’m afraid you are rather naove. It is done all the time, because
>there often is no alternative. AMD just needs to ship hardware. They
>aren’t particularly interested in establishing driver standards. They
>just need the stuff to work.

Although arguing if AMD would design a production level driver totally based
on reverse-engineering approach is nonsense, I still want to say, it’s
pretty tough for me to imagine that AMD’s project manager go to their
engineer’s cubicle and say: “We need a USB driver stack. We have no resource
for you to reference and we know neither you do. So please just go studying
how Microsoft implments it and duplicate one for me.”

>> The only possible choice among the three you mentioned would be “work
>> closely with MS”. If this is true, I think that’s really double
>> standard. On the one hand, MS tells their developer not trying to
>> product driver types beyond WDK classification.
>
>Where have you seen that? The WDK does contain samples for some driver
>types, but no one ever told you not to develop others.

So why the WDK came into being? Undocumented is not recommended, this is the
Windows’ philosophy, isn’t it?

>> On the other hand, they open propriatary interfaces to some specific
>> company (for $).
>
>No one ever said they wanted money for it. For example, if you want to
>build a WDDM display driver, for all practical purposes, you need to
>have a team in Redmond who can walk down the hall and chat with the
>Microsoft developers. There are no additional products to buy, and
>they won’t charge you to have your team there, but you need the brainpower.

Well, maybe I’m wrong. But from my experience, if you pay $400 to MS for a
one year technet subscription, you can ask 2 questions regarding Microsoft
products’ usage. If you pay $1200 to take part in a logo fest event, you may
have the chance to get some detailed idea on how some of the winqual test
items work. And now, you are implying that if I want to know something
undocumented about Windows kernel, all things I need to do is just going
down there to the Redmond.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I wrote a long reply and deleted it. Twice! Ooops, now make that 3 times!!

The Tao Te Ching starts (according to one translation): “The way the can be written, is not the true way.”

OP: There appear to be quite a few business realities – in terms of how the industry works and how Microsoft works – about which you are not aware.

People who know what they’re talking about have given you the honest and true answers here in this thread. You can continue to refuse to believe those answers.

But, given that you’re asking just for the sake of curiosity, it doesn’t really matter… does it?

Peter
OSR

Hi Peter,

I guess you’ve misundertood my previous comments in this thread. I was not refusing to accept your advice. On the contrary, I felt it great honor to hear all your great idea and my original question was in fact got answered at the very begining of this thread. It’s just our discussion has expanded to somewhat a wider scope and I’d like to learn more about them. If this has been bothering you too much or it wasted too much of your time, I’d really really apologize it to you all.

At 2011-11-18 12:36:43,xxxxx@osr.com wrote:

I wrote a long reply and deleted it. Twice! Ooops, now make that 3 times!!

The Tao Te Ching starts (according to one translation): “The way the can be written, is not the true way.”

OP: There appear to be quite a few business realities – in terms of how the industry works and how Microsoft works – about which you are not aware.

People who know what they’re talking about have given you the honest and true answers here in this thread. You can continue to refuse to believe those answers.

But, given that you’re asking just for the sake of curiosity, it doesn’t really matter… does it?

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer