What ABOUT KMDF Source Code?

Bill McKenzie brought it up in another thread (about BDA, which to ME means “bios data area”… However, it now seems that all 3 letter acronyms have been used and are being recycled to mean different things… but I digress):

First:

Then, in a follow-up:

Good question, Bill. I wonder that too.

I know the devs were strongly in favor of this during KMDF development… so what happened?

Where IS the whole issue of KMDF source code being distributed with KMDF??

Because I suspect I know the answer, I’ll list a few reasons that KMDF source code would be ultra-helpful:

  1. Debugging would be VASTLY easier – My favorite case is you’ve got KMDF Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a breakpoint in the Framework. No message, just a break point. You dump the IFR. No information. There WILL be information in the log, of course, but it won’t be there until after the higher-level KMDF function detects the error and PUTs it there. AFTER the breakpoint.

  2. The little niggling bugs in KMDF would be more quickly spotted, and reported by the community (well, assuming we HAD a way to report them) – I’m thinking of things like weirded-out error messages here.

  3. Many of the existing limitations/inconsistencies/quirks of the current KMDF implementation would be clear… You wouldn’t have to “try it” to see. Here I’m talking about things like which Objects can have ExecutionLevel constraints, how synch scope actually works, etc, etc…

  4. The community would be able to verify the documentation for themselves, and report doc errors. Things like “What’s the default sync scope”??

  5. Devs could help each other with KMDF problems and issues. The KMDF community support program would be something more than “Let’s ask Doron”

Are Bill and I the only ones in the community that thinks KMDF Source would be helpful? Anybody else “notice” that the KMDF source code never shipped??

Let me be clear: Nobody from MSFT, not once, ever actually promised to ship KMDF source code, so it’s NOT an issue of “You promised but didn’t deliver”… but during the project, when asked about source they DID certainly say “that’s the plan” and “we’re working on it”.

So, seriously… where ARE we with getting source code for KMDF?

Maybe I need to turn this into a Pontification or an article or something, huh?? Maybe get this issue more exposure???

Peter
OSR

Short story: we pushed for it, got quite a bit of resistance internally
from various angles and the community stopped asking for it, so we went
on to other things. It is a lower priority item until we prove
otherwise to the powers that be.

As for how synch scope works, sometimes even I can’t figure it out and
have to ask eliyas, so the src might not be as instructive as you would
like ;P. The sync stuff is something we want to completely revamp in a
future version so that it is way easier to understand.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, June 09, 2007 8:29 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] What ABOUT KMDF Source Code?

Bill McKenzie brought it up in another thread (about BDA, which to ME
means “bios data area”… However, it now seems that all 3 letter
acronyms have been used and are being recycled to mean different
things… but I digress):

First:

Then, in a follow-up:

Good question, Bill. I wonder that too.

I know the devs were strongly in favor of this during KMDF
development… so what happened?

Where IS the whole issue of KMDF source code being distributed with
KMDF??

Because I suspect I know the answer, I’ll list a few reasons that KMDF
source code would be ultra-helpful:

  1. Debugging would be VASTLY easier – My favorite case is you’ve got
    KMDF Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a
    breakpoint in the Framework. No message, just a break point. You dump
    the IFR. No information. There WILL be information in the log, of
    course, but it won’t be there until after the higher-level KMDF function
    detects the error and PUTs it there. AFTER the breakpoint.

  2. The little niggling bugs in KMDF would be more quickly spotted, and
    reported by the community (well, assuming we HAD a way to report them)
    – I’m thinking of things like weirded-out error messages here.

  3. Many of the existing limitations/inconsistencies/quirks of the
    current KMDF implementation would be clear… You wouldn’t have to “try
    it” to see. Here I’m talking about things like which Objects can have
    ExecutionLevel constraints, how synch scope actually works, etc, etc…

  4. The community would be able to verify the documentation for
    themselves, and report doc errors. Things like “What’s the default sync
    scope”??

  5. Devs could help each other with KMDF problems and issues. The KMDF
    community support program would be something more than “Let’s ask Doron”

Are Bill and I the only ones in the community that thinks KMDF Source
would be helpful? Anybody else “notice” that the KMDF source code never
shipped??

Let me be clear: Nobody from MSFT, not once, ever actually promised to
ship KMDF source code, so it’s NOT an issue of “You promised but didn’t
deliver”… but during the project, when asked about source they DID
certainly say “that’s the plan” and “we’re working on it”.

So, seriously… where ARE we with getting source code for KMDF?

