Latest recommended tool chain

NTDEV
21

My problem wasn’t rendering them harmless for other tool chains. That just
means when you hand the driver source over to the client they can’t use the
older tools, or if you can they are pretty worthless. Theoretically one
could map SAL2 back to SAL with driver annotations for most SAL2 constructs,
but the work involved is not worth it for a one man shop.

Peter’s comments about my not using the latest tools misses the point, many
of my clients are tiny shops. They try to get the client pinned down, but
if I go basing things on the latest toolset then have to say pay up to go
back, they go under or lose their shirt on the deal. So either I anticipate
this, or I accept that about 1 in 3 contracts I lose money on because my
tiny client could not push the big firm hard enough to get the right answer
and somebody has to eat the cost of the rework.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Tuesday, November 19, 2013 5:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Latest recommended tool chain

On my machine, I have this file from Microsoft. They already ship the exact
include file you need to render you SAL into NOOP macros for other tool
chains

Windows Kits\8.0\Include\shared\no_sal2.h

/***
* no_sal2.h - renders the SAL annotations for documenting APIs
harmless.
*
* Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
* sal.h provides a set of SAL2 annotations to describe how a function
uses its
* parameters - the assumptions it makes about them, and the guarantees

it makes
* upon finishing. This file redefines all those annotation macros to
be harmless.
* It is designed for use in down-level build environments where the
tooling may
* be unhappy with the standard SAL2 macro definitions.
*
* [Public]
*
****/

“Don Burn” wrote in message news:xxxxx@ntdev…

But as you pointed out SAL has changed and unfortunately Microsoft did not
put any effort into compatibility. Whether we like it or not, there is
still a need for drivers for older systems. I am dealing with clients right
now who want drivers that support XP embedded, must support Server 2008 (not
just R2), and the ultimate a query for a driver to support NT 4.0
embedded!!!

Microsoft could have designed the annotations, so the ones that were not
supported could be #defined to be empty on older systems. But the amount of
changes they did, makes this essentially impossible. Then throw in the pain
in moving anything other than the simplest project from SOURCES to VS and we
have the current mess.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 19, 2013 9:22 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

Agreed. I found it annoying, ugly, and of marginal value. But that was
2008.

Take another look at SAL, specifically SAL 2. While it’s still fugly, it is
now *beyond* merely useful. It has become an incredible tool for validating
things like good programming practices and locking requirements.

You really should give SAL a second change. That’s what we’re doing here at
OSR, in any case.

Sounds like a good article for The NT Insider: “A Second Chance for SAL”…

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

22

I’m not missing the point at all… I don’t think.

Then your client has an unsustainable business model. Seriously. “I have a customer that I need to supply something to, but I can’t get them to tell me what it is I’m supposed to give them” is guaranteed to be successful approximately… never.

Even so. Let’s say this IS their business model. Shouldn’t it be up to your client to determine the potential for changing requirements from THEIR customer… not you? Then, you know, when THEIR customer says “we want it on S12” and your client… using THEIR knowledge of THEIR customer (which only THEY really have, not you) can tell you “Don… we want it to work on Windows XP and earlier” – Or, not.

But you’re in no position to substitute your business judgement for that of your client’s, when it comes to your client’s customer’s requirements. How could you be?

Suppose they ask you to write a driver for S12 and then later say “Oh, wait! We need it for BeOS”… should you have anticipated that, too?

Again, with all sincere respect… What you’re saying doesn’t add up. At least not in any world I live in or can imagine living in.

Unless you have a truly enormous or complex project, simply changing from one WDK toolset to another – should that EVER be necessary – can’t be a matter of more than an engineering week’s worth of work. That’s changing and retesting your driver. Even at what OSR charges for one-off casual project work, that wouldn’t bankrupt even the smallest conceivable client.

