New driver model?

I read that article at wd-3.com about a new driver model which will be
announced at WinHec in a few days…

I remember reading many months ago about some kind of library that Microsoft
was working on, which would simplify WDM driver development. At that time,
I think they called it something like “WDM+”… I believe I read that from
some official source (msdn?). I have tried to find that article a couple of
times already but without success.

Am I the only one who read that? Was that just a dream or some sort of
twisted autosuggestion? Anyone else remember seeing that?

Anyway, I guess I’ll have my mind clear in a couple of days :slight_smile: Too bad I
won’t be at WinHec this year… :frowning:

Mat

There were some talks at the 2002 WinHEC on simplifying
the driver model, this work came out of those.

Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting

----- Original Message -----
From: “Mathieu Routhier”
To: “NT Developers Interest List”
Sent: Thursday, May 01, 2003 2:07 PM
Subject: [ntdev] New driver model?

> I read that article at wd-3.com about a new driver model which will be
> announced at WinHec in a few days…
>
> I remember reading many months ago about some kind of library that
Microsoft
> was working on, which would simplify WDM driver development. At that
time,
> I think they called it something like “WDM+”… I believe I read that
from
> some official source (msdn?). I have tried to find that article a couple
of
> times already but without success.
>
> Am I the only one who read that? Was that just a dream or some sort of
> twisted autosuggestion? Anyone else remember seeing that?
>
> Anyway, I guess I’ll have my mind clear in a couple of days :slight_smile: Too bad I
> won’t be at WinHec this year… :frowning:
>
> Mat
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com

This new model is called the Windows Driver Framework (WDF) and is a
refinement of the simplification model introduced last year. In a nutshell,
the WDF will simplify driver writing by providing default processing to
handle the boilerplate processing (i.e. IRP forwarding, reference counters,
lock management, etc.) which clutters many WDM drivers. Much of the default
processing can be overridden with device specific processing if the device
requires it (such as a bus driver being able to respond to
IRP_MN_QUERY_DEVICE_RELATIONS instead of allowing the default device driver
handling of the IRP to occur).

After reviewing the new and improved Toaster sample written to the WDF in
the Longhorn Developer Kit (LDK) distributed at WinHEC last week, I am quite
impressed and anxious to see the WDF move forward to full implementation. I
believe the WDF will allow drivers to ignore the common boilerplate
processing and instead focus on required device specific processing, all of
which allows for improved readability and maintainability of the driver
code.

“Don Burn” wrote in message news:xxxxx@ntdev…
>
> There were some talks at the 2002 WinHEC on simplifying
> the driver model, this work came out of those.
>
> Don Burn
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
> ----- Original Message -----
> From: “Mathieu Routhier”
> To: “NT Developers Interest List”
> Sent: Thursday, May 01, 2003 2:07 PM
> Subject: [ntdev] New driver model?
>
>
> > I read that article at wd-3.com about a new driver model which will be
> > announced at WinHec in a few days…
> >
> > I remember reading many months ago about some kind of library that
> Microsoft
> > was working on, which would simplify WDM driver development. At that
> time,
> > I think they called it something like “WDM+”… I believe I read that
> from
> > some official source (msdn?). I have tried to find that article a
couple
> of
> > times already but without success.
> >
> > Am I the only one who read that? Was that just a dream or some sort of
> > twisted autosuggestion? Anyone else remember seeing that?
> >
> > Anyway, I guess I’ll have my mind clear in a couple of days :slight_smile: Too bad
I
> > won’t be at WinHec this year… :frowning:
> >
> > Mat
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>

> After reviewing the new and improved Toaster sample written to the WDF in

the Longhorn Developer Kit (LDK) distributed at WinHEC last week, I am quite
impressed and anxious to see the WDF move forward to full implementation.

Wow really? I looked over this stuff, and I have to say this is exactly
what I was afraid of. Well not exactly, at least I can still get at the
underlying objects in some cases. But really, with as abstracted as the
underlying driver model is in this new model, the objects won’t do much
good.

