Latest recommended tool chain

NTDEV
41

AH… I think I’m starting to understand, thanks to Don’s patient tutorial.

Let’s say… an IHV gets pushed-around by their OEM. They try to mitigate the impact of this by pushing the problem onto you. You can’t, for a variety of reasons, either absorb the cost of the change (you’re already working on slim margins) or tell them politely, “change in scope means change in price” (you risk not getting paid at all or, at best you have major hassles which you’ll have to fight… which means while you’re off fighting you’re not writing code and making money).

So… the way you guard against having to absorb the cost of this change is by maintaining the maximum flexibility in the toolset you use. Use the Win7 toolset, get every OS version that anybody uses within reason. Use the Win8.1 toolset, limit your options… and potentially expose yourself to financia/time/annoyance risk of having to convert the project. Given this calculus, and the fact that such changes happen regularly, the Win8.1 toolset is a non-starter.

I think I’m starting to understand the situation better.

Thank you again. As I’ve repeatedly said, this is just a situation we’ve not ever encountered. I now suspect the reason for this is due to a combination of factors including client mix, pricing, the overall way we approach projects, and having a dedicated staff to handle business development (both initial contract specification/negotiation, and working through the types of issues that inevitably occur in any such endeavor).

Peter
OSR

42

Peter,

I think a lot of this is that the firms I deal with want drivers for
less than it costs to send one developer to an OSR class out of town.
Part of the problem is the bigger firm (still smaller than most OSR
customers I’ve known of) have gotten quotes for drivers from offshore firms
that are idiotic. Of course the offshore firm says we will do it for X/hour
but trust us it is only a few hours, the latest I saw was a claim for a file
system filter driver I would not touch without OSR data modification kit,
and the offshore quote was for less than you can buy any new car in the US!

So in one sense I am living in a totally different driver economy than
OSR, the people who go to OSR classes, or go to a conference. Yes I do
cross over, but mostly I am putting together a string of small jobs that
together pay the bills (most years). The other case OSR does not see are
the folks who are large who need to support environments that Microsoft has
claimed are dead years ago. I am probably one of the few people who has
ever run PreFast on multiple NT4.0 drivers to check them, and yes I still
have everything I need to build for NT 4.0 since I have clients in the
medical and telecomm fields who find in some places in the world it is
cheaper to use NT 4.0 Embedded than to try to get certification for their
device with XP embedded! In these cases they don’t have driver developers
themselves and basically I and others do the work, and get panic calls if
something fails (which is why they pay me because I have a good track record
for them).

It has been years since I have had a contract with the luxury of just
using the newest tools. I love those contracts, but the reality is for many
of us quite different. In the last 2 years only one firm wanted Windows 8
as the primary target and I turned them down since they really needed a good
user space person not kernel work.

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:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latest recommended tool chain

[quote]
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 [/quote]

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

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

43

On Wed, Nov 20, 2013 at 9:52 AM, wrote:

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

I tried to explain what actually happens and I failed, obviously. The
customer has a functional WDM XP implementation. The customer needs a
functional KMDF Win7 implementation. The customer may OPTIONALLY DESIRE
to apply the KMDF Win7 implementation to XP.

Mark Roddy

44

Before this thread dies completely to go back to closer to the original
topic. If Microsoft provided a tool(s) that would handle the conversion
from Win7 to VS based environments including SAL and projects, that worked
reliably I would check my efforts with the VS tools for all projects. If
Microsoft provided a tool(s) that would allow downgrade to Win7 based WDK
projects, I would move all my development to current WDK.

It is interesting that back when we had DDC’s and Microsoft solicited input
from developers, I had some long discussions with the guys then tasked to
support a VS based WDK. All the developers repeatedly said, that the one
clear message they heard was the requirement to upgrade/downgrade between
SOURCES based WDK’s to VS based WDK’s. Somewhere in the intervening years
that requirement was dropped.

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

45

Practically speaking…As Peter mentioned we currently have a project that
requires Server 2003 through Server 2008 R2. The code includes a KMDF
driver, a user mode DLL, and two user mode applications. All code is written
to build in the Win7 WDK and thus uses SAL v1 annotations.