Maybe I need to turn this into a Pontification or an article or
something, huh?? Maybe get this issue more exposure???

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Generally after the first few dozen "no sorry no way"s I just stop asking. I got the memo. No source. The super secret Open Driver Framework project will have to have progressed far enough to create sufficient FUD over in Redmond before there will be a change in policy.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-289617-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, June 09, 2007 11:29 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] What ABOUT KMDF Source Code?

Bill McKenzie brought it up in another thread (about BDA, which to ME
means “bios data area”… However, it now seems that all 3 letter
acronyms have been used and are being recycled to mean different
things… but I digress):

First:

Then, in a follow-up:

Good question, Bill. I wonder that too.

I know the devs were strongly in favor of this during KMDF
development… so what happened?

Where IS the whole issue of KMDF source code being distributed with
KMDF??

Because I suspect I know the answer, I’ll list a few reasons that KMDF
source code would be ultra-helpful:

  1. Debugging would be VASTLY easier – My favorite case is you’ve got
    KMDF Verifier on, you call a function KmdfBlahMakeMyDay… and you hit
    a breakpoint in the Framework. No message, just a break point. You
    dump the IFR. No information. There WILL be information in the log,
    of course, but it won’t be there until after the higher-level KMDF
    function detects the error and PUTs it there. AFTER the breakpoint.

  2. The little niggling bugs in KMDF would be more quickly spotted, and
    reported by the community (well, assuming we HAD a way to report them)
    – I’m thinking of things like weirded-out error messages here.

  3. Many of the existing limitations/inconsistencies/quirks of the
    current KMDF implementation would be clear… You wouldn’t have to “try
    it” to see. Here I’m talking about things like which Objects can have
    ExecutionLevel constraints, how synch scope actually works, etc, etc…

  4. The community would be able to verify the documentation for
    themselves, and report doc errors. Things like “What’s the default
    sync scope”??

  5. Devs could help each other with KMDF problems and issues. The KMDF
    community support program would be something more than “Let’s ask
    Doron”

Are Bill and I the only ones in the community that thinks KMDF Source
would be helpful? Anybody else “notice” that the KMDF source code
never shipped??

Let me be clear: Nobody from MSFT, not once, ever actually promised to
ship KMDF source code, so it’s NOT an issue of “You promised but didn’t
deliver”… but during the project, when asked about source they DID
certainly say “that’s the plan” and “we’re working on it”.

So, seriously… where ARE we with getting source code for KMDF?

Maybe I need to turn this into a Pontification or an article or
something, huh?? Maybe get this issue more exposure???

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Very well stated…thank you Peter.

I actually expected to get flamed bringing this back up. I am glad I am not
alone in my concerns.

One of my greatest fears, and it seems to be coming to pass, is that we are
going to be forced to use this framework for any driver we want to get
logo’d. If that happens, and I am certain it will, we, the driver
development community, will have been instantly set back more than 10 years.

We have always been dependent upon careful low-level observation, tidbits of
information from Microsoft, experience, and each other for getting through
issues we run into with kernel development. Not having much information or
source, we have had to carefully piece together the intracacies,
inconsistencies, errors, and holes that exist in this low-level world. Now,
with the framework, we have a brand new model, new sets of DDIs and still no
source. We start all over again.

I love a technical challenge, but I hate being held up by mere hidden
convention.

Bill M.

wrote in message news:xxxxx@ntdev…
> Bill McKenzie brought it up in another thread (about BDA, which to ME
> means “bios data area”… However, it now seems that all 3 letter acronyms
> have been used and are being recycled to mean different things… but I
> digress):
>
> First:
>


>
> Then, in a follow-up:
>