OTOH, if that amount of money will bankrupt YOUR average client… I would – once again with the utmost respect – suggest you’ve got bigger problems than using the wrong toolset. A client that can’t suck-up that type of unforeseen expense just isn’t very likely to pay your bill. You know, the electric bill is a little higher than anticipated and POOF! They’ve spent your consulting fee…

Sorry, I realize this is off-topic. We shouldn’t be debating this here. It’s just that after running OSR for more than 20 years “I won’t use the new tool set because my client doesn’t know what they want, and if later by chance they discover they need to run my code on a system that requires an older toolset, they won’t be able to pay for me to convert it to the older toolset without going broke” strikes me as a very silly argument.

Peter
OSR

23

It’s nice if you can deal with the biggies, but some of us have to play with
the marginal firms (either financially or skill wise). As you say this has
gone far enough, and I used to use the latest tools, but now I have the
choice of earning a living or spending my time trying to live with
incompatible toolsets. It is ironic because I used to be one of the people
who jumped on the newest tools the day they came out, but the cost (time and
equipment) is such I guess I am now a luddite.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 19, 2013 6:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

I’m not missing the point at all… I don’t think.

[quote]
my tiny client could not push the big firm hard enough to get the right
answer and somebody has to eat the cost of the rework [/quote]

Then your client has an unsustainable business model. Seriously. “I have a
customer that I need to supply something to, but I can’t get them to tell me
what it is I’m supposed to give them” is guaranteed to be successful
approximately… never.

Even so. Let’s say this IS their business model. Shouldn’t it be up to
your client to determine the potential for changing requirements from THEIR
customer… not you? Then, you know, when THEIR customer says “we want it
on S12” and your client… using THEIR knowledge of THEIR customer (which
only THEY really have, not you) can tell you “Don… we want it to work on
Windows XP and earlier” – Or, not.

But you’re in no position to substitute your business judgement for that of
your client’s, when it comes to your client’s customer’s requirements. How
could you be?

Suppose they ask you to write a driver for S12 and then later say “Oh, wait!
We need it for BeOS”… should you have anticipated that, too?

Again, with all sincere respect… What you’re saying doesn’t add up. At
least not in any world I live in or can imagine living in.

Unless you have a truly enormous or complex project, simply changing from
one WDK toolset to another – should that EVER be necessary – can’t be a
matter of more than an engineering week’s worth of work. That’s changing
and retesting your driver. Even at what OSR charges for one-off casual
project work, that wouldn’t bankrupt even the smallest conceivable client.

OTOH, if that amount of money will bankrupt YOUR average client… I would
– once again with the utmost respect – suggest you’ve got bigger problems
than using the wrong toolset. A client that can’t suck-up that type of
unforeseen expense just isn’t very likely to pay your bill. You know, the
electric bill is a little higher than anticipated and POOF! They’ve spent
your consulting fee…

Sorry, I realize this is off-topic. We shouldn’t be debating this here.
It’s just that after running OSR for more than 20 years “I won’t use the new
tool set because my client doesn’t know what they want, and if later by
chance they discover they need to run my code on a system that requires an
older toolset, they won’t be able to pay for me to convert it to the older
toolset without going broke” strikes me as a very silly argument.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

24

Perhaps your perspective is based on the sort of customers who can afford
OSR’s rates?

I have made exactly the same choice as Don has - stick with the Win7 WDK -
for pretty much the same reasons, it is the least risky cost effective
solution for small shop customers. Many of them are very small government
contractors with specialized hardware who are up against hard requirements
to leave XP behind, and they are doing so very reluctantly because what
they have works for them and works for their customers. I’m not going to
foist the burly VS on them and then force them into a two build solution
while their XP business continues to not quite go away.

Mark Roddy

On Tue, Nov 19, 2013 at 6:30 PM, wrote:

> I’m not missing the point at all… I don’t think.
>
>