I’m religious about using the new Code Analysis and SDV, so about once a
week I “check in” with the new build tools. Being a fairly straightforward
project, the SOURCES converter in Visual Studio almost does a perfect
conversion (it misses an include path in one application for some reason and
doesn’t properly set a dependency of the other app on the DLL). I wouldn’t
*ship* these project files, but it was enough to get me to the new
environment within about 10 minutes. From there, SAL v1 is still supported
in VS2013 so I get the benefits of Code Analysis in addition to SDV.

If you have a larger project and the automated conversion isn’t applicable,
the conversion can be more time consuming of course. However, once you’re
done you get to periodically run the driver through the new Code Analysis
and SDV. This doesn’t mean you have to *ship* (or even run) the resulting
binaries of course, just continue to use the Win 7 environment for your real
development and testing.

This then becomes a judgment call: once your build files are stable, is the
one time pain of doing a conversion *just* to get the new tools (i.e. not to
*ship* with) not worth it? I think it’s completely worth it (and about as
painful as what you have to do to get, say, Lint running on your driver),
but maybe I’m a bit biased as we’ve had the time to play with this for a
while and I’ve found a few real bugs in doing this.

-scott
OSR

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

Before this thread dies completely to go back to closer to the original
topic. If Microsoft provided a tool(s) that would handle the conversion
from Win7 to VS based environments including SAL and projects, that worked
reliably I would check my efforts with the VS tools for all projects. If
Microsoft provided a tool(s) that would allow downgrade to Win7 based WDK
projects, I would move all my development to current WDK.

It is interesting that back when we had DDC’s and Microsoft solicited input
from developers, I had some long discussions with the guys then tasked to
support a VS based WDK. All the developers repeatedly said, that the one
clear message they heard was the requirement to upgrade/downgrade between
SOURCES based WDK’s to VS based WDK’s. Somewhere in the intervening years
that requirement was dropped.

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

46

Scott,

My experience with the SOURCES converter has not been good. Note: even
taking just slightly modified versions of Win7 samples (for instance
changing the name of the driver) has yielded misery in getting a working
project. And my luck with doing it from scratch is about as bad.

For almost anything I ship, I have a makefile.inc stuff so that I
produce a directory that can be copied to install media and will work.
Things like that drive the conversion tool nuts, including having it crash
multiple times on my system.

This may be because I have so little demand for the VS based
environment, but my success rate with getting projects to build at all is
abysmal (unless I am taking a standard sample from Microsodt, and not trying
to really change it). I’ve read the NT Insider article on using the
environment and the Microsoft doc’s multiple times, and I still fail more
often than not on getting a useable project. Even when I get a project that
builds, it seems fairly often I get a bizarre failure on trying to start
(not run) the code analysis tools on a project I created. At some point you
just say to heck with it, and go back to making a living. I am the tools
fanatic, I do spend the time to make Lint work and clean up most Lint
complaint before shipping a driver, but I find the VS environment has a
barrier that for me is still very high.

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 Scott Noone
Sent: Wednesday, November 20, 2013 11:54 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Latest recommended tool chain

Practically speaking…As Peter mentioned we currently have a project that
requires Server 2003 through Server 2008 R2. The code includes a KMDF
driver, a user mode DLL, and two user mode applications. All code is written
to build in the Win7 WDK and thus uses SAL v1 annotations.

I’m religious about using the new Code Analysis and SDV, so about once a
week I “check in” with the new build tools. Being a fairly straightforward
project, the SOURCES converter in Visual Studio almost does a perfect
conversion (it misses an include path in one application for some reason and
doesn’t properly set a dependency of the other app on the DLL). I wouldn’t
*ship* these project files, but it was enough to get me to the new
environment within about 10 minutes. From there, SAL v1 is still supported
in VS2013 so I get the benefits of Code Analysis in addition to SDV.

If you have a larger project and the automated conversion isn’t applicable,
the conversion can be more time consuming of course. However, once you’re
done you get to periodically run the driver through the new Code Analysis
and SDV. This doesn’t mean you have to *ship* (or even run) the resulting
binaries of course, just continue to use the Win 7 environment for your real
development and testing.

This then becomes a judgment call: once your build files are stable, is the
one time pain of doing a conversion *just* to get the new tools (i.e. not to
*ship* with) not worth it? I think it’s completely worth it (and about as
painful as what you have to do to get, say, Lint running on your driver),
but maybe I’m a bit biased as we’ve had the time to play with this for a
while and I’ve found a few real bugs in doing this.