>
> Good question, Bill. I wonder that too.
>
> I know the devs were strongly in favor of this during KMDF development…
> so what happened?
>
> Where IS the whole issue of KMDF source code being distributed with KMDF??
>
> Because I suspect I know the answer, I’ll list a few reasons that KMDF
> source code would be ultra-helpful:
>
> 1) Debugging would be VASTLY easier – My favorite case is you’ve got
> KMDF Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a
> breakpoint in the Framework. No message, just a break point. You dump
> the IFR. No information. There WILL be information in the log, of
> course, but it won’t be there until after the higher-level KMDF function
> detects the error and PUTs it there. AFTER the breakpoint.
>
> 2) The little niggling bugs in KMDF would be more quickly spotted, and
> reported by the community (well, assuming we HAD a way to report them) –
> I’m thinking of things like weirded-out error messages here.
>
> 3) Many of the existing limitations/inconsistencies/quirks of the current
> KMDF implementation would be clear… You wouldn’t have to “try it” to
> see. Here I’m talking about things like which Objects can have
> ExecutionLevel constraints, how synch scope actually works, etc, etc…
>
> 4) The community would be able to verify the documentation for themselves,
> and report doc errors. Things like “What’s the default sync scope”??
>
> 5) Devs could help each other with KMDF problems and issues. The KMDF
> community support program would be something more than “Let’s ask Doron”
>
> Are Bill and I the only ones in the community that thinks KMDF Source
> would be helpful? Anybody else “notice” that the KMDF source code never
> shipped??
>
> Let me be clear: Nobody from MSFT, not once, ever actually promised to
> ship KMDF source code, so it’s NOT an issue of “You promised but didn’t
> deliver”… but during the project, when asked about source they DID
> certainly say “that’s the plan” and “we’re working on it”.
>
> So, seriously… where ARE we with getting source code for KMDF?
>
> Maybe I need to turn this into a Pontification or an article or something,
> huh?? Maybe get this issue more exposure???
>
> Peter
> OSR
>
>

I second this.

KMDF is a framework like MFC. For such frameworks, source is critically
important.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Bill McKenzie brought it up in another thread (about BDA, which to ME means
“bios data area”… However, it now seems that all 3 letter acronyms have been
used and are being recycled to mean different things… but I digress):
>
> First:
>


>
> Then, in a follow-up:
>


>
> Good question, Bill. I wonder that too.
>
> I know the devs were strongly in favor of this during KMDF development… so
what happened?
>
> Where IS the whole issue of KMDF source code being distributed with KMDF??
>
> Because I suspect I know the answer, I’ll list a few reasons that KMDF source
code would be ultra-helpful:
>
> 1) Debugging would be VASTLY easier – My favorite case is you’ve got KMDF
Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a breakpoint
in the Framework. No message, just a break point. You dump the IFR. No
information. There WILL be information in the log, of course, but it won’t be
there until after the higher-level KMDF function detects the error and PUTs it
there. AFTER the breakpoint.
>
> 2) The little niggling bugs in KMDF would be more quickly spotted, and
reported by the community (well, assuming we HAD a way to report them) – I’m
thinking of things like weirded-out error messages here.
>
> 3) Many of the existing limitations/inconsistencies/quirks of the current
KMDF implementation would be clear… You wouldn’t have to “try it” to see.
Here I’m talking about things like which Objects can have ExecutionLevel
constraints, how synch scope actually works, etc, etc…
>
> 4) The community would be able to verify the documentation for themselves,
and report doc errors. Things like “What’s the default sync scope”??
>
> 5) Devs could help each other with KMDF problems and issues. The KMDF
community support program would be something more than “Let’s ask Doron”
>
> Are Bill and I the only ones in the community that thinks KMDF Source would
be helpful? Anybody else “notice” that the KMDF source code never shipped??
>
> Let me be clear: Nobody from MSFT, not once, ever actually promised to ship
KMDF source code, so it’s NOT an issue of “You promised but didn’t deliver”…
but during the project, when asked about source they DID certainly say “that’s
the plan” and “we’re working on it”.
>
> So, seriously… where ARE we with getting source code for KMDF?
>
> Maybe I need to turn this into a Pontification or an article or something,
huh?? Maybe get this issue more exposure???
>
> Peter
> OSR
>
>

If it ends up being a requirement or effectively the same, I’ll give it
a third.

mm

>> xxxxx@storagecraft.com 2007-06-09 15:52 >>>
I second this.

KMDF is a framework like MFC. For such frameworks, source is
critically
important.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Bill McKenzie brought it up in another thread (about BDA, which to ME
means
“bios data area”… However, it now seems that all 3 letter acronyms
have been
used and are being recycled to mean different things… but I
digress):
>
> First:
>


>
> Then, in a follow-up:
>


