On my quest to port my NT driver to WDM I come face to face with a
completely different approach as far as global variables in concerned.
In the new model, all books suggest that no global variables should be used
and instead of that each variable should be attached with a device in the
device extension. I don’t argue about that. I find it very concrete in
architectural and due to my object-oriented familiarization is quite simple
to port the system to device oriented architecture.
My question is what about softice? What if I want to ice the execution and
monitor several internal parameters of my driver? Suppose I want to use the
virtual memory address assigned by the system in order to write manualy on
hardware. Softice is able to depict the driver and the device context. What
about the device extension?
Should I apply a way around? I mean is it common to use both the extension
and global space variables?
On my quest to port my NT driver to WDM I come face to face with a
completely different approach as far as global variables in concerned.
In the new model, all books suggest that no global variables should be used
and instead of that each variable should be attached with a device in the
device extension. I don’t argue about that. I find it very concrete in
architectural and due to my object-oriented familiarization is quite simple
to port the system to device oriented architecture.
My question is what about softice? What if I want to ice the execution and
monitor several internal parameters of my driver? Suppose I want to use the
virtual memory address assigned by the system in order to write manualy on
hardware. Softice is able to depict the driver and the device context. What
about the device extension?
Should I apply a way around? I mean is it common to use both the extension
and global space variables?
----- Original Message -----
From: Nikolas Stylianides
To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 5:20 PM
Subject: [ntdev] WDM and Softice
On my quest to port my NT driver to WDM I come face to face with a completely different approach as far as global variables in concerned.
In the new model, all books suggest that no global variables should be used and instead of that each variable should be attached with a device in the device extension. I don’t argue about that. I find it very concrete in architectural and due to my object-oriented familiarization is quite simple to port the system to device oriented architecture.
My question is what about softice? What if I want to ice the execution and monitor several internal parameters of my driver? Suppose I want to use the virtual memory address assigned by the system in order to write manualy on hardware. Softice is able to depict the driver and the device context. What about the device extension?
Should I apply a way around? I mean is it common to use both the extension and global space variables?
Sure, it has. Something like _MY_DEVICE_EXTENSION(hex_addr) and device extension address can be extracted from the device object. It should be possible to write macro and completely automate it but I usually find it once and add to watches when need to debug something.
It’s funny; I’m long time SoftICE user and don’t remember syntax exactly because haven’t used it for ages. No need for it; good traces are better. I usually have to examine data structures this way only during crashdump analysis.
BTW, there is nothing wrong with globals in driver. It is just necessary to distinguish correctly device and driver wide data. Device wide should be of course stored in device extension and it is possible there won’t be driver wide data.
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 3:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDM and Softice
In WinDbg, you use
dt poi(xxxxxxxx + 0x28) _MY_DEVICE_EXTENSION
where xxxxxxxx is a device object address in hex.
I’m sure SoftICE have the same feature.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation xxxxx@storagecraft.commailto:xxxxx > http: > > > ----- Original Message ----- > From: Nikolas Stylianides mailto:xxxxx > To: Windows System Software Devs Interest List mailto:xxxxx > Sent: Wednesday, March 30, 2005 5:20 PM > Subject: [ntdev] WDM and Softice > > > On my quest to port my NT driver to WDM I come face to face with a completely different approach as far as global variables in concerned. > > In the new model, all books suggest that no global variables should be used and instead of that each variable should be attached with a device in the device extension. I don’t argue about that. I find it very concrete in architectural and due to my object-oriented familiarization is quite simple to port the system to device oriented architecture. > > > > My question is what about softice? What if I want to ice the execution and monitor several internal parameters of my driver? Suppose I want to use the virtual memory address assigned by the system in order to write manualy on hardware. Softice is able to depict the driver and the device context. What about the device extension? > > > > Should I apply a way around? I mean is it common to use both the extension and global space variables? > > > > Thank you In advance. > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’ > To unsubscribe send a blank email to xxxxx@lists.osr.com > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’ > To unsubscribe send a blank email to xxxxx@lists.osr.com ></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
Just skip the whole WDM mess and use WDF if you can. You’ll save
yourself a ton of time, hassle, and annoyance. AND your implementation
of PnP and Power Management will be correct. Something that I can
guarantee you will not be the case in your WDM driver.
However WDF is neither released nor is the Beta currently locked in to its
api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at this
point in time is problematic.
On the other hand, it certainly does an excellent job of getting rid of the
whole pnp/power-management support debacle in WDM.
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola (OSR)
Sent: Wednesday, March 30, 2005 12:48 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDM and Softice
Nikolas Stylianides wrote:
On my quest to port my NT driver to WDM
You sure you want to do this?
Just skip the whole WDM mess and use WDF if you can. You’ll save yourself a
ton of time, hassle, and annoyance. AND your implementation of PnP and
Power Management will be correct. Something that I can guarantee you will
not be the case in your WDM driver.
However WDF is neither released nor is the Beta currently locked in to its
api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at this
point in time is problematic.
All reasonably valid points.
However I can tell you that I, personally, would not implement a new
device driver using WDM at this point in time, if the WDF kernel mode
driver framework was applicable to the device class in question.
In fact, we’re about to start a new driver for a very high-profile piece
of hardware… the driver nees to ship in the Sept/Oct timeframe… and
we’re going to use WDF.
Now, consider that I’ve been writing WDM drivers for more than 5 years,
have access to some pretty decent resources for WDM assistance, and
already have PnP/Power code that I think works pretty well.
I agree with the principles of WDF and am hoping for the best on its
implemtation. But at the moment, I have had zero luck with getting anything
in the way of a driver that is not a simple clone of the WDF samples going.
With the current beta I run into:
It ain’t documented
It is documented and the docs are wrong
It doesn’t work (is this me, or is this WDF can’t tell since
there are only a few stock samples and no doc!)
I have been build a large set of drivers for a project, the target is
Longhorn so WDF should be my friend. But it is totally worthless at the
moment to me, because the one condition of the project is “No discussions of
anything that could allow Redmond to know what we are doing!”. From what I
have seen, either you need to be doing something that you can find an
example of every call in the samples, you are willing to ask a ton of
questions on the beta group (and hope they are answered with something other
than “We changed that wait for the next drop”), or you can get inside
Redmond to read the source.
I did believe in WDF strongly, now someone is going to have to prove to
me it is not a waste of time.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Peter Viscarola (OSR)” wrote in message news:xxxxx@ntdev… > Roddy, Mark wrote: >> However WDF is neither released nor is the Beta currently locked in to >> its >> api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at >> this >> point in time is problematic. > > All reasonably valid points. > > However I can tell you that I, personally, would not implement a new > device driver using WDM at this point in time, if the WDF kernel mode > driver framework was applicable to the device class in question. > > In fact, we’re about to start a new driver for a very high-profile piece > of hardware… the driver nees to ship in the Sept/Oct timeframe… and > we’re going to use WDF. > > Now, consider that I’ve been writing WDM drivers for more than 5 years, > have access to some pretty decent resources for WDM assistance, and > already have PnP/Power code that I think works pretty well. > > I STILL choose WDF. > > Peter > OSR >
Don’s points are well taken but they are counterbalanced by the other side,
expressed by both myself and by Peter, that WDF contains a standard and
correct* implementation of the PnP/PowerManagement infrastructure support
required of any WDM driver, and for that alone it is worth considering.
AFAIC the showstopper is not quality or documentation but instability of the
API and lack of committed release dates. Peter’s October time frame for his
Big Deal Drivers *might* be aligned with an actual release of WDF, I
certainly wouldn’t know, but until I do know that the API is locked in and
that there is an actual release date for something which is shippable (like
for example a public beta) I can’t advise people to go WDF right now.
*correct not in the sense of provably correct, rather in the sense of it has
a low probability of major bugs
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, March 30, 2005 1:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDM and Softice
Peter,
I agree with the principles of WDF and am hoping for the best on its
implemtation. But at the moment, I have had zero luck with getting anything
in the way of a driver that is not a simple clone of the WDF samples going.
With the current beta I run into:
It ain’t documented
It is documented and the docs are wrong
It doesn’t work (is this me, or is this WDF can’t tell since
there are only a few stock samples and no doc!)
I have been build a large set of drivers for a project, the target is
Longhorn so WDF should be my friend. But it is totally worthless at the
moment to me, because the one condition of the project is "No discussions of
anything that could allow Redmond to know what we are doing!". From what I
have seen, either you need to be doing something that you can find an
example of every call in the samples, you are willing to ask a ton of
questions on the beta group (and hope they are answered with something other
than “We changed that wait for the next drop”), or you can get inside
Redmond to read the source.
I did believe in WDF strongly, now someone is going to have to prove to
me it is not a waste of time.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Peter Viscarola (OSR)” wrote in message news:xxxxx@ntdev… > Roddy, Mark wrote: >> However WDF is neither released nor is the Beta currently locked in to >> its >> api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at >> this >> point in time is problematic. > > All reasonably valid points. > > However I can tell you that I, personally, would not implement a new > device driver using WDM at this point in time, if the WDF kernel mode > driver framework was applicable to the device class in question. > > In fact, we’re about to start a new driver for a very high-profile piece > of hardware… the driver nees to ship in the Sept/Oct timeframe… and > we’re going to use WDF. > > Now, consider that I’ve been writing WDM drivers for more than 5 years, > have access to some pretty decent resources for WDM assistance, and > already have PnP/Power code that I think works pretty well. > > I STILL choose WDF. > > Peter > OSR >
On my quest to port my NT driver to WDM I come face to face with a
completely different approach as far as global variables in concerned.
In the new model, all books suggest that no global variables should be
used and instead of that each variable should be attached with a
device in the device extension.
This has always been true in NT drivers. In virtually every case, the
data you want to track is per-device data, not per-driver data.
Remember that you will only have one copy of a global variable, no
matter how many devices your driver is handling.
My question is what about softice? What if I want to ice the execution
and monitor several internal parameters of my driver? Suppose I want
to use the virtual memory address assigned by the system in order to
write manualy on hardware. Softice is able to depict the driver and
the device context. What about the device extension?
The device object includes a pointer to the device extension in the
DeviceExtension member. For that matter, the driver object includes a
pointer to a driver extension as well, in DriverExtension, although it
is not commonly used.
For convenience, I often use KdPrint to print the address of my
DeviceExtension when the device is created. That way, I can look in the
message log to know what address to dump.
Should I apply a way around? I mean is it common to use both the
extension and global space variables?
Not at all. Global variables are quite rare in NT drivers. You will
sometimes see a global for “MyDriverDebugLevel”, to allow you to adjust
the volume level of your debug statements, and you will sometimes see
large read-only data structures, but those are the only common examples
I can think of.
I don’t disagree that the PNP and Power implementations are great. But as
you have said there has been no real test of this code with a stable beta.
Moreover the drivers written so far are at Microsoft (ok maybe OSR), this is
fine but this does mean there is one style and approach to the drivers. The
only real test of the WDF will be when a bunch of people start writing
drivers, and find where the problems and lack of functionality are.
I am not blaming the developers of WDF, but the 3 year process has not been
a good one. The lack of drops, the inability to ship a product based on the
kit, and the general lack of documentation has turned me from a major fan,
to a major doubter. Note: I suggests “a roast” at DevCon where the
marketing and legal types who made this mess, had to head the complaints,
but apparently no one had the power to get them there. It does not bode
well for fixing this in the future.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Roddy, Mark” wrote in message news:xxxxx@ntdev… > Don’s points are well taken but they are counterbalanced by the other > side, > expressed by both myself and by Peter, that WDF contains a standard and > correct* implementation of the PnP/PowerManagement infrastructure support > required of any WDM driver, and for that alone it is worth considering. > > AFAIC the showstopper is not quality or documentation but instability of > the > API and lack of committed release dates. Peter’s October time frame for > his > Big Deal Drivers might be aligned with an actual release of WDF, I > certainly wouldn’t know, but until I do know that the API is locked in and > that there is an actual release date for something which is shippable > (like > for example a public beta) I can’t advise people to go WDF right now. > > > *correct not in the sense of provably correct, rather in the sense of it > has > a low probability of major bugs > > ===================== > Mark Roddy > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn > Sent: Wednesday, March 30, 2005 1:20 PM > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] WDM and Softice > > Peter, > > I agree with the principles of WDF and am hoping for the best on its > implemtation. But at the moment, I have had zero luck with getting > anything > in the way of a driver that is not a simple clone of the WDF samples > going. > With the current beta I run into: > > 1. It ain’t documented > 2. It is documented and the docs are wrong > 3. It doesn’t work (is this me, or is this WDF can’t tell since > there are only a few stock samples and no doc!) > > I have been build a large set of drivers for a project, the target is > Longhorn so WDF should be my friend. But it is totally worthless at the > moment to me, because the one condition of the project is “No discussions > of > > anything that could allow Redmond to know what we are doing!”. From what > I > > have seen, either you need to be doing something that you can find an > example of every call in the samples, you are willing to ask a ton of > questions on the beta group (and hope they are answered with something > other > than “We changed that wait for the next drop”), or you can get inside > Redmond to read the source. > > I did believe in WDF strongly, now someone is going to have to prove > to > me it is not a waste of time. > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > “Peter Viscarola (OSR)” wrote in message > news:xxxxx@ntdev… >> Roddy, Mark wrote: >>> However WDF is neither released nor is the Beta currently locked in to >>> its >>> api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at >>> this >>> point in time is problematic. >> >> All reasonably valid points. >> >> However I can tell you that I, personally, would not implement a new >> device driver using WDM at this point in time, if the WDF kernel mode >> driver framework was applicable to the device class in question. >> >> In fact, we’re about to start a new driver for a very high-profile piece >> of hardware… the driver nees to ship in the Sept/Oct timeframe… and >> we’re going to use WDF. >> >> Now, consider that I’ve been writing WDM drivers for more than 5 years, >> have access to some pretty decent resources for WDM assistance, and >> already have PnP/Power code that I think works pretty well. >> >> I STILL choose WDF. >> >> Peter >> OSR >> > > > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@stratus.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
I don’t disagree that the PNP and Power implementations are great. But as
you have said there has been no real test of this code with a stable beta.
Sorry, but I find this to be mostly silly whining.
WHY do you say that WDF is not a “stable beta”? The code’s worked
remarkably well in my experience. The DDI’s have changed some, as Mark
Roddy pointed out, but in my view they’ve changed minimally – a few
words here and there in the name of a DDI, or a small parameter change.
I recently updated a driver I wrote using last year’s WinHEC release
of WDF to work with the latest WDF DDIs, and I managed to get all the
changes done on the plan during a flight from San Fransisco to Boston.
AND have time to sample the exquisite cuisine on offer from the airline,
I might add.
Moreover the drivers written so far are at Microsoft (ok maybe OSR), this is
fine but this does mean there is one style and approach to the drivers.
>
Point One:
The WDF beta has been well publicized and (basically) wide-open. If the community hasn’t written any/many WDF drivers as you apparently believe, then the community needs to take the responsibility for that. It’s bullshit to not bother to exercise the beta and then turn around and say “the only drivers are written by Microsoft and OSR.” Hullo? Self-fulfilling prophecy.
The community will get what results from their participation or lack thereof. If YOU, and I’m talking to each driver writer on this list now, if YOU want a new driver model that works for YOU, the only way to make sure that happens is to invest the time and effort necessary to use the betas. And, no, I am not sympathetic to the claim that “I’m busy.” We’re ALL busy. Sleep less. Get used to it.
Satisfy yourself (and your significant other) with the promise that your substantive participation in the WDF beta will help ensure that you never again have to spend your weekends debugging some stupid IRP_MN_SET_POWER bug.
Just remember: The WDF you get will be the WDF that is created as the result of your input.
Point Two:
WHY would you think that all the drivers written by Microsoft, with HOW
many thousand employees, would all be one style and approach? Do you
know every project in Microsoft that’s using WDF? I know that *I*
don’t. I bet NOBODY does.
And, sorry, but I do not agree with even the smaller implication that
any driver *I* write is the same style and approach as that written by
somebody at Microsoft. WTF does this mean?
I am not blaming the developers of WDF, but the 3 year process has not been
a good one. The lack of drops, the inability to ship a product based on the
kit, and the general lack of documentation has turned me from a major fan,
to a major doubter.
OK, I agree that the WDF beta has not been the best-run beta process
that I’ve seen. And I, too, have been frustrated by the slow pace of
the documentation. But have you looked at the docs lately?
And, still, I don’t see why the points you cite are any reason not to
invest time/effort in the beta. Every engineer here at OSR (OK, not
Tony… cuz you can’t write WDF file systems… but everyone else) has
been working with WDF for quite a while now. It’s in our best
interests, and we know it.
When WDF ships – whenever that is – each of the engineers at OSR will
have some YEARS of WDF experience under our belts. There’s no reason
why any other interested community member couldn’t say the same thing.
OK. I just couldn’t hold off any longer. If you need a global, use it.
Just make sure you really need one and if it is more than read-only protect
it with a global spinlock too. Most of the time globals are because of bad
design - in fact probably all of the time. The most famous driver that all
of us have and have used in the past - some don’t any more - is the floppy
driver. It has to have globals to handle the case where you have two
floppies on a system. The floppy controller (hardware) can only access one
device at a time. You may not select nor turn on the motor for more than
one floppy at a time. The floppy driver overcomes this limitation by
putting all requests that require access to the hardware into a queue for a
single worker thread to process. That queue and worker thread have to be
driver based - in fact they must also be machine based. When the floppy
driver was split into two parts so that tape drives could be accessed, this
logic had to be changed slightly to put it into the lower driver where all
access to the hardware occurs.
“Tim Roberts” wrote in message news:xxxxx@ntdev… > Nikolas Stylianides wrote: > >> On my quest to port my NT driver to WDM I come face to face with a >> completely different approach as far as global variables in concerned. >> >> In the new model, all books suggest that no global variables should be >> used and instead of that each variable should be attached with a device >> in the device extension. >> > > This has always been true in NT drivers. In virtually every case, the > data you want to track is per-device data, not per-driver data. Remember > that you will only have one copy of a global variable, no matter how many > devices your driver is handling. > >> My question is what about softice? What if I want to ice the execution >> and monitor several internal parameters of my driver? Suppose I want to >> use the virtual memory address assigned by the system in order to write >> manualy on hardware. Softice is able to depict the driver and the device >> context. What about the device extension? >> > > The device object includes a pointer to the device extension in the > DeviceExtension member. For that matter, the driver object includes a > pointer to a driver extension as well, in DriverExtension, although it is > not commonly used. > > For convenience, I often use KdPrint to print the address of my > DeviceExtension when the device is created. That way, I can look in the > message log to know what address to dump. > >> Should I apply a way around? I mean is it common to use both the >> extension and global space variables? >> > > Not at all. Global variables are quite rare in NT drivers. You will > sometimes see a global for “MyDriverDebugLevel”, to allow you to adjust > the volume level of your debug statements, and you will sometimes see > large read-only data structures, but those are the only common examples I > can think of. > > – > - Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > >
“Peter Viscarola (OSR)” wrote in message news:xxxxx@ntdev… > And, still, I don’t see why the points you cite are any reason not to > invest time/effort in the beta. Every engineer here at OSR (OK, not > Tony… cuz you can’t write WDF file systems… but everyone else) has > been working with WDF for quite a while now. It’s in our best interests, > and we know it. > All I can say is I tried, when the last WinHEC beta came around, I took a month. Experimented with the code, and found that I didn’t get very far beyond the samples. I did file a bunch of bugs, most of which got closed with little or no reponse. I’ve have invested a fair amount of time tracking WDF over the last 3 years. I do believe this is an important effort and I would like to see it succeed, but bottom line is so far most of the “beta” is not something that was ready for beta.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
Well not to nitpick (i.e. I’m about to nitpick) but the existing APIs can’t
CHANGE AT ALL given that the directive is to use the dynamic version of WDF.
The API definitions have to be locked in before this is possible.
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola (OSR)
Sent: Wednesday, March 30, 2005 2:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDM and Softice
Don Burn wrote:
I don’t disagree that the PNP and Power implementations are great.
But as you have said there has been no real test of this code with a
stable beta.
Sorry, but I find this to be mostly silly whining.
WHY do you say that WDF is not a “stable beta”? The code’s worked
remarkably well in my experience. The DDI’s have changed some, as Mark
Roddy pointed out, but in my view they’ve changed minimally – a few words
here and there in the name of a DDI, or a small parameter change.
I recently updated a driver I wrote using last year’s WinHEC release of
WDF to work with the latest WDF DDIs, and I managed to get all the changes
done on the plan during a flight from San Fransisco to Boston.
AND have time to sample the exquisite cuisine on offer from the airline, I
might add.
Moreover the drivers written so far are at Microsoft (ok maybe OSR),
this is fine but this does mean there is one style and approach to the
drivers.
>
Point One:
The WDF beta has been well publicized and (basically) wide-open. If the community hasn’t written any/many WDF drivers as you apparently believe, then the community needs to take the responsibility for that. It’s bullshit to not bother to exercise the beta and then turn around and say “the only drivers are written by Microsoft and OSR.” Hullo? Self-fulfilling prophecy.
The community will get what results from their participation or lack thereof. If YOU, and I’m talking to each driver writer on this list now, if YOU want a new driver model that works for YOU, the only way to make sure that happens is to invest the time and effort necessary to use the betas. And, no, I am not sympathetic to the claim that “I’m busy.” We’re ALL busy. Sleep less. Get used to it.
Satisfy yourself (and your significant other) with the promise that your substantive participation in the WDF beta will help ensure that you never again have to spend your weekends debugging some stupid IRP_MN_SET_POWER bug.
Just remember: The WDF you get will be the WDF that is created as the result of your input.
Point Two:
WHY would you think that all the drivers written by Microsoft, with HOW
many thousand employees, would all be one style and approach? Do you
know every project in Microsoft that’s using WDF? I know that *I*
don’t. I bet NOBODY does.
And, sorry, but I do not agree with even the smaller implication that
any driver *I* write is the same style and approach as that written by
somebody at Microsoft. WTF does this mean?
I am not blaming the developers of WDF, but the 3 year process has not
been
a good one. The lack of drops, the inability to ship a product based on
the
kit, and the general lack of documentation has turned me from a major fan,
to a major doubter.
OK, I agree that the WDF beta has not been the best-run beta process
that I’ve seen. And I, too, have been frustrated by the slow pace of
the documentation. But have you looked at the docs lately?
And, still, I don’t see why the points you cite are any reason not to
invest time/effort in the beta. Every engineer here at OSR (OK, not
Tony… cuz you can’t write WDF file systems… but everyone else) has
been working with WDF for quite a while now. It’s in our best
interests, and we know it.
When WDF ships – whenever that is – each of the engineers at OSR will
have some YEARS of WDF experience under our belts. There’s no reason
why any other interested community member couldn’t say the same thing.
So I think the difference in experience is proportional to how close you are
to source code and/or WDF developer access. That is indeed a problem. As
things are right now, lack of source code is a real barrier to understanding
how WDF works.
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, March 30, 2005 4:28 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDM and Softice
“Peter Viscarola (OSR)” wrote in message news:xxxxx@ntdev… > And, still, I don’t see why the points you cite are any reason not to > invest time/effort in the beta. Every engineer here at OSR (OK, not > Tony… cuz you can’t write WDF file systems… but everyone else) has > been working with WDF for quite a while now. It’s in our best > interests, and we know it. > All I can say is I tried, when the last WinHEC beta came around, I took a month. Experimented with the code, and found that I didn’t get very far beyond the samples. I did file a bunch of bugs, most of which got closed with little or no reponse. I’ve have invested a fair amount of time tracking WDF over the last 3 years. I do believe this is an important effort and I would like to see it succeed, but bottom line is so far most of the “beta” is not something that was ready for beta.
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Roddy, Mark[SMTP:xxxxx@stratus.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 31, 2005 12:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDM and Softice
So I think the difference in experience is proportional to how close you are
to source code and/or WDF developer access. That is indeed a problem. As
things are right now, lack of source code is a real barrier to understanding
how WDF works.
Yep, for me that’s the reason why to not use WDF, at least for now. Lack of docs isn’t such a big problem if source code is available and moderately readable; at least as DDK samples and IFS kit sources. It is important mainly in beta phase when bugs and inaccuracies are expected so developer can easily find the root of possible problem. I’m sorry but I savoured enough single stepping and disassembling framework/support library code when I developed NDIS drivers. Peter may be right beeing busy isn’t an excuse but I guess beeing busy and don’t have all reasonable info available is. As far as I know, all similar 3rd party frameworks contain sources.
Does anybody know if it is planned to make WDF sources available with final version? Or at least, does WDF use ETW extensively?
In SoftICE you can use the Locals Window. Turn it on with a "wl" command, and the moment you step into your SvRead or SvOpen routine, for example, a pointer to your DeviceObject will be on the stack and clicking on the "+" sign of the Locals Window Tree Control expands the data structure. No need for commands, unless I misunderstand the issue.
Alberto.
----- Original Message -----
From: Maxim S. Shatskih
To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 8:48 AM
Subject: Re: [ntdev] WDM and Softice
----- Original Message -----
From: Nikolas Stylianides
To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 5:20 PM
Subject: [ntdev] WDM and Softice
On my quest to port my NT driver to WDM I come face to face with a completely different approach as far as global variables in concerned.
In the new model, all books suggest that no global variables should be used and instead of that each variable should be attached with a device in the device extension. I don't argue about that. I find it very concrete in architectural and due to my object-oriented familiarization is quite simple to port the system to device oriented architecture.
My question is what about softice? What if I want to ice the execution and monitor several internal parameters of my driver? Suppose I want to use the virtual memory address assigned by the system in order to write manualy on hardware. Softice is able to depict the driver and the device context. What about the device extension?
Should I apply a way around? I mean is it common to use both the extension and global space variables?
----- Original Message -----
From: “Roddy, Mark” To: “Windows System Software Devs Interest List” Sent: Wednesday, March 30, 2005 10:36 PM Subject: RE: [ntdev] WDM and Softice
> Don’s points are well taken but they are counterbalanced by the other side, > expressed by both myself and by Peter, that WDF contains a standard and > correct* implementation of the PnP/PowerManagement infrastructure support > required of any WDM driver, and for that alone it is worth considering. > > AFAIC the showstopper is not quality or documentation but instability of the > API and lack of committed release dates. Peter’s October time frame for his > Big Deal Drivers might be aligned with an actual release of WDF, I > certainly wouldn’t know, but until I do know that the API is locked in and > that there is an actual release date for something which is shippable (like > for example a public beta) I can’t advise people to go WDF right now. > > > *correct not in the sense of provably correct, rather in the sense of it has > a low probability of major bugs > > ===================== > Mark Roddy > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn > Sent: Wednesday, March 30, 2005 1:20 PM > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] WDM and Softice > > Peter, > > I agree with the principles of WDF and am hoping for the best on its > implemtation. But at the moment, I have had zero luck with getting anything > in the way of a driver that is not a simple clone of the WDF samples going. > With the current beta I run into: > > 1. It ain’t documented > 2. It is documented and the docs are wrong > 3. It doesn’t work (is this me, or is this WDF can’t tell since > there are only a few stock samples and no doc!) > > I have been build a large set of drivers for a project, the target is > Longhorn so WDF should be my friend. But it is totally worthless at the > moment to me, because the one condition of the project is “No discussions of > > anything that could allow Redmond to know what we are doing!”. From what I > > have seen, either you need to be doing something that you can find an > example of every call in the samples, you are willing to ask a ton of > questions on the beta group (and hope they are answered with something other > than “We changed that wait for the next drop”), or you can get inside > Redmond to read the source. > > I did believe in WDF strongly, now someone is going to have to prove to > me it is not a waste of time. > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > “Peter Viscarola (OSR)” wrote in message > news:xxxxx@ntdev… > > Roddy, Mark wrote: > >> However WDF is neither released nor is the Beta currently locked in to > >> its > >> api, nor is the Beta release without ‘issues’, so ‘going with WDF’ at > >> this > >> point in time is problematic. > > > > All reasonably valid points. > > > > However I can tell you that I, personally, would not implement a new > > device driver using WDM at this point in time, if the WDF kernel mode > > driver framework was applicable to the device class in question. > > > > In fact, we’re about to start a new driver for a very high-profile piece > > of hardware… the driver nees to ship in the Sept/Oct timeframe… and > > we’re going to use WDF. > > > > Now, consider that I’ve been writing WDM drivers for more than 5 years, > > have access to some pretty decent resources for WDM assistance, and > > already have PnP/Power code that I think works pretty well. > > > > I STILL choose WDF. > > > > Peter > > OSR > > > > > > — > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@stratus.com > To unsubscribe send a blank email to xxxxx@lists.osr.com > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks everybody for your response. My question was clearly aswered.
Global variables are used when they addressed in DriverObject. I have
allready a banch of global variables which can be enclosed in a
DeviceExtension structure because they address in Device Objects.
Softice is able to format an address space in whatever type I want (not
clear to me but I will read the documentation more carefully and find out
how).
The conversation about WDF really tricked my curiosity. Although it Is not
in my intend to port my driver right now according to this new model, I will
safe some time in order to find out more and experiment with it. The debate
was just excellent.
