Building a common driver binary for both XP, Vista and 7
Bo Skjoett
both Windows XP, Vista and 7. I know I have to build a separate driver binary
for 32-bit (x86) and 64-bit (x64), but is it possible to use each of these
drivers on both XP, Vista and 7?
Should I use the WDK build environment for the oldest OS (XP in this case)
to build the driver?
Hannes
Windows Server 2003. That will run on all those OSes. Latest (Win7) WDK is
fine.
Also - If your driver uses WDF, you will need to decide on a WDF version to
build for (by installing and using the corresponding WDK), and also
distribute your driver with a matching WDF Coinstaller DLL. XP uses WDF 1.5,
Vista 1.7, and Win7 1.9. If your driver is for example built and distributed
with WDF 1.9, then a WDF upgrade (requires a restart) will be done on the PC
when you install on XP and Vista. If you instead go for WDF 1.5, no WDF
upgrade will happen on neither OS. I would go for the latest WDF, i.e. 1.9.
Good luck,
/ Hannes.
skiloup
architecture that the WDK has a build environment for. My build script
copies in the correct wdfcoinstaller for each build environment. At the end
of my build I have a directory structure that has a folder for each build
environment where each folder has the signed driver package for that
particular environment. In order to not make the customer navigate to the
appropriate OS and x86/x64 directory to find the appropriate driver I write
.msi installers that detect the OS and install the appropriate driver
package. That way for a given driver I just have two .msi installers. One
for x86 platforms and another for x64 platforms. In my .msi I put
installation conditions that check for whether or not it's executing on a
32-bit platform or a 64-bit platform and bailout if they ran the wrong one.
That way there it's impossible for them to install the wrong driver package.
It's a bit of extra work up front, but in the end it's dirt simple for the
customer and they can't screw it up. Hope that helps.
I know it's dirty, but my build scripts are in Perl, and I'm using
WiX/Votive for my .msi creation process.
Don Burn
up front translates into a HUGE AMOUNT OF WORK at the tail end. FIrst you
have to test all those drivers on each platform. While it is true you
should test on every platform most dev's realize that if you have a binary
that tests well on the earliest OS and the lastest OS you can probably get
by with fewer tests for the OS'es in the middle. Second, if you want to
sign the driver for WHQL you have just upped your costs significantly since
each binary is more cost.
There are reasons for having seperate binaries for some OS'es but just
blindly doing this is not a great idea.
--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"skiloup" <ski...@discussions.microsoft.com> wrote in message
news:BA7EF704-F986-4AFD...@microsoft.com...
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4622 (20091119) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4622 (20091119) __________
The message was checked by ESET NOD32 Antivirus.
skiloup
cost for WHQL though. My reason for doing it this way has always been to use
the build environment for the intended deployment. I don't know the inner
details of which build environments will 'work' for deployment on a different
environment. Perhaps that's just me being naive.
If someone here knows, I'd be interested in hearing. If to support x86 and
amd64 architectures I only need to build two .sys files that work for Win XP
through Windows7/2008R2 that'd be great information to know.
"Don Burn" wrote:
> .
>
Don Burn
then the old rule of build for the oldest OS works for most drivers. I've
been doing this since NT 3.5.1 and it works well.
--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
"skiloup" <ski...@discussions.microsoft.com> wrote in message
news:8A6C7BA5-5380-4413...@microsoft.com...
> signature database 4623 (20091119) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4623 (20091119) __________
skiloup
intention of the different build environments. Can you explain any further
why there is a need for seperate build environments for say Windows Xp (x86)
and Windows7 (x86) if the build for Xp will work in Win7?
"Don Burn" wrote:
> .
>
David Craig
driver for your device and the stacks are different you may need to target
the older version of Windows to get the correct libraries to support the new
features. I don't know the details, but video card drivers changed a lot
from XP to Vista. While a particular vendor will have a lot of code that
can be used in both targets the 'upper' interface to the OS will be
significantly different. There are other stacks where this is also true,
but a review of the WDK documentation can show you the difference. In some
cases you might want to have the docs from the last DDK 3790.1830 just to
ensure you can find only the structures and functions supported by that
version.
In other cases you might want to use a new OS call that is not available on
the earliest OS target but you can use a function pointer for it and call it
if available. You could have that pointer call an internal function on the
versions the OS where the support doesn't exist and implement a function
with the same results using your own code. You would then compile for the
earlier OS, but in code see if the function is exported by the OS.
"skiloup" <ski...@discussions.microsoft.com> wrote in message
news:32384C33-6C9B-49CD...@microsoft.com...
Kota
>There are reasons for having seperate binaries for some OS'es but just blindly doing this is not a great idea.
Could you provide me a link or details about this?, on which circumstances,
I should build the driver for each OS? On what basis, we decide, Or if we
build the driver supports win 7 API's & it wont build for xp?
I am using a PCI device, want to build for xp, vista, win 7 for both x86 &
x64 arch(2 binary x86 & x64 for all os)
Thanks,
Kota
"Don Burn" wrote:
> .
>
Don Burn
present since Windows 2000. If you avoid the API's that are not available
(which if you want to support an older OS you are going to have to do
anyway) then the logical approach is build the driver for the oldest OS and
use it for all platforms.
If you have a PCI device and it does not fall into one of the specific
classes that have their own model such as storage controller then use KMDF
and build your driver.
--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Kota" <Ko...@discussions.microsoft.com> wrote in message
news:E628FFAB-2752-4515...@microsoft.com...
> signature database 4858 (20100211) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4858 (20100211) __________
Maxim S. Shatskih
> build the driver supports win 7 API's & it wont build for xp?
Yes.
> I am using a PCI device, want to build for xp, vista, win 7 for both x86 &
> x64 arch(2 binary x86 & x64 for all os)
1) Do you _really need_ to employ the new features of the new OS? think about it. Usually, they are of minor value, unless the whole architecture is remade - i.e. NDIS5 vs. NDIS6.
2) If your answer to "1" is "no" - build using the build env for the oldest OS you support. Have this single binary for newer OSes too.
3) If your answer to "1" is "yes" - then you can either have different binaries for different OS versions, _each built with its particular build env_. The source can be the same, just with #ifdef _NTDDI_VERSION in it.
Either you can query the OS version by RtlIsNtDdiVersionAvailable and then adapt your behaviour based on it, including MmGetSystemRoutineAddress to get the kernel exports which appeared in the new versions. The build env for this is again _for the oldest OS you support_.
4) You can also have completely different code for different OS versions. Like, say, NDIS5 vs. NDIS6.
What you must NEVER do: build with newer OS build env and run on older OS.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
alberto
If you have a wdm driver, you can try this:
%ddkdir%\bin\setenv %ddkdir% %model% %arch% wnet
build /c
For example,
e:\winddk\6001.18001\bin\setenv chk x64 wnet
build /c
I've been building my drivers this way for quite some time (these
lines are part of a script that's executed by the MSVC shell when I
press the build button) and the driver works fine from XP all the way
to Windows 2008 R2.
> > "skiloup" <skil...@discussions.microsoft.com> wrote in message
> > .- Hide quoted text -
>
> - Show quoted text -
Kota
I am finding trouble with WDF Coinstaller DLL 1.5 version for all OS with
WDK 7600 build environments.
I have build the binary for xp-32 bit, It is working fine for Win-7 32 bit
with 1.5 dll, but it is not working for older os for xp & vista.
Instead 1.5, i have replaced with 1.9 in inf, it is working fine for xp &
vista.
I want to use 1.5 to avoid system restart for all OS, but it is not working
in 7600 build environment, I have tried with 6000 environment, It installed
fine in XP, this way i ensured that, my inf, sys everything is fine for xp as
well.
Can i build the driver in wdk-6000 and can i use the same for Win-7 32 as
well?, 6000 doesnt support win-7.
Is there any incompatbility trouble with 7600 & coinstaller for older OS.
But surprisingly, it is working fine for win-7.
Here is my inf file, related to coinstaller and service sections:
;----------------------------------------------------------------------------------
; For x86
[GE-IP.NTX86]
; DisplayName Section DeviceId
; ----------- ------- --------
%Device.Description%= pmc55xx_Inst_x86, pci\ven_114a&dev_5565
[pmc55xx_Inst_X86.NT]
CopyFiles = PMC55XX.Files_12,PMC55XX.Files_11_32
Characteristics=0x04
BusType=5
;------------------------------------------------------
; For AMD64 Arch
[GE-IP.NTAMD64]
; DisplayName Section DeviceId
; ----------- ------- --------
%Device.Description%= pmc55xx_Inst_AMD64, pci\ven_114a&dev_5565
[pmc55xx_Inst_AMD64.NT]
CopyFiles = PMC55XX.Files_12,PMC55XX.Files_10_32,PMC55XX.Files_11_64
Characteristics = 0x04
BusType = 5
;--------------------common--------------------------------------------------------
[pmc55xx_Inst_$ARCH$.NT.Services]
AddService =PMC55XXSERV,%SPSVCINST_ASSOCSERVICE%,pmc55xx_Service
[pmc55xx_Service]
DisplayName = "Rfm2g PCI5565 Driver"
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_SYSTEM_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\pmc55xx.sys
AddReg = pmc55xx_Parameters_AddReg
LoadOrderGroup = "Base"
[pmc55xx_Parameters_AddReg]
HKR,Ndi,Service,0,"pmc55xx"
;-------------- Coinstaller installation
[DestinationDirs]
CoInstaller_CopyFiles = 11
[pmc55xx_Inst_$ARCH$.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles
[pmc55xx_Inst_$ARCH$.NT.Wdf]
KmdfService = PMC55XXSERV, pmc55xx_wdfsect
;--------------------coinstaller common-----------------------------
[CoInstaller_CopyFiles]
WdfCoInstaller01005.dll
[SourceDisksFiles]
WdfCoInstaller01005.dll=1 ; make sure the number matches with SourceDisksNames
[CoInstaller_AddReg]
HKR,,CoInstallers32,0x00010000, "WdfCoInstaller01005.dll,WdfCoInstaller"
[pmc55xx_wdfsect]
KmdfLibraryVersion = 1.5
------------------------------------------------------------------------
Setup api log file for XP & Vista
Here is log observed in xp, Vista:
-------------------------------------
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [pmc55xx_Inst_X86.NT.Interfaces] from
"c:\windows\system32\drvstore\pmc55xx_1a0936efbfe3c187fb3dff3e11d3fdb74dde842f\pmc55xx.inf".
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of
"PCI\VEN_114A&DEV_5565&SUBSYS_00801556&REV_00\7&33B3AFA5&0&00002000E0".
#E360 An unsigned or incorrectly signed file
"c:\windows\system32\drvstore\pmc55xx_1a0936efbfe3c187fb3dff3e11d3fdb74dde842f\pmc55xx.inf"
for driver "Rfm2g PCI/PMC 5565 Driver" will be installed (Policy=Ignore).
Error 0xe000022f: The third-party INF does not contain digital signature
information.
#I163 Device not started: Device has problem: 0x27:
CM_PROB_DRIVER_FAILED_LOAD.
#I121 Device install of
"PCI\VEN_114A&DEV_5565&SUBSYS_00801556&REV_00\7&33B3AFA5&0&00002000E0"
finished successfully.
-------------------------------------------------------------------------------------
CM_PROB_DRIVER_FAILED_LOAD ==> Err msg appeared here, but same binary works
fine for Win7-32 os.
----------------------------------
vista setup api log
----------------------------------
\driverstore\filerepository\pmc55xx.inf_45cdb725\pmc55xx.inf'.
dvi: Class GUID of device remains:
{6121c478-7b3f-45b8-a2e3-330f04991213}.
dvi: Set selected driver complete.
dvi: Selected:
dvi: Description - [Rfm2g PCI/PMC 5565 Driver]
dvi: InfFile -
[c:\windows\system32\driverstore\filerepository\pmc55xx.inf_45cdb725\pmc55xx.inf]
dvi: Section - [pmc55xx_Inst_X86]
dvi: Signer - [ge fanuc automation americas,
inc.]
dvi: Rank - [0x0fff2001]
dvi: {Select Best Driver - exit(0x00000000)}
dvi: Default installer: Exit
dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x00000000)} 18:49:12.074
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 18:49:12.074
dvi: No class installer for 'Rfm2g PCI/PMC 5565 Driver'
dvi: CoInstaller 1: Enter 18:49:12.074
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 18:49:12.074
dvi: Default installer: Exit
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 18:49:12.074
dvi: {DIF_DESTROYPRIVATEDATA} 18:49:12.074
dvi: CoInstaller 1: Enter 18:49:12.074
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 18:49:12.074
dvi: Default installer: Exit
dvi: {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 18:49:12.074
dvi: {DIF_DESTROYPRIVATEDATA} 18:49:12.074
dvi: CoInstaller 1: Enter 18:49:12.074
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 18:49:12.090
dvi: Default installer: Exit
dvi: {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 18:49:12.090
<<< Section end 2010/03/03 18:49:12.090
<<< [Exit status: SUCCESS]
--------------------------------------------------------------------------
Here DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)
Thanks,
Kota
Maxim S. Shatskih
> well?, 6000 doesnt support win-7.
Why not? ever heard on "backward compat"?
Write for the oldest and lowest possible KMDF version. This will abolish the reboot requirement.
Kota
Thanks for your reply, WDK-6000 build environmets is not having the win-7
build environments, So i was doubtful about, Is it valid to use the WDK-6000
for Win-7?
From your reply, I understood that, I can still use the same.
But in WDK-7600, I observed the troubles of using KMDF 1.5 version for XP,
Vista{Same driver binaries for xp, vista works fine with KMDF-1.9}.
But it works for WIn-7 with KMDF 1.5, Is this is expected behavior or Am i
doing something wrong here?
Thanks,
Kota.
"Maxim S. Shatskih" wrote:
> .
>
Don Burn
Win7.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
> __________ Information from ESET Smart Security, version of virus
> signature database 4923 (20100307) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
Maxim S. Shatskih
> for Win-7?
Yes.
Drivers built in w2k/32bit build env in 6001 work fine on Win7.