>
> Good question, Bill. I wonder that too.
>
> I know the devs were strongly in favor of this during KMDF
development… so
what happened?
>
> Where IS the whole issue of KMDF source code being distributed with
KMDF??
>
> Because I suspect I know the answer, I’ll list a few reasons that
KMDF source
code would be ultra-helpful:
>
> 1) Debugging would be VASTLY easier – My favorite case is you’ve
got KMDF
Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a
breakpoint
in the Framework. No message, just a break point. You dump the IFR.
No
information. There WILL be information in the log, of course, but it
won’t be
there until after the higher-level KMDF function detects the error and
PUTs it
there. AFTER the breakpoint.
>
> 2) The little niggling bugs in KMDF would be more quickly spotted,
and
reported by the community (well, assuming we HAD a way to report them)
– I’m
thinking of things like weirded-out error messages here.
>
> 3) Many of the existing limitations/inconsistencies/quirks of the
current
KMDF implementation would be clear… You wouldn’t have to “try it” to
see.
Here I’m talking about things like which Objects can have
ExecutionLevel
constraints, how synch scope actually works, etc, etc…
>
> 4) The community would be able to verify the documentation for
themselves,
and report doc errors. Things like “What’s the default sync scope”??
>
> 5) Devs could help each other with KMDF problems and issues. The
KMDF
community support program would be something more than “Let’s ask
Doron”
>
> Are Bill and I the only ones in the community that thinks KMDF Source
would
be helpful? Anybody else “notice” that the KMDF source code never
shipped??
>
> Let me be clear: Nobody from MSFT, not once, ever actually promised
to ship
KMDF source code, so it’s NOT an issue of “You promised but didn’t
deliver”…
but during the project, when asked about source they DID certainly say
“that’s
the plan” and “we’re working on it”.
>
> So, seriously… where ARE we with getting source code for KMDF?
>
> Maybe I need to turn this into a Pontification or an article or
something,
huh?? Maybe get this issue more exposure???
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Well said, Peter. Yes, turn this into a Pontification, please. At least
we will have something to read :slight_smile:

For me, missing sources is the main reason why I don’t and won’t use
KMDF until I’m forced to do so.

Actually, that’s silly. Every developer understands why it is important
to have framework sources but the decision was apparently made by
different kind of people. I’d really like to know reasoning behind it.
IMO MS can’t lose anything, just gain. Take WinCE example. Almost
complete sources are available for reading and it is really helpful. I
was able to write working and stable USB driver within few weeks without
any previous experience with CE. Without sources it’d be much more
difficult.

I’d see yet another reason why sources should be available based on my
experience with USB. USB stack is buggy. At Vista, is is extremely
buggy, at least for my taste. KMDF can be quite correct and may not work
in some situations. Standard way, i.e. report bug and wait for hotfix
takes ages. In most situations it is faster to make a workaround which
solves a problem some non-standard way. One example for all: D0 IRP is
sometimes blocked when sent in parallel with susprise removal path. The
workaround for XP (IIRC) is no not wait for completion and forward
remove IRP (or surpise remove, I don’t remember just now), instead. IRP
is completed in most cases. KMDF state machine would lockup waiting
completion. With sources (and statically linked library!) it’d be
possible to change KMDF the necessary way as I did in my WDM driver
code. I’m sure KMDF developers wouldn’t like this but I’m sorry, our
customers don’t care if it is our or MS bug, they just want to have
working driver and want it NOW.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, June 09, 2007 8:29 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] What ABOUT KMDF Source Code?

Bill McKenzie brought it up in another thread (about BDA, which to ME
means “bios data area”… However, it now seems that all 3 letter
acronyms have been used and are being recycled to mean different
things… but I digress):

First:

Then, in a follow-up:

Good question, Bill. I wonder that too.

I know the devs were strongly in favor of this during KMDF
development… so what happened?

Where IS the whole issue of KMDF source code being distributed with
KMDF??

Because I suspect I know the answer, I’ll list a few reasons that KMDF
source code would be ultra-helpful:

  1. Debugging would be VASTLY easier – My favorite case is you’ve got
    KMDF Verifier on, you call a function KmdfBlahMakeMyDay… and you hit a
    breakpoint in the Framework. No message, just a break point. You dump
    the IFR. No information. There WILL be information in the log, of
    course, but it won’t be there until after the higher-level KMDF function
    detects the error and PUTs it there. AFTER the breakpoint.

  2. The little niggling bugs in KMDF would be more quickly spotted, and
    reported by the community (well, assuming we HAD a way to report them)
    – I’m thinking of things like weirded-out error messages here.

  3. Many of the existing limitations/inconsistencies/quirks of the
    current KMDF implementation would be clear… You wouldn’t have to “try
    it” to see. Here I’m talking about things like which Objects can have
    ExecutionLevel constraints, how synch scope actually works, etc, etc…

  4. The community would be able to verify the documentation for
    themselves, and report doc errors. Things like “What’s the default sync
    scope”??

  5. Devs could help each other with KMDF problems and issues. The KMDF
    community support program would be something more than “Let’s ask Doron”