-scott
OSR

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

Before this thread dies completely to go back to closer to the original
topic. If Microsoft provided a tool(s) that would handle the conversion
from Win7 to VS based environments including SAL and projects, that worked
reliably I would check my efforts with the VS tools for all projects. If
Microsoft provided a tool(s) that would allow downgrade to Win7 based WDK
projects, I would move all my development to current WDK.

It is interesting that back when we had DDC’s and Microsoft solicited input
from developers, I had some long discussions with the guys then tasked to
support a VS based WDK. All the developers repeatedly said, that the one
clear message they heard was the requirement to upgrade/downgrade between
SOURCES based WDK’s to VS based WDK’s. Somewhere in the intervening years
that requirement was dropped.

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

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

47

Clear now. Thank you again.

Peter
OSR

48

xxxxx@osr.com wrote:

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 have resisted the urge to jump in on this thread, because I’ve come to
recognize that some of my development practices are based more on
superstition than strict technical rigor, but I can’t stop myself.

Through my two score years in the computer programming world, I
apparently have developed a severe case of “upgrade mistrust”. There
have been way too many instances when I jumped with both feet into some
new technology, only to learn that the Brave New World was perhaps not
as rosy as it looked from the outside. I am now especially jumpy when
there is churn in my toolsets. I need to TRUST my toolset absolutely.
That trust only comes through personal experience, and observing the
personal experiences of others.

As a result, I now wait, sometimes for a long time. That’s the reason
why I only moved my principle development computer off of Windows XP a
couple of months ago (kicking and screaming), and even then I installed
Win 7. XP worked, and worked reliably. What’s the incentive to churn
things? Glassy windows? Please. I expect it will be another 6 years
before I move to Windows 8.

I didn’t migrate any of my projects to Visual Studio 2010 until 2012. I
haven’t migrated anything to VS2012, except for driver projects that
require Win 8 features. I haven’t even installed VS2013 yet.

I participate in a forum for VC++ MVPs. I see those folks champing at
the bit for new bits straight out of the oven, before they’ve even
cooled yet, and I see the VC team doing its level best to satisfy that
addiction. I just don’t get it. How can you get work done, when you’re
spending your time figuring out where all of your buttons and menu
options have gone, always wondering whether some new warning or crash
might be due to features or fixes that were rushed to market a bit too
early?

I don’t want to think of myself as a Luddite, but as I get older, I
certainly seem to be migrating in that direction.

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

49

It isn’t restricted to drivers. Years ago, I had clients who contracted
for an app for Windows NT 4.0, then became irate when it wouldn’t work on
Win95. They demanded changes, at no cost to them, and I pointed out the
contract that explicitly said “Windows NT 4.0” and told them that if they
wanted it to run on Win95, I’d be more than happy to give them a quote and
schedule. But since I’d delivered their project and they’d signed off on
it, I now had another client and would not be able to do the work for at
least six months. Or, I could, with sufficient financial incentive, like
2x my usual fee, I could do the work on weekends.

Some paid, some did not.

Similarly, my contract states that “Work will be done using description> unless otherwise requested by the client. Use of older
versions of the tools is not recommended, and the use of older tooling may
incur surcharges, which must be separately negotiated and are not included
in this quote. The delivered software is guaranteed to compile and
operate correctly only in the tool set in which it was developed.”

