libwdi-devel Mailing List for libwdi (Page 4)
Windows Driver Installer library for USB devices
Brought to you by:
pbatard
You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(6) |
Feb
(40) |
Mar
|
Apr
(11) |
May
|
Jun
(5) |
Jul
(10) |
Aug
(8) |
Sep
(1) |
Oct
(10) |
Nov
(19) |
Dec
(1) |
2013 |
Jan
(7) |
Feb
(4) |
Mar
(9) |
Apr
(2) |
May
(1) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2014 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Pete B. <pb...@gm...> - 2012-10-11 22:07:40
|
On 2012.10.11 02:10, Liam Staskawicz wrote: > I tried the recently released libwdi-1.2.2 and see the following build > error: "1>c:\users\liam\downloads\libwdi-1.2.2\libwdi\libwdi.c(39) : > error C1083: Cannot open include file: 'embedded.h': No such file > or directory". I have adjusted msvc/config.h to point to my DDK > installation in C:/WinDDK/7600.16385.1, and disabled LIBUSB0, LIBUSBK, > and USER dirs. This is building with ddk_build.cmd from an XP x86 Free > Build shell. Before that, you probably got the following: Embedding binary resources EMBED C:\WinDDK\7600.16385.1\redist\wdf\x86\WdfCoInstaller01011.dll Couldn't open file 'C:\WinDDK\7600.16385.1\redist\wdf\x86\WdfCoInstaller01011.dll'. Unlike the subsequent one, that message doesn't appear in red, so it's easier to miss. If I had more time, I'd probably try to make sure the ddk script stops if the embedder.h generation fails... Be mindful that if you use 7600.x as the source for WinUSB, you also need to edit WDF_VER to have: #define WDF_VER 1009 Otherwise, the more recent 1011 WDF version will be used to lookup. If you change WDF_VER, I'm pretty sure that the compilation will work. > Otherwise, I can successfully build 1.2.1 with the same configuration, > but I see that when I ask wdi-simple.exe to install my device as type 0 > (WinUSB), it generates a .inf file that doesn't associate correctly with > the embedded winusb redistributables. ie, I see the expected DLLs get > embedded into wdi-simple.exe at build time, and extracted when I run it, > but the following 2 lines appear to be incorrect in the generated .inf: > > * DriverVer = 10/10/2012, 0.0.0.0 > * DisplayName = "WinUSB - Kernel Driver 10/10/2012 0.0.0.0" You will need to complain to Microsoft about that! ;) They screwed up their version level in the newer driver installer (despite not changing anything besides WDF), and libwdi is just reporting what we get... If you get 0.0.0.0, and considering your issue above, I'm pretty sure you're using the Windows 8 WinUSB files, that have that issue. And yeah, if your WDF version is wrong, the inf file will be wrong too. Please retry with the 1009 WDF version and let me know if you still have the issue. Regards, /Pete |
From: Liam S. <ls...@gm...> - 2012-10-11 01:31:38
|
On Wed, Oct 10, 2012 at 6:10 PM, Liam Staskawicz <ls...@gm...> wrote: > Hi, > > I'm trying to install a WinUSB device using wdi-simple.exe. A couple > issues I'm having: > > I tried the recently released libwdi-1.2.2 and see the following build > error: "1>c:\users\liam\downloads\libwdi-1.2.2\libwdi\libwdi.c(39) : error > C1083: Cannot open include file: 'embedded.h': No such file or directory". > I have adjusted msvc/config.h to point to my DDK installation > in C:/WinDDK/7600.16385.1, and disabled LIBUSB0, LIBUSBK, and USER dirs. > This is building with ddk_build.cmd from an XP x86 Free Build shell. > > Otherwise, I can successfully build 1.2.1 with the same configuration, but > I see that when I ask wdi-simple.exe to install my device as type 0 > (WinUSB), it generates a .inf file that doesn't associate correctly with > the embedded winusb redistributables. ie, I see the expected DLLs get > embedded into wdi-simple.exe at build time, and extracted when I run it, > but the following 2 lines appear to be incorrect in the generated .inf: > > * DriverVer = 10/10/2012, 0.0.0.0 > * DisplayName = "WinUSB - Kernel Driver 10/10/2012 0.0.0.0" > > I run wdi-simple as follows: "wdi-simple --type 0 --manufacturer "My Co." > --name "My Dev" --vid 0x22FA --pid 0x0115 --inf "my_dev.inf" --log 0" > > I can successfully use zadig to register my device with WinUSB drivers, so > it would appear I haven't configured something correctly in wdi-simple.exe. > In this case, in the generated inf those lines look like: > > * DriverVer = 07/13/2009, 6.1.7600.16385 > * DisplayName = "WinUSB - Kernel Driver 07/13/2009 6.1.7600.16385" > > which matches the version info for the extracted driver files. Any hints? > > Thanks! > Liam > Sorry - to be clear, my successful installation via Zadig is with the binary Zadig released on sourceforge, not the Zadig built locally from libwdi-1.2.1. Trying to install with my locally built version of Zadig, I see a "installation operation timed out" message (or similar, the message went away before I could copy it exactly). Thanks, Liam |
From: Liam S. <ls...@gm...> - 2012-10-11 01:10:51
|
Hi, I'm trying to install a WinUSB device using wdi-simple.exe. A couple issues I'm having: I tried the recently released libwdi-1.2.2 and see the following build error: "1>c:\users\liam\downloads\libwdi-1.2.2\libwdi\libwdi.c(39) : error C1083: Cannot open include file: 'embedded.h': No such file or directory". I have adjusted msvc/config.h to point to my DDK installation in C:/WinDDK/7600.16385.1, and disabled LIBUSB0, LIBUSBK, and USER dirs. This is building with ddk_build.cmd from an XP x86 Free Build shell. Otherwise, I can successfully build 1.2.1 with the same configuration, but I see that when I ask wdi-simple.exe to install my device as type 0 (WinUSB), it generates a .inf file that doesn't associate correctly with the embedded winusb redistributables. ie, I see the expected DLLs get embedded into wdi-simple.exe at build time, and extracted when I run it, but the following 2 lines appear to be incorrect in the generated .inf: * DriverVer = 10/10/2012, 0.0.0.0 * DisplayName = "WinUSB - Kernel Driver 10/10/2012 0.0.0.0" I run wdi-simple as follows: "wdi-simple --type 0 --manufacturer "My Co." --name "My Dev" --vid 0x22FA --pid 0x0115 --inf "my_dev.inf" --log 0" I can successfully use zadig to register my device with WinUSB drivers, so it would appear I haven't configured something correctly in wdi-simple.exe. In this case, in the generated inf those lines look like: * DriverVer = 07/13/2009, 6.1.7600.16385 * DisplayName = "WinUSB - Kernel Driver 07/13/2009 6.1.7600.16385" which matches the version info for the extracted driver files. Any hints? Thanks! Liam |
From: Pete B. <pe...@ak...> - 2012-09-19 22:43:02
|
So that it quickly gets overshadowed by the libusbx release, planned for tomorrow, I have just released libwdi v1.2.2. ;) This is a mostly a maintenance release that, besides the usual set of bugfixes and small improvements, adds the following noticeable features: - Improved support for USB 3.0 controllers, for device enumeration - Support for KMDF v1.11 and Windows Kit 8.0 WinUSB redistributable [1] - Improved libusb-win32 driver support, for use with libusbx As usual, the latest source archive can be downloaded from: https://sourceforge.net/projects/libwdi/files/releases/ For additional information, you can also check the wiki page at: https://github.com/pbatard/libwdi/wiki I'd also like to remind anyone interested that the libwdi Wiki and git repository have been moved from SourceForge to Github. If your git remote is still set to SourceForge, remember to update it to point to: git://github.com/pbatard/libwdi.git Regards, /Pete [1] msdn.microsoft.com/en-US/windows/hardware/br259104 (NB: The only improvement that appears to have been made to WinUSB redistributable in the Windows Kit 8.0 version is a 1009 -> 1011 KDMF upgrade. Especially, neither the WinUSB driver nor the WinUSB DLL appear to have seen any changes) |
From: Pete B. <pe...@ak...> - 2012-08-29 00:45:54
|
On 2012.08.28 14:15, Sethuraman R wrote: > When I Uninstalled my driver package from Control Panel -> Add or remove > programs, the entry got removed and the corresponding inf file gets > deleted. But when I plug-in my device again ( after uninstalling from > add or remove programs), the device get detected and I can see my device > in "Device Manger" and property section with "Device working properly" . > But I cant see any "setupApi.log" for this? > > The same application is working fine in Windows XP and Not working in > Windows 7! > > *The reason for this is mentioned here. That is a Null Driver is being > loaded after uninstallation with DpInst.* I think using DICS_PROPCHANGE with SetupDiChangeState() [1] (or SetupDiCallClassInstaller) is what you're after. Please have a look at the MSDN. If it helps, I'm copy/pasting some *raw* code that I used in rufus.c [2] at one stage, to perform a reset on USB flash drives (using SetupDiCallClassInstaller). > *2) How libwdi handles this scenario?* libwdi doesn't feature driver uninstallation, so we don't have to handle it :) But if we did, we'd probably do it similarly to the code pasted below. Only caveat is that it needs to run as admin, and in a 64 or 32 bit app, depending on whether your system is 64 or 32. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff550930%28v=vs.85%29.aspx [2] https://github.com/pbatard/rufus/blob/master/src/rufus.c --------------------------------------------------------------------- /* * Reset the USB device. However, this call only works if the arch is the same * meaning that if Rufus is compiled as 32 bit, this reset will not work on x64 * and an external x64 compiler app must be used to do the same */ BOOL ResetUSBDevice(char* hwid) { HDEVINFO dev_info = NULL; SP_DEVINFO_DATA dev_info_data; SP_PROPCHANGE_PARAMS prop_params; DWORD size, i, datatype; char buffer[MAX_PATH]; BOOL r = FALSE; if (hwid == NULL) return FALSE; dev_info = SetupDiGetClassDevsA(&_GUID_DEVINTERFACE_DISK, NULL, NULL, DIGCF_PRESENT|DIGCF_DEVICEINTERFACE); if (dev_info == INVALID_HANDLE_VALUE) { uprintf("SetupDiGetClassDevs (Interface) failed: %d\n", WindowsErrorString()); return FALSE; } dev_info_data.cbSize = sizeof(dev_info_data); for (i=0; SetupDiEnumDeviceInfo(dev_info, i, &dev_info_data); i++) { memset(buffer, 0, sizeof(buffer)); if (!SetupDiGetDeviceRegistryPropertyA(dev_info, &dev_info_data, SPDRP_ENUMERATOR_NAME, &datatype, (LPBYTE)buffer, sizeof(buffer), &size)) { uprintf("SetupDiGetDeviceRegistryProperty (Enumerator Name) failed: %d\n", WindowsErrorString()); continue; } if (safe_strcmp(buffer, usbstor_name) != 0) continue; memset(buffer, 0, sizeof(buffer)); if (!SetupDiGetDeviceRegistryPropertyA(dev_info, &dev_info_data, SPDRP_HARDWAREID, &datatype, (LPBYTE)buffer, sizeof(buffer), &size)) { uprintf("SetupDiGetDeviceRegistryProperty (Hardware ID) failed: %d\n", WindowsErrorString()); continue; } uprintf("Got HW ID '%s'\n", buffer); if (safe_strcmp(buffer, hwid) == 0) { uprintf("MATCH!!!!\n"); prop_params.ClassInstallHeader.cbSize = sizeof(SP_CLASSINSTALL_HEADER); prop_params.ClassInstallHeader.InstallFunction = DIF_PROPERTYCHANGE; prop_params.StateChange = DICS_PROPCHANGE; prop_params.Scope = DICS_FLAG_CONFIGSPECIFIC; //DICS_FLAG_GLOBAL; prop_params.HwProfile = 0; if ( (!SetupDiSetClassInstallParamsA(dev_info, &dev_info_data, &prop_params.ClassInstallHeader, sizeof(prop_params))) || (!SetupDiCallClassInstaller(DIF_PROPERTYCHANGE, dev_info, &dev_info_data)) ) { // will return ERROR_IN_WOW64 if ran from 32 bit app on 64 uprintf("BOY DID IT FAIL: %s\n", WindowsErrorString()); } else { uprintf("WHOA... IT ACTUALLY WORKED!\n"); r = TRUE; } break; } } SetupDiDestroyDeviceInfoList(dev_info); return r; } --------------------------------------------------------------------- |
From: Sethuraman R <set...@gm...> - 2012-08-28 13:15:13
|
Hi All, I used Dpinst.exe to install my driver package, a entry got created in Add or remove programs. Issue: When I Uninstalled my driver package from Control Panel -> Add or remove programs, the entry got removed and the corresponding inf file gets deleted. But when I plug-in my device again ( after uninstalling from add or remove programs), the device get detected and I can see my device in "Device Manger" and property section with "Device working properly" . But I cant see any "setupApi.log" for this? The same application is working fine in Windows XP and Not working in Windows 7! *The reason for this is mentioned here. That is a Null Driver is being loaded after uninstallation with DpInst.* * * *Which is mentioned in this link - http://msdn.microsoft.com/en-us/library/windows/hardware/ff549839(v=vs.85).aspx * * * *1) How to avoid the above scenario and properly uninstall my driver?* *2) How libwdi handles this scenario?* * * *Please Advice....* The below is the dpinst.log while Uninstallation : INFO: **************************************** INFO: 08/24/2012 17:40:15 INFO: Product Version 2.1.0.0. INFO: Version: 6.0.6000 INFO: Platform ID: 2 (NT) INFO: Service Pack: 0.0 INFO: Suite: 0x0300, Product Type: 1 INFO: Architecture: AMD64. INFO: Interactive Windows Station INFO: Command Line: '"C:\PROGRA~1\DIFX\0C42727449095D13\DPInstx64.exe" /u C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf' INFO: DPInst is not multi-lingual. INFO: **************************************** INFO: Current working directory: 'C:\PROGRA~1\DIFX\0C42727449095D13' INFO: Uninstall command: uninstall Inf 'C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf' INFO: Starting uninstall of 'C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf' INFO: ENTER: DriverPackageUninstallW INFO: Uninstalling driver package C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf... INFO: Successfully uninstalled 'C:\Windows\INF\oem33.inf'. ERROR: Failed to uninstall device instance ID 'USB\VID_16DE&PID_0010\6&323DD30&0&2'. (Error code 0xE0000203: There is no driver selected for the device information set or element.) INFO: No devices found for C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf uninstall. INFO: Successfully deleted properties for driver store entry 'C:\Windows\System32\DriverStore\FileRepository\drv_usb_commii.inf_amd64_neutral_a0156dbd55a28cd3\drv_usb_commii.inf'. SUCCESS:Uninstall completed. INFO: RETURN: DriverPackageUninstallW (0x0) INFO: Returning with code 0x0 INFO: 08/24/2012 17:40:17 |
From: Pete B. <pb...@gm...> - 2012-08-23 23:35:34
|
This WDK build issue should now be fixed with the latest libwdi commit. Please let me know if you still see a problem. Regards, /Pete |
From: Pete B. <pb...@gm...> - 2012-08-22 22:18:44
|
I was able to reproduce the issue, but only with OACR enabled. Without OACR, compilation seems to work fine. I'll look into it, but in the meantime, I suggest you modify your "WinXP x86 free build environment" and add no_oacr at the end, eg. C:\Windows\System32\cmd.exe /k E:\WinDDK\7600.16385.0\bin\setenv.bat E:\WinDDK\7600.16385.0\ fre x86 WXP no_oacr Regard, /Pete |
From: David G. <dav...@gm...> - 2012-08-21 21:11:38
|
Using the latest revision in the git repository (9d20009fd19c9568d2d337ea3b68199a2cb8133d) I get the following when trying to build with DDK. I don't have any problems when I try to build the latest release (1.2.1). Just thought I'd pass this along in case no one else is seeing this. I'm building on a Windows 7 64-bit machine, using DDK's WinXP x86 free build environment. D:\git\libwdi>ddk_build.cmd D:\git\libwdi\libwdi>build -bcwgZ -M2 -x86 BUILD: Compile and Link for x86 BUILD: Start time: Tue Aug 21 14:01:54 2012 BUILD: Examining d:\git\libwdi\libwdi directory for files to compile. d:\git\libwdi\libwdi Auto-cleaning queue for 'root:x86fre' (1 of 1 file(s) removed) Invalidating OACR warning log for 'root:x86fre' BUILD: Compiling and Linking d:\git\libwdi\libwdi directory Configuring OACR for 'root:x86fre' - <OACR on> _NT_TARGET_VERSION SET TO WINXP Compiling - embedder.c Linking Executable - objfre_wxp_x86\i386\embedder.exe BUILD: Finish time: Tue Aug 21 14:01:54 2012 BUILD: Done 3 files compiled 1 executable built D:\git\libwdi\libwdi>build -bcwgZ -M2 -x86 BUILD: Compile and Link for x86 BUILD: Start time: Tue Aug 21 14:01:54 2012 BUILD: Examining d:\git\libwdi\libwdi directory for files to compile. d:\git\libwdi\libwdi Auto-cleaning queue for 'root:x86fre' (1 of 1 file(s) removed) Invalidating OACR warning log for 'root:x86fre' BUILD: Compiling and Linking d:\git\libwdi\libwdi directory Configuring OACR for 'root:x86fre' - <OACR on> _NT_TARGET_VERSION SET TO WINXP Compiling - installer.c Linking Executable - objfre_wxp_x86\i386\installer_x86.exe BUILD: Finish time: Tue Aug 21 14:01:55 2012 BUILD: Done 3 files compiled 1 executable built D:\git\libwdi\libwdi>build -bcwgZ -M2 -amd64 BUILD: Compile and Link for AMD64 BUILD: Start time: Tue Aug 21 14:01:55 2012 BUILD: Examining d:\git\libwdi\libwdi directory for files to compile. BUILD: Compiling and Linking d:\git\libwdi\libwdi directory Configuring OACR for 'root:amd64fre' - <OACR on> _NT_TARGET_VERSION SET TO WS03 Linking Executable - objfre_wxp_x86\amd64\installer_x64.exe 1>errors in directory d:\git\libwdi\libwdi 1>link : error LNK1181: cannot open input file 'd:\git\libwdi\libwdi\objfre_wxp_x86\amd64\installer.obj' BUILD: Finish time: Tue Aug 21 14:01:55 2012 BUILD: Done 1 file compiled 1 executable built - 1 Error Build failed |
From: Pete B. <pb...@gm...> - 2012-08-09 19:17:44
|
(copying the reply I sent earlier when you e-mailed me personally. Have you not received my reply?) On 2012.08.09 10:39, Sethuraman R wrote: > Hello All, > I am into development of automated driver installation, with Test > certificate installation. I found libwdi and its really great. Really > Thanks for *the wonderful product. * Thanks. That's appreciated. > I have the following doubts in general and in regard with libwdi. > 1) Does Libwdi supports multiple languages? Actually my application has > to run in France, German, Portugal, China etc.. libwdi does support internationalization, yes, as we're using UTF-8 wherever internationalized strings may be used, internally. As a matter of fact, we have a whole helper layer allowing us to use UTF-8 strings with the Microsoft APIs [1]. And if you check Zadig, you should find out that it's able to handle multilingual device designation, directories, etc. We spent a great deal of time making sure we could handle those, so libwdi should fully support multiple languages, in so far as the Windows API themselves permit it. > 2) To make my application to support multi-lingual is it enough to > handle only UNICODE or UTF8? I'd advise using UTF-8 rather than UNICODE (WCHAR), though Microsoft does provide a WCHAR API, rather than an UTF-8 one, so it might be simpler to use WCHAR. Just make sure your strings are either UTF-8 or WCHAR. > 3) If UNICODE alone does the above, I found a code snippet in libwdi > which converts w_char_to_UTF8, what is the use of it. As its name indicates. We prefer using UTF-8 over WCHAR, because then it allows us to use easier to handle char* strings. > 4) Based on your answers,if I need to convert my application (does not > support UNICODE currently) to UNICODE or UTF8, what are the steps I > need to follow? Can you please provide me your valuable suggestions.. My suggestion would be to use an UTF-8 layer as we did in libwdi, since then you can continue to use char* strings in your app. However, if you are beginning with Unicode support, I'd suggest following Microsoft's advice and using TCHAR, which is what most Windows application developers tend to do [2]. You'll also understand that I'm a bit too busy to provide advice on how to switch your application to support Unicode. I strongly suggest that you use the MSDN and dedicated forums to find the answers you are looking for, starting with [3]. Of course, if you find any issue with internationalization support in libwdi itself, I'll be happy to hear about them. Regards, /Pete [1] https://github.com/pbatard/libwdi/blob/master/libwdi/msapi_utf8.h [2] http://msdn.microsoft.com/en-us/library/windows/desktop/dd374131.aspx [3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd374089.aspx |
From: Sethuraman R <set...@gm...> - 2012-08-09 09:39:31
|
Hello All, I am into development of automated driver installation, with Test certificate installation. I found libwdi and its really great. Really Thanks for *the wonderful product. * I have the following doubts in general and in regard with libwdi. 1) Does Libwdi supports multiple languages? Actually my application has to run in France, German, Portugal, China etc.. 2) To make my application to support multi-lingual is it enough to handle only UNICODE or UTF8? 3) If UNICODE alone does the above, I found a code snippet in libwdi which converts w_char_to_UTF8, what is the use of it. 4) Based on your answers,if I need to convert my application (does not support UNICODE currently) to UNICODE or UTF8, what are the steps I need to follow? Can you please provide me your valuable suggestions.. I am using mingw with gcc compiler. Target Environment : Windows xp ( 32bit and 64bit), Windows Vista ( 32bit and 64bit ), Windows 7 ( 32bit and 64bit ). Not going to get any input from the user. Thanks, Sethu |
From: Pete B. <pb...@gm...> - 2012-08-01 19:56:19
|
Hi Uri, Thanks for the patches. I have now applied all of them except this one, as I find it preferable to keep the templates embedded even if the files are not present (they are small enough for size not to be a concern and I'm still hoping to overhaul the whole driver embedding process, in which case having access to all the supported templates may be necessary). Also please note that due to SourceForge's closure of its hosted apps, libwdi is moving to github, including the git repository. Please make sure you update the git URL to: git://github.com/pbatard/libwdi.git Regards, /Pete |
From: Uri L. <ur...@re...> - 2012-07-23 15:20:33
|
--- configure.ac | 7 ++++++- libwdi/Makefile.am | 4 ++++ libwdi/libwdi.pc.in | 10 ++++++++++ 3 files changed, 20 insertions(+), 1 deletions(-) create mode 100644 libwdi/libwdi.pc.in diff --git a/configure.ac b/configure.ac index e43d1f6..3d462d3 100644 --- a/configure.ac +++ b/configure.ac @@ -325,5 +325,10 @@ AC_SUBST([AM_LDFLAGS]) AC_SUBST([LIBCONFIG_CFLAGS]) AC_SUBST([LIBCONFIG_LIBADD]) -AC_CONFIG_FILES([Makefile] [libwdi/Makefile] [examples/Makefile]) +AC_CONFIG_FILES([ +Makefile +libwdi/Makefile +libwdi/libwdi.pc +examples/Makefile +]) AC_OUTPUT diff --git a/libwdi/Makefile.am b/libwdi/Makefile.am index 7958654..92f6699 100644 --- a/libwdi/Makefile.am +++ b/libwdi/Makefile.am @@ -57,3 +57,7 @@ embedded.h: embedder $(noinst_PROGRAMS) clean-local: -rm -rf embedded.h embedder embedder.exe + + +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = libwdi.pc diff --git a/libwdi/libwdi.pc.in b/libwdi/libwdi.pc.in new file mode 100644 index 0000000..03da628 --- /dev/null +++ b/libwdi/libwdi.pc.in @@ -0,0 +1,10 @@ +prefix=@prefix@ +exec_prefix=@exec_prefix@ +libdir=@libdir@ +includedir=@includedir@ + +Name: libwdi +Description: Windows (USB) Driver Installation library +Version: @VERSION@ +Libs: -L${libdir} -lwdi +Cflags: -I${includedir} -- 1.7.7.6 |
From: Uri L. <ur...@re...> - 2012-07-23 15:20:31
|
--- libwdi/Makefile.am | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/libwdi/Makefile.am b/libwdi/Makefile.am index 92f6699..2e96dd3 100644 --- a/libwdi/Makefile.am +++ b/libwdi/Makefile.am @@ -11,7 +11,8 @@ BUILT_SOURCES = embedded.h noinst_PROGRAMS = noinst_EXES = lib_LTLIBRARIES = libwdi.la -LIB_SRC = resource.h logging.h tokenizer.h installer.h mssign32.h libwdi.h logging.c tokenizer.c vid_data.c pki.c libwdi_dlg.c libwdi.c +LIB_SRC = resource.h logging.h tokenizer.h installer.h mssign32.h logging.c tokenizer.c vid_data.c pki.c libwdi_dlg.c libwdi.c +LIB_HDR = libwdi.h if OPT_M32 noinst_PROGRAMS += installer_x86 @@ -51,6 +52,8 @@ libwdi_la_CFLAGS = $(ARCH_CFLAGS) $(VISIBILITY_CFLAGS) $(AM_CFLAGS) libwdi_la_LDLAGS = $(AM_LDFLAGS) libwdi_la_LIBADD = libwdi_rc.lo -lsetupapi -lole32 libwdi_la_SOURCES = $(LIB_SRC) +libwdi_la_HEADERS = $(LIB_HDR) +libwdi_ladir = $(includedir) embedded.h: embedder $(noinst_PROGRAMS) @./embedder embedded.h -- 1.7.7.6 |
From: Uri L. <ur...@re...> - 2012-07-23 14:59:33
|
Following the previous patch that fixes libwdi.def file itself. --- autogen.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/autogen.sh b/autogen.sh index dce765b..5d843ab 100755 --- a/autogen.sh +++ b/autogen.sh @@ -4,7 +4,7 @@ create_def() { echo "rebuidling libwdi.def file" - echo "LIBRARY" > libwdi/libwdi.def + echo 'LIBRARY "libwdi.dll"' > libwdi/libwdi.def echo "EXPORTS" >> libwdi/libwdi.def sed -n -e "s/.*LIBWDI_API.*\([[:blank:]]\)\(wdi.*\)(.*/ \2/p" libwdi/libwdi.c libwdi/vid_data.c libwdi/logging.c >> libwdi/libwdi.def # We need to manually define a whole set of DLL aliases if we want the MS @@ -35,4 +35,4 @@ autoconf || exit 1 automake -a -c || exit 1 ./configure --enable-toggable-debug --enable-examples-build --disable-debug --with-ddkdir="E:/WinDDK/7600.16385.0" --with-libusb0="D:/libusb-win32" --with-libusbk="D:/libusbK/bin" $* # rebuild .def, if sed is available -type -P sed &>/dev/null && create_def \ No newline at end of file +type -P sed &>/dev/null && create_def -- 1.7.7.6 |
From: Uri L. <ur...@re...> - 2012-07-23 14:59:27
|
libwdi.def: add name to LIBRARY line Similar to a libusbx patch 89b43a6929 by Xiaofan Chen with the same subject. The following information is found in that patch log message: * Even though the library name is optional as specified by Microsoft, some recent versions of libtool require one in libusb-1.0.def. * Reference thread in MinGW-w64 mailing list. http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/5141 --- libwdi/libwdi.def | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libwdi/libwdi.def b/libwdi/libwdi.def index 4318e1d..778c116 100644 --- a/libwdi/libwdi.def +++ b/libwdi/libwdi.def @@ -1,4 +1,4 @@ -LIBRARY +LIBRARY "libwdi.dll" EXPORTS wdi_is_driver_supported wdi_is_file_embedded -- 1.7.7.6 |
From: Uri L. <ur...@re...> - 2012-07-23 11:40:47
|
--- libwdi/embedder_files.h | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/libwdi/embedder_files.h b/libwdi/embedder_files.h index b813a74..60b867c 100644 --- a/libwdi/embedder_files.h +++ b/libwdi/embedder_files.h @@ -149,11 +149,23 @@ struct emb embeddable_fixed[] = { { 0, INSTALLER_PATH_64 "\\installer_x64.exe", "." }, #endif // inf templates for the tokenizer ("" directory means no extraction) +#if defined(DDK_DIR) { 0, "winusb.inf.in", "" }, +#endif +#if defined(LIBUSB0_DIR) { 0, "libusb0.inf.in", "" }, +#endif +#if defined(LIBUSBK_DIR) { 0, "libusbk.inf.in", "" }, +#endif // cat file lists for self signing +#if defined(DDK_DIR) { 0, "winusb.cat.in", "" }, +#endif +#if defined(LIBUSB0_DIR) { 0, "libusb0.cat.in", "" }, +#endif +#if defined(LIBUSBK_DIR) { 0, "libusbk.cat.in", "" }, +#endif }; -- 1.7.7.6 |
From: Pete B. <pb...@gm...> - 2012-07-12 09:59:54
|
On 2012.07.12 10:51, Arnon Gilboa wrote: > At least from several runs on my desktop, when calling wdi_create_list I > get different device_id You mean device instance IDs. The Device/Hardware ID (usb\vid_####&pid_####) should be the same. > for each instance of the same vid:pid, even when > drivers are not installed. So why not use device_id in libwdi to differ > between instances? Because libwdi relies on the UpdateDriverForPlugAndPlayDevices() API call to perform the installation, and the call takes a Device/Hardware ID that is usually the same for all devices with the same VID:PID. Thus the installation will occur for all matching devices at once. As stated in [1]: Given an INF file and a hardware ID, the UpdateDriverForPlugAndPlayDevices function installs updated drivers for devices that match the hardware ID. It doesn't matter if we can further differentiate devices in libwdi compared to what UpdateDriverForPlugAndPlayDevices() does, as we will be limited by what the latter call can do. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534%28v=vs.85%29.aspx |
From: Arnon G. <ag...@re...> - 2012-07-12 09:45:19
|
Pete Batard wrote: > Hi Arnon, > > On 2012.07.11 16:54, Arnon Gilboa wrote: > >> I have several instances of the same device (same vid:pid). >> When I use wdi_prepare_driver() and wdi_install_driver() on a specific >> device (found by its device_id), it installs the driver on all the >> plugged instances with the same vid:pid. >> I would like to install the driver only on the specified device_id. Any >> way to do that? >> > > If you haven't got it already, can you please download and run the > latest version of Zadig from > https://sourceforge.net/projects/libwdi/files/zadig/, the go to the > Options menu and check: "List All Devices", "Advanced Mode" as well as > set "Log Verbosity" to "Debug" and then plug in at least two of your > devices. > > If you see the Hardware ID reported for both devices as identical (and > unless your devices have different revisions, since they have same > VID:PID, they probably are), then it is unlikely that libwdi will be > able to install a driver for only one device. > > The reason is we are using UpdateDriverForPlugAndPlayDevices() [1], > which takes the Hardware ID as parameter, and, since there is no > additional parameter we can use to differentiate devices with the same > Hardware ID, which will install a driver for all devices that match. > > Unfortunately, I don't think there exists a method that lets Window only > target a specific device for driver installation when hardware IDs are > the same. Specifically, doing so would require using a device instance > ID which, as far as I recall, is only generated once a driver a device > has been installed => chicken and egg problem. > At least from several runs on my desktop, when calling wdi_create_list I get different device_id for each instance of the same vid:pid, even when drivers are not installed. So why not use device_id in libwdi to differ between instances? > You may also want to have a look at [2] for additional info. > > Regards, > > /Pete > > > [1] > http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534%28v=vs.85%29.aspx > [2] > http://msdn.microsoft.com/en-us/library/windows/hardware/ff549553%28v=vs.85%29.aspx > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libwdi-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libwdi-devel > |
From: Pete B. <pb...@gm...> - 2012-07-11 22:18:23
|
Hi Arnon, On 2012.07.11 16:54, Arnon Gilboa wrote: > I have several instances of the same device (same vid:pid). > When I use wdi_prepare_driver() and wdi_install_driver() on a specific > device (found by its device_id), it installs the driver on all the > plugged instances with the same vid:pid. > I would like to install the driver only on the specified device_id. Any > way to do that? If you haven't got it already, can you please download and run the latest version of Zadig from https://sourceforge.net/projects/libwdi/files/zadig/, the go to the Options menu and check: "List All Devices", "Advanced Mode" as well as set "Log Verbosity" to "Debug" and then plug in at least two of your devices. If you see the Hardware ID reported for both devices as identical (and unless your devices have different revisions, since they have same VID:PID, they probably are), then it is unlikely that libwdi will be able to install a driver for only one device. The reason is we are using UpdateDriverForPlugAndPlayDevices() [1], which takes the Hardware ID as parameter, and, since there is no additional parameter we can use to differentiate devices with the same Hardware ID, which will install a driver for all devices that match. Unfortunately, I don't think there exists a method that lets Window only target a specific device for driver installation when hardware IDs are the same. Specifically, doing so would require using a device instance ID which, as far as I recall, is only generated once a driver a device has been installed => chicken and egg problem. You may also want to have a look at [2] for additional info. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff553534%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/windows/hardware/ff549553%28v=vs.85%29.aspx |
From: Sethuraman R <set...@gm...> - 2012-07-11 16:08:11
|
Hi All, I'm using windows default driver Usbser.sys for my Embedded device to connect it with my PC. I need to create a LAN connection between my PC and my Embedded device. I used Ras dial to achieve this. But the problem here is before making the dial-up connection I need to create a Modem. I follow the below steps to create a Modem. Control Panel -> Phone and Modem options -> Navigate To Modem Menu -> Click Add button -> Select “Don’t detect my modem;I will select it from a list” -> Select “Communications cable between two computers” and click Next button -> Selected my COM port in which device is connected -> Finish. And below is my SetupApi.log when installing the new modem: [2012/07/11 21:07:12 4324.27 Driver Install] #-198 Command line processed: "C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\shell32.dll,Control_RunDLL "C:\WINDOWS\system32\telephon.cpl",Phone and Modem Options #I060 Set selected driver. [2012/07/11 21:07:12 4324.28] #-198 Command line processed: "C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\shell32.dll,Control_RunDLL "C:\WINDOWS\system32\telephon.cpl",Phone and Modem Options #-166 Device install function: DIF_INSTALLDEVICE. #I123 Doing full install of "ROOT\MODEM\0009". #-011 Installing section [M2700] from "c:\windows\inf\mdmhayes.inf". #I121 Device install of "ROOT\MODEM\0009" finished successfully. How to achieve this part ( creating New Modem ) Programatically? Is there any Windows APIs available or is there a way to do this with writing some inf files? Please Suggest me to proceed. Thanks.. |
From: Arnon G. <ag...@re...> - 2012-07-11 15:48:22
|
Hi all, I have several instances of the same device (same vid:pid). When I use wdi_prepare_driver() and wdi_install_driver() on a specific device (found by its device_id), it installs the driver on all the plugged instances with the same vid:pid. I would like to install the driver only on the specified device_id. Any way to do that? Thanks, Arnon |
From: Liam S. <ls...@gm...> - 2012-06-18 19:13:22
|
On Mon, Jun 18, 2012 at 11:59 AM, < lib...@li...> wrote: > > Message: 7 > Date: Mon, 11 Jun 2012 23:31:25 +0100 > From: Pete Batard <pb...@gm...> > Subject: Re: [libwdi-devel] wdi-simple WinUSB installation > To: lib...@li... > Message-ID: <4FD...@gm...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Liam, > > On 2012.06.11 21:42, Liam Staskawicz wrote: > > I'm trying to determine the simplest way to register a device of mine as > > a WinUSB device within an InnoSetup installer. I've been following along > > through the signed driver walkthrough > > ( > http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Signed_driver_walkthrough#Creating_a_signed_cat_file > ), > > but I am not sure which parts of that apply for a WinUSB installation > > only, as opposed to a custom driver. > > > > I was hoping to use wdi-simple, but am not sure which other resources I > > need. If I generate an INF file with INF wizard, it generates > > installer_x86/64.exe and has duplicates of some of the winusb driver > > DLLs, but I thought that since WinUSB ships on (suitably recent) Windows > > machines, that I wouldn't need to install WinUSB myself? > > Unfortunately, it's not that simple. The default installation of WinUSB > does not rely on the provision of a winusb.sys and winusb.dll, as would > be the case with a regular driver. Instead it does require the provision > of 2 rather large CoInstaller DLLs, in case an upgrade of the WinUSB > files existing on the system is necessary, or if no existing WinUSB > driver is available, and these DLLs are rather large because of KMDF > requirements. > > Please see point 4. at the bottom of > > http://msdn.microsoft.com/en-us/library/windows/hardware/ff540283%28v=vs.85%29.aspx > : > > "The KMDF co-installer (WdfcoinstallerXXX.dll) installs the correct > version of KMDF on the target system, if necessary. The version of > WinUSB co-installer must match the KMDF co-installer because KMDF-based > client drivers, such as Winusb.sys, require the corresponding version of > the KMDF framework to be installed properly on the system. For example, > Winusbcoinstaller2.dll requires KMDF version 1.9, which is installed by > Wdfcoinstaller01009.dll." > > Unfortunately, Microsoft does not appear to endorse any other way of > using WinUSB as a driver outside of using the CoInstaller DLLs, even if > WinUSB might already be available. And because libwdi aims at being > generic, we follow Microsoft's recommendations. > > On systems where WinUSB is pre-installed, it may be possible to simply > reference the WinUSB.sys and WinUSB.dll driver files in the inf, but > this method is not documented and it prevents targets, such as Windows > XP, from being supported, as well as potentially limit systems to using > older versions of WinUSB. > > If you don't do that, then to be as generic as possible, 4 DLLs need to > be provided (2 for x86_32 and 2 for x86_64), regardless of whether the > target OS may already have the necessary components to run WinUSB. And > of course, since we want to support either x86_32 and x86_64 with a > single application, both installers are provided (as it is not possible > to run a 32 bit driver installer on a 64 bit platform), hence the files > you see extracted with libwdi. > > I would say that, unless space is really an issue with your application > redistributable, you probably should stick with the Microsoft > recommended approach for WinUSB installation, which is what wdi-simple > provides. > > Regards, > > /Pete > Hi Pete - thanks for the response. Sorry I did not respond sooner - I'm subscribed to the digest version of the mailing list, and it looks like there wasn't enough traffic to trigger a new digest until just now :) This makes sense, though it still just makes me a bit sad that Windows makes it so difficult. I'll likely end up signing the package generated by inf-wizard and installing as you've described. A bit of extra work, but no real blockers. Thanks again, Liam |
From: Pete B. <pb...@gm...> - 2012-06-18 18:59:30
|
Hi Sethu, On 2012.06.18 14:26, Sethuraman R wrote: > I have a doubt with regard to libwdi.In libwdi manifest has been written > with requestedExecutionLevel as "highest available", which will be > working fine for UAC controls. But the option in Local security policy - > "Only elevate executable files that are signed and validated" is enabled > what will happen with libwdi? If the local security policy is enabled, then the policy will in effect prevent a non-signed application from running, including libwdi-based one, as it requires elevation. Whether static or shared, the library of runs in the same context as the application that uses it, and it makes no attempt at overriding local policies. If the application does not start as elevated, libwdi will request elevation during driver installation, which, depending on whether the application is signed or not, should either succeed or return an error. > How it is handled in libwdi? As per the policy restrictions: If your libwdi based application is signed, then you should be able to run it. If not, then you should get an error. For the record, the official Zadig libwdi based installer application is digitally signed, so it can still be used when such a policy is active. But if you want to develop a libwdi based application and use it in an environment where the policy above is in use, you will have to sign it. The recommendation is also to start your application with elevated privileges rather than let libwdi request elevation during installation, as this will minimize installation prompts. It is not possible to install a driver outside of elevate mode. Regards, /Pete |
From: Sethuraman R <set...@gm...> - 2012-06-18 13:26:50
|
Dear All, I have a doubt with regard to libwdi.In libwdi manifest has been written with requestedExecutionLevel as "highest available", which will be working fine for UAC controls. But the option in Local security policy - "Only elevate executable files that are signed and validated" is enabled what will happen with libwdi? How it is handled in libwdi? Regards, Sethu |