>
> Then your client has an unsustainable business model. Seriously. “I have
> a customer that I need to supply something to, but I can’t get them to tell
> me what it is I’m supposed to give them” is guaranteed to be successful
> approximately… never.
>
> Even so. Let’s say this IS their business model. Shouldn’t it be up to
> your client to determine the potential for changing requirements from THEIR
> customer… not you? Then, you know, when THEIR customer says “we want it
> on S12” and your client… using THEIR knowledge of THEIR customer (which
> only THEY really have, not you) can tell you “Don… we want it to work on
> Windows XP and earlier” – Or, not.
>
> But you’re in no position to substitute your business judgement for that
> of your client’s, when it comes to your client’s customer’s requirements.
> How could you be?
>
> Suppose they ask you to write a driver for S12 and then later say “Oh,
> wait! We need it for BeOS”… should you have anticipated that, too?
>
>


>
> Again, with all sincere respect… What you’re saying doesn’t add up. At
> least not in any world I live in or can imagine living in.
>
> Unless you have a truly enormous or complex project, simply changing from
> one WDK toolset to another – should that EVER be necessary – can’t be a
> matter of more than an engineering week’s worth of work. That’s changing
> and retesting your driver. Even at what OSR charges for one-off casual
> project work, that wouldn’t bankrupt even the smallest conceivable client.
>
> OTOH, if that amount of money will bankrupt YOUR average client… I would
> – once again with the utmost respect – suggest you’ve got bigger problems
> than using the wrong toolset. A client that can’t suck-up that type of
> unforeseen expense just isn’t very likely to pay your bill. You know, the
> electric bill is a little higher than anticipated and POOF! They’ve spent
> your consulting fee…
>
> Sorry, I realize this is off-topic. We shouldn’t be debating this here.
> It’s just that after running OSR for more than 20 years “I won’t use the
> new tool set because my client doesn’t know what they want, and if later by
> chance they discover they need to run my code on a system that requires an
> older toolset, they won’t be able to pay for me to convert it to the older
> toolset without going broke” strikes me as a very silly argument.
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

25

The largest, meanest, most aggressive predators with the highest energy
requirements sit at the top of the food chain (that is, carnivores are at
the top, and by inclusion, omnivores, and by inclusion, humans). Do I see
similarities?

Ned Ludd was a fictional character invented by those who opposed the
mechanization of cotton mills. The invented character was based on an
incident not related to machines taking over.

From the Smithsonian web site:

Despite their modern reputation, the original Luddites were neither
opposed to technology nor inept at using it. Many were highly skilled
machine operators in the textile industry. Nor was the technology they
attacked particularly new. Moreover, the idea of smashing machines as a
form of industrial protest did not begin or end with them. In truth, the
secret of their enduring reputation depends less on what they did than on
the name under which they did it. You could say they were good at
branding.

Read more:
http://www.smithsonianmag.com/history-archaeology/What-the-Luddites-Really-Fought-Against.html#ixzz2l8mvbUij

Read the article. Ned Ludd (the real character) was about as interesting
as Aunt Tilly, who threw her laptop through the kitchen window. Or Uncle
Fred, who, in a similar rage, destroyed his computer by pulling out his
Glock Nine and shooting the monitor.
joe

It’s nice if you can deal with the biggies, but some of us have to play
with
the marginal firms (either financially or skill wise). As you say this
has
gone far enough, and I used to use the latest tools, but now I have the
choice of earning a living or spending my time trying to live with
incompatible toolsets. It is ironic because I used to be one of the
people
who jumped on the newest tools the day they came out, but the cost (time
and
equipment) is such I guess I am now a luddite.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 19, 2013 6:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

I’m not missing the point at all… I don’t think.

[quote]
my tiny client could not push the big firm hard enough to get the right
answer and somebody has to eat the cost of the rework [/quote]

Then your client has an unsustainable business model. Seriously. “I have
a
customer that I need to supply something to, but I can’t get them to tell
me
what it is I’m supposed to give them” is guaranteed to be successful
approximately… never.