I sure hope they release their source with this framework so that folks
don’t have to be absolutely dependent on MS getting the framework code
absolutely correct. That or they sure better have a good and quick method
of addressing bug fixes. But I am sure there will be no bugs.

Having gone down the framework path a couple of times I have to say, I am
not holding my breath on this ever being remotely useful except in the
simplest of cases. I say this for a couple of reasons. I am not totally
convinced that WDM needs a framework versus just some helper libraries.
Also, the more you abstract the more you have to be able to consider every
possible usage scenario. This framework abstracts more than any I have
ever seen. I sure hope the folks writing it have written a BUNCH of
commercial drivers for all of the technologies eventually encompassed by
this framework. Their generalization skills will have to be quite
impressive. Did anyone address the performance of an event driven model
like this? I wonder how a frame grabber, or similar high speed PCI DMA
device would do under this model. I mean once DMA support is available.

I see this as the miniport model for the rest of us, with all the pitfalls
and joys that come with miniport models. I was really really hoping for
the “just a few helpful libraries to take care of PnP and Power and
otherwise stay out of the way” approach, but alas I guess that is not to
be.

I hope your enthusiasm is well placed and my skepticism is not.


Bill McKenzie

Pardon my ignorance, but for those of us who were so unlucky as to not be
able to attend WinHEC, can the LDK be obtained from MS (for example via MSDN
downloads) in any manner whatsoever? TIA

Philip Lukidis

[snip interesting discussion]

First there are two different things here:

  1. The LDK is a new build/test environment that will replace the DDK and
    the HCT tests in the Longhorn timeframe.

  2. The second is Driver Framework (DFW) that is the new driver model,
    this will be comming out earlier. See
    http://www.microsoft.com/whdc/hwdev/driver/drvframewk.mspx for a paper on
    the framework.

Microsoft promised to cover both at the Device Driver Confernce this
November,
http://www.microsoft.com/whdc/resources/events/driverdevcon.mspx

Before that you might send mail to xxxxx@microsoft.com for how to get on
beta’s etc.

Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting

----- Original Message -----
From: “Philip Lukidis”
To: “NT Developers Interest List”
Sent: Thursday, May 15, 2003 11:03 AM
Subject: [ntdev] Re: New driver model?

> Pardon my ignorance, but for those of us who were so unlucky as to not be
> able to attend WinHEC, can the LDK be obtained from MS (for example via
MSDN
> downloads) in any manner whatsoever? TIA
>
> Philip Lukidis
>
> [snip interesting discussion]
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Two points…

(1) DFW is not intended to be all things to all people. It’s intended
to solve a certain set of problems for a certain class of devices/driver
writers. DFW is not targeted at NT kernel mode experts working on
projects where every nanosecond counts. What DFW offers is an easy
way to write simple drivers for simple devices. This is a Good Thing.
Right now people with limited kernel experience are writing complex
WDM drivers for their simple devices, and too often they screw up.
BSOD’s from buggy drivers are bad for the entire industry, not just
the vendor of the deficient driver.

(2) Unlike other miniport models, DFW allows you to escape from the
framework and use the full kernel API’s when needed. This makes a
world of difference. You can argue about how easy it is to “escape”,
but at least now it’s possible.

>(1) DFW is not intended to be all things to all people.

Well, I believe this statement is true, and fortunately it doesn’t appear
people will be forced to use this model as with other miniport models.
However, as it isn’t all things to all people, it’s usefulness is somewhat
degraded. I just don’t believe this approach (heavily abstracted framework
model) is viable in the WDM space. AND if you were going to attempt to
provide this type of solution, then I don’t believe C is the language to use
for it frankly. C is excellent for providing helper functions and libs, but
it is really limited in the framework space.

You can argue about how easy it is to “escape”,
but at least now it’s possible.

