You are missing the point of “If you want your driver to run on multiple
versions of Windows and dynamically determine the features that are
available to the driver”. This is the case where you want a single binary
image driver to use interfaces if they are present while being able to run
on platforms where they are not present. For example you want your driver
(and this discussion really only applies to drivers) to use kernel
interfaces only supported in Vista but also be able to run on XP and W2K3.
You build your driver for Vista but you also have to identify every
interface that you intend to use that is not present in XP and you have to
write code to dynamically test for the presence of that interface, use it if
it is present, and use a substitute if it is not. You do that by using
MmGetSystemRoutineAddress - which is present in W2K and later - to find the
address of a kernel function if it is present on the platform.
The much simpler approach is to build for the lowest version platform you
need to support - XP in your case - and to not use any higher version
platform kernel interfaces.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Abhishek Bhadouria
Sent: Friday, March 02, 2007 1:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows 2003/XP
Hi bob,
Thanks for your reply but i think there is some gap in understanding. I
think i am not able to put my query correctly.
According to MSDN
MSDN Library-> Win32 and com Developement -> Windows Driver Kit -> Getting
Started with Windows Driver -> Building , Debugging and Testing Driver ->
Header Files In Windows Driver Kit ->Best Practices for using WDK header
Files.
. If you want your driver to run on multiple versions of Windows and
dynamically determine the features that are available to the driver, build
the driver in the build environment for the most recent version of the
operating system. For example, if your driver will support all Windows
versions starting with Windows 2000 but you want the driver to use certain
features that were first made available in Windows XP when your driver is
running on Windows XP or later operating systems, build your driver in the
Windows Vista build environment of the WDK.
My use case is like this: -
In DDK, I used to build my driver in W2K3 build env so that my driver could
be deployed in any lower version of Windows without missing XP specific
feature on XP target machine, without missing W2K3 specific features on W2K3
target machine.
But In WDK, When i am building my driver on W2K3 build env I am not able to
deploy it in any lower version of windows.but If i am building using WINXP
build env i am able to use it on W2K3.
SO that means with WDK there is a forward support for binaries but no
reverse support.
In WDK, it appears that if I need a driver which should work on Win2K,
WinXP, W2K3, then I should build the driver using the Win2K build env of
WDK. But then if my driver is trying to use some WinXP feature, will i am
going to miss those feature.
It appears from the MSDN documentation that my use case should work with WDK
as it was working with DDK, but it is not so.
Thanks & regards
Abhishek
On 3/1/07, Bob Kjelgaard mailto:xxxxx > wrote:
Abishek-
About 1, the DDK is arguably the one in error. It lets you build a binary
with calls that didn’t exist on NT4, but is marked as being an NT 4 binary.
Also, you said “source files”- in case that wasn’t a typo- this setting is
made in the SOURCES file in each leaf directory of your build tree, not in
each source file in your tree. I suppose you really could have 300 drivers,
test apps, and libraries you build in this project- it just seems a bit
large.
I realize that doesn’t answer why, but that’s a big question. One reason is
that you get what we use, and that’s a change that improves our engineering
processes by forcing us to be more explicit about where each binary built in
the OS source tree is expected to work. Another is that it prevents you
from targeting a binary at a platform that contains calls the platform
doesn’t support. There are probably some others, but I don’t think they
matter in any practical sense. This is the recommended way to fix this
problem. I’ve had to do it myself quite a few times, since we have to test
KMDF on all those legacy platforms.
For 2, I believe one thing you can do is just use the SET command and set
the corresponding environment variable (I haven’t tried it, but I believe
this is an environment variable and not a macro). You should be able to do
that in a batch file (but I would also recommend you do this as a temporary
measure while you fix the sources files, because you will eventually run
into support issues if you are not using the WDK).
For 3- there is no such setting. NT4 is unsupported in the WDK. The WDK
supports WINXP and WIN2K for targets of this macro.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>