Are Bill and I the only ones in the community that thinks KMDF Source
would be helpful? Anybody else “notice” that the KMDF source code never
shipped??

Let me be clear: Nobody from MSFT, not once, ever actually promised to
ship KMDF source code, so it’s NOT an issue of “You promised but didn’t
deliver”… but during the project, when asked about source they DID
certainly say “that’s the plan” and “we’re working on it”.

So, seriously… where ARE we with getting source code for KMDF?

Maybe I need to turn this into a Pontification or an article or
something, huh?? Maybe get this issue more exposure???

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

In the OTHER thread where KMDF source code, or lack thereof, was being discussed, Don Burn said in response to a call for KMDF source code being made available:


Sorry, if you believe this then do not write in the kernel until you have negotiated a source license for Windows. All KMDF is is another kernel layer, the same as many other functions (if you step through a DDI in assembler, you will probably recognize a lot of the calls)…

One of the great things about KMDF is that Doron, Elyias and others are willing to not only look things up, but will try to convey the model behind it…

[/quote]


So, let me make sure I understand your argument: Because the source code to ALL OF Windows isn’t widely available to driver writers, then the source code to KMDF also shouldn’t be mde widely available?? Because, ah, why… it might just make things EASIER?

Don, Don, Don… Sure, the source code to KMDF could be abused. In fact, some of the things that our colleagues here on the list have recently suggested (like, using the source code to fix bugs) frightens the shit out of me. In fact, I’ve called for doing EXACTLY what they do for MFC: Release a non-buildable version of the source code.

And yeaaaahhhh. Having source code access is no substitute for having the TECHNICAL LEAD for the Framework answer questions live, real-time, practically 24/7/365.

But, in my not so humble opinion, better to have the source code available and give the community a CHANCE of supporting itself, than to have the entire community rely on Doron for support. Sure, Doron does an outstanding, terrific, wonderful, above-and-beyond-the-call-of-duty job supporting KMDF specifically, and supporting the entire driver development community in general. But what happens if, G*d forbid, Doron tires of this or his management decides that his considerable skills can no longer be “wasted” answering support questions from “mere third parties”? You know what happens? Without community access to KMDF source code we’re up shit creek, that’s what.

Peter
OSR

wrote in message news:xxxxx@ntdev…
> So, let me make sure I understand your argument: Because the source code
> to ALL OF Windows isn’t widely available to driver writers, then the
> source code to KMDF also shouldn’t be mde widely available?? Because,
> ah, why… it might just make things EASIER?
>
> Don, Don, Don… Sure, the source code to KMDF could be abused. In fact,
> some of the things that our colleagues here on the list have recently
> suggested (like, using the source code to fix bugs) frightens the shit
> out of me. In fact, I’ve called for doing EXACTLY what they do for MFC:
> Release a non-buildable version of the source code.

Peter,

My argument was purely that if someone tries to justify not using KMDF
because of the lack of source, then they should not be writing kernel mode
code without Windows source. I do concur the source would be a great help,
and hopefully Microsoft will not only release it, but put the resources
into fixing the documentation when we start finding all the things that are
incorrect in the doc’s since we can read the source.

My concern about abuse is even a simpler argument. My concern is that
the source is not the definition it is the implementation. Developers will
start using the source as documentation, and that leads to problems.

Perhaps I am sensitive because in a previous life as an OS developer, I
had to implement over 50 system calls of the form ***Ex because idiots in
and out side of the company read the source, and realized they could play
games with parameters that were undefined and supposed to be zero. Of
course when the OS started checking for zero, not one of these developers
had read the big comment at the start of each routine “THE RESERVED
PARAMETERS NEED TO BE CHECKED FOR ZERO, SINCE WE PLAN ON USING NON-ZERO
VALUES WITH VERSION 4.0”. I could blame the original dev’s who did not add
the checks, but you would think someone could read.


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

> My argument was purely that if someone tries to justify not using

KMDF
because of the lack of source, then they should not be writing kernel
mode
code without Windows source.

Sure, I believe Windows sources should be available, too. Again, there
is WinCE example.

However, in the real world the choice is to write Windows drivers
without Windows sources or don’t write them. I decided to do it long
time ago so I can live with it. KMDF is different; it isn’t mandatory
(yet?) and it is a framework where is it much easier to argue sources
should be available than for whole OS.

My concern about abuse is even a simpler argument. My concern is
that
the source is not the definition it is the implementation. Developers
will
start using the source as documentation, and that leads to problems.