What it wasn’t possible before? :slight_smile: I suppose you mean like in other
miniport models such as for SCSI. Yeah, well, that is great but what really
does allow escape is the fact you can choose not to use this model at all,
and I hope that choice remains! I wish that choice had been offered with
SCSI/NDIS/name your favorite miniport model here. WDM was sort of hacked in
for NDIS which finally made NDIS useful to some degree. I digress.

My problem with these overreaching models is that the architects of them
have to be of supreme caliber and experience. Experience here meaning vast
experience architecting drivers for all technologies encompassed (possibly
including future technologies), and vast experience architecting frameworks
like this. I wonder where you get those folks from? Seriously, if you
haven’t tried it, try it sometime, frameworks are tricky business and they
take several YEARS to get wrung out and correct.

On the performace front, I don’t believe easier to use implies slower. BUT,
you have to make performance one of your top three or four design
priorities. I wonder where it ranked here. This is a problem because let
us say you have some company making hardware. Let us now say that most of
their devices are not that taxing, and they have been able to get away with
DFW drivers for a while. Now, they come out with a device that pushes the
boundaries WRT performance in some way. What are they going to do? They
are going to try to use what they know, namely DFW, and fail miserably.
Then, when they have to go back and use WDM they are going to get broadsided
with a world of complexity they had not known existed. Some helper libs
would have been useful in all contexts and not sheltered these poor folks
from what they really needed to know in the first place.

Having worked on, and working on frameworks I am obviously not oppossed to
frameworks. But, they are of limited use in this space, an insight gained
through experience. The most useful part of the tools I have worked on,
IMHO, are the samples, libraries for the big mostly static items like
PnP/Power/Queues, and the wizards which generate a tremendous amount of code
and support files for you. With just a framework some of the complexity is
removed, but much is not (INF files as an example), and some new complexity
is added (new APIs and such). In general frameworks are great provided they
solve the hard problems easily, don’t make the easy code hard, don’t
abstract more than is absolutely necessary, and as long as they are
accompanied by other useful tools like code generating wizards. Again, on
their own, they are of very limited usefulness IMO.

But, I do see an initiative for some really good new DDK WDM samples on the
horizon so there is hope yet. New pristine WDM sample drivers for the DDK,
that is just flat out a great great idea. Kudos to whomever came up with
that.


Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…

Two points…

(1) DFW is not intended to be all things to all people. It’s intended
to solve a certain set of problems for a certain class of devices/driver
writers. DFW is not targeted at NT kernel mode experts working on
projects where every nanosecond counts. What DFW offers is an easy
way to write simple drivers for simple devices. This is a Good Thing.
Right now people with limited kernel experience are writing complex
WDM drivers for their simple devices, and too often they screw up.
BSOD’s from buggy drivers are bad for the entire industry, not just
the vendor of the deficient driver.

(2) Unlike other miniport models, DFW allows you to escape from the
framework and use the full kernel API’s when needed. This makes a
world of difference. You can argue about how easy it is to “escape”,
but at least now it’s possible.</john.mcnamee>

Thanks for the info, it’s much appreciated.

Philip Lukidis

----- Original Message -----
From: “Don Burn”
To: “NT Developers Interest List”
Sent: Thursday, May 15, 2003 11:29 AM
Subject: [ntdev] Re: New driver model?

> First there are two different things here:
>
> 1. The LDK is a new build/test environment that will replace the DDK
and
> the HCT tests in the Longhorn timeframe.
>
> 2. The second is Driver Framework (DFW) that is the new driver model,
> this will be comming out earlier. See
> http://www.microsoft.com/whdc/hwdev/driver/drvframewk.mspx for a paper on
> the framework.
>
> Microsoft promised to cover both at the Device Driver Confernce this
> November,
> http://www.microsoft.com/whdc/resources/events/driverdevcon.mspx
>
> Before that you might send mail to xxxxx@microsoft.com for how to get
on
> beta’s etc.
>
> Don Burn
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
>
>
>
> ----- Original Message -----
> From: “Philip Lukidis”
> To: “NT Developers Interest List”
> Sent: Thursday, May 15, 2003 11:03 AM
> Subject: [ntdev] Re: New driver model?
>
>
> > Pardon my ignorance, but for those of us who were so unlucky as to not
be
> > able to attend WinHEC, can the LDK be obtained from MS (for example via
> MSDN
> > downloads) in any manner whatsoever? TIA
> >
> > Philip Lukidis
> >
> > [snip interesting discussion]
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Thanks John. I want to add a few more things.

