“Mike Kemp” wrote in message news:xxxxx@ntdev…
> BTW Re the source code hot potato: I wonder if today’s EU ruling against
> MS will cause the release of source code (at least in Europe, it may
> remain legally unavailable in the US). It seems that if MS can make better
> applications by having access to the source code then it would fall
> foul…
>
IMO they got fined for something ridiculous. The $600M fine will not kick in
but it really sets the way free for a lot of new claims where prosecutors
actually do have a good point. I think they will be more or less outlawed in
the future.
I don’t know if EU will enforce the release of source but a negative
consequence for them is that as they are official bandits and they do not
offer source code, governments are inventing policies which forbid the use
of MS technologies and are switching to open source alternatives.
The best thing they can do themselves to prolong their imperial status is
release source and try to build up goodwill right from the ground up (that
is NTOSKRNL).
/Daniel
> Why not reveal *all* the undocumented interdependencies in the operating
system?
Well, why not cure all diseases and feed the hungry across the world too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in 2000
I have wondered how Windows could be as stable as it is when virtually every
WDM driver developed has synchronization holes in this area which cannot be
covered. They can’t be covered because there is no way to know or reverse
engineer the interdependencies here. They need to get this information out
and there is no better way than sample source IMHO.
However, I bet the majority are undocumented *intentionally*. As in:
“*don’t* rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write a
driver correctly and that is what I am talking about here.
Besides the laudable goal of helping the helpless avoid many of the WDM
pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
that Microsoft *could* document more or less completely. It is intended to
be straightforward and orthogonal enough to be expressible in English as
well as C++, and yet still have something they are able to maintain and
improve.
Once again, you leave out all of the existing Windows drivers if you take
this tact without releasing source.
KMDF is a good step in the right direction, but it’s clearly not all the
way there yet. It’s *way* too early for Microsoft to be locking themselves
into this first brand new implementation by exposing, and thereby
implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not 
Releasing source does not lock
them in any more or less to their interfaces than they already are.
Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months or
soif you’re unclear on the headaches Microsoft endures because of
yahoo programmers relying on undocumented behaviors. The number of
“compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
If Microsoft *wants* to reveal the intricacies that they found while
developing KMDF, I have every confidence in their ability to *document*
those. The KMDF team (or maybe their tech writers?
capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
All that said, if Microsoft really wants to release the KMDF source, I
won’t be looking a gift horse in the mouth… They just have to accept
that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power, DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were it
released as it should be.
Bill M.
Bill, we actually developed KMDF without relying too much on ntos sources. We occasionally dove into the sources, but it was more often than not to debug a bug we found in the kernel vs KMDF ;). Kernel sources were not that interesting b/c we had to work across many different releases and could not rely on a single release’s implementation of a particular feature.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Oney C++ lib
Why not reveal *all* the undocumented interdependencies in the operating
system?
Well, why not cure all diseases and feed the hungry across the world too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in 2000
I have wondered how Windows could be as stable as it is when virtually every
WDM driver developed has synchronization holes in this area which cannot be
covered. They can’t be covered because there is no way to know or reverse
engineer the interdependencies here. They need to get this information out
and there is no better way than sample source IMHO.
However, I bet the majority are undocumented *intentionally*. As in:
“*don’t* rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write a
driver correctly and that is what I am talking about here.
Besides the laudable goal of helping the helpless avoid many of the WDM
pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
that Microsoft *could* document more or less completely. It is intended to
be straightforward and orthogonal enough to be expressible in English as
well as C++, and yet still have something they are able to maintain and
improve.
Once again, you leave out all of the existing Windows drivers if you take
this tact without releasing source.
KMDF is a good step in the right direction, but it’s clearly not all the
way there yet. It’s *way* too early for Microsoft to be locking themselves
into this first brand new implementation by exposing, and thereby
implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not Releasing source does not lock
them in any more or less to their interfaces than they already are.
Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months or
so
yahoo programmers relying on undocumented behaviors. The number of
“compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
If Microsoft *wants* to reveal the intricacies that they found while
developing KMDF, I have every confidence in their ability to *document*
those. The KMDF team (or maybe their tech writers?
capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
All that said, if Microsoft really wants to release the KMDF source, I
won’t be looking a gift horse in the mouth… They just have to accept
that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power, DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were it
released as it should be.
Bill M.
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
All I know is I was emailed about 4 printed pages worth of discussion on
interdependencies between power, PnP, and I/O from someone at Microsoft. It
was all information you could not glean other than looking at source, at
least there is no way I could see that you could figure out these
relationships between the pieces.
I think having source perhaps it is easy to forget how often or in what
circumstances it gets used or influences what you do maybe?
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Bill, we actually developed KMDF without relying too much on ntos sources.
We occasionally dove into the sources, but it was more often than not to
debug a bug we found in the kernel vs KMDF ;). Kernel sources were not that
interesting b/c we had to work across many different releases and could not
rely on a single release’s implementation of a particular feature.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Oney C++ lib
> Why not reveal all the undocumented interdependencies in the operating
> system?
Well, why not cure all diseases and feed the hungry across the world too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in 2000
I have wondered how Windows could be as stable as it is when virtually every
WDM driver developed has synchronization holes in this area which cannot be
covered. They can’t be covered because there is no way to know or reverse
engineer the interdependencies here. They need to get this information out
and there is no better way than sample source IMHO.
> However, I bet the majority are undocumented intentionally. As in:
> “don’t rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write a
driver correctly and that is what I am talking about here.
> Besides the laudable goal of helping the helpless avoid many of the WDM
> pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
> that Microsoft could document more or less completely. It is intended to
> be straightforward and orthogonal enough to be expressible in English as
> well as C++, and yet still have something they are able to maintain and
> improve.
Once again, you leave out all of the existing Windows drivers if you take
this tact without releasing source.
> KMDF is a good step in the right direction, but it’s clearly not all the
> way there yet. It’s way too early for Microsoft to be locking themselves
> into this first brand new implementation by exposing, and thereby
> implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not Releasing source does not lock
them in any more or less to their interfaces than they already are.
> Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months or
> so if you’re unclear on the headaches Microsoft endures because of
> yahoo programmers relying on undocumented behaviors. The number of
> “compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
> If Microsoft wants to reveal the intricacies that they found while
> developing KMDF, I have every confidence in their ability to document
> those. The KMDF team (or maybe their tech writers? are manifestly
> capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
> All that said, if Microsoft really wants to release the KMDF source, I
> won’t be looking a gift horse in the mouth… They just have to accept
> that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power, DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were it
released as it should be.
Bill M.
—
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
Well certainly if you design something based on assumptions about how
some black box works and then you find a bug in your design and you
analyze the bug’s root cause using the source code for that black box,
that source code access is a huge aid to understanding.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 12:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Oney C++ lib
All I know is I was emailed about 4 printed pages worth of discussion on
interdependencies between power, PnP, and I/O from someone at Microsoft.
It
was all information you could not glean other than looking at source, at
least there is no way I could see that you could figure out these
relationships between the pieces.
I think having source perhaps it is easy to forget how often or in what
circumstances it gets used or influences what you do maybe?
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Bill, we actually developed KMDF without relying too much on ntos
sources.
We occasionally dove into the sources, but it was more often than not to
debug a bug we found in the kernel vs KMDF ;). Kernel sources were not
that
interesting b/c we had to work across many different releases and could
not
rely on a single release’s implementation of a particular feature.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Oney C++ lib
> Why not reveal all the undocumented interdependencies in the
operating
> system?
Well, why not cure all diseases and feed the hungry across the world
too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in
2000
I have wondered how Windows could be as stable as it is when virtually
every
WDM driver developed has synchronization holes in this area which cannot
be
covered. They can’t be covered because there is no way to know or
reverse
engineer the interdependencies here. They need to get this information
out
and there is no better way than sample source IMHO.
> However, I bet the majority are undocumented intentionally. As in:
> “don’t rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write
a
driver correctly and that is what I am talking about here.
> Besides the laudable goal of helping the helpless avoid many of the
WDM
> pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
> that Microsoft could document more or less completely. It is
intended to
> be straightforward and orthogonal enough to be expressible in English
as
> well as C++, and yet still have something they are able to maintain
and
> improve.
Once again, you leave out all of the existing Windows drivers if you
take
this tact without releasing source.
> KMDF is a good step in the right direction, but it’s clearly not all
the
> way there yet. It’s way too early for Microsoft to be locking
themselves
> into this first brand new implementation by exposing, and thereby
> implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not Releasing source does not
lock
them in any more or less to their interfaces than they already are.
> Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months
or
> so if you’re unclear on the headaches Microsoft endures because of
> yahoo programmers relying on undocumented behaviors. The number of
> “compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I
deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
> If Microsoft wants to reveal the intricacies that they found while
> developing KMDF, I have every confidence in their ability to
document
> those. The KMDF team (or maybe their tech writers? are manifestly
> capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
> All that said, if Microsoft really wants to release the KMDF source, I
> won’t be looking a gift horse in the mouth… They just have to accept
> that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power,
DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the
hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were
it
released as it should be.
Bill M.
—
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
No, I didn’t forget…the interdependencies were flushed out from our collective experiences writing drivers and then testing the heck out of the framework in a bunch of different device classes (networking and storage being the 2 that brought up the most problems to address) and writing a bunch of new drivers. This is why it tooks us years to release something, we needed broad coverage to see what was going on.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:57 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Oney C++ lib
All I know is I was emailed about 4 printed pages worth of discussion on
interdependencies between power, PnP, and I/O from someone at Microsoft. It
was all information you could not glean other than looking at source, at
least there is no way I could see that you could figure out these
relationships between the pieces.
I think having source perhaps it is easy to forget how often or in what
circumstances it gets used or influences what you do maybe?
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Bill, we actually developed KMDF without relying too much on ntos sources.
We occasionally dove into the sources, but it was more often than not to
debug a bug we found in the kernel vs KMDF ;). Kernel sources were not that
interesting b/c we had to work across many different releases and could not
rely on a single release’s implementation of a particular feature.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Oney C++ lib
> Why not reveal all the undocumented interdependencies in the operating
> system?
Well, why not cure all diseases and feed the hungry across the world too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in 2000
I have wondered how Windows could be as stable as it is when virtually every
WDM driver developed has synchronization holes in this area which cannot be
covered. They can’t be covered because there is no way to know or reverse
engineer the interdependencies here. They need to get this information out
and there is no better way than sample source IMHO.
> However, I bet the majority are undocumented intentionally. As in:
> “don’t rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write a
driver correctly and that is what I am talking about here.
> Besides the laudable goal of helping the helpless avoid many of the WDM
> pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
> that Microsoft could document more or less completely. It is intended to
> be straightforward and orthogonal enough to be expressible in English as
> well as C++, and yet still have something they are able to maintain and
> improve.
Once again, you leave out all of the existing Windows drivers if you take
this tact without releasing source.
> KMDF is a good step in the right direction, but it’s clearly not all the
> way there yet. It’s way too early for Microsoft to be locking themselves
> into this first brand new implementation by exposing, and thereby
> implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not Releasing source does not lock
them in any more or less to their interfaces than they already are.
> Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months or
> so if you’re unclear on the headaches Microsoft endures because of
> yahoo programmers relying on undocumented behaviors. The number of
> “compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
> If Microsoft wants to reveal the intricacies that they found while
> developing KMDF, I have every confidence in their ability to document
> those. The KMDF team (or maybe their tech writers? are manifestly
> capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
> All that said, if Microsoft really wants to release the KMDF source, I
> won’t be looking a gift horse in the mouth… They just have to accept
> that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power, DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were it
released as it should be.
Bill M.
—
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 wish I had that email here…I could point out some good examples. There
were PnP and Power dependencies that you couldn’t get by experiment. I
remember that.
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
No, I didn’t forget…the interdependencies were flushed out from our
collective experiences writing drivers and then testing the heck out of the
framework in a bunch of different device classes (networking and storage
being the 2 that brought up the most problems to address) and writing a
bunch of new drivers. This is why it tooks us years to release something,
we needed broad coverage to see what was going on.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:57 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Oney C++ lib
All I know is I was emailed about 4 printed pages worth of discussion on
interdependencies between power, PnP, and I/O from someone at Microsoft. It
was all information you could not glean other than looking at source, at
least there is no way I could see that you could figure out these
relationships between the pieces.
I think having source perhaps it is easy to forget how often or in what
circumstances it gets used or influences what you do maybe?
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Bill, we actually developed KMDF without relying too much on ntos sources.
We occasionally dove into the sources, but it was more often than not to
debug a bug we found in the kernel vs KMDF ;). Kernel sources were not that
interesting b/c we had to work across many different releases and could not
rely on a single release’s implementation of a particular feature.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Monday, September 17, 2007 9:21 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Oney C++ lib
> Why not reveal all the undocumented interdependencies in the operating
> system?
Well, why not cure all diseases and feed the hungry across the world too?
KMDF solves the particular and nasty problems having to deal with PnP,
Power and I/O interdependencies. Since I first worked on WinDK back in 2000
I have wondered how Windows could be as stable as it is when virtually every
WDM driver developed has synchronization holes in this area which cannot be
covered. They can’t be covered because there is no way to know or reverse
engineer the interdependencies here. They need to get this information out
and there is no better way than sample source IMHO.
> However, I bet the majority are undocumented intentionally. As in:
> “don’t rely on this interdependency”.
Nope, not true. You don’t hide information people have to have to write a
driver correctly and that is what I am talking about here.
> Besides the laudable goal of helping the helpless avoid many of the WDM
> pitfalls, the point of KMDF, as far as I can tell, was to create a DDI
> that Microsoft could document more or less completely. It is intended to
> be straightforward and orthogonal enough to be expressible in English as
> well as C++, and yet still have something they are able to maintain and
> improve.
Once again, you leave out all of the existing Windows drivers if you take
this tact without releasing source.
> KMDF is a good step in the right direction, but it’s clearly not all the
> way there yet. It’s way too early for Microsoft to be locking themselves
> into this first brand new implementation by exposing, and thereby
> implicitly documenting, its internals for the world to see.
Couldn’t disagree more. They are already locked into their interfaces.
Trust me I worked on frameworks for years, they have already created
tomorrow’s legacy issues like it or not Releasing source does not lock
them in any more or less to their interfaces than they already are.
> Go read Raymond Chen’s blog for a while (ok, ignore the last 6 months or
> so if you’re unclear on the headaches Microsoft endures because of
> yahoo programmers relying on undocumented behaviors. The number of
> “compatibility hacks” needed by Windows is utterly absurd already.
Much of the hacking people do is due to lack of information. I know I deal
with it everyday with existing drivers. Good samples to follow would
eliminate a lot of these problems IMHO.
> If Microsoft wants to reveal the intricacies that they found while
> developing KMDF, I have every confidence in their ability to document
> those. The KMDF team (or maybe their tech writers? are manifestly
> capable of quite eloquent expression.
I have no doubt in their abilities either its their motivations I worry
about.
> All that said, if Microsoft really wants to release the KMDF source, I
> won’t be looking a gift horse in the mouth… They just have to accept
> that they’re pretty much stuck with it as soon as they do.
They are stuck anyway…but if they think they wrote I/O, PnP, Power, DMA,
USB, whatever code correctly, then it sure would benefit the 3rd party
driver development world to release this example code so that the hundreds
or thousands of existing Windows drivers could take advantage of the
learnings. I suspect we would all learn something from this source were it
released as it should be.
Bill M.
—
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
Hi Folks. No answer to this so am I to assume that UMDF would NOT be able to
this? If so my original point stands and Don’s defence falls to the
ground… Please let me know I’m wrong! Best regards, Mike
----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Monday, September 17, 2007 9:35 AM
Subject: Re: Re:[ntdev] Re:Oney C++ lib
Thanks, Don, UMDF is on my list the next time I need a driver. When I
started my last one UMDF was predicted for some time in the future and for
Vista only.
As a point of information, my requirement was simply to communicate with my
1394 device streaming isoch data (at realtime priority level) to and from it
and exchanging async data (less critical). I did this all ok in user mode on
OSX. Would you say that as far as I describe it this is within the ability
of UMDF? If so it is indeed a great leap forward, especially if it will run
on XP (we don’t go further back than that).
I can see why you can’t invalidate old drivers, legacy support must
continue, it is MS’s cross to bear. But the ability to specifically permit
them one by one as Vista seems to permit is (was) the ideal point to start
the change to a scaled priority approach don’t you think?
I for one was shocked when I started writing this driver how much I could
do - MS seemed to be giving me carte blanche to do anything with or under
the OS, when all I wanted was an interface, and I’d rather just our product
crashed than the whole machine (given that I suffer from occasional
imperfection, rare amongst driver writers)…
Best regards, Mike
BTW Re the source code hot potato: I wonder if today’s EU ruling against MS
will cause the release of source code (at least in Europe, it may remain
legally unavailable in the US). It seems that if MS can make better
applications by having access to the source code then it would fall foul…
----- Original Message -----
From: Don Burn
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Friday, September 14, 2007 5:41 PM
Subject: Re:[ntdev] Re:Oney C++ lib
“Mike Kemp” wrote in message news:xxxxx@ntdev…
>
> Most drivers do not need to be able to corrupt the OS. It is a pity that
> the effort did not go into introducing a driver privelege that does not
> extend that far…
>
Gee, that is exactly what UMDF is for. Now if you are saying get riid of
the kernel mode drivers ability to do this, all one would need to do is
come up with a new interface that does everything that Windows has
supported for the last 15 years (of course that should not take any time
right), and then tell everyone to throw out every driver and start over
again.
Now imagine the howls and lawsuits. Microsoft had a ton of legal actions
on the PatchGuard front from people like Symantec and McAfee because they
stonpped on 64-bit the ability to patch certain area which MALWARE loved to
touch. Obviously this was just a ploy to assert the Microsoft monopoly!!!
Now imagine what would be said if they took all the capabilities away, and
required a complete rewrite of every driver.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
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
To date 1394 doesn’t expose an interface that you can use to issue bus level commands from user-mode, so it’s difficult to drive through UMDF. We have one of our guys looking into a split model that includes some kernel and user code … no ETA just yet though.
I would expect UMDF to be able to handle this once the necessary pieces are in place but not today.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, September 19, 2007 9:56 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Oney C++ lib
Hi Folks. No answer to this so am I to assume that UMDF would NOT be able to
this? If so my original point stands and Don’s defence falls to the
ground… Please let me know I’m wrong! Best regards, Mike
----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Monday, September 17, 2007 9:35 AM
Subject: Re: Re:[ntdev] Re:Oney C++ lib
Thanks, Don, UMDF is on my list the next time I need a driver. When I
started my last one UMDF was predicted for some time in the future and for
Vista only.
As a point of information, my requirement was simply to communicate with my
1394 device streaming isoch data (at realtime priority level) to and from it
and exchanging async data (less critical). I did this all ok in user mode on
OSX. Would you say that as far as I describe it this is within the ability
of UMDF? If so it is indeed a great leap forward, especially if it will run
on XP (we don’t go further back than that).
I can see why you can’t invalidate old drivers, legacy support must
continue, it is MS’s cross to bear. But the ability to specifically permit
them one by one as Vista seems to permit is (was) the ideal point to start
the change to a scaled priority approach don’t you think?
I for one was shocked when I started writing this driver how much I could
do - MS seemed to be giving me carte blanche to do anything with or under
the OS, when all I wanted was an interface, and I’d rather just our product
crashed than the whole machine (given that I suffer from occasional
imperfection, rare amongst driver writers)…
Best regards, Mike
BTW Re the source code hot potato: I wonder if today’s EU ruling against MS
will cause the release of source code (at least in Europe, it may remain
legally unavailable in the US). It seems that if MS can make better
applications by having access to the source code then it would fall foul…
----- Original Message -----
From: Don Burn
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Friday, September 14, 2007 5:41 PM
Subject: Re:[ntdev] Re:Oney C++ lib
“Mike Kemp” wrote in message news:xxxxx@ntdev…
>
> Most drivers do not need to be able to corrupt the OS. It is a pity that
> the effort did not go into introducing a driver privelege that does not
> extend that far…
>
Gee, that is exactly what UMDF is for. Now if you are saying get riid of
the kernel mode drivers ability to do this, all one would need to do is
come up with a new interface that does everything that Windows has
supported for the last 15 years (of course that should not take any time
right), and then tell everyone to throw out every driver and start over
again.
Now imagine the howls and lawsuits. Microsoft had a ton of legal actions
on the PatchGuard front from people like Symantec and McAfee because they
stonpped on 64-bit the ability to patch certain area which MALWARE loved to
touch. Obviously this was just a ploy to assert the Microsoft monopoly!!!
Now imagine what would be said if they took all the capabilities away, and
required a complete rewrite of every driver.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
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
—
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
Doron may not be as affected as the rest of us are [or he handles it better], but most of the WDF team is, shall we say, “overcommitted” recently and probably for a while to come. So any response from any of us is likely to be less than timely.
UMDF support for 1394 is evolving, but we can’t currently handle the scenario you describe.
Among the sticking points (gleaned from a few quick questions to the developer of the sample I mention below):
* 1394 IRBs use MDLs in some cases- support for direct I/O will be coming in some future version, but it isn’t there today.
* DMA- can’t do that yet from a UMDF driver, although we have thought about it.
* time to test the whole idea and see what else may be a problem.
There is a 1394 sample in the works which has a KMDF function driver with a UMDF upper filter- we missed the upcoming WDK window, but hope to make the one after it. There have been some blog entries on Patrick’s blog related to it, but don’t know that they really shed much light on these issues: http://blogs.msdn.com/888_umdf_4_you/
FWIW, I liked OS/X [in the short time I worked with it] for one thing above all else- C++ wasn’t a cuss word in IoKit… :->
Bob Kjelgaard wrote:
There is a 1394 sample in the works which has a KMDF function driver with a UMDF upper filter- we missed the upcoming WDK window, but hope to make the one after it.
Wouldn’t it be nice to have a web repository for samples that “miss the
window”, or aren’t quite up to DDK standards, or that demonstrate
techniques that have fallen out of favor?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks all for the update re 1394 and UMDF. I’d urge everyone looking at
this to review the OSX model, it is surprisingly powerful and certainly gave
me all the support I need wholly in user mode. I haven’t tried other
interfaces on OSX but they seem to be standardised so I assume they all work
the same, rather than having to roll USB differently to 1394 etc, each
needing a new team and more coffee. Meantime I will do the usual thing of
applying more plasters to the wounds of my WDF driver, as each time the
decision whether to rewrite comes up there is never any clear benefit, just
the prospect of another can of worms… M.
PS regarding workloads, I would urge MS to fund better this fundamental work
that would improve the OS immeasurably if profits permit.
----- Original Message -----
From: Bob Kjelgaard
To: Windows System Software Devs Interest List
Sent: Wednesday, September 19, 2007 8:20 PM
Subject: RE: Re:[ntdev] Re:Oney C++ lib
Doron may not be as affected as the rest of us are [or he handles it
better], but most of the WDF team is, shall we say, “overcommitted” recently
and probably for a while to come. So any response from any of us is likely
to be less than timely.
UMDF support for 1394 is evolving, but we can’t currently handle the
scenario you describe.
Among the sticking points (gleaned from a few quick questions to the
developer of the sample I mention below):
* 1394 IRBs use MDLs in some cases- support for direct I/O will be coming in
some future version, but it isn’t there today.
* DMA- can’t do that yet from a UMDF driver, although we have thought about
it.
* time to test the whole idea and see what else may be a problem.
There is a 1394 sample in the works which has a KMDF function driver with a
UMDF upper filter- we missed the upcoming WDK window, but hope to make the
one after it. There have been some blog entries on Patrick’s blog related
to it, but don’t know that they really shed much light on these issues:
http://blogs.msdn.com/888_umdf_4_you/
FWIW, I liked OS/X [in the short time I worked with it] for one thing above
all else- C++ wasn’t a cuss word in IoKit… :->
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