Approaches for converting DIRS/SOURCES projects to WDK 8+

[Maxim_S_Shatskih]

> Do people in the 21st century really want to study and hand edit incredibly complex project files that

are miles long?

The answer is “yes”, if the people are real professionals, and not amateurish children writing some small smartphone applets consisting 5-10 source files each.

Visual Studio is exactly fine for this kind of projects. It is also fine for C#, but C#, being a by far simpler language (if you do not create your own generics) operating in a specially crafted simple environment, does not require and build scripts except a couple of global compiler options and the referenced assemblies list.

In open source world, there is no Visual Studio (though there are good comparable code text editors). They live with GNU make and CMake, and produce good software (there are exceptions, but OSS is generally good and even the mentioned exceptions are not such due to build scripts).

Makefiles are NOT incredibly complex, and are NOT miles long.

And SOURCES is even a simplified version of makefile, containing what is enough for 90% of cases.

Now look at MSVC’s project files. First there were .DSP files, which have their own arcane syntax by far not simpler then a makefile.

Then there was XML. Contrary to popular belief XML is not human readable. Old-style description languages like the makefile’s one are by far better.

And, as about the project management GUI in MSVC - good luck comparing what have changed in the build script (a mandatory task for a serious team work) since the last commit using this toy. It’s just incapable of this.

It would be going back to the days before WYSIWYG

WYSIWYG for project/build scripts is just an evil pathetic toy.

where you had to create documents using a markup language.

Documents are not build scripts. The final purpose of any document is to create a paper-style image, if not even being physically printed. For making images, WYSIWYG is good.

The final purpose of the build script is NOT to become an image. It’s purpose is to define actions. How WYSIWIG helps with this (aside of improving the learning curve for the very newbies)? drawing actions on the screen by diamond-style shapes? Funny and childish.

Also note that the world scientific community still use TeX (a 1970ies invention, which was already old and venerable in around 1992) which is exactly “create documents using a markup language”.

Why? Because it is the best way to type complex math formulas to the computer.

MS’s WYSIWYG Equation Editor in Word just plain sucks compared to TeX in terms of usability (too many mouse clicks and hovering to do), and also, being implemented as an embedded OLE object, does not allow the simple stuff of “please resize all formulas in this document”.

Surely typing “\sub” is simpler then a) choosing one of the toolbox icons and hitting it and them b) moving the mouse to the new appeared rectangle below the main formula to move the focus there. If you do this 100 times - the difference is very serious.

> With THIS bad issues on build management, and with debugger which is a
> pretty toy compared to WinDbg

Using both on a daily basis it is clear as day the VS debugger is miles ahead of the joke windbg.

Can you dump a structure list in VS’s debugger? without doing lots of mouse clicks on these tiny plus signs in the tree (remember you need to target the mouse at them)?

I remember when I once complained you couldn’t do something as simple as hover the mouse

Who cares about hovering a mouse? well, really, who cares? I’m too lazy to do this. This requires a) scrolling then b) targeting. Too clumsy.

Typing “dv” is simpler in terms of hand/finger movements then targeting the variable name (and scrolling the code to find it) by mouse.

Command line rules. I can tell you - I forgot the last time I had a source file in WinDbg open. Command window is enough for me

Actually, nearly the only 2 debugging techniques I now use, after 20 years of SD experience, is a) adding a temporary printf()/KdPrint() etc, small rebuild and re-run and b) WinDbg’s Command window. And I know lots of people from the other, i.e. Linux, ecosystem, which use “gdb” the same way (it is more or less a Linux analog of WinDbg, too bad that all commands are typed differently).

I use WinDbg for user mode too a lot, and, after I mastered it in like 1999 (yes, the old buggy version, the good WinDbg only appeared in 2001 I think) - I was just amazed on how pathetic is the MSVC’s debugger. Pathetic exactly because mouse-driven OO GUI is worse for this purpose then the command line.