Even so. Let’s say this IS their business model. Shouldn’t it be up to
your client to determine the potential for changing requirements from
THEIR
customer… not you? Then, you know, when THEIR customer says “we want it
on S12” and your client… using THEIR knowledge of THEIR customer (which
only THEY really have, not you) can tell you “Don… we want it to work on
Windows XP and earlier” – Or, not.

But you’re in no position to substitute your business judgement for that
of
your client’s, when it comes to your client’s customer’s requirements.
How
could you be?

Suppose they ask you to write a driver for S12 and then later say “Oh,
wait!
We need it for BeOS”… should you have anticipated that, too?

Again, with all sincere respect… What you’re saying doesn’t add up. At
least not in any world I live in or can imagine living in.

Unless you have a truly enormous or complex project, simply changing from
one WDK toolset to another – should that EVER be necessary – can’t be a
matter of more than an engineering week’s worth of work. That’s changing
and retesting your driver. Even at what OSR charges for one-off casual
project work, that wouldn’t bankrupt even the smallest conceivable client.

OTOH, if that amount of money will bankrupt YOUR average client… I would
– once again with the utmost respect – suggest you’ve got bigger
problems
than using the wrong toolset. A client that can’t suck-up that type of
unforeseen expense just isn’t very likely to pay your bill. You know, the
electric bill is a little higher than anticipated and POOF! They’ve spent
your consulting fee…

Sorry, I realize this is off-topic. We shouldn’t be debating this here.
It’s just that after running OSR for more than 20 years “I won’t use the
new
tool set because my client doesn’t know what they want, and if later by
chance they discover they need to run my code on a system that requires an
older toolset, they won’t be able to pay for me to convert it to the older
toolset without going broke” strikes me as a very silly argument.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

26

Perhaps. After all, what you see IS a function of where you sit. No escaping that. But we certainly have clients of all sizes… from 5 person companies to super large multinationals.

Let me get this straight:
You’re saying when a client tells you “I want a driver that runs on Win7 and later” you write them a driver with Windows XP features and build it in the Win7 WDK’s XP Build Environment… just because they MIGHT PERHAPS someday change their mind and want to run it on XP, even though they say they don’t need to? This is what Don was arguing.

Please. I’m serious. Please help me understand why using an inferior toolset and down-level features best serves you client’s needs, when they tell you specifically that they don’t need an XP solution. I feel like I *must* be missing something key here.

I’m sure you both have good reasons. I’ve read both your replies several times trying to understand what you’re saying.

Of course not. But in this case you’re citing, your client is ASKING you for XP support, right? In THIS CASE, we would do the same thing. We’re presently finishing a project that needs to support S03 SP1 and later. We’re building it entirely in the Win7 WDK (I think we created a VS12 or 13 solution for it once to test it with the latest PFD and SDV… fixed any discovered anomalies and then deleted the solution).

As a matter of practicality, we do not ship solutions with two build environments. Ever. The oldest target system specified by the client dictates the toolset.

So, sure… but this is NOT the case Don’s citing.

Peter
OSR

27

You know, Dr. Joe… when I saw this reply I read all of it. And my immediate thoughts were:

a) Joe has inadvertently posted to the wrong news group/
OR
b) I hope somebody is home with Joe so they can call 911, cuz he’s having a cerebral event.

Then I finally got the Luddite reference. A bit oblique, OK!

At least I felt reassured that you had not taken leave of your senses.

I hope he used hollow-point ammunition.

Peter
OSR

28

>

I hope he used hollow-point ammunition.

… just imagining Uncle Fred wandering into the repair shop…

“You were lucky. If you had used hollow point ammunition the repair would be a lot more expensive!”.

James

29

> Peter’s comments about my not using the latest tools misses the point, many

of my clients are tiny shops. They try to get the client pinned down, but
if I go basing things on the latest toolset then have to say pay up to go
back, they go under or lose their shirt on the deal. So either I anticipate
this, or I accept that about 1 in 3 contracts I lose money on because my
tiny client could not push the big firm hard enough to get the right answer
and somebody has to eat the cost of the rework.