We are using the Windows Driver Framework internally to update several of
our device stacks (notably storage and 1394), so we are targeting this at
the drivers we will be shipping (not just toy drivers). If you guys have
specific comments about things you believe to be lacking, too simple, or our
not providing enough ways to escape the framework etc.) please send us
feedback at xxxxx@microsoft.com.

We also understand that documenting the subtle semantics of escaping to WDM
from the framework is very difficult. For this reason we are actively
investigating the possibility of shipping the source for the framework in
the LDK.


Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…

Two points…

(1) DFW is not intended to be all things to all people. It’s intended
to solve a certain set of problems for a certain class of devices/driver
writers. DFW is not targeted at NT kernel mode experts working on
projects where every nanosecond counts. What DFW offers is an easy
way to write simple drivers for simple devices. This is a Good Thing.
Right now people with limited kernel experience are writing complex
WDM drivers for their simple devices, and too often they screw up.
BSOD’s from buggy drivers are bad for the entire industry, not just
the vendor of the deficient driver.

(2) Unlike other miniport models, DFW allows you to escape from the
framework and use the full kernel API’s when needed. This makes a
world of difference. You can argue about how easy it is to “escape”,
but at least now it’s possible.</john.mcnamee>

I agree with almost everything Bill McKenzie said. He has a *lot* of
experience in this space. Of course, he also likes C++, but heck…
everyone has their faults :wink:

I think it’s of the utmost importance that WDF be viewed not as the “Windows
Drivers for Dummies” but rather as THE NEW DRIVER MODEL. If the WDM experts
among us dismiss the model as something for “those people” who don’t know
any better, then the thing is doomed from the start.

That’s (one reason) why, as NarG pointed out, MS is starting to re-implement
core O/S stacks using WDF. Not only does it give the folks up in Redmond
some real-live, critical, test cases, but it also is a concrete
demonstration that this is *the* way to write drivers in the future.

Those of you who haven’t had a chance to check out the frameworks, check out
our report from The NT Insider at: http://www.osronline.com. Also (as Don
mentioned) sign up for the DDK Beta Program… Not only will you probably
get download access to the WinHEC DDK (assuming you can get approved quickly
enough, etc) but you’ll also get on-going updates of the DDK to play with
(and report bugs on).

Peter
OSR

> I think it’s of the utmost importance that WDF be viewed not as the
"Windows

Drivers for Dummies" but rather as THE NEW DRIVER MODEL. If the WDM
experts
among us dismiss the model as something for “those people” who don’t
know
any better, then the thing is doomed from the start.

The idea of WDF seems to be great.

If this is something like port-miniport model which is already used
for SCSI, NDIS and KS drivers, which will provide default PnP and
Power paths (for bus drivers too) and device queue, or, in other
words, something like Walter’s GENERIC.SYS - then looks like a great
idea, especially if the source will be included and if WDM will be
preserved as lower-level model, to which one can escape if necessary.

BTW - Nar mentioned the storage stack rewrite for WDF. Will this
include SCSIPORT? or only the class drivers?

Max

> If this is something like port-miniport model which is already used

for SCSI, NDIS and KS drivers, which will provide default PnP and
Power paths (for bus drivers too) and device queue, or, in other
words, something like Walter’s GENERIC.SYS - then looks like a great
idea,