Remember: hovering the mouse is impractical and evil The only real thing about the GUIs is that they have a selp-describing power (and even this can be spoiled by using wrong icon for a button). Well, the second thing about the GUI is file picking dialog boxes - typing pathnames is bothering, though auto-completion helps a lot.

For the professional tool with which person works a lot - command line is superior.

possibly work in the kernel, pffft. The misguided bias towards a completely inferior product is

Looks like you’re considering childish product superior and serious products - inferior.

Yes, there are such people, I know. They are often also obsessed by “modernity” and sometimes use the clumsy toyish new stuff in place of the well-done, years-old, venerable old stuff which is still alive for 30 years (and will be alive, like a simple wrench is still alive).

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

[Maxim_S_Shatskih]

>SoCal here, all I had was a text mode kd prompt. It’s easy to communicate findings to MSFT folks by

pasting kd command outputs.

Oh yes. Just plain impossible with the GUI debugger.

When I use WinDbg GUI, I was mainly stuck in the kd cmd window unless I need to step through my >src.

+1

I nearly never need to step and I have the source open in the text editor just near if I need to look at it.

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

[Maxim_S_Shatskih]

>gets me are the usability gaps a mile wide. I don’t like having windbg sit not responding for 2 minutes

Then you have a cable connection issue. This is not about debugger, this is about the kernel debugging in general.

It’s interesting though to see some people find it awkward to pull down a configuration drop down >menu and instead have an instinctive desire to drill into and hand edit a proprietary file.

Surely.

Since this fancy drop-down menu ends with editing the even more proprietary file in the end, and yes, the sequence of actions (i.e. build script) is better understandable as text and not as a series of diamond-like shapes.

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

[Maxim_S_Shatskih]

> XML is not human-readable at all

Yes.

Though you can grep for some particular name in it and micro-patch it.

Same you can do with SOURCES files.

in Russia call “explosion on a spaghetti factory”

Well, this Russian expression is about some female hair style like the one Euro-Disco singers of 1980ies used

Yes, there is some similarity with XML.

just beautiful and improves with every release. Eclipse is, er,
eclipsed. Their underlying build engines have some common roots (NAnt?)

Aren’t Eclipse start some external tool (like GNU make) for build?

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

[Don_Burn]

I do have besides the problems of just converting things to the new model
some serious problems with the integrated VS/WDK.

1. As I commented earlier it is very hard to compare project files, so when
   clients make changes it is hard to tell what they did. Years ago when VS
   was not an approved build mechanism (except for DDKBUILD) a client was using
   raw VS projects to build drivers. I would send them code I had tested in a
   standalone driver (since the real environment was a very large custom
   cluster) and they would complain it did not work and in some cases did not
   compile! I finally spent some time in their shop to discover the roughly 15
   developers all had different settings on the VS projects, and that QA had
   different settings than any developer, and release engineering different yet
   again. Things got heated when they discovered that no one had ever tested
   the code as it was compiled for their release.

2. Visual Studio has “auto updates”. This has already bitten me once where
   a client had different results using VS2012 than I did on a driver. Turns
   out the compilers were different. This was a real advantage of the WDK, it
   only came out periodically and you could tell the customer “Use version
   7600.16385.1 of the WDK”.

3. The samples are not part of the WDK and get updated. This is a variant
   of the above in that clients may find different samples than what I have.
   Also, since there is no notification that a sample has been upgraded, you
   cannot easily check if there is a bug fix that should be applied to a driver
   derived from a sample. I used to on each WDK check the samples I had
   derived code from for changes so that I could apply any fixes Microsoft had
   discovered.

Now there are a lot of nice things about the integrated environment, but it
would be nice if Microsoft would consider the above and fix them. A few
suggestions on fixing them:

1. Microsoft does have an XML compare library/program (I’ve used it on
   project files), would someone please consider using this to provide a
   friendly project file comparison tool.