Of course. But not having sources leads to different kind of problems
and I believe there is more cons than pros.

Perhaps I am sensitive because in a previous life as an OS
developer,
I
had to implement over 50 system calls of the form ***Ex because idiots
in
and out side of the company read the source, and realized they could
play
games with parameters that were undefined and supposed to be zero. Of
course when the OS started checking for zero, not one of these
developers
had read the big comment at the start of each routine “THE RESERVED
PARAMETERS NEED TO BE CHECKED FOR ZERO, SINCE WE PLAN ON USING
NON-ZERO
VALUES WITH VERSION 4.0”. I could blame the original dev’s who did
not
add
the checks, but you would think someone could read.

Anybody with disassembler can play the same games with parameters. Or
even without it. The blame is on original devs who didn’t add the
checks. If an interface is defined, implementation should make at least
asserts to verify callers’ behaviour.

In other words, I don’t take this argument. I define interfaces for my
coworkers who have full access to the implementation which is also mine.
And we don’t have this kind of problems because there are asserts
everywhere and it is mandatory code runs with asserts enabled.

Michal

> In fact,

some of the things that our colleagues here on the list have recently
suggested (like, using the source code to fix bugs) frightens the shit
out
of me.

So what’s you proposal for the scenario when you encounter an OS bug and
a customer don’t care? They want something working within few days (with
WHQL signature, prefferably) and you know going through MS support would
take at least two months. Management doesn’t care about technical
details; it’s your responsibility to solve it some way. You’d find a
workaround usable for WDM driver which can’t be used with KMDF without
its modification.

It is last resort solution but I encontered this situation several times
within past year (and love Vista :-#). From technical point of view it
is wrong approach but in the real world technical arguments aren’t
always considered.

Michal

Don Burn wrote:

Developers will
start using the source as documentation, and that leads to problems.

A well-known difficulty of the open-source community. The only known solution is to emphasize documentation. You really have to take the position of “if your program uses undocumented features, it will break in a future release and don’t cry to us if it does.” It’s true that Microsoft’s Win32 API has taken the opposite stance (because backwards-compatibility is a selling point), but no one expects that from their kernel APIs.

There’s a history of Microsoft freely distributing source to libraries (CRT), frameworks (MFC) and tools (I found the DevCon source very helpful), and even supporting open-source projects (WiX comes to mind) - however, doing so with their OS is not in their best interest. The real question is whether KMDF is really a framework/library or should be considered part of their OS.

Consider the following points:
. KMDF is the recommended starting point for all future drivers as well as any drivers that will need future changes.
. Microsoft has suggested that KMDF will be supported on future versions of Windows. Someone had a nice quote about how KMDF can actually act as a portability layer for device drivers.

In fact, the only ways that KMDF behaves more like a framework is its distribution (as a co-installer) and the fact that it’s completely optional (for now).

Now, I haven’t been around the driver world for a long time, but it seems to me that KMDF is poised to become the next WDM (not an exact analogy, since some KMDF drivers will have to dip into the lower-level WDM). I would not be surprised if in 10 years Windows logo testing required KMDF drivers, and the KMDF binaries were updated through Windows Update.

If that happens, then KMDF should be considered part of the Windows OS, and not a separate framework by itself. And in that case, releasing the source would not be in Microsoft’s best interest.

These random ramblings on a peaceful Sunday afternoon were brought to you by:
-Stephen Cleary

> But, in my not so humble opinion, better to have the source code available
and

give the community a CHANCE of supporting itself, than to have the entire
community rely on Doron for support.

…and this is exactly how the things are going with KMDF for now. Really so.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> > Developers will

> start using the source as documentation, and that leads to problems.

A well-known difficulty of the open-source community.

Correct, if you avoid using “static” keyword for functions which you do not
want to define to the public.

Also, IIRC the UNIX linkers expose all non-static functions as module
exports, they do not understand __declspec(dllexport) and the DEF files.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Mr. Cleary wrote, on releasing source code to the Windows operating system:

Do you really believe this? I don’t and never have.

I know that Microsoft *believes* it is not in their best interest to release the Windows OS source code. I don’t think they should release a BUILDABLE version of the Windows OS Source Code. But I think it would be, entirely, in their best interests to make the sources for the Windows OS widely available.

Sure… some assholes would use a lot of undocumented stuff. Whatever. Those people get what they deserve.

Sure… some other jerks will exploit security loopholes… Guess those loopholes will get found and filled quickly, huh??

But, seriously, what HARM could come of releasing the Windows source code? Note that there’s a TON of it is already avaiable on the internet (on Chinese and Russian sites).

If I were “King for a Day” at Microsoft, I’d release the OS source code for the I/O Subsystem at the VERY LEAST. The code is surprisingly well written (mostly). Imagine the positive press this would engender. The good feelings among the community members.

And now when you got back STATUS_BLAH from IoSomeRandomFunction you could LOOK IT UP and be on your way, instead of praying to a random diety for guidance.

P

Thanks, Peter, for clearly expressing this standpoint which I share. I’d
emphasize: part of Windows sources already leaked some time before and
what happened? Nothing noticeable.

MS can’t lose anything, just gain. Now only if some open mind with
necessary power realizes it.

Well, I guess you have enough material for a Pontification about source
code. I’m looking forward for it :wink:

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-289760-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, June 11, 2007 9:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] What ABOUT KMDF Source Code?