I would not bother writing any SAL in such kind of business, actually.

Product teams are another song.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

30

> Ned Ludd was a fictional character invented by those who opposed the

mechanization of cotton mills.

Cotton? maybe wool?

Cotton became industrial IIRC much later, after Whitney invented his machine, mid 1850-ies.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

31

Although I must admit that my brain is a bit fried from counting all the
leaves that have fallen off our trees, so it might be a consequence of
taking a census of my leaves.
joe

You know, Dr. Joe… when I saw this reply I read all of it. And my
immediate thoughts were:

a) Joe has inadvertently posted to the wrong news group/
OR
b) I hope somebody is home with Joe so they can call 911, cuz he’s having
a cerebral event.

Then I finally got the Luddite reference. A bit oblique, OK!

At least I felt reassured that you had not taken leave of your senses.

I hope he used hollow-point ammunition.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

32

On Tue, Nov 19, 2013 at 11:17 PM, wrote:

> Let me get this straight:
> You’re saying when a client tells you “I want a driver that runs on Win7
> and later” you write them a driver with Windows XP features and build it in
> the Win7 WDK’s XP Build Environment… just because they MIGHT PERHAPS
> someday change their mind and want to run it on XP, even though they say
> they don’t need to? This is what Don was arguing.
>
> Please. I’m serious. Please help me understand why using an inferior
> toolset and down-level features best serves you client’s needs, when they
> tell you specifically that they don’t need an XP solution. I feel like I
> must be missing something key here.
>

Actually yes that is pretty much it. They are all moving to KMDF/Win7 and
have existing XP/WDM projects. It is entirely likely that after evaluating
the KMDF/Win7 implementation they are going want it running on XP. So if I
foist a VS/WDK8 implementation on them they then have to pay me to re-work
that to build for XP. I lay out the options they have, and they see no
value in pinning themselves to the VS implementation and I don’t either.

Mark Roddy

33

I see.

Thanks to both you, Mr. Roddy, and to Mr. Burn for having the patience to educate me as to your views and practices.

We obviously have very different opinions as to the value of the newer toolsets and/or the effort required to move a relatively simple project back to the old toolset in the event that would be required contrary to a client’s previously stated functional requirements.

I sincerely appreciate the education.

Will you indulge me one more question? I promise, the last one…

If the VS-integrated WDK toolset had the ability to quickly and accurately “round trip” projects (convert, on demand, in either direction between sources/dirs and a VS Solution)… would that change your practices/preferences at all?

Peter
OSR

34

I have found the discussion fascinating; thanks! I share many of the
same problems with small clients who often change their mind after the
fact. Flexibility is something I therefore value in the tool chain.

To circle back around to the original qucstion, I’ve decided to go with
the WDK 7.1.0 and VS 2010. And I had to update to Mark’s latest
DDKbuild.cmd. That’s all working now (although I can’t seem to convince
it NOT to build a BSC file–anyone know how to do that?).

The discussion did lead me to wonder what’s new in the DDI in later
Windows version. I had a quick Google-around, but didn’t come up with a
nice simple summary. Does something like that exist? Or do I just need
to spend some quality time crawling through the latest DDK docs?

Cheers,

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

35

Peter,

I’m going to put in my two cents as a reply to your question.

1.) The conversion would need to be utterly reliable converting in either
direction.
2.) The conversion would need to handle more than the trivial one-sources
build tree.

Item two addresses the requirement to convert fairly massive build
environments that rely extensively on documented but less often used
“expert-level” features of the WDK 7 build environment.

The current VS 2013 has trouble converting anything beyond the simplest
cases. I can’t imagine the feasibility of your suggestion.

Of course, one can dream…

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, November 20, 2013 8:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

I see.

Thanks to both you, Mr. Roddy, and to Mr. Burn for having the patience to
educate me as to your views and practices.