2. How about having some easy place to see which updates were applied to
   VS?

3. How about for the samples, having a change history on the webpage, and
   RSS of some other notification that a sample has been updated? The ultimate
   would be a way on the download page to get previous versions of the samples.

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

[Calvin_Guan-3]

The beauty of kd engine is that I can write extension and script to
automate tedious things like dumping registers, driver vars to compute the
state of the driver as to how it got here and why. For example, I can write
my own !analyze command to check the probable causes of why my nic won’t
send. Every time I learned a new debug techni, or discovered a debug
register either from RTL folks or by consulting with the source code
itself, I added it to my kd extension so that I won’t forget. As time goes
by, it became smarter.

kd framework and protocol is the greatest thing MSFT has engineered so far
in my book.

Calvin

p.s. I’m not a fan of hover-mouse-and-show game. The value usually
disappeared before I can read and remember it. Memorizing a 7 digit phone#
is challenge enough to me, let alone an 8 digit hex number.

On Sun, Dec 8, 2013 at 11:45 AM, Maxim S. Shatskih
wrote:

> > Do people in the 21st century really want to study and hand edit
> incredibly complex project files that
> >are miles long?
>
> The answer is “yes”, if the people are real professionals, and not
> amateurish children writing some small smartphone applets consisting 5-10
> source files each.
>
> Visual Studio is exactly fine for this kind of projects. It is also fine
> for C#, but C#, being a by far simpler language (if you do not create your
> own generics) operating in a specially crafted simple environment, does not
> require and build scripts except a couple of global compiler options and
> the referenced assemblies list.
>
> In open source world, there is no Visual Studio (though there are good
> comparable code text editors). They live with GNU make and CMake, and
> produce good software (there are exceptions, but OSS is generally good
> and even the mentioned exceptions are not such due to build scripts).
>
> Makefiles are NOT incredibly complex, and are NOT miles long.
>
> And SOURCES is even a simplified version of makefile, containing what is
> enough for 90% of cases.
>
> Now look at MSVC’s project files. First there were .DSP files, which have
> their own arcane syntax by far not simpler then a makefile.
>
> Then there was XML. Contrary to popular belief XML is not human readable.
> Old-style description languages like the makefile’s one are by far better.
>
> And, as about the project management GUI in MSVC - good luck comparing
> what have changed in the build script (a mandatory task for a serious team
> work) since the last commit using this toy. It’s just incapable of this.
>
> >It would be going back to the days before WYSIWYG
>
> WYSIWYG for project/build scripts is just an evil pathetic toy.
>
> >where you had to create documents using a markup language.
>
> Documents are not build scripts. The final purpose of any document is to
> create a paper-style image, if not even being physically printed. For
> making images, WYSIWYG is good.
>
> The final purpose of the build script is NOT to become an image. It’s
> purpose is to define actions. How WYSIWIG helps with this (aside of
> improving the learning curve for the very newbies)? drawing actions on the
> screen by diamond-style shapes? Funny and childish.
>
> Also note that the world scientific community still use TeX (a 1970ies
> invention, which was already old and venerable in around 1992) which is
> exactly “create documents using a markup language”.
>
> Why? Because it is the best way to type complex math formulas to the
> computer.
>
> MS’s WYSIWYG Equation Editor in Word just plain sucks compared to TeX in
> terms of usability (too many mouse clicks and hovering to do), and also,
> being implemented as an embedded OLE object, does not allow the simple
> stuff of “please resize all formulas in this document”.
>
> Surely typing “\sub” is simpler then a) choosing one of the toolbox icons
> and hitting it and them b) moving the mouse to the new appeared rectangle
> below the main formula to move the focus there. If you do this 100 times -
> the difference is very serious.
>
> >> With THIS bad issues on build management, and with debugger which is a
> >> pretty toy compared to WinDbg
> >
> > Using both on a daily basis it is clear as day the VS debugger is miles
> ahead of the joke windbg.
>
> Can you dump a structure list in VS’s debugger? without doing lots of
> mouse clicks on these tiny plus signs in the tree (remember you need to
> target the mouse at them)?
>
> > I remember when I once complained you couldn’t do something as simple as
> hover the mouse
>
> Who cares about hovering a mouse? well, really, who cares? I’m too lazy to
> do this. This requires a) scrolling then b) targeting. Too clumsy.
>
> Typing “dv” is simpler in terms of hand/finger movements then targeting
> the variable name (and scrolling the code to find it) by mouse.
>
> Command line rules. I can tell you - I forgot the last time I had a
> source file in WinDbg open. Command window is enough for me
>
> Actually, nearly the only 2 debugging techniques I now use, after 20 years
> of SD experience, is a) adding a temporary printf()/KdPrint() etc, small
> rebuild and re-run and b) WinDbg’s Command window. And I know lots of
> people from the other, i.e. Linux, ecosystem, which use “gdb” the same way
> (it is more or less a Linux analog of WinDbg, too bad that all commands are
> typed differently).
>
> I use WinDbg for user mode too a lot, and, after I mastered it in like
> 1999 (yes, the old buggy version, the good WinDbg only appeared in 2001 I
> think) - I was just amazed on how pathetic is the MSVC’s debugger. Pathetic
> exactly because mouse-driven OO GUI is worse for this purpose then the
> command line.
>
> Remember: hovering the mouse is impractical and evil The only real
> thing about the GUIs is that they have a selp-describing power (and even
> this can be spoiled by using wrong icon for a button). Well, the second
> thing about the GUI is file picking dialog boxes - typing pathnames is
> bothering, though auto-completion helps a lot.
>
> For the professional tool with which person works a lot - command line is
> superior.
>
> >possibly work in the kernel, pffft. The misguided bias towards a
> completely inferior product is
>
> Looks like you’re considering childish product superior and serious
> products - inferior.
>
> Yes, there are such people, I know. They are often also obsessed by
> “modernity” and sometimes use the clumsy toyish new stuff in place of the
> well-done, years-old, venerable old stuff which is still alive for 30 years
> (and will be alive, like a simple wrench is still alive).
>
> –
> 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
>