Mr. Cleary wrote, on releasing source code to the Windows operating
system:

Do you really believe this? I don’t and never have.

I know that Microsoft *believes* it is not in their best interest to
release the Windows OS source code. I don’t think they should release
a
BUILDABLE version of the Windows OS Source Code. But I think it would
be,
entirely, in their best interests to make the sources for the Windows
OS
widely available.

Sure… some assholes would use a lot of undocumented stuff.
Whatever.
Those people get what they deserve.

Sure… some other jerks will exploit security loopholes… Guess
those
loopholes will get found and filled quickly, huh??

But, seriously, what HARM could come of releasing the Windows source
code?
Note that there’s a TON of it is already avaiable on the internet (on
Chinese and Russian sites).

If I were “King for a Day” at Microsoft, I’d release the OS source
code
for the I/O Subsystem at the VERY LEAST. The code is surprisingly
well
written (mostly). Imagine the positive press this would engender.
The
good feelings among the community members.

And now when you got back STATUS_BLAH from IoSomeRandomFunction you
could
LOOK IT UP and be on your way, instead of praying to a random diety
for
guidance.

P


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

I guess the source code inevitably violates many software patents, so it
will be easier for the patent owners to find a reason for a new lawsuit.

wrote in message news:xxxxx@ntdev…
> Mr. Cleary wrote, on releasing source code to the Windows operating
> system:
>
>


>
> Do you really believe this? I don’t and never have.
>
> I know that Microsoft believes it is not in their best interest to
> release the Windows OS source code. I don’t think they should release a
> BUILDABLE version of the Windows OS Source Code. But I think it would be,
> entirely, in their best interests to make the sources for the Windows OS
> widely available.
>
> Sure… some assholes would use a lot of undocumented stuff. Whatever.
> Those people get what they deserve.
>
> Sure… some other jerks will exploit security loopholes… Guess those
> loopholes will get found and filled quickly, huh??
>
> But, seriously, what HARM could come of releasing the Windows source code?
> Note that there’s a TON of it is already avaiable on the internet (on
> Chinese and Russian sites).
>
> If I were “King for a Day” at Microsoft, I’d release the OS source code
> for the I/O Subsystem at the VERY LEAST. The code is surprisingly well
> written (mostly). Imagine the positive press this would engender. The
> good feelings among the community members.
>
> And now when you got back STATUS_BLAH from IoSomeRandomFunction you could
> LOOK IT UP and be on your way, instead of praying to a random diety for
> guidance.
>
> P
>

So while everyone is pondering this if you could provide some feedback on what you’d be willing to sign to get source access that would be good to hear too.

Clearly there are people who think that source access has no risk to MS. I’d personally disagree, and so I assume that if we do put access out that there will be some restrictions you have to agree to first.

At what point would restrictions become too onerous for you to accept them?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, June 11, 2007 10:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] What ABOUT KMDF Source Code?

Thanks, Peter, for clearly expressing this standpoint which I share. I’d
emphasize: part of Windows sources already leaked some time before and
what happened? Nothing noticeable.

MS can’t lose anything, just gain. Now only if some open mind with
necessary power realizes it.

Well, I guess you have enough material for a Pontification about source
code. I’m looking forward for it :wink:

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-289760-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, June 11, 2007 9:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] What ABOUT KMDF Source Code?

Mr. Cleary wrote, on releasing source code to the Windows operating
system:

Do you really believe this? I don’t and never have.