We obviously have very different opinions as to the value of the newer
toolsets and/or the effort required to move a relatively simple project back
to the old toolset in the event that would be required contrary to a
client’s previously stated functional requirements.

I sincerely appreciate the education.

Will you indulge me one more question? I promise, the last one…

If the VS-integrated WDK toolset had the ability to quickly and accurately
“round trip” projects (convert, on demand, in either direction between
sources/dirs and a VS Solution)… would that change your
practices/preferences at all?

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

36

Really. Well color me surprised. Again. I can’t remember *ever* encountering this. Not once. Not in hundreds of clients (short example list here http://www.osr.com/clients.html), and in 20 years of business.

So, it’s COMMON for your clients to not know what version of the OS they want a driver to support? Because if it’s not exactly common, in the eventuality that this IS required, isn’t moving a project from VS back to sources/dirs really pretty easy… a couple of days work including testing, all told? And if it’s just a couple of days… who cares really. You could charge them a nominal fee or you could eat it. It doesn’t really matter at that point, right?

Again, I’m asking sincerely. To me, hearing this is like learning in a country far away there’s no gravity. At OSR, we work with clients to determine their functional requirements including the platforms and OS versions they want to support. We try to be thorough during this process. We take that information as given and use it as the basis for our choice of architectural approach and toolset. We treat ANY changes to the project requirements the same way: If it’s relatively small, we eat it, give the results to the client, and say thank you. If it’s significant, we tell the client “You asked us to build Y, you now want both Y and Z… that will be another $X.” They then make a business decision as to whether the change is worth it.

What I’m attempting to understand is:

a) Are we doing our clients a disservice by taking them at their word when they tell us that they want to support Win7 and later… do they wind-up doing the back-port themselves?

b) Are we perhaps just that much better at fleshing out requirements from clients, and therefore what some of you guys see as “client changes their mind” we would have discovered up-front (and therefore ALSO used the down-level toolset)? I hesitate to ascribe special abilities to our team in this way, obviously.

c) Do we tend to value the newer toolset more than many other people… and therefore are more eager to use it?

d) Are the projects we deal with bigger, and therefore we’re more easily able to absorb the cost of a change like this? This can’t be it, though, because I don’t remember ever having a client change their mind as to the OS version they need to support.

d) Do we just deal with different clients, who have different needs?

Thank you for your posting and for your patience in enlightening me, Mr. Jones.

Peter
OSR

37

Peter,

I was going to write a detailed how and why of my business, and why I
am stuck with Win7 WDK. But to answer your question, it does not even need
to be a round-trip. If there was a good tools for converting a project from
Win7 to Win8 or Win8.1 where the tool:

a. Converted the SOURCES to a clean project (the current tools are
failing over 50% of the time).
b. Took SAL1 plus driver extensions and mapped them to SAL2
v. Did this in relatively quick time, i.e. a few minutes or less on
a slow system
d. Did not in any way screw up the Win7 WDK build project

Then I would at least be checking and using the Win8/Win8.1 tool chain
to check things. This was the environment I used for all projects up to the
Visual Studio transition. I would put up with doing the minor tweaks to the
SOURCES files, and using #if around the changes to WPP tracing (not always
supporting WPP on other than the target system) so that I could use the
latest code analysis tools. I am even someone who when the customer insists
they don’t need the driver to work with X64 I still built and tested it for
that environment.

But all the above could be done in a man-hour or two until the VS
transition. At that point I found it takes a man-day to even get a frigging
stable Win8 project without annotations (maybe I am stupind but the
Microsoft documentation and even the NT Insider article fail me fairly often
on getting a VS project that is stable), then I have to schedule days for
annotations. Of course if anything is wrong I now have two parallel
projects with means double the cost for everything.

My market has become primarily FAST and CHEAP. The only way I compete
is I offer quality and a one year warranty, since I am not the least
expensive solution. Typically I am fixed price for less than OSR would take
on doing anything a few years ago, and in many cases less than OSR charged
for a comparable driver 20 years ago! The only way I can do that is because
of things like KMDF and that I have a lot of code I can reuse, but the cost
of living sure has gone up in the last 20 years, and the cost of drivers has
dropped.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, November 20, 2013 8:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