I’ve had clients take VS2008 projects and tried to compile them n VS6 (by
modern naming, that would be VS1998), or something done in VS2005 and
compile it in VS2008, whose error checking was more extreme, and which had
different prototypes in windows.h for the MFC-generated functions (usually
to guarantee Win64 compatibility

Years of bad experiences similar to the current discussion taught me to be
very specific. Change your mind and be prepared to pay for that.

joe

>


>
> 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
>
> —
> 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
>

50

For us, it’s simple: The updates to Prefast (Code Analysis) and SDV make it worth it. To us.

PLUS, I have yet to encounter a non-driver developer client who doesn’t think “Install the free WDK add-in to the latest version of VS and build your project” isn’t easier than “Install the WDK, open the correct build environment window, CD to the directory with your sources file, and type bcz”.

Peter
OSR

51

So what is the problem here? They have a working solution targeted at an older OS, okay. They are implementing a new solution targeted at a newer OS, okay. Should not the solution targeted at the newer OS use newer tools that support the newer OS? After all, they already have a binary for the older OS; and if they need the new code to work on the older OS, then an option for down level compilation via a header that can be locally included seems totally reasonable to me.

Of course I have spent most of my day attempting to convince certain people that they shouldn’t break our software to ‘fix’ our software with marginal results, so I may not be the best judge

“Mark Roddy” wrote in message news:xxxxx@ntdev…

On Wed, Nov 20, 2013 at 9:52 AM, wrote:

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

I tried to explain what actually happens and I failed, obviously. The customer has a functional WDM XP implementation. The customer needs a functional KMDF Win7 implementation. The customer may OPTIONALLY DESIRE to apply the KMDF Win7 implementation to XP.

Mark Roddy

52

> I think I’m starting to understand the situation better.

Absolutely.

To avoid all these business (and sometimes legal) issues, you’ve better support all popular OS versions by default for all customers, even if the customer says “Win7 only”.

I can sacrifice all bells and whistles of new VS-based builds in favor of lack of such issues. And, since we are the product company, we cannot drop XP (I regret this, but let’s face the reality) - and thus WDK 7.x rules. No VS-based builds. A waste of dev time.

BTW, with Linux, the picture is the same. Customers want from RHEL to Ubuntu, and these ones are like 0.3 kernel versions aside - RHEL (and Centos) is very conservative, while Ubuntu uses the latest.

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

53

>In addition, the fact that VS project files are not compatible across VS
releases is an endless annoyance.

Nor are they reasonably diff’able/merge’able, unless you happen to think in
UUID’s.

I guess that’s really more of SLN thing though.

I could have developers using VS2013 or VS2012 as they prefer, and our
build system using VS2012 except of course the project files are in source
code control and >don’t work across VS versions

Just to do my part to make this thread spiral even further: CMake does a
pretty nice job of handling this problem. Like all build systems/build
system generation tools, if of course sucks in its own way.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, November 18, 2013 2:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Latest recommended tool chain

Also note that WDK 8.1 drops Vista era support. Seems to be a pattern
developing. It is difficult to adopt new tools when they keep dropping
support for assorted platforms. In addition, the fact that VS project files
are not compatible across VS releases is an endless annoyance. I could have
developers using VS2013 or VS2012 as they prefer, and our build system using
VS2012 except of course the project files are in source code control and
don’t work across VS versions, and it seems I can never let go of the Win7
WDK because VS keeps dropping support for prior releases of Windows.

They should stop doing that. Add support for new windows releases, stop
dropping support for old ones. Keep compatibility across VS releases for
project files.

Mark Roddy

On Mon, Nov 18, 2013 at 4:30 PM, Doron Holan
wrote:

If you want to support XP, the win7 WDK is the last one to do so and that is
what you should use. It contains its own tool chain, don’t use the VS
compilers. You can still use ddkbuild.cmd to invoke the wdk build
environment. Honestyl it doesn’t matter which version of VS you d0 that
from.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Monday, November 18, 2013 1:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Latest recommended tool chain

Some years ago I did a driver for a client for an embedded board. It was
32-bit only (they were not interested in 64-bit Windows at the time), and
had an existing user-mode API (implemented by a DLL which applications used
to access the hardware functionality).

I did it as a KMDF driver, using the 6001.18002 DDK, and Mark Roddy’s
DDKbuild.cmd from a Visual Studio 2005 project to build it.

Now they want a 64-bit version, and I’m going to tweak the driver’s IOCTL
interface to be 64-bit friendly (all changes which I hope to contain in the
interface DLL, so the applications don’t have to change).

My question is what tool chain folks would recommend. Specifically:

Which DDK should I be using? I have to support from XP up (mainly XP and
Windows 7, but I imagine their customers will be using Win8 at some point).
Both 32- and 64-bit versions (x86 and x64 only–luckily not Itannic).

I’ve got VS 2005, 2008, and 2010 currently installed. I am an MSDN
subscriber, so I also have access to VS 2012 and 2013. Which one should I
be using, given that I need to build both a driver and an interface DLL?

Should I stick with DDKbuild.cmd for the driver? If I understand correctly,
VS 2012/2013 has support for driver projects, but not for XP.
I assume I can upgrade my driver project (which is a makefile project
using DDKbuild) to 2012/2013.

All recommendations/caveats welcome.

TIA,

– mkj

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

—
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

— 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