I know that Microsoft *believes* it is not in their best interest to
release the Windows OS source code. I don’t think they should release
a
BUILDABLE version of the Windows OS Source Code. But I think it would
be,
entirely, in their best interests to make the sources for the Windows
OS
widely available.

Sure… some assholes would use a lot of undocumented stuff.
Whatever.
Those people get what they deserve.

Sure… some other jerks will exploit security loopholes… Guess
those
loopholes will get found and filled quickly, huh??

But, seriously, what HARM could come of releasing the Windows source
code?
Note that there’s a TON of it is already avaiable on the internet (on
Chinese and Russian sites).

If I were “King for a Day” at Microsoft, I’d release the OS source
code
for the I/O Subsystem at the VERY LEAST. The code is surprisingly
well
written (mostly). Imagine the positive press this would engender.
The
good feelings among the community members.

And now when you got back STATUS_BLAH from IoSomeRandomFunction you
could
LOOK IT UP and be on your way, instead of praying to a random diety
for
guidance.

P


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Peter Wieland wrote:

So while everyone is pondering this if you could provide some feedback on what you’d be willing to sign to get source access that would be good to hear too.

Clearly there are people who think that source access has no risk to MS. I’d personally disagree, and so I assume that if we do put access out that there will be some restrictions you have to agree to first.

At what point would restrictions become too onerous for you to accept them?

This is a good point. As a DDK MVP, I was offered the opportunity to
gain access to the source code. I seriously considered it, but after
reading through the agreement documents, my concerns about
contamination, and about what I could say and what I couldn’t say, were
just enough over the comfort line for me that I turned it down. Now, if
I took some dedicated quiet time and read the documents more carefully,
I would probably find that my concerns were unfounded, but I’m afraid
I’d need a lawyer to be 100% sure.


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

Are you talking about complete OS source access or just the KMDF ?

I admit the risk of some company releasing their own Windows distribution
after doing some clever searches and replaces with a text editor and running
some clever obfuscator and doing some tasks out of order and some other
changes in such a way that it will be difficult for MS to prove to the judge
at the binary level it was originally created from the same source is not
unimaginable. I don’t know what a non-buildable version of the source
exactly means, if it just omits the makefiles I think it does not change
much.

However it is hard to imagine what is the potential risk of MS of just
releasing the KMDF source. I heard something like the academic source
license has some reasonable restrictions about posting no more than 50
lines. But I think not being allowed at all to publicly quote from the
source is going to be too hard for some.

/Daniel

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
So while everyone is pondering this if you could provide some feedback on
what you’d be willing to sign to get source access that would be good to
hear too.

Clearly there are people who think that source access has no risk to MS.
I’d personally disagree, and so I assume that if we do put access out that
there will be some restrictions you have to agree to first.

At what point would restrictions become too onerous for you to accept them?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, June 11, 2007 10:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] What ABOUT KMDF Source Code?

Thanks, Peter, for clearly expressing this standpoint which I share. I’d
emphasize: part of Windows sources already leaked some time before and
what happened? Nothing noticeable.

MS can’t lose anything, just gain. Now only if some open mind with
necessary power realizes it.

Well, I guess you have enough material for a Pontification about source
code. I’m looking forward for it :wink:

Michal

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-289760-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Monday, June 11, 2007 9:11 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] What ABOUT KMDF Source Code?
>
> Mr. Cleary wrote, on releasing source code to the Windows operating
> system:
>
>


>
> Do you really believe this? I don’t and never have.
>
> I know that Microsoft believes it is not in their best interest to
> release the Windows OS source code. I don’t think they should release
a
> BUILDABLE version of the Windows OS Source Code. But I think it would
be,
> entirely, in their best interests to make the sources for the Windows
OS
> widely available.
>
> Sure… some assholes would use a lot of undocumented stuff.
Whatever.
> Those people get what they deserve.
>
> Sure… some other jerks will exploit security loopholes… Guess
those
> loopholes will get found and filled quickly, huh??
>
> But, seriously, what HARM could come of releasing the Windows source
code?
> Note that there’s a TON of it is already avaiable on the internet (on
> Chinese and Russian sites).
>
> If I were “King for a Day” at Microsoft, I’d release the OS source
code
> for the I/O Subsystem at the VERY LEAST. The code is surprisingly
well
> written (mostly). Imagine the positive press this would engender.
The
> good feelings among the community members.
>
> And now when you got back STATUS_BLAH from IoSomeRandomFunction you
could
> LOOK IT UP and be on your way, instead of praying to a random diety
for
> guidance.
>
> P
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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