libwdi-devel — libwdi development

Re: [libwdi-devel] libwdi

[Pete B. <pb...@gm...>]

Hi Bob,

On 2012.02.02 22:55, Bob Paddock wrote:
> With the help of Verisign support this is what I found my problem to be:
>
> In CertMgr if the Certification Path for your certificate only shows
> three items in the tree, it means there will be problems using the
> certificate on XP machines that are not up to date.
>
> The problem stems back from the original private key that was exported out
> of Windows to make the .pfx file.  If the file is around 6.6K it
> indicates that part of the chain is missing, that it seems outdated XP
> machines need, and nothing else does.  The .pfx file needs to be
> around the size of 7.4K if it has the correct chain of certificates to
> make XP happy.  The exact file size will vary somewhat due to
> variations of length in the certificate name (has nothing to do with
> the name of the file), and the particular CA that was used.
>
> When you export the Private Key make sure 'Include all certificates in
> the certificate path if possible' and 'Export all extended properties'
> are checked, to make old XP machines happy.
> May have been an other click or two to disable none code-signing
> usage, not sure it was required.
>
> I asked Verisign support where this was documented and they said 'it
> was not documented'.
>
> Wanted to document this to save others from the frustrating experience
> this has been.

Thanks a lot for this information! I'm still trying to find the time to 
update the Signed Driver walkthrough with some of this good data. 
Hopefully, I'll have done that by the end of next week, and I'll let you 
know so that you can review it.

Regards,

/Pete

Re: [libwdi-devel] libwdi

[Bob P. <bob...@gm...>]