[Alex_Grig]

My copy of PCI standard shows that the address on PCI bus is only asserted for one clock.

I assume CS/RD are internal signals of their board. For how long they are asserted depends on the board design. These are not PCI signals.

[Alex_Grig]

Oops, wrong window.

[Prokash_Sinha-1]

IIRC, I wrote extension back in 1999. Windbg was quite weak at that
time. Now the engine is com based, and wrote extension again based on
new approach.

Does it have its problems? I think so, but can it be avoided and take
another route to get things done, yeah for sure. One particular is when
you try to invoke some scripting directly, instead of invoking .wds,
the scripting has to be one liner, otherwise it is lost in parsing ( I
call it - It is pershing county, Nevada back in 1823, wild wild west,
every one has his/her own rule: Yeah parsing is bunch rules).

For the quick look of hoovering the mouse over, I kinda like it though,
but not necessarily for a large var since I would not dare to remember
and look for other refs.

It is indeed a very useful tool.

-pro

On 12/8/2013 3:21 PM, Calvin Guan (news) wrote:

The beauty of kd engine is that I can write extension and script to
automate tedious things like dumping registers, driver vars to compute
the state of the driver as to how it got here and why. For example, I
can write my own !analyze command to check the probable causes of why
my nic won’t send. Every time I learned a new debug techni, or
discovered a debug register either from RTL folks or by consulting
with the source code itself, I added it to my kd extension so that I
won’t forget. As time goes by, it became smarter.

kd framework and protocol is the greatest thing MSFT has engineered so
far in my book.

Calvin