I see.

Thanks to both you, Mr. Roddy, and to Mr. Burn for having the patience to
educate me as to your views and practices.

We obviously have very different opinions as to the value of the newer
toolsets and/or the effort required to move a relatively simple project back
to the old toolset in the event that would be required contrary to a
client’s previously stated functional requirements.

I sincerely appreciate the education.

Will you indulge me one more question? I promise, the last one…

If the VS-integrated WDK toolset had the ability to quickly and accurately
“round trip” projects (convert, on demand, in either direction between
sources/dirs and a VS Solution)… would that change your
practices/preferences at all?

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

38

It’s more a case of them deciding to go one way (“Sure, Windows 7 and
later is fine”), and then later having an opportunity arise that would
require XP support.

In many cases, these are low-volume, specialized things, and often
Windows isn’t even the primary market for them. Sometimes the clients
find me only after the discover (fairly late in the game) that a driver
is necessary, and there’s no easy way to port the Linux version they
already have running.

I also have clients who are very clear on what their target market is
(or who are building a Windows Embedded solution, so they control the
environment totally). But, in the absence of such clear marching
orders, I do tend to err on the oldest environment which can do the job
(which fortunately tends to be XP these days–I haven’t had to deal with
Win2K for several years now).

–mkj

On 11/20/2013 9:32 AM, xxxxx@osr.com wrote:

Really. Well color me surprised. Again. I can’t remember *ever* encountering this. Not once. Not in hundreds of clients (short example list here http://www.osr.com/clients.html), and in 20 years of business.

So, it’s COMMON for your clients to not know what version of the OS they want a driver to support? Because if it’s not exactly common, in the eventuality that this IS required, isn’t moving a project from VS back to sources/dirs really pretty easy… a couple of days work including testing, all told? And if it’s just a couple of days… who cares really. You could charge them a nominal fee or you could eat it. It doesn’t really matter at that point, right?

Again, I’m asking sincerely. To me, hearing this is like learning in a country far away there’s no gravity. At OSR, we work with clients to determine their functional requirements including the platforms and OS versions they want to support. We try to be thorough during this process. We take that information as given and use it as the basis for our choice of architectural approach and toolset. We treat ANY changes to the project requirements the same way: If it’s relatively small, we eat it, give the results to the client, and say thank you. If it’s significant, we tell the client “You asked us to build Y, you now want both Y and Z… that will be another $X.” They then make a business decision as to whether the change is worth it.

What I’m attempting to understand is:

a) Are we doing our clients a disservice by taking them at their word when they tell us that they want to support Win7 and later… do they wind-up doing the back-port themselves?

b) Are we perhaps just that much better at fleshing out requirements from clients, and therefore what some of you guys see as “client changes their mind” we would have discovered up-front (and therefore ALSO used the down-level toolset)? I hesitate to ascribe special abilities to our team in this way, obviously.

c) Do we tend to value the newer toolset more than many other people… and therefore are more eager to use it?

d) Are the projects we deal with bigger, and therefore we’re more easily able to absorb the cost of a change like this? This can’t be it, though, because I don’t remember ever having a client change their mind as to the OS version they need to support.

d) Do we just deal with different clients, who have different needs?

Thank you for your posting and for your patience in enlightening me, Mr. Jones.

Peter
OSR

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

39

Peter,

Typically, my clients are hardware or software firms that are smaller
the OSR in number of employees. They then deal with larger firms, who
because these folks are the little guys they either:

  1. Don’t get the attention of the decision makers when trying to get
    the final specifications

  2. The big firm assumes these guys are desperate enough they can
    change the requirements