No that is exactly my point. If it were something like generic.sys, which I
was really really hoping it would be, I would be all for it. Generic.sys,
like many of Walter’s solutions to problems, is a really really good
solution. I don’t say this because I like Walter, rather because
generic.sys is a well engineered solution. It follows the KISS principle,
providing just enough solution. Miniports like SCSI and NDIS overreach and
become MUCH less useful. Again, the model has to anticipate too much if it
abstracts too much. With WDF or DFW or whatever it is called, they even
abstract IRPs which I have a hard time buying into. Why use a C struct to
abstract a C struct? But, I digress, that is just an example, overall WDF
abstracts everything and thus must anticipate everything. At least that is
my take.

Releasing source to this framework would go a long way in making this more
palatable, I will say that. I would love to hear a confirmation that that
was indeed going to happen.

My long range fear is that WHQL won’t sign a non-WDF driver. I know as sure
as I am standing here that that is going to happen at least to some measure
or in certain circumstances. I just hope the model is up to the task.

But, I suppose at this point there is no use in crying over spilt milk. It
is what it is and we will have to like it one way or another.

I can’t wait to see the new 1394 stack!


Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm

> I think it’s of the utmost importance that WDF be viewed not as the

“Windows Drivers for Dummies” but rather as THE NEW DRIVER MODEL.
If the WDM experts among us dismiss the model as something for
“those people” who don’t know any better, then the thing is doomed
from the start.

The impression I got at WinHEC is that Microsoft doesn’t exactly see
DFW as “Windows Drivers for Dummies”, but more like “Windows Drivers
for simple devices”. It isn’t intended to allow Visual Basic weenies
to write kernel code, but to allow systems programmers of average
talent to quickly and easily write *correct* drivers for simple devices.
Whenever questions came up about limitations in the framework, the
answer was often “continue to use WDM or an existing-miniport model
to do that”. That Microsoft is planning to rewrite core OS drivers
using the framework is news to me; I don’t recall hearing that at
WinHEC. Maybe I missed that sesssion (or it was one the started at
8AM and I slept through it – will somebody please tell me why they
start WinHEC sessions so f#*%:@! early in the morning! How many
systems programmers show up for work at 8AM?).

–John

“McNamee, John” wrote:

will somebody please tell me why they
start WinHEC sessions so f#*%:@! early in the morning! How many
systems programmers show up for work at 8AM?).

Not to mention putting it at the *far* end of the convention center and
setting the thermostat so low that the logo store was bound to sell out
of sweatshirts. And then, of course, there were all those keynotes that
were long on mind-numbing sound and short on technical content. Here’s
hoping that this Fall’s DDC, or whatever, avoids all of these
features…


Walter Oney
Famous Curmudgeon

>>>With WDF or DFW or whatever it is called, they even
abstract IRPs which I have a hard time buying into. Why use a C struct
to
abstract a C struct?

DFWREQUEST is not a C struct. It is an object. It has a reference count,
a set of properties, internal behavior, and a lifetime model. This is
the same for every framework object.

I hear your concerns, but the framework borrows ideas from the .NET
Framework library (not MFC), in which you start with a working
application and build it up from there. An alternative approach would be
to put something together with individual “piece parts”, but you do not
get the integration we are looking for in regards to request flow
through the driver. Also there is the “how do I start” issue which
involves basically taking a sample driver and cutting and pasting it
with a piece parts approach.

We want real, heavy duty drivers to be able to use the framework. That
is one of the reasons we have made the framework available in such an
early form.

JohnR

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Friday, May 16, 2003 7:19 AM
To: NT Developers Interest List
Subject: [ntdev] Re: New driver model?

If this is something like port-miniport model which is already used
for SCSI, NDIS and KS drivers, which will provide default PnP and
Power paths (for bus drivers too) and device queue, or, in other
words, something like Walter’s GENERIC.SYS - then looks like a great
idea,

