Note that what has been missing here is the concept of “backward
compatibility” .
That is, BinPlace will do so much more. But this is not justification for
breaking all existing builds. So people who need the new features can use
them, and people who don’t need them don’t need to do anything special,
their builds keep running.
This is something that has to be kept in mind when such changes are
contemplated. Just because there is a *better* way to do things does not
justify making features that worked well (but may not have been nearly as
powerful) go away just because someone thought there was a need to make them
go away. So in principle, TARGETPATH= is simply defined as a way to get a
subset of the BinPlace functionality. When people complain that it can’t do
this-or-that, then they have reason to use the new technology.
In recent years, there has been a strange set of attitudes within Microsoft.
All kinds of weird kludges in the OS to allow, for example, old video games
to continue to work in spite of the fact that they actually contain serious
bugs that should never have been allowed to exist in the first place, but in
the developer world or Office world, it is felt acceptable to completely
break everything on a new release. Up to and including the user interface.
Apparently, only video game developers deserve backward compatibility, an
attitude which indicates either indifference or hostility to the Rest Of Us.
As someone who is both a developer and a user, but not a videogame player, I
feel I’m getting the short end of the stick in the only ways that matter to
me.
(I would love a feature in WinDbg that says “Never allow undocking”; I watch
new users try to use it and the undocking actively interferes with the
usability of this program. A messagebox popping up under an undocked window
is hard for them to identify, all they see is that the debugger has hung)
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Tuesday, January 20, 2009 11:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path
Binplace will put things together in a folder relative to _NTTREE.
In WDK _NTTREE is defined as $(BASEDIR).binaries, so it is a completely
separate folder then WDK root.
Example:
Source code in: c:\WinDDK\base\abc\project TARGET_DESTINATION = customfolder
Output will result in: c:\WinDDK.binaries..\customfolder
Also, binplace is not meant to replace TARGETPATH. A good example for using
Binplace is the Toaster sample. To build, install and run the Toaster
virtual device you would need the toaster bus, the function driver, a filter
if you want, maybe some exe, etc.
With Binplace the following line in your Toaster sample projects will put
all files that you need together :
TARGET_DESTINATION = customfolder
plus - you can copy the co-installers and other files that you don’t
currently build - all together, in a custom folder ready for testing or
packaging.
Can you achieve this with TARGETPATH?
Also, what’s the point for you to redirect TARGETPATH here and there in your
source tree, don’t you want to keep it clean?
TARGETPATH macro will be restored, but we’ll put some comments in the WDK
documentation explaining why you should be careful with its usage.
NTDEV is sponsored by OSR
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.