> ...
>
> Then I see:
> [syslog] #E367 An unsigned or incorrectly signed file
> "C:\Temp\usb_driver\usb_port.cat" for [SIC] will be installed
> (Policy=Warn, user said ok). Error 0x800b0110: The certificate is not
> valid for the requested usage.
>
> :-(
>
> As far as I know I signed the .cat files correctly.

With the help of Verisign support this is what I found my problem to be:

In CertMgr if the Certification Path for your certificate only shows
three items in the tree, it means there will be problems using the
certificate on XP machines that are not up to date.

The problem stems back from the original private key that was exported out
of Windows to make the .pfx file.  If the file is around 6.6K it
indicates that part of the chain is missing, that it seems outdated XP
machines need, and nothing else does.  The .pfx file needs to be
around the size of 7.4K if it has the correct chain of certificates to
make XP happy.  The exact file size will vary somewhat due to
variations of length in the certificate name (has nothing to do with
the name of the file), and the particular CA that was used.

When you export the Private Key make sure 'Include all certificates in
the certificate path if possible' and 'Export all extended properties'
are checked, to make old XP machines happy.
May have been an other click or two to disable none code-signing
usage, not sure it was required.

I asked Verisign support where this was documented and they said 'it
was not documented'.

Wanted to document this to save others from the frustrating experience
this has been.



-- 
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/

Re: [libwdi-devel] libwdi

[Bob P. <bob...@gm...>]

> OK, I found that old e-mail. I'm copy/pasting it, but I think it should
> still apply. I generated 2 certs in this method, one for a fake authority
> and one for the signing of the cat.
> -------------------------------------------------------------------------
> Here's how you can do it, from a WinDDK prompt:
>
> makecert -r -pe -n "CN=SELF SIGNED DRIVER TEST AUTHORITY" -sr localmachine
> -a sha1 -cy authority -sky signature -sv selfroot.pvk selfroot.cer
> (you'll be prompted for password twice)
>
> makecert -pe -n CN="SELF SIGNED DRIVER TEST" -a sha1 -sky signature -eku
> 1.3.6.1.5.5.7.3.3 -ic selfroot.cer -iv selfroot.pvk -sv selfsign.pvk
> selfsign.cer
> (again prompted)
>
> pvk2pfx -pvk selfsign.pvk -spc selfsign.cer -pfx selfsign.pfx
>
> Then from an elevated prompt, one can install the certificates in the system
> store with:
>
> CertMgr /add selfroot.cer /s /r localMachine root
> CertMgr /add selfsign.cer /s /r localMachine trustedpublisher
>
> Finally, to create the signed .cat, in the directory where you have the
> .inf:
>
> inf2cat /v /driver:. /os:XP_X86,XP_X64,Vista_X86,Vista_X64,7_X86,7_X64
> signtool sign /v /ac selfsign.cer /f selfsign.pfx *.cat
>
> Once you have done all the above, you can get promptless driver
> installation. I suppose doing it with a single self signed cert, that is
> installed in both root and trustedpublisher will work as well, but I haven't
> tried it.
> ------------------------------------------------------------------------

Turned the above into a .bat file.  End result was still getting 'cat
not signed, or not signed correctly for the intended usage'.
:-(

Thank you for the detailed answer in the other message.

Re: [libwdi-devel] libwdi

[Pete B. <pb...@gm...>]

On 2012.01.30 01:26, Bob Paddock wrote:
> On Sun, Jan 29, 2012 at 7:02 PM, Pete Batard<pb...@gm...>  wrote:
>
>> Verisign is only there for application&  cat signing.
>
> I'm still confused.  That says Verisign is there for the .cat, which
> is what I'm not getting to work?

Well, you are currently signing your cat with your driver signing 
credentials, for which the security chain ultimately ends up with a 
Microsoft root certificate, not a Verisign one, AFAIK. This is a 
completely different security chain than the one used for app/cat signing.

The way Verisign is able to provide driver signing credentials that work 
for driver signing, even if Microsoft is the only the root CA there, is 
that Microsoft generated an intermediate credential for them to use 
(public and private key pair) to generate the credentials you got and 
the the public key of this intermediate credential is contained in the 
Verisign .cer that you use for cross signing. When you cross sign with 
this cer, the root chain becomes:

Microsoft driver signing root cert -> Verisign driver signing 
intermediate cert -> cert that you used to sign the driver.

But this Verisign .cer is different from the Trusted Root CA Verisign 
certificate that one can find in the certificate store (the same company 
can have different root certificates used for different validation 
chains) and it doesn't appear to be linked to the security chain that is 
used for application signing.

In other words, the Verisign root cert(s) that you find in the 
certificate store have no link whatsoever with the Verisign driver 
signing intermediate cert.

I think the intermediate cert is also crafted in a special way, so that 
even if you install itt as trusted root CA cert in the cert store, you 
will still not be able to validate a signature. Else, people would 
probably be using that as a workaround on XP. I think I tested that, but 
that was some time ago, so I might be off.

>  From the details provided it seems that Verisign can not be used to
> sign a .cat, but a self-signed-cert needs to be cross signed by
> Verisign, to make an acceptable .cat for a driver?

Yes. That's because there are 2 different security chains that validate 
either drivers or cat+apps. What works for one may not work for the 
other, and the root certs from one are also different from the root 
certs of the other.

> So I now need to install two certs?  My PubKey.cer,  from Verisign,
> for the .sys and .dlls, and the self-signed cert for the .cat?
> Does the order there certs are installed mater?  Run wdi for each cert?

You don't have to install the PubKey.cer. It's only be valid for the 
driver validation chain and unneeded because it is already embedded, 
along with the driver signing Verisign cross certificate in the signed 
sys and dll and its chain already ends up with a root cert that is 
trusted by the system.

Our problem with the cat is that either when using the PubKey.cer or a 
self-signed cer, the validation chain doesn't end up with a cert that is 
trusted by the system, for cat validation, so it must be installed.

Thus, the only .cer you need to provide to libwdi is either a self 
signed one, or a regular code signing one, so that it can install it as 
trusted.

> So the .sys and .dlls found in usb_driver will get copied someplace
> into \Windows, but not a place that they are yet used.

Yes. On Windows 7 that's C:\Windows\System32\DriverStore\FileRepository 
and you will the inf and all the files referenced by the inf there, 
ready to be installed when the device is plugged in.

> I did a DIR /s of \Windows looking for the files, but didn't see them
> anyplace, other than system32\drivers, could be because it was already
> in the right place in system32\driver, from past failed attempts (been
> a lot of those with the official Microsoft tools).

Haven't checked XP, but it should have a driverstore equivalent.

> I'm trying to do a PreInstall.  There are several different devices
> with different PIDs.
> No way to know which one will be installed in advance.

That shouldn't be a problem. As long as you either have a single inf 
with multiple VID:PID, or multiple infs with single VID:PID, and 
"install" them, they will be copied to driverstore, along with the 
files, and Windows will install the driver when the relevant device is 
plugged.

Regards,

/Pete

Re: [libwdi-devel] libwdi

[Bob P. <bob...@gm...>]

On Sun, Jan 29, 2012 at 7:02 PM, Pete Batard <pb...@gm...> wrote:

> Verisign is only there for application & cat signing.

I'm still confused.  That says Verisign is there for the .cat, which
is what I'm not getting to work?

>From the details provided it seems that Verisign can not be used to
sign a .cat, but a self-signed-cert needs to be cross signed by
Verisign, to make an acceptable .cat for a driver?

> OK, I found that old e-mail. I'm copy/pasting it, but I think it should
> still apply. I generated 2 certs in this method, one for a fake authority
> and one for the signing of the cat.

Thank you.

> Once you have done all the above, you can get promptless driver
> installation...

So I now need to install two certs?  My PubKey.cer,  from Verisign,
for the .sys and .dlls, and the self-signed cert for the .cat?
Does the order there certs are installed mater?  Run wdi for each cert?

>> Something I've been unclear about, I need to read more of the wdi docs.
>> When I use the --inf option I see that the .inf gets copied.  I'm not
>> seeing that the .sys's and .dll are getting copied.
>> Do I need to do something else?
>
> the driver is actually installed. This is a two step process:
>
> 1. Windows copies the inf and inf referenced files to the driver store.

So the .sys and .dlls found in usb_driver will get copied someplace
into \Windows, but not a place that they are yet used.
I did a DIR /s of \Windows looking for the files, but didn't see them
anyplace, other than system32\drivers, could be because it was already
in the right place in system32\driver, from past failed attempts (been
a lot of those with the official Microsoft tools).

> driver store is a different location than System32, etc, so while the files
> are copied onto the system at this stage, they are only available in the
> driver store. If Windows doesn't detect any device referenced by the inf at
> this stage, the driver installation process stops there (and nothing gets
> installed in system32).

I'm trying to do a PreInstall.  There are several different devices
with different PIDs.
No way to know which one will be installed in advance.

Re: [libwdi-devel] libwdi

[Pete B. <pb...@gm...>]

On 2012.01.29 17:23, Bob Paddock wrote:
>>>> be that XP only seems to be able to recognize authenticode (i.e. driver
>>>> signing) certificate when used for driver binary signing
>
> That would be the .sys and .dlls?

Yes

>> and not for anything else.
>
> The .cats ?

Yes. Windows uses a different security validation mechanism for driver 
files and for everything else. As a matter of fact, the Trusted Root CAs 
for drivers contains different root certificates than the Trusted Root 
CAs for applications and cats.

This is actually the reason why you can use a self-signed crdedential to 
sign a cat, as long as you install the cert part as trusted root 
CA/Publisher.

>> On XP, that seems to be the case. On the other hand, XP seems to be more lax
>> when it comes to code signing that later versions, and once again, you can
>> create your own self-signed credentials (which of course is free), though
>> this then requires installing the cert in the certificate store, which
>> libwdi can also do for you, and which you would also have to do with the
>> Verisign cert, as it is also not recognized by default as a trusted
>> certification authority for applications/cat.
>
> Do you mean the cert I bought from VeriSign, or VeriSign's cert (next
> level up from mine)?
> I can understand having to install mine, but why isn't VeriSigns already there?

Verisign is only there for application & cat signing. My current 
understanding is that for driver signing, there is actually only one 
root CA, which is a Microsoft one, and that this is the reason why we 
nee to cross sign with a Versign, GlobalSign or someone else's .cer when 
signing the driver.

>> If I have a chance, I'll try to dig up the process of creating a self signed
>> credential to sign the cat, which I think I have in an old mail, but this
>> may take a while. I'll also try to mention something about the XP limitation
>> on the Wiki.
>
> I'd appreciate that.

OK, I found that old e-mail. I'm copy/pasting it, but I think it should 
still apply. I generated 2 certs in this method, one for a fake 
authority and one for the signing of the cat.
-------------------------------------------------------------------------
Here's how you can do it, from a WinDDK prompt:

makecert -r -pe -n "CN=SELF SIGNED DRIVER TEST AUTHORITY" -sr 
localmachine -a sha1 -cy authority -sky signature -sv selfroot.pvk 
selfroot.cer
(you'll be prompted for password twice)

makecert -pe -n CN="SELF SIGNED DRIVER TEST" -a sha1 -sky signature -eku 
1.3.6.1.5.5.7.3.3 -ic selfroot.cer -iv selfroot.pvk -sv selfsign.pvk 
selfsign.cer
(again prompted)

pvk2pfx -pvk selfsign.pvk -spc selfsign.cer -pfx selfsign.pfx

Then from an elevated prompt, one can install the certificates in the 
system store with:

CertMgr /add selfroot.cer /s /r localMachine root
CertMgr /add selfsign.cer /s /r localMachine trustedpublisher

Finally, to create the signed .cat, in the directory where you have the 
.inf:

inf2cat /v /driver:. /os:XP_X86,XP_X64,Vista_X86,Vista_X64,7_X86,7_X64
signtool sign /v /ac selfsign.cer /f selfsign.pfx *.cat

Once you have done all the above, you can get promptless driver 
installation. I suppose doing it with a single self signed cert, that is 
installed in both root and trustedpublisher will work as well, but I 
haven't tried it.
------------------------------------------------------------------------

> Something I've been unclear about, I need to read more of the wdi docs.
> When I use the --inf option I see that the .inf gets copied.  I'm not
> seeing that the .sys's and .dll are getting copied.
> Do I need to do something else?

The sys and dll are copied over when the driver is actually installed. 
This is a two step process:

1. Windows copies the inf and inf referenced files to the driver store. 
The driver store is a different location than System32, etc, so while 
the files are copied onto the system at this stage, they are only 
available in the driver store. If Windows doesn't detect any device 
referenced by the inf at this stage, the driver installation process 
stops there (and nothing gets installed in system32).

2. When the device is available, Windows searches for a compatible inf 
in the driver store, using the device hardware ID, and if it finds a 
match, processes it to copy the files referenced to the target 
designated by the inf. It's only at this stage that the files are 
actually installed onto the system.

Most of the time, you would install a driver for a device that is 
already present, so the 2 steps will occur one after the other, but this 
is not always the case. Also, step 2 is handled entirely by Windows 
alone. Libwdi only worries about step 1, which is making sure that 
Windows will be able to find the inf and relevant files into the store 
for step 2.

> Also I have two .inf that need installed.  Run wdi twice or put --inf
> on the command line twice?

Run twice I'm afraid, at least with wdi-simple. Or you can modify 
wdi-simple to run multiple infs if needed, but I tried to keep things 
simple for the time being.

Regards,

/Pete

Re: [libwdi-devel] libwdi

[Bob P. <bob...@gm...>]

> I signed the DLL's and SYS's, then ran inf2cat then signed the cats with:
>
> signtool sign /v /ac MSCV-VSClass3.cer /f keys.pfx /p %SIGN_PASSWORD%
> usb_port.cat

signtool sign /v /ac MSCV-VSClass3.cer /f keys.pfx /p %SIGN_PASSWORD%
/n "Name"  usb_port.cat

The /n "Name" got cut off in transferring between machines.

Re: [libwdi-devel] libwdi

[Bob P. <bob...@gm...>]

> I think SourceForge falsely mention that the list is read-only when
> displaying the archives. If you susbcribe to the list you should be able to
> post.

Should be subscribed now.  You might see two of these replies, I'll
use the list hereafter.

> Look like it. Since you have access to XP, I think the easiest way to obtain
> the cer is to import your pfx file into the Windows certificate store
> (double clickling the pfx should guide you on how to do that), and once it
> is there, you can open the certificate store and export the .cer. For
> instance, you can do that by launching Internet Explorer and then go to
> Options -> Internet Options -> Certificates. Then, once you have located
> your credentials, click the export button to export a .cer that Windows can
> handle...

> That's something I'd like to know too, so that I can provide it on the wiki...

Okay.  I figured out how to export a working cert that way.
Once I saw what the format looked like, I quickly figured out the
proper openssl commands:

openssl pkcs12 -in keys.pfx -out keys.pem -nodes
openssl x509 -in keys.pem -inform PEM -out PubKey.cer -outform DER

To view:
openssl x509 -in PubKey.cer -inform DER -text

Running:
wdi-simple --type 3 -l0 --inf "usb_port.inf" --cert "PubKey.cer"
now says:

... certificate 'PubKey.cer' successfully added as Trusted Publisher Success

Yeah!!

...

Then I see:
[syslog] #E367 An unsigned or incorrectly signed file
"C:\Temp\usb_driver\usb_port.cat" for [SIC] will be installed
(Policy=Warn, user said ok). Error 0x800b0110: The certificate is not
valid for the requested usage.

:-(

As far as I know I signed the .cat files correctly.
I signed the DLL's and SYS's, then ran inf2cat then signed the cats with:

signtool sign /v /ac MSCV-VSClass3.cer /f keys.pfx /p %SIGN_PASSWORD%
usb_port.cat

Other than missing the timestamping there, did I do something wrong?
Does it have to be WINQL stamped to get that message to go away?

Re: [libwdi-devel] libwdi

[Pete B. <pb...@gm...>]

Hi Bob,

On 2012.01.28 20:01, Bob Paddock wrote:
> I could not find a working help form, and sourceforge devel list is
> 'read-only'

I think SourceForge falsely mention that the list is read-only when 
displaying the archives. If you susbcribe to the list you should be able 
to post.

> didn't really want to bother you directly, some dev's
> don't like that.

I don't mind. I tend to prefer when problems and their resolution become 
public (which is why I'm CC'ing the list on this reply), but whatever 
suits you better is fine.

> I need some help please.  I'm following this:
> http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Signed_driver_walkthrough
>
> I seem to be having trouble with this part:
> "If you have openssl installer [I do on my Linux box], you could use
> the pkcs12 and x509 option to extract the .cer from the command line."
>
> My question is how?

That's something I'd like to know too, so that I can provide it on the 
wiki, as I haven't tried it. If you're running Windows, you should be 
able to export the certificate part without going through openssl, so 
that's why I haven't investigated it further.

>  This is what I'm doing, and what is going wrong:
>
> Running:
>   wdi-sample ... -l0 --inf "usb_bus.ini" --cert mycert.cer ... says:
>
> Installing certificate 'mycert.cer' as Trusted Publisher...
> libwdi:info [detected version] Widnows XP
> libwdi:warning [AddCerToTrustedPublisher] could not create context for
> certificate: [#8009310B] ASN1 bad tag value met.
>
> Looking at mycert.cer with Widnows Explore says this:
> Dialog frame says "Invalid Public Key Security Object File" with a
> text of "This file is invalid for use as the following: Security
> Certificate".
>
> Clearly I've created my mycert.cer file in a way that is not
> compatible with libwdi and/or Windows.

Look like it. Since you have access to XP, I think the easiest way to 
obtain the cer is to import your pfx file into the Windows certificate 
store (double clickling the pfx should guide you on how to do that), and 
once it is there, you can open the certificate store and export the 
.cer. For instance, you can do that by launching Internet Explorer and 
then go to Options -> Internet Options -> Certificates. Then, once you 
have located your credentials, click the export button to export a .cer 
that Windows can handle.

Can you try that and let me know how it goes?

> What I'm trying to do is setup a FTDI USB-Serial cable, with a custom
> name and VID/PID.
>
> I'm using these files:
>
> http://www.ftdichip.com/Drivers/CDM/Beta/CDM20817.zip
>
> I've signed the appropriate files and catalogs with my VeriSign Code
> Signing certificate via
> signtool etc.
>
> I just can't seem to find the right magic command line, after many
> many tries, to openssl to convert my importantkeys.pfx file to a
> proper form of .cer that libwdi will pass on happily to Windows.

Openssl is a hairy beast. I tried to locate a "magic command" that I 
could put on the wiki, but couldn't find one, and I think I may have 
given it a few tries but without success.

> How I create the needed .cer file from the pfx file that I have?

The easiest way would have to be the import/export method using the 
Windows certificate store.

> Adding that answer to the Wiki would also help others like me, from
> bothering you in the future too.

I'll see what I can do. Please let me know if the import/export works 
for you.

Regards,

/Pete

Re: [Libwdi-devel] wdi-simple for VC++6 or precompiled?

[Pete B. <pb...@gm...>]

Hi Elmi,

On 2011.12.20 10:36, Satz Klauer wrote:
> I plan to use libwdi-simple to auto-install an USB-driver out of an
> setup. Unfortunately it seems like there is no possibility for
> MSVC-users to compile it from scratch.

Well, you will understand that with libwdi being mostly a one man 
project, I had to draw the line, especially after already providing 
support for 4 different development environments. Also, considering that 
MSVC6 is on the way, unless someone proposes to add and maintain support 
for it, I have no plans to do so.

> Beside of that the Windows DDK is a fairly huge BLOB of data.

I'm not seeing this way. With the latest DDK you get a 32 + 64 bit 
compilation environment, which is not that much bigger compared to 
others, especially as it comes with samples, and which is actually 
extremely straightforward to use when recompiling libwdi.

I think the smallest win32 development you will find these days is 
MinGW32, and it's probably about half size. Also, last time I checked 
MSVC6 came on 2 or 3 CDs while the WDK only comes on one. By this 
rationale, shouldn't we say that MSVC6 a fairly huge BLOB of data as well?
As to the space it occupies once installed, unless your budget is very 
limited in terms of storage hardware, this shouldn't be an issue either 
in 2011.

Therefore, I can't really see how the DDK qualifies as a huge BLOB of 
data any more than another development environment.

> So the efforts to create wdi-simple
> just for a plain and simple installer seem to be fairly huge.

Sorry, but I strongly disagree there.

Installing the WDK is a no brainer. It's a relatively large download if 
your internet connection is slow, as any development environment will 
be, but its setup is as straightforward as it comes. And with MinGW-get, 
installing MinGW + msys is also very straightforward (provided that your 
development platform has a direct internet connection).

Therefore I strongly disagree that the efforts to compile a simple 
installer is huge, as far as installing one of the supported development 
environments goes. It may take a little time, but most of this time is 
spent on unattended installation, so the effort is actually quite 
minimal. Understandably, having to familiarize yourself with a new 
development environment will always seem daunting, but if you actually 
give it a try, you may be pleasantly surprised at how easy it is to use.

Now, if size is your concern, have you actually tried msys-get-inst [1]? 
The last time I set a MinGW environment up, which was for Clang 
recompilation, I was surprised at how easy it has become to get MinGW 
installed (and considering that your preference is MSVC6, I assume that 
you only need 32 bit?). As a matter of fact, the MinGW installation only 
takes one point in the post I wrote for getting Clang running on 
Windows, which should indicate that there is very little to get MinGW32 
installed these days [2].

> So my question: are there any ready-to-use binaries available somewhere?

As indicated in the FAQ [3], providing snapshots would require an effort 
that is greater than what most libwdi users consider, because many 
combinations may be required (especially as MSVC and MinGW static 
libraries are incompatible). Therefore we have no plans of doing so in 
the short term. This is even more true as, unlike what you state, we 
have evidence that installing a development environment such as MinGW32 
or WDK, in order to be in a position to recompile libwdi, is quite painless.

Now, if you find that configuring libwdi itself, after installing a 
development environment, is too complicated or daunting, please let us 
know and we'll see what we can do.

Also not that, there is currently some effort to rework the driver file 
embedding system, which may lead to the ability to assemble a libwdi 
library from a binary core and a 7z archive produced by libwdi users 
with their drivers. Once we have that, we will probably release binaries 
for the core part to allow easy assembly for libwdi users who may not 
want to recompile. This work is conducted the 7z branch in the git 
repository [4] (which is pre-alpha and nowhere near usability).
It will take a bit of time before we get there.

But at the risk of being blunt, unless you can qualify more precisely 
how the installation of either of WDK or MinGW32 is prohibitive for the 
recompilation of libwdi, compared to what would be the case if we 
supported MSVC6 and you didn't have MSVC6 installed, the evidence I have 
would tend to indicate that, if you try it for yourself, you may 
actually be surprised at how easy WDK or MinGW32 make libwdi 
recompilation easy. As you may realize, adding development environments 
or binaries, just because a single person may be more familiar with them 
and wants to avoid familiarizing themselves with another, is not a very 
compelling reason to modify a project.

Therefore, if your interest is with MS binaries, I would strongly 
encourage you to give the WDK/DDK a try.

Regards,

/Pete

[1] 
http://ftp.heanet.ie/mirrors/sourceforge/m/project/mi/mingw/Automated%20MinGW%20Installer/mingw-get-inst/
[2] http://pete.akeo.ie/2011/10/building-and-running-clang-static.html
[3] 
http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Faq#Where_can_I_get_binary_snapshots_of_libwdi.3F
[4] 
http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Faq#Where_can_I_get_binary_snapshots_of_libwdi.3F

[Libwdi-devel] wdi-simple for VC++6 or precompiled?

[Satz K. <sat...@go...>]

Hi,

I plan to use libwdi-simple to auto-install an USB-driver out of an
setup. Unfortunately it seems like there is no possibility for
MSVC-users to compile it from scratch. Beside of that the Windows DDK
is a fairly huge BLOB of data. So the efforts to create wdi-simple
just for a plain and simple installer seem to be fairly huge.

So my question: are there any ready-to-use binaries available somewhere?

Elmi

Re: [Libwdi-devel] Fwd: libwdi Zadig installation Using 7zip on XP

[Pete B. <pb...@gm...>]

Hi Rob,

It looks like you downloaded the source archive after you installed 
7-zip and not the Zadig archive.

As you will see from https://sourceforge.net/projects/libwdi/files/ 
there are 2 subdirectories. "release" is not directly related to Zadig 
but libwdi, of which Zadig is only a part.

To download the Zadig executable, you need to go to the "zadig" folder. 
Or you can just click on the following link:

http://sourceforge.net/projects/libwdi/files/zadig/zadig_v2.0.0.150.7z/download

Regards,

/Pete

[Libwdi-devel] Fwd: libwdi Zadig installation Using 7zip on XP

[Rob D. <the...@gm...>]

---------- Forwarded message ----------
From: Rob Denton <the...@gm...>
Date: Tue, Oct 18, 2011 at 10:06 AM
Subject: libwdi Zadig installation Using 7zip on XP
To: //lib...@li...


Hi There,

I'm trying to install Zadig on my Acer Aspire One netbook running Windows XP
SP3. According to the instructions, I downloaded "7zip" in order to
decompress it. 7zip installed successfully but I can find no executable
files to install Zadig. The "Install" file doesn't seem to be executable.
What am I doing wrong?

I downloaded libwdi 1.2.0.tar.gz from sourceforge this morning (18 October,
2011)

Thanks for your help,
Rob Denton

Re: [Libwdi-devel] Zadig VendorName in INF

[Pete B. <pb...@gm...>]

Hi Maarten,

On 2011.09.21 14:53, Maarten Brock wrote:
> Now my request: Would it be possible to enhance zadig such that I can edit the VendorName field of the generated .inf file? I mean, currently zadig creates a file with VendorName "(Unknown Vendor)". I would very much like to fill in the VendorName myself. Or is this against some policy of yours?

Well, the feature you require is already in libwdi [1], and Zadig is 
Open Source, so if you want to have a Zadig that allows you to override 
the VendorName, you should be able to produce one.

Now, the reason why Zadig does not offer this possibility by default is 
because it picks up the VendorName from the USB ID Repository [2] 
according to the USB VID, and the expected way of getting your Vendor ID 
properly filled then is to submit it to the USB ID Repository database. 
Every new release of Zadig uses the most up to date version of this 
database, and through encouraging people to update this database rather 
than fill their Vendor data in Zadig, we ensure that the public list of 
USB Vendor IDs grows more accurate as time goes by, which benefits everyone.

Unless you are using your own test device (in which case I have to 
assume that you can build your own version of Zadig to change the Vendor 
ID), I would encourage you to submit your Vendor Name to the USB ID 
Repository.

Regards,

/Pete

[1] 
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Usage#struct_wdi_options_prepare_driver
[2] http://www.linux-usb.org/usb-ids.html

[Libwdi-devel] Zadig VendorName in INF

[Maarten B. <m....@va...>]

Hello,

First of all, thank you for creating libusb and zadig. It's great!

Now my request: Would it be possible to enhance zadig such that I can edit the VendorName field of the generated .inf file? I mean, currently zadig creates a file with VendorName "(Unknown Vendor)". I would very much like to fill in the VendorName myself. Or is this against some policy of yours?

Greetings,
Maarten Brock
-- 
Van Mierlo Ingenieursbureau BV
Postbus 6466 5600HL Eindhoven Nederland
tel 040-2969999 fax 040-2969990 www.vanmierlo.com