VS2013 Driver Package Failure

NTDEV
21

xxxxx@hotmail.com wrote:

Remember that .NET was the ultimate response from Microsoft to Java and that’s why I think XML is so present in .NET.

Unfortunately, that sentence makes no sense whatsoever. .NET and Java
nave nothing to do with XML.

The advantage of XML is that the syntax is very well defined. I don’t
have to learn Yet Another Configuration File Format. Anyone remember
.dsp files? They were hopeless. Comments meant something, nesting was
unclear. XML can at least be predicted and automated.

I just don’t see the fuss. vcxproj files make just as much sense as
complicated gmake makefiles. I have several Python scripts that
manipulate and generate sections of vcxproj files, something that was
not generally possible with earlier ad hoc formats.

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

22

Sorry but undocumented (and yes I* have the MsBuild books) XML is not
something anyone should be expected to edit. By the way the FileToPackage
was the key, but it did cleanup with the GUI, and the suggested changes made
things worse.

If people believe having to know a “magic keyword” then root around in
working projects to figure how to move it into their project, is good
programming practice and documentation, I recommend you seriously ask
yourself if you should be in this industry. Yes we have all done this type
of stuff, but having been a tools and compiler guy expecting this as a
solution for a customer, is unprofessional.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, October 15, 2014 12:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] VS2013 Driver Package Failure

Don Burn wrote:

No they did not. The reason they are talking about reverting is the
perceived fragility of the environment. You sneeze around the properties
and nothing works any more. Their attitude is give them something that
can
easily track the changes (forget that with project and solution
files), and easily can be rolled back to a working version.

I disagree. I now treat the project and solution files like makefiles on
steroids. I edit them all by hand. I almost never enter the IDE, and when
I do I don’t make project file changes.

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

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

23

Nmake/build.exe/sources suffered from the same magic keyword syndrome you just described.every build system has them.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, October 15, 2014 9:29 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] VS2013 Driver Package Failure

Sorry but undocumented (and yes I* have the MsBuild books) XML is not something anyone should be expected to edit. By the way the FileToPackage was the key, but it did cleanup with the GUI, and the suggested changes made things worse.

If people believe having to know a “magic keyword” then root around in working projects to figure how to move it into their project, is good programming practice and documentation, I recommend you seriously ask yourself if you should be in this industry. Yes we have all done this type of stuff, but having been a tools and compiler guy expecting this as a solution for a customer, is unprofessional.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, October 15, 2014 12:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] VS2013 Driver Package Failure

Don Burn wrote:

No they did not. The reason they are talking about reverting is the
perceived fragility of the environment. You sneeze around the properties
and nothing works any more. Their attitude is give them something that
can
easily track the changes (forget that with project and solution
files), and easily can be rolled back to a working version.

I disagree. I now treat the project and solution files like makefiles on
steroids. I edit them all by hand. I almost never enter the IDE, and when
I do I don’t make project file changes.

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

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

24

Don Burn wrote:

Sorry but undocumented (and yes I* have the MsBuild books) XML is not
something anyone should be expected to edit.

Well, all I can say is that you’re wrong. The format is different from
a makefile, and the things are spelled differently, but the same
capabilities are all present, plus a lot more. Most of the “magic
keywords” are spelled out (with comments, even!) in the files that get
included from “C:\Program Files (x86)\MSBuild”. Rooting around in those
files is no different from rooting around in \DDK\7600\bin\makefile.new,
and we’ve ALL certainly done that to get the final answer on an
old-style build question.

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

25

Tim the difference is that there was one makefile.new and if you followed
good practice it never was touched (maybe read but not touched). Now we
have a file for each project, and there is the wonderful GUI that will
change things in ways most people don’t understand (for instance my customer
was not even aware till I told them that the project file was XML, but they
had through properties somehow messed up the project). So by the new rules
of your logic, anyone building a driver in the years from NT 3.1 to Window 7
had better understand every nuance of makefile.new? Sorry most people did
not even know what that file was.

Doron the difference between the magic keywords of SOURCES was the
common ones were documented and most sources only had those. I worked a
number of years doing Windows drivers before I ever ducked under the hood to
look at the makefile,new stuff. This is the third client I know of in less
than a year that accidently made their project non-functional, while using
the GUI and thinking they were doing something that would not even impact
the area they ultimately broke.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, October 15, 2014 12:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] VS2013 Driver Package Failure

Don Burn wrote:

Sorry but undocumented (and yes I* have the MsBuild books) XML is not
something anyone should be expected to edit.

Well, all I can say is that you’re wrong. The format is different from a
makefile, and the things are spelled differently, but the same capabilities
are all present, plus a lot more. Most of the “magic keywords” are spelled
out (with comments, even!) in the files that get included from “C:\Program
Files (x86)\MSBuild”. Rooting around in those files is no different from
rooting around in \DDK\7600\bin\makefile.new, and we’ve ALL certainly done
that to get the final answer on an old-style build question.

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

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