p.s. I’m not a fan of hover-mouse-and-show game. The value usually
disappeared before I can read and remember it. Memorizing a 7 digit
phone# is challenge enough to me, let alone an 8 digit hex number.

On Sun, Dec 8, 2013 at 11:45 AM, Maxim S. Shatskih
> wrote:
>
> > Do people in the 21st century really want to study and hand edit
> incredibly complex project files that
> >are miles long?
>
> The answer is “yes”, if the people are real professionals, and not
> amateurish children writing some small smartphone applets
> consisting 5-10 source files each.
>
> Visual Studio is exactly fine for this kind of projects. It is
> also fine for C#, but C#, being a by far simpler language (if you
> do not create your own generics) operating in a specially crafted
> simple environment, does not require and build scripts except a
> couple of global compiler options and the referenced assemblies list.
>
> In open source world, there is no Visual Studio (though there are
> good comparable code text editors). They live with GNU make and
> CMake, and produce good software (there are exceptions, but OSS
> is generally good and even the mentioned exceptions are not such
> due to build scripts).
>
> Makefiles are NOT incredibly complex, and are NOT miles long.
>
> And SOURCES is even a simplified version of makefile, containing
> what is enough for 90% of cases.
>
> Now look at MSVC’s project files. First there were .DSP files,
> which have their own arcane syntax by far not simpler then a makefile.
>
> Then there was XML. Contrary to popular belief XML is not human
> readable. Old-style description languages like the makefile’s one
> are by far better.
>
> And, as about the project management GUI in MSVC - good luck
> comparing what have changed in the build script (a mandatory task
> for a serious team work) since the last commit using this toy.
> It’s just incapable of this.
>
> >It would be going back to the days before WYSIWYG
>
> WYSIWYG for project/build scripts is just an evil pathetic toy.
>
> >where you had to create documents using a markup language.
>
> Documents are not build scripts. The final purpose of any document
> is to create a paper-style image, if not even being physically
> printed. For making images, WYSIWYG is good.
>
> The final purpose of the build script is NOT to become an image.
> It’s purpose is to define actions. How WYSIWIG helps with this
> (aside of improving the learning curve for the very newbies)?
> drawing actions on the screen by diamond-style shapes? Funny and
> childish.
>
> Also note that the world scientific community still use TeX (a
> 1970ies invention, which was already old and venerable in around
> 1992) which is exactly “create documents using a markup language”.
>
> Why? Because it is the best way to type complex math formulas to
> the computer.
>
> MS’s WYSIWYG Equation Editor in Word just plain sucks compared to
> TeX in terms of usability (too many mouse clicks and hovering to
> do), and also, being implemented as an embedded OLE object, does
> not allow the simple stuff of “please resize all formulas in this
> document”.
>
> Surely typing “\sub” is simpler then a) choosing one of the
> toolbox icons and hitting it and them b) moving the mouse to the
> new appeared rectangle below the main formula to move the focus
> there. If you do this 100 times - the difference is very serious.
>
> >> With THIS bad issues on build management, and with debugger
> which is a
> >> pretty toy compared to WinDbg
> >
> > Using both on a daily basis it is clear as day the VS debugger
> is miles ahead of the joke windbg.
>
> Can you dump a structure list in VS’s debugger? without doing lots
> of mouse clicks on these tiny plus signs in the tree (remember you
> need to target the mouse at them)?
>
> > I remember when I once complained you couldn’t do something as
> simple as hover the mouse
>
> Who cares about hovering a mouse? well, really, who cares? I’m too
> lazy to do this. This requires a) scrolling then b) targeting. Too
> clumsy.
>
> Typing “dv” is simpler in terms of hand/finger movements then
> targeting the variable name (and scrolling the code to find it) by
> mouse.
>
> Command line rules. I can tell you - I forgot the last time I had
> a source file in WinDbg open. Command window is enough for me
>
> Actually, nearly the only 2 debugging techniques I now use, after
> 20 years of SD experience, is a) adding a temporary
> printf()/KdPrint() etc, small rebuild and re-run and b) WinDbg’s
> Command window. And I know lots of people from the other, i.e.
> Linux, ecosystem, which use “gdb” the same way (it is more or less
> a Linux analog of WinDbg, too bad that all commands are typed
> differently).
>
> I use WinDbg for user mode too a lot, and, after I mastered it
> in like 1999 (yes, the old buggy version, the good WinDbg only
> appeared in 2001 I think) - I was just amazed on how pathetic is
> the MSVC’s debugger. Pathetic exactly because mouse-driven OO GUI
> is worse for this purpose then the command line.
>
> Remember: hovering the mouse is impractical and evil The only
> real thing about the GUIs is that they have a selp-describing
> power (and even this can be spoiled by using wrong icon for a
> button). Well, the second thing about the GUI is file picking
> dialog boxes - typing pathnames is bothering, though
> auto-completion helps a lot.
>
> For the professional tool with which person works a lot - command
> line is superior.
>
> >possibly work in the kernel, pffft. The misguided bias towards a
> completely inferior product is
>
> Looks like you’re considering childish product superior and
> serious products - inferior.
>
> Yes, there are such people, I know. They are often also obsessed
> by “modernity” and sometimes use the clumsy toyish new stuff in
> place of the well-done, years-old, venerable old stuff which is
> still alive for 30 years (and will be alive, like a simple wrench
> is still alive).
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com mailto: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>