No that is exactly my point. If it were something like generic.sys,
which I
was really really hoping it would be, I would be all for it.
Generic.sys,
like many of Walter’s solutions to problems, is a really really good
solution. I don’t say this because I like Walter, rather because
generic.sys is a well engineered solution. It follows the KISS
principle,
providing just enough solution. Miniports like SCSI and NDIS overreach
and
become MUCH less useful. Again, the model has to anticipate too much if
it
abstracts too much. With WDF or DFW or whatever it is called, they even
abstract IRPs which I have a hard time buying into. Why use a C struct
to
abstract a C struct? But, I digress, that is just an example, overall
WDF
abstracts everything and thus must anticipate everything. At least that
is
my take.

Releasing source to this framework would go a long way in making this
more
palatable, I will say that. I would love to hear a confirmation that
that
was indeed going to happen.

My long range fear is that WHQL won’t sign a non-WDF driver. I know as
sure
as I am standing here that that is going to happen at least to some
measure
or in certain circumstances. I just hope the model is up to the task.

But, I suppose at this point there is no use in crying over spilt milk.
It
is what it is and we will have to like it one way or another.

I can’t wait to see the new 1394 stack!


Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I concur with both on this one.
In one of the DFW sessions, the presenter mentioned the tyranny of the 1%
meaning that the enormous complexity of the current WDM is for the 1% of the
drivers that really need it. All other drivers can be developed using WDF.

----- Original Message -----
From: “McNamee, John” <john.mcnamee>
To: “NT Developers Interest List”
Sent: Friday, May 16, 2003 11:04 AM
Subject: [ntdev] Re: New driver model?

> I think it’s of the utmost importance that WDF be viewed not as the
> “Windows Drivers for Dummies” but rather as THE NEW DRIVER MODEL.
> If the WDM experts among us dismiss the model as something for
> “those people” who don’t know any better, then the thing is doomed
> from the start.

The impression I got at WinHEC is that Microsoft doesn’t exactly see
DFW as “Windows Drivers for Dummies”, but more like “Windows Drivers
for simple devices”. It isn’t intended to allow Visual Basic weenies
to write kernel code, but to allow systems programmers of average
talent to quickly and easily write correct drivers for simple devices.
Whenever questions came up about limitations in the framework, the
answer was often “continue to use WDM or an existing-miniport model
to do that”. That Microsoft is planning to rewrite core OS drivers
using the framework is news to me; I don’t recall hearing that at
WinHEC. Maybe I missed that sesssion (or it was one the started at
8AM and I slept through it – will somebody please tell me why they
start WinHEC sessions so f#*%:@! early in the morning! How many
systems programmers show up for work at 8AM?).

–John


You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</john.mcnamee>

Mark Thompson wrote:

In one of the DFW sessions, the presenter mentioned the tyranny of the 1%
meaning that the enormous complexity of the current WDM is for the 1% of the
drivers that really need it. All other drivers can be developed using WDF.

This is one of the key points about WDF. It won’t box you in to a narrow
model like NDIS or SCSI does, but it will also give you much of the
boilerplate code that every driver needs.

There’s a fully worked out example of the simplest possible WDF driver
(called STUPID.SYS) to accompany my summary article on WDF at
http://www.wd-3.com. It makes three (!) calls to framework DDI’s, not
counting debug prints. It loads, unloads, disables, enables, and stays
out of the way of power transitions. It takes about 2000 lines of WDM
code to accomplish that without the framework, which is what the speaker
meant when he referred to the “tyranny of the 1%” in older programming
models.

Please note: WD-3 is NONCOMMERCIAL and doesn’t require you to register
to read its content. We get our reward for our volunteer efforts when
you read our stuff.


Walter Oney
Editor in Chief
Windows Driver Developer’s Digest

I haven’t looked at WDF yet – I will soon – but the phrase “request
flow” makes me squirm. Sounds like the narrow confinement of NDIS.


If replying by e-mail, please remove “nospam.” from the address.

James Antognini