Tim Roberts wrote:

Unfortunately, that sentence makes no sense whatsoever. .NET and Java nave nothing to do with XML.

Well, the only things that make no sense is your spelling and interpretation. I was talking about the context in the industry at that time and nothing more.

Now XML is an industry-wide adopted standard and that is a good thing. Standardization is better whenever possible and Microsoft made the right move when the XML standard was chosen.

And what about Java Ant ? Isn’t Java Ant a build system for java projects using XML makefiles ? It is very similar to the MSBUILD system.

27

Ntdevgeek wrote:

“Now XML is an industry-wide adopted standard and that is a good thing.
Standardization is better whenever possible and Microsoft made the right
move when the XML standard was chosen.”

Yes XML is a standard, but not a very good one. The reason most compiler
people I know dislike XML is that for most computer language standards work
the syntax takes less than 1% of the work, and the semantics takes the rest.
Unfortunately, XML is only a standard for syntax and is missing the other
99+%.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

28

On 10/15/2014 5:21 PM, Don Burn wrote:

Yes XML is a standard, but not a very good one. The reason most compiler
people I know dislike XML is that for most computer language standards work
the syntax takes less than 1% of the work, and the semantics takes the rest.
Unfortunately, XML is only a standard for syntax and is missing the other
99+%.

People I know prefer build systems like Scons over XML, because you can
write any Python code you want. I dislike it for the same reason - it
becomes difficult to understand any particular project because each one
has a library of code you need to understand first.

–
Bruce

29

I would like to add that editing a project file is not “undocumented” provided that you know what you are doing and that you take necessary preliminary steps to avoid disasters like backing up.

How to: Edit Project Files (MSDN)

http://msdn.microsoft.com/en-us/library/ms171487(v=vs.90).aspx

30

Never said editing the project file was undocumented, what is undocumented
is a large number of the XML tags in a driver project file. I will also
point out that editing one or more XML files is a little more daunting to
most folks than editing some sources files, consider that the toaster kmdf
driver in Win8.1 is described by 165KB of .vcxproj files, and that in Win7
3KB of SOURCES files. Don’t know about you but my customers find between
the size and the lack of documentation on the tags, that editing project
files can be a scary place.

Finally, I kept asking and no one could tell me how from the properties
dialog you could completely mess up the FilesToPackage area. For that
matter the comment about undocumented tags, try finding documentation on
FilesToPackage, not in the MsBuild books, and not found by Bing or Google
(except your post of earlier today). So we have a fragile tool since if you
use the GUI and mess up it easy to break things, at which point your only
choice is to wander into undocumented parts of project files to fix it.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, October 15, 2014 7:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] VS2013 Driver Package Failure

I would like to add that editing a project file is not “undocumented”
provided that you know what you are doing and that you take necessary
preliminary steps to avoid disasters like backing up.

How to: Edit Project Files (MSDN)

http://msdn.microsoft.com/en-us/library/ms171487(v=vs.90).aspx

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

31

The VS templates for drivers are defined in a group of XML files
located in the following (default) directory:

C:\Program Files (x86)\Windows Kits\8.1\build

There is an even worst case of property you shoud not touch with the GUI, it is:

Project’s Properties -> Configuration Properties -> Driver Model Settings -> Override Target Version Defines

This is a boolean property used to define
the values of _WIN32_WINNT, WINVER, WINNT and NTDDI_VERSION.

If you set this property to true and save
the project’s settings, the project won’t load again
and you won’t be able to edit any source file from the GUI.

32

xxxxx@hotmail.com wrote:

Tim Roberts wrote:
> Unfortunately, that sentence makes no sense whatsoever. .NET and Java nave nothing to do with XML.
Well, the only things that make no sense is your spelling and interpretation. I was talking about the context in the industry at that time and nothing more.

We don’t really need to get into a war of words here, but that’s not
what you said. Your statement concluded that there was a direct cause
and effect. Here’s your comment

Remember that .NET was the ultimate response from Microsoft to Java and that’s why I think XML is so present in .NET

I certainly agree that .NET was a response to Java (or, more accurately,
the restrictions that prevented Microsoft from “improving” Java), but
the conclusion that this is the reason XML is now part of Visual Studio
is unsupportable.

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

33

Don Burn wrote:

Yes XML is a standard, but not a very good one.

That’s simply too general of an assertion. XML is a fabulous solution
for storing data in a platform-independent way. By defining an XSD
schema (which is also well-standardized), I can describe the meaning of
and validation for every field in my XML files. It’s like a type-safe
version of JSON. I can export a complete SQL database into XML, and
retain every aspect and nuance of the original data, so that it can be
imported into some other kind of data store using an entirely different
operating system. I can, using automated tools, validate the XML
against my schema and know before starting whether the file has been
damaged. I don’t know of any alternatives that can do all of that.