[OSR_Community_User]

On 12/8/2013 7:45 PM, Maxim S. Shatskih wrote:

In open source world, there is no Visual Studio (though there are good comparable code text editors).

Aren’t Eclipse or KDevelop equivalent?

–
Bruce

[Pavel_A1]

On 08-Dec-2013 21:53, Maxim S. Shatskih wrote:

Aren’t Eclipse start some external tool (like GNU make) for build?

AFAIK, not exactly. Not quite. Lets take this offtopic offline if you like.

• pa

[Maxim_S_Shatskih]

>> In open source world, there is no Visual Studio (though there are good comparable code text

editors).

Aren’t Eclipse or KDevelop equivalent?

In terms of text editing and plugins yes, Eclipse maybe even better, but… do they have a project file management or rely on external make tool?

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

[Phil_Barila]

As I commented earlier it is very hard to compare project files, so when clients make changes it is hard to tell what they did. Years ago when VS was not an approved build mechanism …

While the rest of your post describes valid issues, this one is quite stale, at least in my experience since VS 2010/12/13. File additions/subtractions, property/option changes, and project addition to solutions add, remove and modify lines in unsurprising ways. I’ve not seen that reordering in any of these versions.

I’ve blocked the experience of using Visual Studio 2008 and earlier out of my memory, it’s too painful, for a lot of reasons, so I can’t reliably state one way or other whether the ordering issues that made so hard to compare earlier versions were fixed in 2010, or an earlier release.

