Menu
▾
▴
libusb-devel
|
From: Pete B. <pb...@gm...> - 2010-08-21 00:18:44
|
On 2010.08.20 15:59, Xiaofan Chen wrote: > "xusb -d" works. The simple test program initially did not work. > Again I needed to compile it again (with MinGW) so that it works again. > This is very strange. I have no ideas why this happens. > I can only suspect there is some compatibility issues with > the binary snapshots and my MinGW.org 32bit compiler. I tested recompiling the test program against the last binary snapshot, and I'm not experiencing any issue. I tried both shared, against the 32 bit DLLs from the snaphost (both of them) and static against the static multilib MinGW32 libusb-1.0.a from the snapshot, and in each case I got a successful open. Below is some sample output for the static version. $ gcc -o lsusb lsusb.c -I. -L/e/dailies/2010.08.19/MinGW32/lib/ -lusb-1.0 -lsetupapi -lole32 $ ./lsusb.exe 1d6b:0001 (bus 0, device 255) 1d6b:0001 (bus 1, device 255) 1d6b:0001 (bus 2, device 255) 1d6b:0001 (bus 3, device 255) 1d6b:0001 (bus 4, device 255) 1d6b:0002 (bus 5, device 255) 0424:a700 (bus 5, device 1) 04d8:0053 (bus 5, device 2) Found device 04d8:0053 opened successfully! 1d6b:0002 (bus 6, device 255) If you see this issue again, can you please provide more information about how you compiled your sample? Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-21 01:08:02
|
On Sat, Aug 21, 2010 at 8:18 AM, Pete Batard <pb...@gm...> wrote: > I tested recompiling the test program against the last binary snapshot, > and I'm not experiencing any issue. I tried both shared, against the 32 > bit DLLs from the snaphost (both of them) and static against the static > multilib MinGW32 libusb-1.0.a from the snapshot, and in each case I got > a successful open. Below is some sample output for the static version. > > $ gcc -o lsusb lsusb.c -I. -L/e/dailies/2010.08.19/MinGW32/lib/ > -lusb-1.0 -lsetupapi -lole32 > Now I see the difference. I am taking the more "typical" way of using MinGW. I copy the libraries (.dll.a and .a) file to the MinGW lib directory and the include (.h) file to the MinGW include directory. In this more "typical" way, the default will be using dynamic linking. Only when you specifically use -l\full-path-to\libusb-1.0.a, ld will use static linking. But occasionally I forgot to put the dll.a file because your binary snapshots put the dll.a import library in the dll directory. I would suggest you put them to put in the lib directory. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-21 22:12:11
|
On 2010.08.21 02:07, Xiaofan Chen wrote: > But occasionally I forgot to put the dll.a file because > your binary snapshots put the dll.a import library in > the dll directory. I would suggest you put them to > put in the lib directory. I could do that. The only problem I see is that we cannot do the same for MS as both the import and the static library have the exact same name (libusb-1.0.lib). So we'd have a different behaviour between MS and MinGW in the snapshots. Also, I think most users of the snapshot are expected to chose whether they want to use the shared or static version of the library, rather than use both, so having both static and import in the same dir could be confusing. The way this is supposed to work right now, in the absence of a proper installer (which the binary snapshot is NOT a substitute for), is that someone is meant to pick the .h (and possibly the .def) from the root directory, then decide whether they want to use static or shared, MS or MinGW, 32 or 64, and as a result, pick the remainder of the files from a single one of the lower level subdirs, and manually dispatch the files where appropriate. The subdirectories are especially not broken down to mimic how files would be organized on the target system (else we would have an "include" dir for the .h, etc). My fear is that, if we start mixing files around and putting everything in /lib, we might end up with people using static when they wanted to use the DLL, or people linking against the DLL and getting an error when they wanted to use static. In the absence of a proper installer then, I would say the snapshot's duty ends at providing the files, in a fashion that most people should be able to understand, and currently, I still think that having static and shared in separate directories makes more sense than having them in the same one, precisely because MS-accustomed users would not expect to find the import and static lib in the same dir. Now, when we have a proper installer, that's a different story... Also, the import library has had drastic modifications when full DLL interchangeability was set up, so if you were still using the old one, it is indeed not surprising that there were issues. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-22 00:36:55
|
On Sun, Aug 22, 2010 at 6:12 AM, Pete Batard <pb...@gm...> wrote: > On 2010.08.21 02:07, Xiaofan Chen wrote: >> But occasionally I forgot to put the dll.a file because >> your binary snapshots put the dll.a import library in >> the dll directory. I would suggest you put them to >> put in the lib directory. > > I could do that. The only problem I see is that we cannot do the same > for MS as both the import and the static library have the exact same > name (libusb-1.0.lib). So we'd have a different behaviour between MS and > MinGW in the snapshots. Actually you already have a different behavior between MS and MinGW in the snapshots. The examples of MinGW are using the dynamic linking. If you run them, you will get a application crash due to missing dll. Then the MSVC examples are using static linking. But I know why they are done in this way: the MinGW build is more or less following the Linux way, which use dynamically linking by default. > Also, I think most users of the snapshot are > expected to chose whether they want to use the shared or static version > of the library, rather than use both, so having both static and import > in the same dir could be confusing. I see your points and I know you tend to like static linking. If I were you, I would probably be lazy and save my time and only provide the import library. ;-) > Also, the import library has had drastic modifications when full DLL > interchangeability was set up, so if you were still using the old one, > it is indeed not surprising that there were issues. I will be careful now to constantly update my libusb-1.0 libraries inside MinGW. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-22 00:40:51
|
On Sun, Aug 22, 2010 at 8:36 AM, Xiaofan Chen <xia...@gm...> wrote: > Actually you already have a different behavior between MS and MinGW > in the snapshots. The examples of MinGW are using the dynamic > linking. If you run them, you will get a application crash due to missing > dll. Personally I think this might be better fixed. Simple thing is to copy the MinGW dll inside the MinGW examples. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-22 22:43:54
|
On 2010.08.22 01:40, Xiaofan Chen wrote: > On Sun, Aug 22, 2010 at 8:36 AM, Xiaofan Chen<xia...@gm...> wrote: >> Actually you already have a different behavior between MS and MinGW >> in the snapshots. The examples of MinGW are using the dynamic >> linking. If you run them, you will get a application crash due to missing >> dll. > > Personally I think this might be better fixed. Simple thing is to copy > the MinGW dll inside the MinGW examples. I don't think that's very logical. People don't expect to find a DLL in examples. As to a different behaviour for the examples, well, the examples are just that, examples, or most specifically a sampler of what one can do with libusb. As such, it doesn't bother me much to have a set of examples that uses the DLL and another static. I could have stopped with providing only one set of samples (the static ones, because they're the most straightforward to use, and less likely to cause issues), but since both were available at no extra cost, I included both. If this becomes a contention point, considering that there's no good reason to have 2 set of samples really, I think I'll just drop the dynamically linked ones and keep static. As long as the snapshot includes the required files, and these files are logically organized, as I think they currently are right now, I don't really see much incentive to do more. As I explained, I don't really expect people who want to use both the static and shared library at the same time, to forget to copy all the files they need simply because they happen to be in two different directories. On the contrary, if I were to place both the import and static library in the same dir, I very much expect to see some complaints, which is why I'm not planning to do so. The reasoning is as straightforward as I could make it really. If you want to work with the libudb dll, then look into the "dll" dir. If you want to work with the static lib, then look into the "lib" dir (I could rename it to "static lib" if needed). If you want to work with both, then it is your responsibility to pick the files from both and copy them where required. Just like not everybody is expected to copy DLLs into system32 (but the people who do would obviously like us to go the extra mile for that), not everybody would copy the libraries in their system lib dir. Gotta draw the line as to where the responsibility of the library provider ends and the responsibility of the library user begins. You are supposed to know that you need to use an import lib if you work with the DLL, and therefore, you are supposed not to forget to update it, just like, if you want to have both a debug and release dll in system32, you are supposed to do the renaming as you see fit, not us. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-08-22 22:58:53
|
Pete Batard wrote: >> n 2010.08.22 01:40, Xiaofan Chen wrote: >> > On Sun, Aug 22, 2010 at 8:36 AM, Xiaofan Chen<xia...@gm...> wrote: >> >> Actually you already have a different behavior between MS and MinGW >> >> in the snapshots. The examples of MinGW are using the dynamic >> >> linking. If you run them, you will get a application crash due to missing >> >> dll. >> > >> > Personally I think this might be better fixed. Simple thing is to copy >> > the MinGW dll inside the MinGW examples. >> >> I don't think that's very logical. People don't expect to find a DLL in >> examples. Well, from the perspective of a sane layout, it's not logical, but I don't know that "sane layout" is what we're after. 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. Maybe even distribute a 2-3 line .bat/.cmd file that passes the right command line arguments and pauses before the console window closes, as long as we're cutting out the build step for people who refuse to build it from source: test-lsusb.bat: @echo off lsusb.exe pause But the idea of being able to unzip and run in place is just a suggestion. I don't particularly care what the binaries do. And I'll add the caveat that I'm basing this off the discussion, not having looked at the snapshot layout yet. >> I could have stopped with >> providing only one set of samples (the static ones, because they're the >> most straightforward to use, and less likely to cause issues), but since >> both were available at no extra cost, I included both. If this becomes a >> contention point, considering that there's no good reason to have 2 set >> of samples really, I think I'll just drop the dynamically linked ones >> and keep static. Maybe keep it simple? They are just examples, and, unlike the DLL/LIB/A/SO files, are not likely to be redistributed as-is. The source is more important for the examples, though providing ONE working binary each is a good idea. 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? Or document (if not already) how to use the snapshot on the wiki somewhere? But again, feel free to ignore my advice on this. >> On the contrary, if I were to >> place both the import and static library in the same dir, I very much >> expect to see some complaints, which is why I'm not planning to do so. Agreed. They have the same name in MS compilers, don't they? >> (I could rename it to "static lib" if needed). Maybe "static" and "shared" as directory names? Regards, Michael |
|
From: Pete B. <pb...@gm...> - 2010-08-23 00:36:43
|
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 |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-23 01:32:59
|
On Mon, Aug 23, 2010 at 8:36 AM, Pete Batard <pb...@gm...> wrote: > 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. > [1] http://code.google.com/p/libusb-winusb-wip/downloads/list Ok, now I know your stand and I think the current snapshots serve the purpose you intended. I was more in the line of treating the binary snapshots as "semi-official". BTW, it is nice to see the total download count of the binary snapshots is steadily increasing. > 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. I see now. I think in this case, the current binary snapshots are probably good enough. > 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. An installer is probably good to have in the future. On the other hand, even without an installer, a zip archive can archive the goal you want with better documentation or wiki page and examples. Just an example, libusb-win32 libraries are mainly distributed as a zip file: libusb-win32-bin-1.2.1.0.zip. There is also an installer, mainly for the filter service, wrapped in a zip file to discourage people from using it: libusb-win32-devel-filter-1.2.1.0.zip. Of course, there is also the 3rd package, the source package. http://sourceforge.net/projects/libusb-win32/files/ Judging from the download count, indeed, Windows users typically download the binary, not the source package. So we set the default download for Windows users to the binary package. For the other OS, we set the default download to be the source package since some of them may want to cross-compile the package. -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-08-23 01:46:42
|
Xiaofan Chen wrote: >> I see now. I think in this case, the current binary snapshots are >> probably good enough. If you're ok with the layout of the files, then I have no objection. Michael |
|
From: Peter S. <pe...@st...> - 2010-08-23 01:38:58
|
Pete Batard wrote: > sheesh, the amount of justification you have to deliver I don't think you have to deliver any justification. I certainly don't expect any in any case. You're the one making the snapshots, go with what makes sense to you. :) Personally I think this thread is about us learning what seems like a good way to organize files that will be installed by an installer. //Peter |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-23 02:25:06
|
On Mon, Aug 23, 2010 at 9:38 AM, Peter Stuge <pe...@st...> wrote:
> Personally I think this thread is about us learning what seems like a
> good way to organize files that will be installed by an installer.
>
Say if the installer will install the binary snapshots to the
C:\Program Files\libusb-1.0; then I think a way to do this
is like the following. The installer also can drop the x64
binary if the system is 32bit Windows. For 64bit Windows,
it is good to have both sets.
Also I am omitting the files like Authors.txt, Copying.txt,
readme.txt, changelog.txt, etc. They probably should
reside in the root directory.
Here I am treating lsusb.exe and xusb.exe
as having "higher status" since they are good for debugging
purpose.
bin
x86
libusb-1.0.dll
lsusb.exe
xusb.exe
x64
libusb-1.0.dll
lsusb.exe
xusb.exe
lib
MinGW32
static
libusb-1.0.a
import
libusb-1.0.dll.a
MinGW64
static
libusb-1.0.a
import
libusb-1.0.dll.a
MSVC32
static
libusb-1.0.lib
import
libusb-1.0.lib
MinGW64
static
libusb-1.0.lib
import
libusb-1.0.lib
include
libusb.h
Example
lsusb.c
xusb.c
dpfp.c
If we treat lsusb.exe and xusb.exe as not having that higher
status, then the following organization might be good.
dll
x86
libusb-1.0.dll
x64
libusb-1.0.dll
lib
MinGW32
static
libusb-1.0.a
import
libusb-1.0.dll.a
MinGW64
static
libusb-1.0.a
import
libusb-1.0.dll.a
MSVC32
static
libusb-1.0.lib
import
libusb-1.0.lib
MinGW64
static
libusb-1.0.lib
import
libusb-1.0.lib
include
libusb.h
Example
lsusb.c
xusb.c
dpfp.c
binary
x86
lsusb.exe
xusb.exe
dpfp.exe
x64
lsusb.exe
xusb.exe
dpfp.exe
--
Xiaofan
|
|
From: Michael P. <mic...@gm...> - 2010-08-23 02:52:29
|
Xiaofan Chen wrote: >> lib >> MinGW64 >> static >> libusb-1.0.a >> import >> libusb-1.0.dll.a >> MinGW64 >> static >> libusb-1.0.lib >> import >> libusb-1.0.lib Did you mean MSVC64 for the second case? (this appears repeated for both "lower-status" and "higher-status" case) >> binary >> x86 >> lsusb.exe >> xusb.exe >> dpfp.exe >> x64 >> lsusb.exe >> xusb.exe >> dpfp.exe You listed dpfp.exe in the "lower-status" case, but omitted it in the "higher-status" case. Are we still building dpfp on Windows? Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-23 03:02:04
|
On Mon, Aug 23, 2010 at 10:51 AM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> lib >>> MinGW64 >>> static >>> libusb-1.0.a >>> import >>> libusb-1.0.dll.a >>> MinGW64 >>> static >>> libusb-1.0.lib >>> import >>> libusb-1.0.lib > > Did you mean MSVC64 for the second case? (this appears repeated for both > "lower-status" and "higher-status" case) You are right. The second MinGW64 should be MSVC64. > >>> binary >>> x86 >>> lsusb.exe >>> xusb.exe >>> dpfp.exe >>> x64 >>> lsusb.exe >>> xusb.exe >>> dpfp.exe > > You listed dpfp.exe in the "lower-status" case, but omitted it in the > "higher-status" case. Are we still building dpfp on Windows? > I think I was able to build dpfp under MinGW at some point since Pete has some patches for it. I need to check again. If not, it should be dropped in the binary. I would still like to keep dpfp.c though and patch it so that it can be built under MinGW at least. It is a good example to show the use of async API. -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-08-23 03:07:22
|
Xiaofan Chen wrote: >> I think I was able to build dpfp under MinGW at some point since >> Pete has some patches for it. Yes, but I believe support was dropped due to sigaction concerns. >> I would still like to keep dpfp.c Agreed, of course, along with dpfp_threaded.c >> It is a good example to show the use of async API. Yep. >> patch it so that it can be built under MinGW at least. That would intentionally deviate from official policy. Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-23 03:44:04
|
On Mon, Aug 23, 2010 at 11:06 AM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> I think I was able to build dpfp under MinGW at some point since >>> Pete has some patches for it. > > Yes, but I believe support was dropped due to sigaction concerns. > >>> I would still like to keep dpfp.c > > Agreed, of course, along with dpfp_threaded.c > >>> patch it so that it can be built under MinGW at least. > > That would intentionally deviate from official policy. > You are right. I just went back to see the thread and indeed you are right. Danile's patch is to not to build dpfp under MinGW. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-23 09:27:38
|
OK. I don't have a problem reviewing the snapshot's file organization when we do something official (which the current snapshots is not), however a couple of things: 1. I don't see the examples ever having higher status than the library files. 2. _NOBODY_ seems to have the fingerprint device that the dpfp samples target. Providing executables for a device that almost nobody has access to is a waste of space IMO. Unless we ever see requests from people who have the "U.are.U 4000B fingerprint scanner", I don't think there's much point in expecting people to learn from a sample exe they can't use... The source of that sample is useful, especially the threaded one, but the exe, not so much. On the other hand, xusb and lsusb will return useful information, regardless of the USB device you have access to. 3. I agree that ultimately we should only provide one set of DLLs. However, we're still pretty much in experimental stage, with DLL interchangeability having only very recently been added. Also, since not everybody seems to be convinced about that, I want to confirm that the multilib MinGW32 DLLs work as well as the DDK one. As such, and as I consider any user of non-official binaries to be OK with being guinea pigs, I am planning to continue providing 2 sets of DLLs. Because of that, I'll keep the MinGW/MS -> DLL/static_lib approach in my snapshot, instead of DLL/static_lib -> MinGW/MS But I think this discussion makes sense, since I doubt we'll have an installer ready by the time we have an official release but we'll need something a bit more official than the current non official snapshots. Might also want to get started on a readme describing the files included, that would also provide links to the API, etc, so that we have something that looks redistributable when we go official. It might also make sense to include the source for the examples in what we distribute, as the expectation is that people downloading the library snapshot are going build a libusb based application, so having some sample code included by default could be useful. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-23 10:45:37
|
On Mon, Aug 23, 2010 at 5:23 PM, Pete Batard <pb...@gm...> wrote: > OK. I don't have a problem reviewing the snapshot's file organization > when we do something official (which the current snapshots is not), > however a couple of things: > > 1. I don't see the examples ever having higher status than the library > files. Of course that is right. The include file and the libraries are the most important files. > 2. _NOBODY_ seems to have the fingerprint device that the dpfp samples > target. Providing executables for a device that almost nobody has access > to is a waste of space IMO. I agree the binary of dpfp can be dropped since it is not to be built under MinGW and MSVC. And we may not want to provide binares for Cygwin anyway. > 3. I agree that ultimately we should only provide one set of DLLs. > However, we're still pretty much in experimental stage, with DLL > interchangeability having only very recently been added. Also, since not > everybody seems to be convinced about that, I want to confirm that the > multilib MinGW32 DLLs work as well as the DDK one. As such, and as I > consider any user of non-official binaries to be OK with being guinea > pigs, I am planning to continue providing 2 sets of DLLs. Because of > that, I'll keep the MinGW/MS -> DLL/static_lib approach in my snapshot, > instead of DLL/static_lib -> MinGW/MS Okay. > But I think this discussion makes sense, since I doubt we'll have an > installer ready by the time we have an official release but we'll need > something a bit more official than the current non official snapshots. That is probably the object of this discussion. > Might also want to get started on a readme describing the files > included, that would also provide links to the API, etc, so that we have > something that looks redistributable when we go official. I agree. > It might also make sense to include the source for the examples in what > we distribute, as the expectation is that people downloading the library > snapshot are going build a libusb based application, so having some > sample code included by default could be useful. Yes. So the source lsusb.c, xusb.c, dpfp.c and dpfp_threaded.c should be provided. -- Xiaofan |
|
From: Tim R. <ti...@pr...> - 2010-08-19 17:33:02
|
Pete Batard wrote: > > Still very much puzzled about what was so impossible with using System64 > for 64 bit DLLs, especially as System32 came from keeping system for 16 > bit and placing 32 bit DLLs elsewhere... You're pushing one of my hot buttons here. I've tried to resist chiming in, because I tend to rant like a lunatic when this topic gets brought up. I should say that I make my living writing Windows drivers. I live in a Microsoft world, and have done so for 20 years. I think they've done an awful lot of things right, but they horribly botched a large number of rather important things in the 32-to-64 transition. This is merely one of the most visible. As a developer, I have an appreciate for beauty and simplicity in design. All these things they botched go directly against the principles of beauty and simplicity. SysWow64. File system redirection. Registry redirection. Registry reflection. 32-bit longs. Side-by-side. These are all cases where they made a conscious decision to go in a direction that was utterly contrary to intuition. We developers handled the 16-to-32 transition just fine. There was a bit of pain, because people had made incredibly stupid decisions, but that was our fault to begin with. We learned what to do and what not to do. Once we learned those lessons and stopped making assumptions, the next transition should have been a piece of cake. Instead, Microsoft assumed that we were all too stupid to handle another transition. Now, admittedly, I do have the merest glimmer of understanding of how this came about. I gave this speech to a group that included part of the DDK team. Their marching orders in the 32/64 transition -- their watchword -- their mantra -- was application compatibility. If the Microsoft developers made any design decision that caused grief to some Fortune 500's internal line of business application, they were ordered to find another way. EVEN IF the answer was "you made an invalid assumption here" or "you made a poor design decision there", that didn't matter. They were simply not allowed to upset Procter & Gamble. And that's what led to the mess we have today. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Pete B. <pb...@gm...> - 2010-08-19 18:25:00
|
On 2010.08.19 18:32, Tim Roberts wrote: > Now, admittedly, I do have the merest glimmer of understanding of how > this came about. I gave this speech to a group that included part of > the DDK team. Their marching orders in the 32/64 transition -- their > watchword -- their mantra -- was application compatibility. If the > Microsoft developers made any design decision that caused grief to some > Fortune 500's internal line of business application, they were ordered > to find another way. EVEN IF the answer was "you made an invalid > assumption here" or "you made a poor design decision there", that didn't > matter. They were simply not allowed to upset Procter& Gamble. And > that's what led to the mess we have today. Thanks Tim. I guess a lot of people suspect that compatibility was the main reason (though I've seen some ludicrous theory that Microsoft just didn't want to have to replace "system32" in their kernel source [1]). It's nice to finally see some confirmation of it. But really, if maximizing revenue from the Fortune 500 was Microsoft's objective, they missed a good opportunity to sell dedicated 32 -> 64 bit transition support by going the other route then ;) And if anything, I'd say trusted developers like you have a very valid reason to be quite vocal on this, as this might be the only way to get future executive decisions from Microsoft, with a little more consideration for logic. Regards, /Pete [1] http://www.msfn.org/board/topic/69489-pointless-question-system32-folder/page__view__findpost__p__485154 |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-21 00:37:21
|
On Sat, Aug 21, 2010 at 8:18 AM, Pete Batard <pb...@gm...> wrote: > On 2010.08.20 15:59, Xiaofan Chen wrote: >> "xusb -d" works. The simple test program initially did not work. >> Again I needed to compile it again (with MinGW) so that it works again. >> This is very strange. I have no ideas why this happens. >> I can only suspect there is some compatibility issues with >> the binary snapshots and my MinGW.org 32bit compiler. > > I tested recompiling the test program against the last binary snapshot, > and I'm not experiencing any issue. I tried both shared, against the 32 > bit DLLs from the snaphost (both of them) and static against the static > multilib MinGW32 libusb-1.0.a from the snapshot, and in each case I got > a successful open. Below is some sample output for the static version. > > $ gcc -o lsusb lsusb.c -I. -L/e/dailies/2010.08.19/MinGW32/lib/ > -lusb-1.0 -lsetupapi -lole32 > > $ ./lsusb.exe > 1d6b:0001 (bus 0, device 255) > 1d6b:0001 (bus 1, device 255) > 1d6b:0001 (bus 2, device 255) > 1d6b:0001 (bus 3, device 255) > 1d6b:0001 (bus 4, device 255) > 1d6b:0002 (bus 5, device 255) > 0424:a700 (bus 5, device 1) > 04d8:0053 (bus 5, device 2) > Found device 04d8:0053 opened successfully! > 1d6b:0002 (bus 6, device 255) > > If you see this issue again, can you please provide more information > about how you compiled your sample? I believe I found the problem. I was using an older version of the libusb-1.0.a file. For example, if I was using the version of June 14, I have the following results, even though I have the latest libusb-1.0.dll (pbd299) in the same directory. gcc -o lsusb-with-open lsusb-with-open.c -lusb-1.0 -lsetupapi -lole32 D:\work\libusb1win32\Test>lsusb-with-open.exe libusb:debug [libusb_get_device_list] libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255 libusb:debug [usb_enumerate_hub] allocating new device for session 255 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 11 ports Hub: \\.\USB#ROOT_HUB#4&ED791&0#{F18A0 E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 0 devaddr 1 session_id 1 libusb:debug [usb_enumerate_hub] allocating new device for session 1 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor #1 (34 bytes) libusb:debug [usb_enumerate_hub] busnum 0 devaddr 2 session_id 2 libusb:debug [usb_enumerate_hub] allocating new device for session 2 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor #1 (32 bytes) libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511 libusb:debug [usb_enumerate_hub] allocating new device for session 511 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 11 ports Hub: \\.\USB#ROOT_HUB20#4&37B181E7&0#{ F18A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257 libusb:debug [usb_enumerate_hub] allocating new device for session 257 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor #1 (569 bytes) libusb:debug [usb_enumerate_hub] busnum 2 devaddr 255 session_id 767 libusb:debug [usb_enumerate_hub] allocating new device for session 767 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 1 ports Hub: \\.\USB#ROOT_HUB#4&3A6FCBF5&0#{F18 A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 2 devaddr 1 session_id 513 libusb:debug [usb_enumerate_hub] allocating new device for session 513 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor #1 (216 bytes) libusb:debug [usb_enumerate_hub] busnum 3 devaddr 255 session_id 1023 libusb:debug [usb_enumerate_hub] allocating new device for session 1023 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 1 ports Hub: \\.\USB#ROOT_HUB20#4&3287596&0#{F1 8A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [set_device_paths] path (0:1): \\.\USB#VID_046D&PID_C058#5&2E09F03B &0&1#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver: HidUsb libusb:debug [set_hid_device] interface_path[0]: \\.\HID#VID_046D&PID_C058#6&6AA AE87&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030} libusb:debug [set_device_paths] path (2:1): \\.\USB#VID_0B05&PID_1788#1C4BD6065A 96#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver: BTHUSB libusb:debug [set_device_paths] path (0:2): \\.\USB#VID_1234&PID_0001#BMD001#{A5 DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver: libusb0 libusb:debug [set_device_paths] path (1:1): \\.\USB#VID_13D3&PID_5130#5&20BE7240 &0&7#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver: usbccgp libusb:warning [set_composite_device] interface_path[0]: unhandled API - interfa ce will be disabled libusb:warning [set_composite_device] composite device: no interfaces were found libusb:debug [libusb_get_device_descriptor] 1d6b:0001 (bus 0, device 255) libusb:debug [libusb_get_device_descriptor] 046d:c058 (bus 0, device 1) libusb:debug [libusb_get_device_descriptor] 1234:0001 (bus 0, device 2) libusb:debug [libusb_open] open 0.2 libusb:debug [unsupported_open] unsupported API call for 'open' (unrecognized de vice driver) -12:Operation not supported or unimplemented on this platform failed opening device 1234:0001 libusb:debug [libusb_unref_device] destroy device 0.255 libusb:debug [libusb_unref_device] destroy device 0.1 libusb:debug [libusb_unref_device] destroy device 0.2 libusb:debug [libusb_unref_device] destroy device 1.255 libusb:debug [libusb_unref_device] destroy device 1.1 libusb:debug [libusb_unref_device] destroy device 2.255 libusb:debug [libusb_unref_device] destroy device 2.1 libusb:debug [libusb_unref_device] destroy device 3.255 libusb:debug [libusb_exit] libusb:debug [usbi_remove_pollfd] remove fd 3 libusb:debug [windows_clock_gettime_threaded] timer thread quitting libusb:debug [libusb_exit] freeing default context Rebuild the program with the latest libusb-1.0.a (MinGW32) and it works. gcc -o lsusb-with-open lsusb-with-open.c -lusb-1.0 -lsetupapi -lole32 D:\work\libusb1win32\Test>lsusb-with-open.exe libusb:debug [libusb_get_device_list] libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255 libusb:debug [usb_enumerate_hub] allocating new device for session 255 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 11 ports Hub: \\.\USB#ROOT_HUB#4&ED791&0#{F18A0 E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 0 devaddr 1 session_id 1 libusb:debug [usb_enumerate_hub] allocating new device for session 1 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati onValue=1, 34 bytes) libusb:debug [usb_enumerate_hub] busnum 0 devaddr 2 session_id 2 libusb:debug [usb_enumerate_hub] allocating new device for session 2 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati onValue=1, 32 bytes) libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511 libusb:debug [usb_enumerate_hub] allocating new device for session 511 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 11 ports Hub: \\.\USB#ROOT_HUB20#4&37B181E7&0#{ F18A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257 libusb:debug [usb_enumerate_hub] allocating new device for session 257 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati onValue=1, 569 bytes) libusb:debug [usb_enumerate_hub] busnum 2 devaddr 255 session_id 767 libusb:debug [usb_enumerate_hub] allocating new device for session 767 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 1 ports Hub: \\.\USB#ROOT_HUB#4&3A6FCBF5&0#{F18 A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [usb_enumerate_hub] busnum 2 devaddr 1 session_id 513 libusb:debug [usb_enumerate_hub] allocating new device for session 513 libusb:debug [initialize_device] active config: 1 libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati onValue=1, 216 bytes) libusb:debug [usb_enumerate_hub] busnum 3 devaddr 255 session_id 1023 libusb:debug [usb_enumerate_hub] allocating new device for session 1023 libusb:debug [initialize_device] active config: 1 libusb:debug [usb_enumerate_hub] 1 ports Hub: \\.\USB#ROOT_HUB20#4&3287596&0#{F1 8A0E88-C30C-11D0-8815-00A0C906BED8} libusb:debug [set_device_paths] path (0:1): \\.\USB#VID_046D&PID_C058#5&2E09F03B &0&1#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver(s): HIDUSB libusb:debug [set_device_paths] matched driver name against HID API libusb:debug [set_hid_device] interface_path[0]: \\.\HID#VID_046D&PID_C058#6&6AA AE87&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030} libusb:debug [set_device_paths] path (2:1): \\.\USB#VID_0B05&PID_1788#1C4BD6065A 96#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver(s): BTHUSB libusb:debug [set_device_paths] lower filter driver(s): BTUSBFLT libusb:debug [set_device_paths] path (0:2): \\.\USB#VID_1234&PID_0001#BMD001#{A5 DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver(s): LIBUSB0 libusb:debug [set_device_paths] lower filter driver(s): WINUSB libusb:debug [set_device_paths] matched lower filter driver name against WinUSB API libusb:debug [set_device_paths] path (1:1): \\.\USB#VID_13D3&PID_5130#5&20BE7240 &0&7#{A5DCBF10-6530-11D2-901F-00C04FB951ED} libusb:debug [set_device_paths] driver(s): USBCCGP libusb:debug [set_device_paths] matched driver name against Composite API libusb:warning [set_composite_device] interface_path[0]: unhandled API - interfa ce will be disabled libusb:warning [set_composite_device] composite device: no interfaces were found libusb:debug [libusb_get_device_descriptor] 1d6b:0001 (bus 0, device 255) libusb:debug [libusb_get_device_descriptor] 046d:c058 (bus 0, device 1) libusb:debug [libusb_get_device_descriptor] 1234:0001 (bus 0, device 2) libusb:debug [libusb_open] open 0.2 Found device 1234:0001 opened successfully! libusb:debug [libusb_close] libusb:debug [libusb_get_device_descriptor] 1d6b:0002 (bus 1, device 255) libusb:debug [libusb_get_device_descriptor] 13d3:5130 (bus 1, device 1) libusb:debug [libusb_get_device_descriptor] 1d6b:0001 (bus 2, device 255) libusb:debug [libusb_get_device_descriptor] 0b05:1788 (bus 2, device 1) libusb:debug [libusb_get_device_descriptor] 1d6b:0002 (bus 3, device 255) libusb:debug [libusb_unref_device] destroy device 0.255 libusb:debug [libusb_unref_device] destroy device 0.1 libusb:debug [libusb_unref_device] destroy device 0.2 libusb:debug [libusb_unref_device] destroy device 1.255 libusb:debug [libusb_unref_device] destroy device 1.1 libusb:debug [libusb_unref_device] destroy device 2.255 libusb:debug [libusb_unref_device] destroy device 2.1 libusb:debug [libusb_unref_device] destroy device 3.255 libusb:debug [libusb_exit] libusb:debug [libusb_exit] destroying default context -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-21 00:44:25
|
On Sat, Aug 21, 2010 at 8:37 AM, Xiaofan Chen <xia...@gm...> wrote: > I believe I found the problem. I was using an older version of the > libusb-1.0.a file. For example, if I was using the version of > June 14, I have the following results, even though I have > the latest libusb-1.0.dll (pbd299) in the same directory. > > Rebuild the program with the latest libusb-1.0.a (MinGW32) > and it works. > > gcc -o lsusb-with-open lsusb-with-open.c -lusb-1.0 -lsetupapi -lole32 > Ok, it seems to me if I use libusb-1.0.dll.a, then even the old version of the import library will work. Interestingly, if I have both libusb-1.0.dll.a and libusb-1.0.a, the above command will use the correct import library (libusb-1.0.dll.a) and then it works. If there is only libusb-1.0.a, the above will produce an exe which does not work. In that case, it seems to be static linked to the old library. And of course it would not work. Sorry for the false alarming. As for this whole thread, it seems WInUSB can not be a real generic filter after all. But I think your patch to enable the support of filter may still make sense to be kept. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-21 00:59:08
|
On Sat, Aug 21, 2010 at 8:44 AM, Xiaofan Chen <xia...@gm...> wrote: > Ok, it seems to me if I use libusb-1.0.dll.a, then even the old > version of the import library will work. > > Interestingly, if I have both libusb-1.0.dll.a and libusb-1.0.a, > the above command will use the correct import library > (libusb-1.0.dll.a) and then it works. If there is only > libusb-1.0.a, the above will produce an exe which > does not work. In that case, it seems to be > static linked to the old library. And of course it would > not work. > > Sorry for the false alarming. > ++++++++++ http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. ++++++++++ So this is correct behavior, the dll.a have higher precedence than the .a file. -- Xiaofan |
|
From: Travis <tra...@co...> - 2010-08-19 11:46:42
|
> Xiaofan Chen wrote: >>> This particular part may be a .Net problem or my problem. I was putting >>> the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. >>> Maybe >>> I should have put the 64bit one to see if that helps. I will check >>> again. > Yep, that would do it. This is a bit off topic, but you can force libusbdotnet to always run as a "32bit" application by recompiling it with the "Win32" solution configuration selected (instead of "Any CPU"). Regards, Travis |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 13:27:09
|
On Thu, Aug 19, 2010 at 7:46 PM, Travis <tra...@co...> wrote: >> Xiaofan Chen wrote: >>>> This particular part may be a .Net problem or my problem. I was putting >>>> the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. >>>> Maybe I should have put the 64bit one to see if that helps. I will check >>>> again. >> > > Yep, that would do it. Indeed. Using the 64bit dll makes benchmarkcon (libusbdotnet) happy. D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234 pid=0x00 01 driver=libusb10 LibUsbDotNet USB Benchmark v2.2.7.85 Copyright (c) 2010 Travis Robinson. <lib...@gm...> website: http://sourceforge.net/projects/libusbdotnet Benchmark device 1234:0001 opened.. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Bulk Write (Ep01h) max packet size: 64 While the test is running: Press 'Q' to quit Press 'T' for test details Press 'I' for status information Press 'R' to reset averages Press 'Q' to exit, any other key to begin.. Avg. Bytes/s: 510364.22 Transfers: 117 Bytes/s: 510364.22 Avg. Bytes/s: 510944.33 Transfers: 242 Bytes/s: 511488.51 Avg. Bytes/s: 511303.40 Transfers: 367 Bytes/s: 512000.00 qAvg. Bytes/s: 511610.05 Transfers: 492 Bytes/s: 512512.51 stopped Ep81h thread. stopped Ep01h thread. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Total Bytes : 2019328 Total Transfers : 493 Avg. Bytes/sec : 511481.26 Elapsed Time : 3.95 seconds Bulk Write (Ep01h) max packet size: 64 Total Bytes : 2019328 Total Transfers : 493 Avg. Bytes/sec : 511610.84 Elapsed Time : 3.95 seconds Press any key to exit.. > This is a bit off topic, but you can force libusbdotnet to always run as a > "32bit" application by recompiling it with the "Win32" solution > configuration selected (instead of "Any CPU"). > I see. Somehow the default solution file is not ready for this, at least for SharpDevelop. I got several of the following errors. The OutputPath property is not set for this project. Please check to make sure that you have specified a valid Configuration/Platform combination. Configuration='Debug' Platform='Win32' -- Xiaofan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X