Re: [Libusb-devel] libusb-1.0 Windows backend when WinUSB isafilter driver

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

On 2010.08.22 23:57, Michael Plante wrote:
> You've often stated you want
> it to be incredibly easy for people to use.  Because of the search order of
> the Windows loader, it makes sense that a dynamically-linked executable have
> its DLL in the same directory if you want a lazy or careless person to be
> able to double-click the executable and have it work.

Ah, but the examples included with the binary snapshots are just a 
by-product.
Here's my perspective on the snapshots:

1. People complained that developer-users (VERY different range of 
people as libusb app end users) would prefer to have a set of pre-built 
libraries ready for use.

2. I provided that (and that's the important part:) in the least amount 
of effort required to satisfy the request above (else, I'd have created 
a full fledged binary installer)

3. Additionally, but mostly for my own benefit, I added the examples, so 
that, if someone uses the library and suspects a problem, I can ask them 
to run a quick test with xusb -d and at get some enumeration debug about 
their device(s) or possibly other data. Very useful. And while I was at 
it, I provided 2 set of samples, just in case something occurs with the 
DLL and not static, etc.

Now, if I wanted to make a package that's incredibly easy for people to 
use, and targeted at a wider range than developer-users willing to use 
experimental not yet officially released libraries, I'd make an 
installer. But this is NOT it. So don't expect the ease of use of an 
installer from a zip archive, period. The snapshots are just "'AS IS' 
till we have something better" stuff, and if people are going to 
complain about them, because they expect something as easy to use as an 
installer, I'm not sure I'm going to bother with them, precisely because 
I don't think there's anything to be gained in spending time making the 
snapshots solve issues that we're going to address with the installer 
anyway.

> But the idea of being able to unzip and run in place

Run what? The snapshot's only goal is to provide pre-built libraries. 
The libraries in themselves don't run. Snapshot examples = cereal's box 
free toy, not main breakfast. If you can't run the snapshot samples, 
then you probably shouldn't use the snapshot. Especially, there's no 
README in the snapshot, no additional data on the file's intended 
purpose, or how to use them. This should give a clue that this is not 
intended as a full fledged redistributable package. Never has been.

But judging by what I set to do with the snapshots, and what people seem 
to be *mistakenly* expecting from them, it's very clear now that I have 
to remove the DLL based examples. If you want to run examples, the 
static DDK ones will have to do. The DLL ones were provided in the 
expectation that people who run them would know how to copy a DLL if 
required, but if the current expectation is that they won't, I probably 
have to simplify things further. The less amount of work I have to do 
with the informal snapshots, the better, so be prepared to have some 
very strong justification as to why I should do anything differently, 
that our developer-users, who are supposed to have diligently read the 
wiki cannot figure out themselves, if you want to see it happening. I 
consider that what we have right now is more than good enough for the 
targeted audience of these experimental, informal & non-official binary 
snapshots.

> Maybe keep it simple?  They are just examples, and, unlike the DLL/LIB/A/SO
> files, are not likely to be redistributed as-is.

I don't really consider any of the files from the snapshots to be 
redistributable as-is. For redistributable libusb 1.0 Windows libraries 
we'd need:
- full integration in the official branch (i.e. official that can be 
used to generate the snaphots - won't happen until we have MS integration)
- official binary snapshots on the main page (since the expectation is 
that most Windows user will use snapshots, not source, and if Windows is 
recognized as official, the preferred method of obtaining Windows libusb 
should be on the main page)
- some readme along with the binaries, so that someone who only received 
the package can figure out what it's all about.

Until that happens, I'd advise against any redistribution of the 
libraries from the snapshots, esepcially as there's no firm guarantee 
that what we currently provide will match what we end up with in official.

> If following one or both of Xiaofan's suggestions is infeasible,
> maybe just include the static builds so we get fewer support requests on the
> example snapshot?

It's not that they're infeasible. It's just that, as long as I'm the one 
building the snapshots, I'll try to follow the logic I deem best, and I 
have yet to see any convincing argument for a change in the snapshot 
organization (apart from removing the DLL based examples).

Because the snapshots are definitely not made to be as straightforward 
to use as an installer, support requests could really be addressed with 
a "if you don't know how to use the snapshots, wait for an hopefully 
soon-to-come easy-to-use installer".

> Or document (if not already) how to use the snapshot on
> the wiki somewhere?  But again, feel free to ignore my advice on this.

All I can say is, I'll see what I can do. Seemed to be fairly explicit 
to me how to use the snaphost files, and apart from Xiaofan's complaint, 
which, and I apologize to him, I'm going to place mostly in end user 
mistake (though I reckon import libraries are not supposed to change 
that often), I don't remember seeing posts complaining about the binary 
snapshots, while they have been downloaded at a steady rate [1]. If 
developer-users had such a hard time using them, I'd expect to have seen 
some feedback by now.

> They have the same name in MS compilers, don't they?

Yup. Not sure if MinGW users are most likely to come from MS or Linux, 
but I know that the MS ones would probably find it confusing to have the 
import and static lib in the same dir

>> (I could rename it to "static lib" if needed).
>
> Maybe "static" and "shared" as directory names?

I think DLL is more explicit for Windows developer-users than shared, so 
I'm planning to keep DLL. I'll add a static to libs or something.

But sheesh, the amount of justification you have to deliver for what was 
really a 5 mins "you want some binaries - there you go: AS IS" job. If 
it's going to turn out in another "do it properly or don't bother", then 
I have a fairly clear idea of which side I'm going to go with, since 
doing it properly requires an official installer.

Regards,

/Pete

[1] http://code.google.com/p/libusb-winusb-wip/downloads/list