I do have to throw in a commendation to the VS team for keeping the .sln/.vyproj (where y denotes VB, C#, C++, etc) file formats round-trip able from 2010 to 2013 (as long as you target .NET 4.0). That’s the only reason why I’ve been able to use VS 2012/13 in anger, and I will unequivocally endorse 2013 as the best of the .NET-based Visual Studio versions so far.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER in the 2013 SIEM Magic Quadrant
Perfect 5-Star Rating in SC Magazine for 5 Consecutive Years

[Don_Burn]

Phil,

My experience with VS2012 is moderate and VS2013 highly limited, but I
had one client whose vxproj file came back such that a normal file compare
essentially said everything was different. Even if they are kept in the
same order this still means you are trying to translate XML back to GUI
options to figure out what has changed. Worse yet when you have 3 or more
people all getting different results the compares can be painful, even
though I believe it is normally better.

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 Phil Barila
Sent: Monday, December 09, 2013 2:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Approaches for converting DIRS/SOURCES projects to WDK
8+

As I commented earlier it is very hard to compare project files, so when
clients make changes it is hard to tell what they did. Years ago when VS
was not an approved build mechanism …

While the rest of your post describes valid issues, this one is quite stale,
at least in my experience since VS 2010/12/13. File additions/subtractions,
property/option changes, and project addition to solutions add, remove and
modify lines in unsurprising ways. I’ve not seen that reordering in any of
these versions.

I’ve blocked the experience of using Visual Studio 2008 and earlier out of
my memory, it’s too painful, for a lot of reasons, so I can’t reliably state
one way or other whether the ordering issues that made so hard to compare
earlier versions were fixed in 2010, or an earlier release.

I do have to throw in a commendation to the VS team for keeping the
.sln/.vyproj (where y denotes VB, C#, C++, etc) file formats round-trip able
from 2010 to 2013 (as long as you target .NET 4.0). That’s the only reason
why I’ve been able to use VS 2012/13 in anger, and I will unequivocally
endorse 2013 as the best of the .NET-based Visual Studio versions so far.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER in the 2013 SIEM Magic Quadrant Perfect 5-Star Rating in SC
Magazine for 5 Consecutive Years

---

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

[CK_Software_Consulting]

Regarding debugging. There are some definition pro’s in favor of Windbg: compact: you can just put it on a thumb drive to debug on a system that doesn’t have VS2012/3 on it. This might be out of date as I haven’t tried with VS2013, but you don’t have DML support when debugging via VS. The USB3 debugger extensions make use of DML a lot, and I use it whenever I roll my own extensions.

That said, what the WDK team started with VS2012 is really awesome. I love especially the creation of test signed binaries.

[Phil_Barila]

What are you using for your diff tool?

Using Beyond Compare 3, and the diff tool built into VS 2012/3, I get exactly the changes I expect. The stale leftover from Visual Source Safe that is included in VS 2010 is unbearable, even when configured to ignore whitespace, that’s where I use BC3.

I’ve found the VS 2012/3 built-in diff tool so good, I rarely resort to BC3 when doing version comparisons using those.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER in the 2013 SIEM Magic Quadrant Perfect 5-Star Rating in SC
Magazine for 5 Consecutive Years

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 09, 2013 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Approaches for converting DIRS/SOURCES projects to WDK 8+

Phil,

My experience with VS2012 is moderate and VS2013 highly limited, but I had one client whose vxproj file came back such that a normal file compare
essentially said everything was different. Even if they are kept in the
same order this still means you are trying to translate XML back to GUI options to figure out what has changed. Worse yet when you have 3 or more people all getting different results the compares can be painful, even though I believe it is normally better.

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 Phil Barila
Sent: Monday, December 09, 2013 2:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Approaches for converting DIRS/SOURCES projects to WDK
8+

As I commented earlier it is very hard to compare project files, so when
clients make changes it is hard to tell what they did. Years ago when VS
was not an approved build mechanism …

While the rest of your post describes valid issues, this one is quite stale,
at least in my experience since VS 2010/12/13. File additions/subtractions,
property/option changes, and project addition to solutions add, remove and
modify lines in unsurprising ways. I’ve not seen that reordering in any of
these versions.

I’ve blocked the experience of using Visual Studio 2008 and earlier out of
my memory, it’s too painful, for a lot of reasons, so I can’t reliably state
one way or other whether the ordering issues that made so hard to compare
earlier versions were fixed in 2010, or an earlier release.

I do have to throw in a commendation to the VS team for keeping the
.sln/.vyproj (where y denotes VB, C#, C++, etc) file formats round-trip able
from 2010 to 2013 (as long as you target .NET 4.0). That’s the only reason
why I’ve been able to use VS 2012/13 in anger, and I will unequivocally
endorse 2013 as the best of the .NET-based Visual Studio versions so far.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER in the 2013 SIEM Magic Quadrant Perfect 5-Star Rating in SC
Magazine for 5 Consecutive Years

---

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

[Pavel_A1]

On 10-Dec-2013 00:42, Phil Barila wrote:

Using Beyond Compare 3, and the diff tool built into VS 2012/3, I get exactly the changes I expect.

I have BC3 too, but could not achieve good result with any of its XML
modes (sorted, sorted attributes, and some alternative add-on). Which
mode do you use for VS projects?

thanks,
– pa

[Phil_Barila]

I use the mode, as I’ve never configured it to do anything special with .sln/.csproj/.vcxproj/.vbproj.

appears to just treat it as plain text, and it just works, with the VS project/solution files in question.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER in the 2013 SIEM Magic Quadrant Perfect 5-Star Rating in SC Magazine for 5 Consecutive Years

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Monday, December 09, 2013 3:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Approaches for converting DIRS/SOURCES projects to WDK 8+

On 10-Dec-2013 00:42, Phil Barila wrote:
> Using Beyond Compare 3, and the diff tool built into VS 2012/3, I get exactly the changes I expect.

I have BC3 too, but could not achieve good result with any of its XML modes (sorted, sorted attributes, and some alternative add-on). Which mode do you use for VS projects?

thanks,
– pa

—
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

[Maxim_S_Shatskih]

>Using Beyond Compare 3

Yes, this tool is good, better then Tortoise ones.

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

[MBond]

On your first point, keeping project and solution files in TFS and using the
built-in file comparison tool in pending changes or compare to I have never
had any difficulty determining what the difference are. In my mind, the key
to remember is not to think of the GUI actions one might have used to get
that XML, but just think of the XML as XML. In fact, I mostly edit project
files as XML and then reload them in VS (there is an extension I use called
VSCommands that adds an ‘edit project file’ item to the context menu that
makes this easy)

On your second point, control panel -> programs and features -> show updates
shows a list of updates applied to Visual Studio and the various connected
tools

On your third point, I do not know of a good way to get updates for sample

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

I do have besides the problems of just converting things to the new model
some serious problems with the integrated VS/WDK.

1. As I commented earlier it is very hard to compare project files, so when
   clients make changes it is hard to tell what they did. Years ago when VS
   was not an approved build mechanism (except for DDKBUILD) a client was using
   raw VS projects to build drivers. I would send them code I had tested in a
   standalone driver (since the real environment was a very large custom
   cluster) and they would complain it did not work and in some cases did not
   compile! I finally spent some time in their shop to discover the roughly 15
   developers all had different settings on the VS projects, and that QA had
   different settings than any developer, and release engineering different yet
   again. Things got heated when they discovered that no one had ever tested
   the code as it was compiled for their release.

2. Visual Studio has “auto updates”. This has already bitten me once where
   a client had different results using VS2012 than I did on a driver. Turns
   out the compilers were different. This was a real advantage of the WDK, it
   only came out periodically and you could tell the customer “Use version
   7600.16385.1 of the WDK”.

3. The samples are not part of the WDK and get updated. This is a variant
   of the above in that clients may find different samples than what I have.
   Also, since there is no notification that a sample has been upgraded, you
   cannot easily check if there is a bug fix that should be applied to a driver
   derived from a sample. I used to on each WDK check the samples I had
   derived code from for changes so that I could apply any fixes Microsoft had
   discovered.

Now there are a lot of nice things about the integrated environment, but it
would be nice if Microsoft would consider the above and fix them. A few
suggestions on fixing them:

1. Microsoft does have an XML compare library/program (I’ve used it on
   project files), would someone please consider using this to provide a
   friendly project file comparison tool.

2. How about having some easy place to see which updates were applied to
   VS?

3. How about for the samples, having a change history on the webpage, and
   RSS of some other notification that a sample has been updated? The ultimate
   would be a way on the download page to get previous versions of the samples.

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