The trouble with XML is that it gets used in cases where other solutions
would have been cheaper and easier. For many application configuration
needs, the old INI file is still a great solution.

Project configurations are complicated. You have to work with lists of
things, large sets of options, conditional alternatives, string
manipulation, etc. On can imagine developing a task-specific computer
language for that, but I’m not sure it would have been any better than
the XML solution. Have you ever tried to wade through a project in
Eclipse? Give me a vcxproj file any day.

The reason most compiler
people I know dislike XML is that for most computer language standards work
the syntax takes less than 1% of the work, and the semantics takes the rest.
Unfortunately, XML is only a standard for syntax and is missing the other
99+%.

As it should be. If you need semantics, you supply an XSD (which, since
it is also an XML document, can be parsed using the same tools).

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

34

>so present in .NET. MSBUILD.EXE is very powerful

Yes, though incompatible - even ideologically - with other modern project building tools (like CMake).

and a driver writer MUST learn how to write MSBUILD project flles.

Yes.

And do this without the help of property editors in the IDE, whose only strong point is in attracting children :slight_smile: if you need to do LOTS of work with some properties and not-so-trivial cases, then editing text directly is a much better option.

XML is evil only due to overly complex syntax which by far exceeds the requirements of most tasks like config file authoring.

INI files, or most UNIX config files, as also classic makefiles, are by far better for such tasks.

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

35

> I certainly agree that .NET was a response to Java (or, more accurately,

the restrictions that prevented Microsoft from “improving” Java),

No need in quotes here, Tim.

MS actually and really improved Java in 1990ies, and had the world’s best (most usable, fastest etc) Java toolchain.

Surely p/Invoke and VB’s “Declare Function foo Lib bar.dll” are sharp knives, but they have their uses and adding this stuff to Java (which is what MS did and what caused a lawsuit) is not evil at all.

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

36

> People I know prefer build systems like Scons over XML, because you can

write any Python code you want.

Exactly.

The current trend in build systems is using imperative approach, not declarative.

CMake has its own set of drawbacks, mostly due to being a pathetic imperative language, but it also has strong points too (like portability).

CMake-like stuff based on Python would be even greater.

And, with MSBuild, you need to author DLLs and classes to add imperativity instead of just writing a tiny code snippet.

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

37

Instead of writing a DLL or class, just write a task with inline C# code.

–
Bruce

On Oct 16, 2014, at 1:52 PM, Maxim S. Shatskih wrote:

>> People I know prefer build systems like Scons over XML, because you can
>> write any Python code you want.
>
> Exactly.
>
> The current trend in build systems is using imperative approach, not declarative.
>
> CMake has its own set of drawbacks, mostly due to being a pathetic imperative language, but it also has strong points too (like portability).
>
> CMake-like stuff based on Python would be even greater.
>
> And, with MSBuild, you need to author DLLs and classes to add imperativity instead of just writing a tiny code snippet.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.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

38

Correction:

The binary’s path produced by a typical KMDF project is set
in the variable named $(TargetPath). On a brand new KMDF
project there are only two entries to be packaged:

$(TargetPath)
@(Inf->‘%(CopyOutput)’)

This is the best way to restore the project to it’s initial state
if no addintional entries has been added to the list of packaged
files.

39

Like Bruce said, MSBuild supports inline tasks.

See http://msdn.microsoft.com/en-us/library/dd722601.aspx for info on the builtin inline languages support or http://blogs.msdn.com/b/visualstudio/archive/2010/02/20/msbuild-task-factories-guest-starring-windows-powershell.aspx if you want to add your own task factory to support whatever language inline you want, like powershell in the referenced example.

I recommend reading the book “MSBuild trickery”.

Jan

On Oct 16, 2014, at 6:35 PM, Bruce Cran > wrote:

Instead of writing a DLL or class, just write a task with inline C# code.

–
Bruce

On Oct 16, 2014, at 1:52 PM, Maxim S. Shatskih > wrote:

People I know prefer build systems like Scons over XML, because you can
write any Python code you want.

Exactly.

The current trend in build systems is using imperative approach, not declarative.

CMake has its own set of drawbacks, mostly due to being a pathetic imperative language, but it also has strong points too (like portability).

CMake-like stuff based on Python would be even greater.

And, with MSBuild, you need to author DLLs and classes to add imperativity instead of just writing a tiny code snippet.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.commailto:xxxxx
http://www.storagecraft.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</mailto:xxxxx>

40

On Oct 16, 2014, at 10:01 PM, Jan Bottorff > wrote:

I recommend reading the book ?MSBuild trickery?.

For what it?s worth, i recommend it as well. It really does a great job of introducing the concepts in a progressive way.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>