In the first case I have had clients who when they got the final signed
contract discovered the big company had changed Win8 only to Windows XP to
“Windows 8 plus all future operating systems for the next three years” Of
course they rejected that so the big firm comes back with Windows XP to
Window 8. Now the little firm has spent months negotiating for the contract
and now is in a rock and a hard place. For number two the big firm says we
won’t pay unless you support these other OS’es if you want to fly to XXX
(typically overseas) and sue us good luck.

It is bad enough that I will not take sub-contracts for the drivers if
the big firm is from most of Asia or India, since I have lost my shirt every
time. If you are dealing with the biggies you may get a decent contract,
though even then I have a client who contracted me at a given rate to
develop a driver, then demanded instead I basically provide consulting in
small increments (ala a retainer) for which I charge typically twice as
much. The best firms are the mid-size ones, but unfortunately as of late
they are failing or getting bought by the biggies.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, November 20, 2013 9:32 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

Really. Well color me surprised. Again. I can’t remember *ever*
encountering this. Not once. Not in hundreds of clients (short example
list here http://www.osr.com/clients.html), and in 20 years of business.

So, it’s COMMON for your clients to not know what version of the OS they
want a driver to support? Because if it’s not exactly common, in the
eventuality that this IS required, isn’t moving a project from VS back to
sources/dirs really pretty easy… a couple of days work including testing,
all told? And if it’s just a couple of days… who cares really. You could
charge them a nominal fee or you could eat it. It doesn’t really matter at
that point, right?

Again, I’m asking sincerely. To me, hearing this is like learning in a
country far away there’s no gravity. At OSR, we work with clients to
determine their functional requirements including the platforms and OS
versions they want to support. We try to be thorough during this process.
We take that information as given and use it as the basis for our choice of
architectural approach and toolset. We treat ANY changes to the project
requirements the same way: If it’s relatively small, we eat it, give the
results to the client, and say thank you. If it’s significant, we tell the
client “You asked us to build Y, you now want both Y and Z… that will be
another $X.” They then make a business decision as to whether the change is
worth it.

What I’m attempting to understand is:

a) Are we doing our clients a disservice by taking them at their word when
they tell us that they want to support Win7 and later… do they wind-up
doing the back-port themselves?

b) Are we perhaps just that much better at fleshing out requirements from
clients, and therefore what some of you guys see as “client changes their
mind” we would have discovered up-front (and therefore ALSO used the
down-level toolset)? I hesitate to ascribe special abilities to our team in
this way, obviously.

c) Do we tend to value the newer toolset more than many other people… and
therefore are more eager to use it?

d) Are the projects we deal with bigger, and therefore we’re more easily
able to absorb the cost of a change like this? This can’t be it, though,
because I don’t remember ever having a client change their mind as to the OS
version they need to support.

d) Do we just deal with different clients, who have different needs?

Thank you for your posting and for your patience in enlightening me, Mr.
Jones.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

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

40

No need, Mr. Burn. I don’t want to burden you with this and I’m certainly not trying to make you justify or explain in detail your practices or observations.

I truly appreciate the time you’ve taken to try to enlighten me.

My befuddlement comes from the fact that… Between classes, consulting assignments, development projects, code reviews, or the whole process of scoping and proposing a project I estimate that I, personally, deal with a few hundred members of the community a year. At least. We talk about driver projects, requirements, Windows architecture, and toolsets. A lot.

And I don’t ever remember hearing “the goalposts moved and I now have to support an older version of Windows.”

That’s why I’m so… gobsmacked… by this concept. And I’m trying to get my head around it, to ensure that in our practice here at OSR we’re providing truly “best in class” services to our clients. Whether that service is teaching (should we go back to teaching people how to use the Win7 WDK?), designing (should we be calling out the differences in toolsets more clearly in our evaluations of options), or development (should we be attaching more weight to using the Win7 toolset in the eventuality that a client needs to move downlevel).

When others see a reality that you don’t, there must be SOMETHING to account for that. And I’m trying to determine what that something is.

So, thanks again (all) for taking the time to elucidate me.

Peter
OSR