Building a common driver binary for both XP, Vista and 7
in [Device Drivers]
|
From: Kota on 11 Feb 2010 07:32 Hi, >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: > Actually, that is a pretty lousy way to do it, since the little bit of work > 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" <skiloup(a)discussions.microsoft.com> wrote in message > news:BA7EF704-F986-4AFD-89AE-9F24C645B2FF(a)microsoft.com... > > What I do is have a build script that builds my driver for every OS and > > every > > 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. > > > > "Bo Skjoett" wrote: > > > >> I would like to build a device driver binary (.sys file) that can be used > >> in > >> 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? > >> > > > > __________ 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. > > http://www.eset.com > > > > > . >
From: Don Burn on 11 Feb 2010 09:00 There are no papers on this. But most current kernel API's have been 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" <Kota(a)discussions.microsoft.com> wrote in message news:E628FFAB-2752-4515-A854-B1E040FF2C7A(a)microsoft.com... > Hi, > >>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: > >> Actually, that is a pretty lousy way to do it, since the little bit of >> work >> 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" <skiloup(a)discussions.microsoft.com> wrote in message >> news:BA7EF704-F986-4AFD-89AE-9F24C645B2FF(a)microsoft.com... >> > What I do is have a build script that builds my driver for every OS and >> > every >> > 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. >> > >> > "Bo Skjoett" wrote: >> > >> >> I would like to build a device driver binary (.sys file) that can be >> >> used >> >> in >> >> 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? >> >> >> > >> > __________ 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. >> >> http://www.eset.com >> >> >> >> >> . >> > > __________ Information from ESET NOD32 Antivirus, version of virus > 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) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: Maxim S. Shatskih on 11 Feb 2010 13:04 > 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? 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 maxim(a)storagecraft.com http://www.storagecraft.com
From: alberto on 12 Feb 2010 13:58 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. On Feb 11, 7:32 am, Kota <K...(a)discussions.microsoft.com> wrote: > Hi, > > >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: > > Actually, that is a pretty lousy way to do it, since the little bit of work > > 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" <skil...(a)discussions.microsoft.com> wrote in message > >news:BA7EF704-F986-4AFD-89AE-9F24C645B2FF(a)microsoft.com... > > > What I do is have a build script that builds my driver for every OS and > > > every > > > 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. > > > > "Bo Skjoett" wrote: > > > >> I would like to build a device driver binary (.sys file) that can be used > > >> in > > >> 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? > > > > __________ 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. > > >http://www.eset.com > > > .- Hide quoted text - > > - Show quoted text -
From: Kota on 5 Mar 2010 06:36
Hi, 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 |