[Libusb-devel] Problem compiling using Win DDK

[Graeme Gill]

D:\src\argyll\libusb1>ddk_build.cmd
1 file(s) copied.
D:\src\argyll\libusb1\libusb\os>build -cZ
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objfre_w2K_x86
BUILD: Compile and Link for i386
BUILD: d:\src\argyll\libusb1\libusb\os\sources(0): Unknown TARGETPATH value
BUILD: Examining d:\src\argyll\libusb1\libusb\os directory for files to compile.
BUILD: Compiling (NoSync) d:\src\argyll\libusb1\libusb\os directory
1>errors in directory d:\src\argyll\libusb1\libusb\os
1>NMAKE : fatal error U1064: MAKEFILE not found and no target specified
BUILD: nmake.exe /nologo BUILDMSG=Stop. -i NTTEST= UMTEST= NOLINK=1 PASS1_NOLIB=1 386=1 failed - rc =
BUILD: Compiling d:\src\argyll\libusb1\libusb\os directory
100>NMAKE : fatal error U1064: MAKEFILE not found and no target specified
BUILD: nmake.exe failed - rc = 2
BUILD: Compile errors: not linking d:\src\argyll\libusb1\libusb\os directory
BUILD: Done
0 files compiled - 2 Errors
Build failed

Is there supposed to be a MAKEFILE ?

(I have no problems building libusb-win32 using the DDK)

Graeme Gill.

[Xiaofan Chen]

Strange. Which WDK version are you using? I have no issues using WDK
7600.16385.0 under Windows Vista 32bit (x86 free build).

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>ddk_build.cmd

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\libusb\os>build -cZ

BUILD: Compile and Link for x86
BUILD: Start time: Tue Mar 09 20:46:02 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\li
busb\os directory for files to compile.
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\libusb\os Inval
idating OACR warning log for 'root:x86fre'
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\li
busb\os directory
Configuring OACR for 'root:x86fre' - <OACR on>
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
BUILD: Linking for c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\
libusb\os directory
Compiling resources - c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbata
rd\libusb\libusb-1.0.rc
Linking Executable - objfre_wlh_x86\i386\libusb-1.0.dll
BUILD: Finish time: Tue Mar 09 20:46:09 2010
BUILD: Done

12 files compiled
1 library built
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy libusb\os\objf
re_wlh_x86\i386\libusb-1.0.dll Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy libusb\os\objf
re_wlh_x86\i386\libusb-1.0.pdb Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy libusb\os\objf
re_wlh_x86\i386\libusb-1.0.lib Win32\Release\lib
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\examples\lsusb_ddkb
uild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Tue Mar 09 20:46:09 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\ex
amples\lsusb_ddkbuild directory for files to compile.
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\examples\lsusbI
nvalidating OACR warning log for 'root:x86fre'
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libus
b-pbatard\examples\lsusb_ddkbuild directory
Configuring OACR for 'root:x86fre' - <OACR on>
_NT_TARGET_VERSION SET TO WINXP
Compiling - lsusb.c
Linking Executable - objfre_wlh_x86\i386\lsusb.exe
BUILD: Finish time: Tue Mar 09 20:46:10 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy examples\lsusb
_ddkbuild\objfre_wlh_x86\i386\lsusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy examples\lsusb
_ddkbuild\objfre_wlh_x86\i386\lsusb.pdb Win32\Release\examples
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\examples\xusb_ddkbu
ild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Tue Mar 09 20:46:10 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\ex
amples\xusb_ddkbuild directory for files to compile.
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard\examples\xusb_I
nvalidating OACR warning log for 'root:x86fre'
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libus
b-pbatard\examples\xusb_ddkbuild directory
Configuring OACR for 'root:x86fre' - <OACR on>
_NT_TARGET_VERSION SET TO WINXP
Compiling - xusb.c
Linking Executable - objfre_wlh_x86\i386\xusb.exe
BUILD: Finish time: Tue Mar 09 20:46:11 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy examples\xusb_
ddkbuild\objfre_wlh_x86\i386\xusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\libusb-pbatard>copy examples\xusb_
ddkbuild\objfre_wlh_x86\i386\xusb.pdb Win32\Release\examples
1 file(s) copied.

[Xiaofan Chen]

Post by Xiaofan Chen
Strange. Which WDK version are you using? I have no issues using WDK
7600.16385.0 under Windows Vista 32bit (x86 free build).

On the other hand, the build process failed under WDK 6001.18001.
The error is very strange though.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>ddk_build.c
md

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard\libusb\os>b
uild -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Tue Mar 09 20:53:15 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
BUILD: Linking for c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-
pbatard\libusb\os directory
Compiling resources - c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libu
sb-pbatard\libusb\libusb-1.0.rc
Linking Executable - objfre_wlh_x86\i386\libusb-1.0.dll
BUILD: Finish time: Tue Mar 09 20:53:18 2010
BUILD: Done

12 files compiled
1 library built
1 executable built
goto was unexpected at this time.

[Pete Batard]

Post by Xiaofan Chen
On the other hand, the build process failed under WDK 6001.18001.

Confirmed and now fixed in r202.

Post by Xiaofan Chen
The error is very strange though.
goto was unexpected at this time.

The issue was with the line:
if %_BuildType%==chk goto isDebug

Looks like with 6001, _BuildType is not defined, so we now use
DDKBUILDENV instead.

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard

Post by Xiaofan Chen
On the other hand, the build process failed under WDK 6001.18001.

Confirmed and now fixed in r202.

Post by Xiaofan Chen
The error is very strange though.
goto was unexpected at this time.

  if %_BuildType%==chk goto isDebug
Looks like with 6001, _BuildType is not defined, so we now use
DDKBUILDENV instead.

Thanks. Yes now it is okay.


C:\WinDDK\6001.18001>cd c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001>cd libusb-pbatard

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>ddk_build.c
md

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard\libusb\os>b
uild -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 06:56:06 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
BUILD: Linking for c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-
pbatard\libusb\os directory
Compiling resources - c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libu
sb-pbatard\libusb\libusb-1.0.rc
Linking Executable - objfre_wlh_x86\i386\libusb-1.0.dll
BUILD: Finish time: Wed Mar 10 06:56:14 2010
BUILD: Done

12 files compiled
1 library built
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy libusb
\os\objfre_wlh_x86\i386\libusb-1.0.dll Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy libusb
\os\objfre_wlh_x86\i386\libusb-1.0.pdb Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy libusb
\os\objfre_wlh_x86\i386\libusb-1.0.lib Win32\Release\lib
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard\examples\ls
usb_ddkbuild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 06:56:14 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\examples\lsusb_ddkbuild directory for files to compile.
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk60
01\libusb-pbatard\examples\lsusb_ddkbuild directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - lsusb.c
Linking Executable - objfre_wlh_x86\i386\lsusb.exe
BUILD: Finish time: Wed Mar 10 06:56:16 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy exampl
es\lsusb_ddkbuild\objfre_wlh_x86\i386\lsusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy exampl
es\lsusb_ddkbuild\objfre_wlh_x86\i386\lsusb.pdb Win32\Release\examples
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard\examples\xu
sb_ddkbuild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 06:56:16 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pb
atard\examples\xusb_ddkbuild directory for files to compile.
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk60
01\libusb-pbatard\examples\xusb_ddkbuild directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - xusb.c
Linking Executable - objfre_wlh_x86\i386\xusb.exe
BUILD: Finish time: Wed Mar 10 06:56:17 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy exampl
es\xusb_ddkbuild\objfre_wlh_x86\i386\xusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001\libusb-pbatard>copy exampl
es\xusb_ddkbuild\objfre_wlh_x86\i386\xusb.pdb Win32\Release\examples
1 file(s) copied.

[Graeme Gill]

Post by Xiaofan Chen
Strange. Which WDK version are you using? I have no issues using WDK
7600.16385.0 under Windows Vista 32bit (x86 free build).

3790.1830 under Win2K. I don't think any others work on Win2K.

As I said, works perfectly on libusb-win32, and was the only viable
way I found of building the 64 bit drivers for Vista and Win7.
(If it compiles on MSVC6, it should be possible to compile on this DDK).

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Post by Xiaofan Chen
Strange. Which WDK version are you using? I have no issues using WDK
7600.16385.0 under Windows Vista 32bit (x86 free build).

3790.1830 under Win2K. I don't think any others work on Win2K.

WinUSB does not support Win2k. So the main Windows backend
will not work under Win2k anyway. And Pete says that Win2k
supports will not come from him

[Graeme Gill]

Post by Xiaofan Chen
WinUSB does not support Win2k. So the main Windows backend

Yes it does. I ported the libusb-win32 back end (libusb0.sys) to it,
which is why I'd like to be able to build it as 64 bit using the
DDK, as well as using msvc or MinGW.

The libusb0.sys back end basically works, but there are some issues
to be worked out in the windows polling that show up with both winusb.sys
and libusb0.sys back ends.

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Post by Xiaofan Chen
WinUSB does not support Win2k. So the main Windows backend

Yes it does.

WinUSB does not work under Win2k. And I think WinUSB first came out
in WDK6000.

Post by Graeme Gill
I ported the libusb-win32 back end (libusb0.sys) to it,
which is why I'd like to be able to build it as 64 bit using the
DDK, as well as using msvc or MinGW.
The libusb0.sys back end basically works, but there are some issues
to be worked out in the windows polling that show up with both winusb.sys
and libusb0.sys back ends.

Ah I see. So you have done the hardwork to port libusb0.sys
backend to libusb 1.0. Right? Where is the code? I can give it a try
with later WDK.

[Graeme Gill]

Post by Xiaofan Chen
Ah I see. So you have done the hardwork to port libusb0.sys
backend to libusb 1.0. Right? Where is the code? I can give it a try
with later WDK.

A snapshot of the changed files is at <http://www.argyllcms.com/libusb.zip>

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Post by Xiaofan Chen
Ah I see. So you have done the hardwork to port libusb0.sys
backend to libusb 1.0. Right? Where is the code? I can give it a try
with later WDK.

A snapshot of the changed files is at <http://www.argyllcms.com/libusb.zip>

Thanks. I replace the files but I could not build it under WDK. Maybe
some files are missing.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>ddk_bu
ild.cmd

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:25:59 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
errors in directory c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\l
ibusb-pbatard\libusb\os
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os\windows_usb.c(1525) : error C4013: 'libusb0_io_sync' undefined; assuming ext
ern returning int
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
link : error LNK1181: cannot open input file 'c:\cygwin\home\mcuee\mcu\libusb1wi
n32\git\wdk\wdk6001_test\libusb-pbatard\libusb\os\objfre_wlh_x86\i386\windows_us
b.obj'
BUILD: Compile errors: not linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk
\wdk6001_test\libusb-pbatard\libusb\os directory
BUILD: Finish time: Wed Mar 10 07:26:03 2010
BUILD: Done

11 files compiled - 1 Error
1 library built - 1 Error
Build failed

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Graeme Gill

Post by Xiaofan Chen
Ah I see. So you have done the hardwork to port libusb0.sys
backend to libusb 1.0. Right? Where is the code? I can give it a try
with later WDK.

A snapshot of the changed files is at <http://www.argyllcms.com/libusb.zip>

Thanks. I replace the files but I could not build it under WDK. Maybe
some files are missing.

Ok, it seems I need to put the definition of that libusb0_io_sync()
in front.

***@AcerPC ~/mcu/libusb1win32/git/wdk/wdk6001_test/libusb-pbatard/libusb/os
$ diff -u windows_usb_org.c windows_usb.c
--- windows_usb_org.c 2010-03-06 16:18:37.000000000 +0800
+++ windows_usb.c 2010-03-10 07:40:20.539603200 +0800
@@ -93,6 +93,7 @@
static int libusb0_abort_control(struct usbi_transfer *itransfer);
static int libusb0_reset_device(struct libusb_device_handle *dev_handle);
static int libusb0_copy_transfer_data(struct usbi_transfer *itransfer, uint32_t
io_size);
+static int libusb0_io_sync(HANDLE dev, unsigned int code, void *out, int out_si
ze, void *in, int in_size, int *ret);
// HID API prototypes
static int hid_init(struct libusb_context *ctx);
static int hid_exit(void);

In that case, the build process is fine under WDK 6001.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>ddk_bu
ild.cmd

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:25:59 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
errors in directory c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\l
ibusb-pbatard\libusb\os
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os\windows_usb.c(1525) : error C4013: 'libusb0_io_sync' undefined; assuming ext
ern returning int
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
link : error LNK1181: cannot open input file 'c:\cygwin\home\mcuee\mcu\libusb1wi
n32\git\wdk\wdk6001_test\libusb-pbatard\libusb\os\objfre_wlh_x86\i386\windows_us
b.obj'
BUILD: Compile errors: not linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk
\wdk6001_test\libusb-pbatard\libusb\os directory
BUILD: Finish time: Wed Mar 10 07:26:03 2010
BUILD: Done

11 files compiled - 1 Error
1 library built - 1 Error
Build failed

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>ddk_bu
ild.cmd

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:38:22 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
Compiling - generating code...
errors in directory c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\l
ibusb-pbatard\libusb\os
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os\windows_usb.c(1536) : error C4700: uninitialized local variable 'dev_descrip
tor' used
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
link : error LNK1181: cannot open input file 'c:\cygwin\home\mcuee\mcu\libusb1wi
n32\git\wdk\wdk6001_test\libusb-pbatard\libusb\os\objfre_wlh_x86\i386\windows_us
b.obj'
BUILD: Compile errors: not linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk
\wdk6001_test\libusb-pbatard\libusb\os directory
BUILD: Finish time: Wed Mar 10 07:38:25 2010
BUILD: Done

11 files compiled - 1 Error
1 library built - 1 Error
Build failed

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>ddk_bu
ild.cmd

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:40:25 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory for files to compile.
BUILD: Compiling c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\libusb\os directory
Compiling - core.c
Compiling - descriptor.c
Compiling - io.c
Compiling - sync.c
Compiling - generating code...
Compiling - threads_windows.c
Compiling - poll_windows.c
Compiling - windows_usb.c
Compiling - generating code...
Building Library - objfre_wlh_x86\i386\libusb-1.0.lib
BUILD: Linking for c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\li
busb-pbatard\libusb\os directory
Compiling resources - c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test
\libusb-pbatard\libusb\libusb-1.0.rc
Linking Executable - objfre_wlh_x86\i386\libusb-1.0.dll
BUILD: Finish time: Wed Mar 10 07:40:29 2010
BUILD: Done

12 files compiled
1 library built
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy l
ibusb\os\objfre_wlh_x86\i386\libusb-1.0.dll Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy l
ibusb\os\objfre_wlh_x86\i386\libusb-1.0.pdb Win32\Release\dll
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy l
ibusb\os\objfre_wlh_x86\i386\libusb-1.0.lib Win32\Release\lib
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\exampl
es\lsusb_ddkbuild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:40:29 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\examples\lsusb_ddkbuild directory for files to compile.
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk60
01_test\libusb-pbatard\examples\lsusb_ddkbuild directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - lsusb.c
Linking Executable - objfre_wlh_x86\i386\lsusb.exe
BUILD: Finish time: Wed Mar 10 07:40:29 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy e
xamples\lsusb_ddkbuild\objfre_wlh_x86\i386\lsusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy e
xamples\lsusb_ddkbuild\objfre_wlh_x86\i386\lsusb.pdb Win32\Release\examples
1 file(s) copied.
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\exampl
es\xusb_ddkbuild>build -cZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Mar 10 07:40:29 2010
BUILD: Examining c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libu
sb-pbatard\examples\xusb_ddkbuild directory for files to compile.
BUILD: Compiling and Linking c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk60
01_test\libusb-pbatard\examples\xusb_ddkbuild directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - xusb.c
Linking Executable - objfre_wlh_x86\i386\xusb.exe
BUILD: Finish time: Wed Mar 10 07:40:30 2010
BUILD: Done

3 files compiled
1 executable built

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy e
xamples\xusb_ddkbuild\objfre_wlh_x86\i386\xusb.exe Win32\Release\examples
1 file(s) copied.

c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard>copy e
xamples\xusb_ddkbuild\objfre_wlh_x86\i386\xusb.pdb Win32\Release\examples
1 file(s) copied.

[Graeme Gill]

Post by Xiaofan Chen
Thanks. I replace the files but I could not build it under WDK. Maybe
some files are missing.

Right, but this brings us back to the problem of it not compiling
under older DDK's :-)

Post by Xiaofan Chen
c:\cygwin\home\mcuee\mcu\libusb1win32\git\wdk\wdk6001_test\libusb-pbatard\libusb
\os\windows_usb.c(1525) : error C4013: 'libusb0_io_sync' undefined; assuming ext
ern returning int

Just a forward declaration missing there. I've updated the .zip file
(45385 bytes) so you can try again.

Graeme Gill.

[Michael Plante]

Post by Xiaofan Chen

Post by Graeme Gill
3790.1830 under Win2K. I don't think any others work on Win2K.

WinUSB does not support Win2k. So the main Windows backend
will not work under Win2k anyway. And Pete says that Win2k
supports will not come from him

Interesting, I missed that part. FWIW, libusb-win32 specifies a
"TARGETPATH" in the "sources_dll" file, but libusb-winusb does NOT in
"sources". You might just try fiddling with the settings to see if
something compiles. If we did eventually add libusb0.sys support, it'd be
nice not to have to #ifdef all WinUSB stuff, even though you can't *use* it
in win2k. I'd be curious to know if you get any farther...

Michael

[Graeme Gill]

Post by Michael Plante
something compiles. If we did eventually add libusb0.sys support, it'd be
nice not to have to #ifdef all WinUSB stuff, even though you can't *use* it
in win2k. I'd be curious to know if you get any farther...

The WinUSB side is quite happy to be there (ie. the libusb1.dll I
compile on my Win2K box using MSVC6 happily runs using the WinUSB.sys driver
on Vista etc.)

Graeme Gill.

[Pete Batard]

Post by Graeme Gill
The WinUSB side is quite happy to be there (ie. the libusb1.dll I
compile on my Win2K box using MSVC6 happily runs using the WinUSB.sys driver
on Vista etc.)

Yes, it doesn't look like we need ifdefs. As long as no devices are seen
using winusb.sys, and that should always be the case on Win2k, the
WinUSB sections of the code wouldn't be called, so we're fine.

As to fixing the Win2k DDK build issue (or doing any kind of Win2k
support), sorry, but I'll just have to pass. While I do understand that
there are people out there who want to run libusb 1.0 on Win2k, and I'll
be happy to try to integrate any Win2k patch you send my way, I'm not
planning to spend any time on my end on Win2k specific issues like the
one we have with DDK builds right now.

As I already explained, and as advertised by Microsoft, Windows 2000 has
officially reached the end of its life, so my approach is that:
1. People who are fine with using an obsolete operating system, should
also be fine with using the older version of libusb (libusb 0.1 through
libusb-win32)
2. If people really need the libusb 1.0 features and are about to write
an application for it on Win2k (as they would be, since so far libsub
1.0 was not available for Windows), they might as well migrate to Linux
altogether and write their new application there.

Thus I don't really see the point of spending much time on Win2k. Still,
anybody who cares that much about that platform is more than welcome to
send patches against the current branch for review and integration.


Now, the adding libusb0.sys to the Windows backend is another story, and
definitely something I'm planning to support. I've actually just pushed
the internal branch I was using with Graeme's files (called "custom",
for "custom libusb0.sys driver"), although it might make more sense if
Graeme asks Peter for his own git tree, as he's doing almost all the
development there, and, apart from bug fixing, I plan to be working on
the driver-installer rather than libusb0.sys in the near future.

I also have to stress out that I will not do any merging of the
libusb0.sys branch(es) with my master until after we have had at least
one official release of libusb with the current HID and WinUSB backends,
and this no matter how soon we can get a working libusb0.sys or how long
our first official release is further delayed...

Regards,

/Pete

[Graeme Gill]

Post by Pete Batard
As I already explained, and as advertised by Microsoft, Windows 2000 has
1. People who are fine with using an obsolete operating system, should
also be fine with using the older version of libusb (libusb 0.1 through
libusb-win32)
2. If people really need the libusb 1.0 features and are about to write
an application for it on Win2k (as they would be, since so far libsub
1.0 was not available for Windows), they might as well migrate to Linux
altogether and write their new application there.

Hmm. The problem is that support for libusb 0.1 has already been dropped
by upstream - when I volunteered patches to fix the concurrency issues in
Linux some time ago, they were rejected because "we're working on libusb1
now". So here we are working on libusb1, and once again I'm being frustrated
because "we're not supporting Win2K now".

As for Win2K "officially reached the end of its life", Microsoft have
little control over that (unlike XP and latter versions where they can
stop issuing activation codes, speeding their demise)), and the whole
thing is mostly marketing anyway (how do we get people to pay for
new copies of what they've already got ? Say it's "end of life'd"
and persuade as many other people as possible to make their
software incompatible with it, even if there's no reason!).

Microsoft certainly don't want me to move on from Win2K, if they
did they would still offer an upgrade (which they don't any more),
rather than forcing me to do a fresh install (which I'm not prepared
to do any time soon - that would be a week or more of my life I wouldn't
get back, for much expense and frustration, and little return) And if
I'm in that boat, then so are many other people. But as a developer,
building on the oldest box that I want to support is generally the
safest and simplest approach, and at this particular point in time
I'm prepared to support Win2K because there really isn't much that
changed since then as far as the application environment is concerned.

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill
Hmm. The problem is that support for libusb 0.1 has already been dropped
by upstream - when I volunteered patches to fix the concurrency issues in
Linux some time ago, they were rejected because "we're working on libusb1
now". So here we are working on libusb1, and once again I'm being frustrated
because "we're not supporting Win2K now".

I think the issue can be fixed and I believe you can get pass the
DDK issue with some efforts. Then you can send the patch
to Pete to be integrated into his master tree so that Windows 2K
can be supported.

I have never really used Windows 2K (DOS 3.3 ->Win95OSR2 ->
98SE ->XP SP1/SP2/SP3 -->Vista, no WinMe or Win2k,
no Win7 yet but soon I will buy a new notebook with Win7).
But those who have used it seem to quite like it. I do hear some
USB related issues with Windows 2K (usbser.sys which is anyway
problemtic across all Windows versions, but also others).

BTW, does it build fine under MinGW/MSYS or MSVC6
under Windows 2000?

[Graeme Gill]

Post by Xiaofan Chen
I think the issue can be fixed and I believe you can get pass the
DDK issue with some efforts. Then you can send the patch
to Pete to be integrated into his master tree so that Windows 2K
can be supported.

Yes, that's the plan.

Post by Xiaofan Chen
But those who have used it seem to quite like it. I do hear some
USB related issues with Windows 2K (usbser.sys which is anyway
problemtic across all Windows versions, but also others).

I've not come across that, but I don't use USB serial very much
on that box. XP is really a minor upgrade to 2K with some disadvantages
(activation) and much like NT4, the most noticeable things are because
Microsoft has chosen not to make patches available for it (there was no
reason why NT4 didn't support USB properly with a service pack
- some 3rd parties were able to provide it, it's just that MS
wanted to "incentivize" people to buy Win2K).

Post by Xiaofan Chen
BTW, does it build fine under MinGW/MSYS or MSVC6
under Windows 2000?

Yes (although I'm using a different build system). It builds
fine under the MSVC6, MSVC8, MSVC9, MinGW-gcc440 compilers
on my Win2K box.

(MSVC9 was yet another case of install it on an XP box and copy
the files to the 2K box and it works fine - ie. the installer blocks
it for no good reason.)

Graeme Gill.

[Graeme Gill]

OK, I've tweaked the DDK build files to successfully compile the library
& examples using the 3790.1830 DDK for both Win32 and x64 build
environments, and also added in the build scripts & sources to build
the libusb0.sys file. (I haven't tried actually running anything built
this way yet though.)

<http://www.argyllcms.com/libusb.zip> 95926 bytes

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill
OK, I've tweaked the DDK build files to successfully compile the library
& examples using the 3790.1830 DDK for both Win32 and x64 build
environments, and also added in the build scripts & sources to build
the libusb0.sys file. (I haven't tried actually running anything built
this way yet though.)
<http://www.argyllcms.com/libusb.zip>  95926 bytes

This seems to be fine with the later WDK 6001.18001 as well.

On the other hand, I need a minor patch to build under Cygwin.

$ diff -u libusb/os/windows_usb_org.h libusb/os/windows_usb.h
--- libusb/os/windows_usb_org.h 2010-03-10 11:35:46.000000000 +0800
+++ libusb/os/windows_usb.h 2010-03-10 19:25:48.701262500 +0800
@@ -687,7 +687,7 @@
* libusb0 API definitions from libusb0-win32.
*/

-#include <driver/driver_api.h>
+#include "./driver/driver_api.h"

#define LIBUSB0_DEFAULT_TIMEOUT 5000
#define LIBUSB0_DEVICE_NAME "\\\\.\\libusb0-"

And there are some warnings.

$ make
make all-recursive
make[1]: Entering directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backen
d/cygwin/libusb-pbatard'
Making all in libusb
make[2]: Entering directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backen
d/cygwin/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-poll_windows.lo
CC libusb_1_0_la-windows_usb.lo
os/windows_usb.c: In function `libusb0_claim_interface':
os/windows_usb.c:3105: warning: unused variable `if_desc'
os/windows_usb.c:3106: warning: unused variable `policy'
os/windows_usb.c:3107: warning: unused variable `endpoint_address'
os/windows_usb.c:3108: warning: unused variable `i'
os/windows_usb.c: In function `libusb0_submit_iso_transfer':
os/windows_usb.c:3215: warning: unused variable `num_packets'
os/windows_usb.c: In function `libusb0_submit_control_transfer':
os/windows_usb.c:3309: warning: unused variable `ret'
os/windows_usb.c: In function `libusb0_clear_halt':
os/windows_usb.c:3583: warning: unused variable `priv'
os/windows_usb.c: In function `libusb0_abort_control':
os/windows_usb.c:3609: warning: unused variable `transfer_priv'
os/windows_usb.c: In function `libusb0_abort_transfers':
os/windows_usb.c:3635: warning: unused variable `transfer_priv'
os/windows_usb.c: In function `libusb0_reset_device':
os/windows_usb.c:3660: warning: unused variable `priv'
os/windows_usb.c: In function `libusb0_claim_interface':
os/windows_usb.c:3104: warning: 'libusb0_handle' might be used uninitialized in
this function
/bin/sh ../libtool --mode=compile windres -i libusb-1.0.rc -o libusb-1.0.lo
libtool: compile: windres -i libusb-1.0.rc -DDLL_EXPORT -DPIC -o .libs/libusb-
1.0.o
libtool: compile: windres -i libusb-1.0.rc -o libusb-1.0.o >/dev/null 2>&1
CCLD libusb-1.0.la
Creating library file: .libs/libusb-1.0.dll.a
make[2]: Leaving directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backend
/cygwin/libusb-pbatard/libusb'
Making all in doc
make[2]: Entering directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backen
d/cygwin/libusb-pbatard/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backend
/cygwin/libusb-pbatard/doc'
Making all in examples
make[2]: Entering directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backen
d/cygwin/libusb-pbatard/examples'
CC xusb.o
CCLD xusb.exe
CC lsusb.o
CCLD lsusb.exe
CC dpfp.o
CCLD dpfp.exe
CC dpfp_threaded-dpfp_threaded.o
CCLD dpfp_threaded.exe
make[2]: Leaving directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backend
/cygwin/libusb-pbatard/examples'
make[2]: Entering directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backen
d/cygwin/libusb-pbatard'
make[2]: Leaving directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backend
/cygwin/libusb-pbatard'
make[1]: Leaving directory `/home/mcuee/mcu/libusb1win32/git/libusbwin32_backend
/cygwin/libusb-pbatard'

[Graeme Gill]

Post by Xiaofan Chen
This seems to be fine with the later WDK 6001.18001 as well.

Sounds good.

Post by Xiaofan Chen
On the other hand, I need a minor patch to build under Cygwin.
$ diff -u libusb/os/windows_usb_org.h libusb/os/windows_usb.h
--- libusb/os/windows_usb_org.h 2010-03-10 11:35:46.000000000 +0800
+++ libusb/os/windows_usb.h 2010-03-10 19:25:48.701262500 +0800
@@ -687,7 +687,7 @@
* libusb0 API definitions from libusb0-win32.
*/
-#include <driver/driver_api.h>
+#include "./driver/driver_api.h"

How about #include "driver/driver_api.h" instead ?

Post by Xiaofan Chen
And there are some warnings.

OK, I've fix them up:

<http://www.argyllcms.com/libusb.zip> 112337 bytes,

[but note there are a few trial code changes involving the
usbi_fd_notification() function as Pete & I try to figure
out why the windows back end (both winusb.sys and libusb0.sys)
is not thread safe ...]

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Post by Xiaofan Chen
-#include <driver/driver_api.h>
+#include "./driver/driver_api.h"

How about #include "driver/driver_api.h" instead ?

Yes this is ok.

Post by Graeme Gill

Post by Xiaofan Chen
And there are some warnings.

<http://www.argyllcms.com/libusb.zip>  112337 bytes,
[but note there are a few trial code changes involving the
usbi_fd_notification() function as Pete & I try to figure
out why the windows back end (both winusb.sys and libusb0.sys)
is not thread safe ...]

I will try this later.

Meanwhile, I just converted one of the libusb 0.1 program
(Linux and Windows) to libusb 1.0. And it seems to work with
the tested libusb0.sys backend.

Original program:
http://www.microchip.com/forums/fb.aspx?m=283761

Original run with libusb-win32 0.1.12.2 device driver.
$ ../libusb0/fsusb_demo.exe --readtemp
Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000
c)
Found USB PICDEM FS USB Demo Board as device '\\.\libusb0-0001--0x04d8-0x000c'
on USB bus bus-0
Communication established.
answer was correct!
Onboard firmware version is 1.0
Temperature now is 25.000000 degC (raw: 400, rawval: 3207)

I did a fast conversion to use the new test libusb0.sys
backend and it seems to work fine.

$ ./fsusb_demo_libusb1.exe --readtemp >readtemp.log
$ cat readtemp.log
Locating Microchip(tm) Custom Device Demo (vendor 0x04d8/product 0x000c)
libusb:info [libusb0_open] usb_os_init: driver version: 0.1.12.1
Found and Opened Microchip(tm) Custom Device Demo (vendor 0x04d8/product 0x000c)

Communication established.
answer was correct!
Onboard firmware version is 1.0
Temperature now is 25.000000 degC (raw: 400, rawval: 3207)

Full run log.
***@AcerPC ~/mcu/libusb1win32/fsusb_demo/libusb1
$ ./fsusb_demo_libusb1.exe --readtemp
Locating Microchip(tm) Custom Device Demo (vendor 0x04d8/product 0x000c)
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation
libusb:debug [windows_clock_gettime_threaded] hires timer available (Frequency:
25000000 Hz)
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [libusb_init] created default context
libusb:debug [libusb_get_device_list]
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 0 session_id 0
libusb:debug [usb_enumerate_hub] allocating new device for session 0
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\.\USB#ROOT_HUB20#4&7056C45&0#{F1
8A0E88-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 (25 bytes)
libusb:debug [usb_enumerate_hub] 4 ports Hub: \\.\USB#VID_05E3&PID_0606#5&17D847
74&0&4#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 3 session_id 3
libusb:debug [usb_enumerate_hub] allocating new device for session 3
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (41 bytes)
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 4 session_id 4
libusb:debug [usb_enumerate_hub] allocating new device for session 4
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (55 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 (39 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 0 session_id 256
libusb:debug [usb_enumerate_hub] allocating new device for session 256
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\.\USB#ROOT_HUB#4&278C294E&0#{F18
A0E88-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 (32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 2 session_id 258
libusb:debug [usb_enumerate_hub] allocating new device for session 258
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (34 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 3 session_id 259
libusb:debug [usb_enumerate_hub] allocating new device for session 259
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (41 bytes)
libusb:debug [cache_config_descriptors] cached config descriptor #2 (32 bytes)
libusb:debug [discovered_devs_append] need to increase capacity
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 4 session_id 260
libusb:debug [usb_enumerate_hub] allocating new device for session 260
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 5 session_id 261
libusb:debug [usb_enumerate_hub] allocating new device for session 261
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (39 bytes)
libusb:debug [set_device_paths] path (0:4): \\.\USB#VID_0403&PID_BCD9#070200A1#{
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] interface_path[1]: unhandled API - interfa
ce will be disabled
libusb:warning [set_composite_device] composite device: no interfaces were found

libusb:debug [set_device_paths] path (1:2): \\.\USB#VID_046D&PID_C054#5&207B166D
&0&3#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: HidUsb
libusb:debug [set_hid_device] interface_path[0]: \\.\HID#VID_046D&PID_C054#6&334
DE466&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (0:3): \\.\USB#VID_046D&PID_C216#6&1DA2B8C1
&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_C216#7&318
A44D&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (1:4): \\.\USB#VID_04D8&PID_000C#5&207B166D
&0&7#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
libusb:debug [set_device_paths] path (1:3): \\.\USB#VID_04D8&PID_0033#PK2NEW#{A5
DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: HidUsb
libusb:debug [set_hid_device] interface_path[0]: \\.\HID#VID_04D8&PID_0033#6&BD5
B18B&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (0:2): \\.\USB#VID_04D8&PID_9009#JIT0935967
58#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: NCBULK
libusb:debug [set_device_paths] path (1:1): \\.\USB#VID_058F&PID_9360#2004888#{A
5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: USBSTOR
libusb:debug [set_device_paths] path (1:5): \\.\USB#VID_1366&PID_0101#123456#{A5
DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: jlink
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_open] open 1.4
libusb:info [libusb0_open] usb_os_init: driver version: 0.1.12.1
libusb:debug [libusb0_open] setting debug level 0 succeeded
libusb:debug [libusb_unref_device] destroy device 0.0
libusb:debug [libusb_unref_device] destroy device 0.1
libusb:debug [libusb_unref_device] destroy device 0.3
libusb:debug [libusb_unref_device] destroy device 0.4
libusb:debug [libusb_unref_device] destroy device 0.2
libusb:debug [libusb_unref_device] destroy device 1.0
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 1.2
libusb:debug [libusb_unref_device] destroy device 1.3
libusb:debug [libusb_unref_device] destroy device 1.5
Found and Opened Microchip(tm) Custom Device Demo (vendor 0x04d8/product 0x000c)

libusb:debug [libusb_set_configuration] configuration 1
libusb:debug [libusb_claim_interface] interface 0
libusb:debug [libusb0_claim_interface] claimed interface 0
libusb:debug [libusb_get_config_descriptor] index 0
libusb:debug [windows_assign_endpoints] (re)assigned endpoint 01 to interface 0
libusb:debug [windows_assign_endpoints] (re)assigned endpoint 81 to interface 0
libusb:warning [libusb0_submit_control_transfer] auto-claimed interface 0 for co
ntrol request
libusb:debug [libusb0_submit_control_transfer] will use interface 0
libusb:debug [usbi_add_pollfd] add fd 5 events 1
libusb:debug [libusb_get_next_timeout] next timeout in 0.994360s
libusb:debug [handle_events] poll() 2 fds with timeout in 995ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
libusb:debug [windows_handle_events] checking fd 5 with revents = 0001
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [windows_transfer_callback] handling I/O completion with errcode 0
libusb:debug [ctrl_transfer_cb] actual_length=0
libusb:debug [libusb_claim_interface] interface 0
Communication established.
libusb:debug [libusb0_submit_bulk_transfer] matched endpoint 01 with interface 0

libusb:debug [libusb0_submit_bulk_transfer] writing bulk 2 bytes from ep 01
libusb:debug [usbi_add_pollfd] add fd 5 events 4
libusb:debug [libusb_get_next_timeout] next timeout in 1.998120s
libusb:debug [handle_events] poll() 2 fds with timeout in 1999ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
libusb:debug [windows_handle_events] checking fd 5 with revents = 0004
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [windows_transfer_callback] handling I/O completion with errcode 0
libusb:debug [bulk_transfer_cb] actual_length=2
libusb:debug [libusb0_submit_bulk_transfer] matched endpoint 81 with interface 0

libusb:debug [libusb0_submit_bulk_transfer] reading bulk 4 bytes from ep 81
libusb:debug [usbi_add_pollfd] add fd 5 events 1
libusb:debug [libusb_get_next_timeout] next timeout in 1.998120s
libusb:debug [handle_events] poll() 2 fds with timeout in 1999ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
libusb:debug [windows_handle_events] checking fd 5 with revents = 0001
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [windows_transfer_callback] handling I/O completion with errcode 0
libusb:debug [bulk_transfer_cb] actual_length=4
answer was correct!
Onboard firmware version is 1.0
libusb:debug [libusb0_submit_bulk_transfer] matched endpoint 01 with interface 0

libusb:debug [libusb0_submit_bulk_transfer] writing bulk 1 bytes from ep 01
libusb:debug [usbi_add_pollfd] add fd 5 events 4
libusb:debug [libusb_get_next_timeout] next timeout in 1.998080s
libusb:debug [handle_events] poll() 2 fds with timeout in 1999ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
libusb:debug [windows_handle_events] checking fd 5 with revents = 0004
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [windows_transfer_callback] handling I/O completion with errcode 0
libusb:debug [bulk_transfer_cb] actual_length=1
libusb:debug [libusb0_submit_bulk_transfer] matched endpoint 81 with interface 0

libusb:debug [libusb0_submit_bulk_transfer] reading bulk 3 bytes from ep 81
libusb:debug [usbi_add_pollfd] add fd 5 events 1
libusb:debug [libusb_get_next_timeout] next timeout in 1.998200s
libusb:debug [handle_events] poll() 2 fds with timeout in 1999ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
libusb:debug [windows_handle_events] checking fd 5 with revents = 0001
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [windows_transfer_callback] handling I/O completion with errcode 0
libusb:debug [bulk_transfer_cb] actual_length=3
Temperature now is 25.000000 degC (raw: 400, rawval: 3207)
libusb:debug [libusb_close]
libusb:debug [libusb_unref_device] destroy device 1.4

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Graeme Gill

Post by Xiaofan Chen
And there are some warnings.

<http://www.argyllcms.com/libusb.zip>  112337 bytes,

Thanks. All the warnings are gone now under Cygwin.

Post by Xiaofan Chen

Post by Graeme Gill
[but note there are a few trial code changes involving the
usbi_fd_notification() function as Pete & I try to figure
out why the windows back end (both winusb.sys and libusb0.sys)
is not thread safe ...]

I will try this later.

I have no tried to test programs with multithread support yet.
Anyway, my modified fsusb_demo_libusb1 still works.

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Graeme Gill
<http://www.argyllcms.com/libusb.zip>  112337 bytes,

Thanks. All the warnings are gone now under Cygwin.

BTW, you may want to rename those makefile in your
zip snapshots as they may be overwritten by Cygwin
autogen.sh.

[Graeme Gill]

Post by Xiaofan Chen
BTW, you may want to rename those makefile in your
zip snapshots as they may be overwritten by Cygwin
autogen.sh.

They are needed by build, so it's a little tricky. The easiest thing
may be to rename them and then get ddk_build.cmd to copy them.

Graeme Gill.

[Pete Batard]

Post by Xiaofan Chen
BTW, you may want to rename those makefile in your
zip snapshots as they may be overwritten by Cygwin
autogen.sh.

Yes, I was also coming to that as well.

First of all, I have now integrated the latest libusb0.sys changes and
merged them against the latest master update => c192.

So, Graeme, can I ask you to do two things:

1. Start using git from now on, either using the branch I put online, or
a new branch that Peter can create for you if you prefer to have control.

[Pete Batard]

Post by Pete Batard
First of all, I have now integrated the latest libusb0.sys changes and
merged them against the latest master update => c192.

Obviously not "master" above, but "custom"

[Graeme Gill]

Now, I see that some GPL code has been introduced (for the driver), so
we'll have to go how the libusb maintainers want to go about that. I
understand this is separate from any LGPL code we alreay have, but my
guess is that they'll want a separate GPL project for the driver.

Nothing has really changed here - libusb-win32 has always been this
way.

Plus I don't want to start any more integration work until I know
exactly where we stand, through the means of an existing release. Thus,
I'm not planning to do any merging of the custom/libusb0.sys branch with
my master until after release, but I will maintain this branch with
patches sent and apply changes from master into it. I'm hoping this is
OK with everyone.

Suite yourself - it doesn't make much difference to me. I'll include
whatever snapshot/version of libusb1 works for my project, whether
or not it is an official release. (What about release early and
release often ? :-)

[Pete Batard]

Post by Graeme Gill
Nothing has really changed here - libusb-win32 has always been this
way.

Yup, and libusb-win32 has always been a separate project (fork) from the
main libusb one.

Post by Graeme Gill
Of more concern to me is that it currently isn't usable on
MSWindows because of the thread interaction issues.

That's a bit harsh. There's a lot of applications that can use the
Windows backend right now, and the reason why there are still bugs in
some threaded apps is because we still don't have a generic threaded app
to test against.

You just happen to have encountered one of these bugs that I'm trying to
weed out. I'll get there, but it won't be an immediate process...

Post by Graeme Gill
It's a somewhat philosophical question, but my opinion is that there
are fundamental structural problems about making Linux truly usable,
and they revolve around money

I would tend to agree with that statement. Developers who can make
significant contributions and improvements to open source software
should have the financial incentive to do so, as their main activity,
rather than as unpaid voluntary work.
How to achieve that however, is a whole different story...

Post by Graeme Gill
I think on the contrary there is
a lot of evidence that proprietary software companies do put customer
satisfaction as a higher priority in many (but not all) areas

I'll have to disagree with that. I have yet to find a single software
company that leaves up to my standards of placing customer satisfaction
at the number one spot. No matter what the official corporate message
is, I've always seen it get dislodged by profit (and yes, I have seen
that from the inside as well)

One good way to rate how high proprietary software companies place
customer satisfaction is to have a look at what they do for customer
support (inherently a very non-profitable operation, when not based on a
subscription model). Ideally, if an issue is reported, there should
exists the shortest route between the customer who reported it and the
person(s) who can address that problem, with an almost direct and
real-time means of communication between all parties.
Then the person(s) who can address the issue also need to have the
relevant amount of time allocated for it, by the company, as part of
their daily job.

Now, when was the last time you had the chance, as a regular customer,
to initiate near-direct communication with software developers from a
major proprietary software company, and where said developers addressed
an issue which required a fix/enhancement in a reasonable timeframe?

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard

Post by Graeme Gill
Of more concern to me is that it currently isn't usable on
MSWindows because of the thread interaction issues.

That's a bit harsh. There's a lot of applications that can use the
Windows backend right now, and the reason why there are still bugs in
some threaded apps is because we still don't have a generic threaded app
to test against.

On that front, do you have anything in mind? Does it need to be
cross-platform (pthread, or Boost -- might be too big as a dependency)
or Windows only?

As per Stephan Meyer, libusb-win32 is not really thread safe,
but it can be used in multi-thread applications. He posted
a few examples using Win32 API.
http://www.microchip.com/forums/fb.aspx?m=480335
http://www.microchip.com/forums/fb.aspx?m=480337

[Pete Batard]

Post by Xiaofan Chen

a generic threaded app to test against.

On that front, do you have anything in mind?

I think something similar to what Jere had would be good. Possibly, if
we could make use of a USB PIC18Fx550 device with a generic firmware,
that might provide us with something a bit more interesting to test a
threaded app (and easier/cheaper to obtain than the 4000B fingerprint
scanner of the dpfp samples)

Post by Xiaofan Chen
Does it need to be cross-platform

Absolutely, but we already have some form of abstraction for threading,
so adding some more for actual thread creation will hopefully not be too
much of an issue. There's little point of creating a libusb showcase for
threaded apps, if we can't have it run on multiple platforms.

Post by Xiaofan Chen
As per Stephan Meyer, libusb-win32 is not really thread safe,
but it can be used in multi-thread applications.

Well, it seems Jere also had some success using the libusb Windows
backend in a multithreaded app, and, as long as only a couple people
test threaded apps against the new backend, we might be in for a long
wait before we find out if there are more bugs that need to be ironed out.

FYI, at the moment, my priorities are pretty much in the following order:
0. any work needed for release / bugfixes
1. driver installer
2. threaded test application and custom PIC firmware
3. libusb0.sys integration
4. compat layer porting to MinGW/cygwin/MSVC
5. hotplug, better poll abstraction, etc.

This is in accordance with where *I think* the demand from our users is
going to be post release. WinUSB driver installation is going to be the
major issue, with ensuring that threading works as it should a likely
close second. As you can see, still a long way to go, which is why it
might be a good idea to get the current code out of the way.

Regards,

/Pete

[Graeme Gill]

Post by Pete Batard
Yup, and libusb-win32 has always been a separate project (fork) from the
main libusb one.

It's not a relevant distinction for anyone doing cross platform
development who needs to supports Linux, OS X and MSWindows,
since they were using both libusb and libusb-win32 anyway.

Post by Pete Batard

Post by Graeme Gill
Of more concern to me is that it currently isn't usable on
MSWindows because of the thread interaction issues.

That's a bit harsh. There's a lot of applications that can use the
Windows backend right now, and the reason why there are still bugs in
some threaded apps is because we still don't have a generic threaded app
to test against.

Sorry, but from my perspective (and my particular usage) the current state
of Libusb1 has that as a major regression compared to libusb0 & libusb0-win32.
I can't switch from libusb0 to libusb1 because of this.

Post by Pete Batard
You just happen to have encountered one of these bugs that I'm trying to
weed out. I'll get there, but it won't be an immediate process...

Well, I'd like to get it sorted out as soon as possible so that I can
move on to other projects (but it may not work out like that of course...:-)

On a tangent...

Post by Pete Batard
One good way to rate how high proprietary software companies place
customer satisfaction is to have a look at what they do for customer
support (inherently a very non-profitable operation, when not based on a
subscription model). Ideally, if an issue is reported, there should
exists the shortest route between the customer who reported it and the
person(s) who can address that problem, with an almost direct and
real-time means of communication between all parties.

...

Post by Pete Batard
Now, when was the last time you had the chance, as a regular customer,
to initiate near-direct communication with software developers from a
major proprietary software company, and where said developers addressed
an issue which required a fix/enhancement in a reasonable timeframe?

I'm not sure I'd ascribe this purely to the policy of proprietary software
companies, but would ascribe it largely to the reality of the situation.
Many successful commercial enterprise work by leveraging the work of a small
number of people and selling it at a moderate cost to a large number of people.
For mass market products that ratio can be overwhelming, so there is no
surprise that sometimes it takes time to get any attention. Any company
that stops further development to deal purely with current user queries
is probably doomed, so limiting developers time on such things is understandable.

And as a example, I can put forward any of the popular Open Source projects -
Mozilla for instance. If you've got a bug or enhancement request, you can't get
an immediate response, you have to log it in a database and wait months-years
if ever for it to be addressed. Too often the response from open source projects
is "patches welcome" which for non-developers or even developers without expertise
in that particular codebase or time to become expert, is a polite way of
saying "@#$% off".

At least a commercial enterprise that has mass market success can (if they've
done their sums right) leverage that success to add more resources if they
choose. Free software doesn't have that option, so even if the response
policy is better, the reality is often as bad.

cheers,
Graeme Gill.

[Pete Batard]

Post by Graeme Gill
It's not a relevant distinction for anyone doing cross platform
development who needs to supports Linux, OS X and MSWindows,
since they were using both libusb and libusb-win32 anyway.

The argument was about what a single individual decides to do, vs a
group of individuals. I had some warnings about trying to bring anything
GPL into libusb in the past (though, as long as the code is kept
separate, I consider we should be fine too), which is why I'm reluctant
to take any hasty decision on how we should proceed with the driver's
GPL code.

Post by Graeme Gill
Sorry, but from my perspective (and my particular usage) the current state
of Libusb1 has that as a major regression compared to libusb0& libusb0-win32.

Alright then, let's define major.

[Graeme Gill]

Post by Pete Batard

Post by Graeme Gill
Sorry, but from my perspective (and my particular usage) the current state
of Libusb1 has that as a major regression compared to libusb0& libusb0-win32.

Alright then, let's define major.

[Pete Batard]

No, it causes a read failure when it shouldn't. This causes the application
to be unusable.

OK. Didn't catch that one with the latest logs.

To be fair, this was apparently due to a very simple bug (using <=
instead of < in threads_windows) if you don't count the fd notification
switcheroo, and you are only the second person I'm aware of who actually
tested a multithreaded application with the new backend. In case this
wasn't clear, as long as we don't have a multithreaded test app (which
we won't have for some time), we're still relying on external users to
test our threaded code.

Oh, and from what I gather, it looks like if we had released the Windows
backend with pthread-win32, as I was originally pushing for, we wouldn't
have been facing this "major regression" issue with our first release.
Sure, we'd still have had some adjustments to make with poll, but
nothing that would have prevented your application to work, and it would
have become a lot easier to identify the bug after thread abstraction
was introduced. Not to say that there might not be a "major regression"
bug still lurking inside the poll layer, but at least, that would have
been one less brand new section of code we'd have had to worry about for
the first release.

As I did point out at the time, even if I'm not unhappy at all with the
thread abstraction we currently have, I think it introduced too many
changes/ too much new code at once, and this leads exactly to kind of
problems we have been facing here. And early release with pthread-win32
would have alleviated much of this issue.

And, aside from prioritization, this is also the reason why I don't want
to see libusb0.sys integrated before we have a first release.

Sure, but commercial enterprises can exploit that resource as well by
creating user forums, so they can still be ahead.

Ah, but God forbid said voluntary users try to modify the commercial
application, say, to make it compatible with Win2k for instance, if the
project manager has arbitrarily decided it should not be. And how many
times have we seen insightful posts on how to bypass disputable
commercial software restrictions (not talking about circumventing IP,
but rather thing like iPhone tethering) or extend the capabilities of a
product that were shot down by the commercial entity?

These forums are usually restricted to usage discussion, which is fine
for support, but, unlike FOSS, rarely promotes active creative
participation from end-users, and certainly does not allow the tracking
of what developers are doing to address issues.

Even a company supposedly open like google still hides behind a cowardly
suggestion page where suggestions disappear into some kind of wormhole
(i.e., if you're lucky, it will magically reappear, properly addressed,
at some point in the future):
http://mail.google.com/support/bin/static.py?hl=en&page=suggestions.cs

Case in point:
http://www.google.com/support/forum/p/gmail/thread?tid=0e5f4c64c9736f8b&hl=en

You'd probably be hard pressed to find an open source project where
something relatively simple as enabling an alternate network port takes
almost a year... And I believe Google do have the facility to throw
developer or resources at the issue and judging by the request thread,
they certainly have the demand for it.

I know you're going to tell me that gmail is free in the first place
(although the data gathered through gmail is probably more valuable to
google than what any paying gmail subscribers would provide), so why
should they throw developer resources at it?

But that was precisely my point. If a commercial software company
doesn't see a profit incentive, they're unlikely to take much heed of
customer satisfaction, no matter how adequately resourced they can
become (also something that's hard to judge from the outside, as
companies will never official admit that they too have resource issues)
or how easy the issue is to fix.

Which is why I'm disputing your point that, because a commercial company
has the ability to throw paid developers on it, you're more likely to
see issues addressed, or development occur, that voluntary FOSS
developers wouldn't do.

Now, I 100% agree with you that the most successful FOSS projects are
the ones that have full time paid developers doing the bulk of the work,
but I don't think that was ever a contention point.

Regards,

/Pete


PS: The sooner X11 dies and is replaced by... anything else, really, the
better. ;) As to Gimp, I'm not sure I want to enter the debate of what
it's really competing against. It's not because a FOSS project seems
under resourced that it's not doing a better job than commercial one
(7zip, ffdshow). Plus, I doubt that there were more developers on IE
than there were on Firefox, when Firefox started dislodging a then very
moribund IE6.

[Xiaofan Chen]

Post by Graeme Gill

Post by Pete Batard
Yup, and libusb-win32 has always been a separate project (fork) from the
main libusb one.

It's not a relevant distinction for anyone doing cross platform
development who needs to supports Linux, OS X and MSWindows,
since they were using both libusb and libusb-win32 anyway.

BTW, I am wondering the reason you include the libusb-win32
device driver libusb0.sys in your snapshots.

Why not just use the existing libusb-win32 0.1.12.2 release?
Or do you include some bug fixes or enhancements in your codes?
If that is the case, you might want to send the patches to
Stephan Meyer. I think he still monitors the libusb-win32
mailing list (and possible this one as well).

[Graeme Gill]

Post by Xiaofan Chen
BTW, I am wondering the reason you include the libusb-win32
device driver libusb0.sys in your snapshots.

To make it a complete project ?

I certainly don't expect people to have to gather code
from all over the place, just to be able to build it.

Post by Xiaofan Chen
Why not just use the existing libusb-win32 0.1.12.2 release?

Because it's a disjoint project, and I'd like to see a single
cross platform USB access library ?

Post by Xiaofan Chen
Or do you include some bug fixes or enhancements in your codes?

There are some minor changes (control timeout, Adding
set_configuration back in on device start to get devices
working).

Post by Xiaofan Chen
If that is the case, you might want to send the patches to
Stephan Meyer. I think he still monitors the libusb-win32
mailing list (and possible this one as well).

I've made that suggestion in the past, and the changed weren't taken up.
(Stephan Meyer seems to almost have abandoned libusb-win32).

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Post by Xiaofan Chen
Or do you include some bug fixes or enhancements in your codes?

There are some minor changes (control timeout, Adding
set_configuration back in on device start to get devices
working).

I see. Adding set_configuration back in the device driver
is definitely a good thing. It sometimes caught people
porting code from libusb 0.1 to libusb-win32 0.1. Under
Linux, typically set_configuration is not necessary. With
the stock libusb-win32 0.1.12.2 binary, it is necessary.

The reason is of course the same code base for the
filter driver. But the filter driver seems to cause a lot
of problems for later Windows version, probably due to
the reason Tim Roberts mentioned here:
http://sourceforge.net/tracker/?func=detail&aid=2658937&group_id=78138&atid=552262

Anyway, the filter driver is much more difficult to
get right than the device driver. So I guess we should
give it a pass.

BTW, did you happen to browse the past patches and
bug reports submitted to libusb-win32?
http://sourceforge.net/tracker/?group_id=78138&atid=552264
http://sourceforge.net/tracker/?group_id=78138&atid=552262
http://sourceforge.net/tracker/?group_id=78138&atid=552265

Post by Graeme Gill

Post by Xiaofan Chen
If that is the case, you might want to send the patches to
Stephan Meyer. I think he still monitors the libusb-win32
mailing list (and possible this one as well).

I've made that suggestion in the past, and the changed weren't taken up.
(Stephan Meyer seems to almost have abandoned libusb-win32).

I see.

Probably because he is too busy. But occasionally he
still replies to emails in the libusb-win32 list. For libusb
0.1, Daniel clearly stated it is un-maintained. For libusb-win32,
at least I did not see anything formally announced from Stephan.

[Graeme Gill]

Post by Xiaofan Chen
The reason is of course the same code base for the
filter driver. But the filter driver seems to cause a lot
of problems for later Windows version, probably due to
http://sourceforge.net/tracker/?func=detail&aid=2658937&group_id=78138&atid=552262

That was my reasoning.

Post by Xiaofan Chen
BTW, did you happen to browse the past patches and
bug reports submitted to libusb-win32?
http://sourceforge.net/tracker/?group_id=78138&atid=552264
http://sourceforge.net/tracker/?group_id=78138&atid=552262
http://sourceforge.net/tracker/?group_id=78138&atid=552265

No I haven't. The code in my snapshot is really a placeholder.

Post by Xiaofan Chen
Probably because he is too busy. But occasionally he
still replies to emails in the libusb-win32 list. For libusb
0.1, Daniel clearly stated it is un-maintained. For libusb-win32,
at least I did not see anything formally announced from Stephan.

Some of the code in libusb-win32 1.0 seems to be less up to
date than what's in libusb-win32 0.1. I started out using
libusb-win32 1.0 as a base for my mods to libusb1, and found
that it wasn't quite right, so reverted to the code
in libusb-win32 0.1.

Graeme Gill.

[Pete Batard]

What about release early and release often ? :-)

That's precisely the issue. There hasn't been any release early, release
often with libusb, and the last thing I want is start integration work
that might get shot down by the official libusb maintainers, since them
not subscribing to the release early release often paradigm means I
cannot vouch for what their standards really are (and it seems I've
gotten it wrong quite a few times already). Spending time recreating
patches against the official git branch so that everybody is happy
(which is something I've done at least 4 times now) is not really my
idea of fun and takes away from development/bugfix time.

Now, if we had an official release already, I would have integrated your
work into my master (well, the dev-master which I plan to create after
release as a staging area for master, which will itself become staging
for official).

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard
That's precisely the issue. There hasn't been any release early, release
often with libusb, and the last thing I want is start integration work
that might get shot down by the official libusb maintainers, since them
not subscribing to the release early release often paradigm means I
cannot vouch for what their standards really are (and it seems I've
gotten it wrong quite a few times already). Spending time recreating
patches against the official git branch so that everybody is happy
(which is something I've done at least 4 times now) is not really my
idea of fun and takes away from development/bugfix time.
Now, if we had an official release already, I would have integrated your
work into my master (well, the dev-master which I plan to create after
release as a staging area for master, which will itself become staging
for official).

Peter apparently has high expectation about the first release
with Windows WinUSB and HID backend.

Just wondering if it is possible to release libsub 1.07 with the
current Windows backend (probably some touch up on the
documents or auxiliary files or things like that) and flag it
as beta and with potential bugs.

[Graeme Gill]

Post by Pete Batard
Now, if we had an official release already, I would have integrated your
work into my master (well, the dev-master which I plan to create after
release as a staging area for master, which will itself become staging
for official).

Hmm. If I were in your shoes, I wouldn't worry about it too much.
Just make available the best possible, up to date code. By all means
keep an eye on making it possible for it to become the next "official"
release, but in the end, working code trumps other considerations.
(And by "working" I do mean packaging, documentation, licenses etc.)

If your code is maintained and the official release is not, then
your code will become the de-facto official release.

(Yes, you might like to make "stable" and "development" versions available.)

Graeme Gill.

[Graeme Gill]

Post by Xiaofan Chen

Post by Xiaofan Chen

Post by Graeme Gill
<http://www.argyllcms.com/libusb.zip> 112337 bytes,

Thanks. All the warnings are gone now under Cygwin.

BTW, you may want to rename those makefile in your
zip snapshots as they may be overwritten by Cygwin
autogen.sh.

OK, fixed.

<http://www.argyllcms.com/libusb.zip> 112419 bytes.

(I also changed the calling convention to __cdecl to
make the .lib link with normally compiled code).

Graeme Gill.

[Graeme Gill]

Post by Michael Plante
Interesting, I missed that part. FWIW, libusb-win32 specifies a
"TARGETPATH" in the "sources_dll" file, but libusb-winusb does NOT in
"sources". You might just try fiddling with the settings to see if
something compiles.

If I add a TARGPATH=obj to sources, and then copy the makefile to
libusb/os it gets further when I run ddk_build.cmd.

(the makefile from libusb-win32 contains:
!INCLUDE $(NTMAKEENV)\makefile.def
)

Post by Michael Plante
D:\src\argyll\libusb1\libusb\os>build -cZ
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objfre_wnet_x86
BUILD: Compile and Link for i386
BUILD: Examining d:\src\argyll\libusb1\libusb\os directory for files to compile.
BUILD: Compiling (NoSync) d:\src\argyll\libusb1\libusb\os directory
1>Compiling - libusb-1.0.rc for i386
1>Compiling - core.c for i386
1>errors in directory d:\src\argyll\libusb1\libusb\os
1>d:\src\argyll\libusb1\libusb\libusbi.h(121) : error C2010: '.' : unexpected in macro formal parameter list
1>d:\src\argyll\libusb1\libusb\libusbi.h(121) : error C2010: '.' : unexpected in macro formal parameter list
1>d:\src\argyll\libusb1\libusb\libusbi.h(121) : error C2010: '.' : unexpected in macro formal parameter list

If I then add a define for _MSC_VER into the sources file

C_DEFINES = $(C_DEFINES) /DDDKBUILD /D_MSC_VER=1200

Post by Michael Plante
D:\src\argyll\libusb1\libusb\os>build -cZ
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objfre_wnet_x86
BUILD: Compile and Link for i386
BUILD: Examining d:\src\argyll\libusb1\libusb\os directory for files to compile.
BUILD: Compiling (NoSync) d:\src\argyll\libusb1\libusb\os directory
1>Compiling - libusb-1.0.rc for i386
1>Compiling - core.c for i386
1>Compiling - descriptor.c for i386
1>Compiling - io.c for i386
1>Compiling - sync.c for i386
1>Compiling - generating code... for i386
1>Compiling - threads_windows.c for i386
1>Compiling - poll_windows.c for i386
1>Compiling - windows_usb.c for i386
1>Compiling - generating code... for i386
BUILD: Compiling d:\src\argyll\libusb1\libusb\os directory
101>Building Library - objfre_wnet_x86\i386\libusb-1.0.lib for i386
BUILD: Linking d:\src\argyll\libusb1\libusb\os directory
1>Linking Executable - objfre_wnet_x86\i386\libusb-1.0.dll for i386
BUILD: Done
10 files compiled
1 library built
1 executable built
==chk was unexpected at this time.

Which seems OK. It would be good to get driver/libusb0.sys compiling too though.

Graeme Gill.

[Michael Plante]

Post by Pete Batard

Post by Graeme Gill
Of more concern to me is that it currently isn't usable on
MSWindows because of the thread interaction issues.

That's a bit harsh. There's a lot of applications that can use the
Windows backend right now, and the reason why there are still bugs in
some threaded apps is because we still don't have a generic threaded app
to test against.
You just happen to have encountered one of these bugs that I'm trying to
weed out. I'll get there, but it won't be an immediate process...

I did not see this bug mentioned on the list, but I may have missed it. I
heard someone make a passing reference to it recently, but saw no
description...


----- ok, I tried to ignore the rest of this the first time it popped up,
thinking it was just a one-off remark, but... -----

Post by Pete Batard
I'll have to disagree with that. I have yet to find a single software
company that leaves up to my standards of placing customer satisfaction
at the number one spot.

Maybe. The motivations for satisfying people are certainly different for
someone who's paid to do it, vs someone who is doing it for fun. In
particular, the latter person is less likely to try to satisfy an unpleasant
user.

Post by Pete Batard
No matter what the official corporate message
is, I've always seen it get dislodged by profit (and yes, I have seen
that from the inside as well)

So? To the extent that customer satisfaction is necessary, it'll be
emphasized. Customer satisfaction is one aspect of enhancing revenue. But
that's all it is or should be. If Company X's customers are satisfied
enough to give them money, when we may consider what they're doing
unsatisfactory, who's losing sleep, us, the [other] customers, or the
company?

Post by Pete Batard
One good way to rate how high proprietary software companies place
customer satisfaction is to have a look at what they do for customer
support (inherently a very non-profitable operation, when not based on a
subscription model).

Perhaps, although the example was Microsoft, and, last I checked (quite
awhile ago), phone support costs. Nowadays, they have monitored forums and
such, which very well may be the correct answer. As long as the devs can
monitor when they want, and only have to answer the questions they want, you
get a situation somewhat more like you have with volunteer development.
I've had some success getting answers this way, and the time it cost me is
probably less than it would take to work my way through levels of support
(assuming they'd let me through).

Post by Pete Batard
Ideally, if an issue is reported, there should
exists the shortest route between the customer who reported it and the
person(s) who can address that problem, with an almost direct and
real-time means of communication between all parties.

Yes and no. Direct access would prevent the dev from doing any actual work,
depending on the volume of support calls. Some volunteers have learned to
cope by ignoring certain "users", although that phenomenon has pleasantly
been almost nonexistent in this project. Are you suggesting companies do
the same?

Post by Pete Batard
Then the person(s) who can address the issue also need to have the
relevant amount of time allocated for it, by the company, as part of
their daily job.

Sure the balance in tech support is currently wrong just about everywhere I
look, but I think this suggestion is too far the other way.

Post by Pete Batard
Now, when was the last time you had the chance, as a regular customer,
to initiate near-direct communication with software developers from a
major proprietary software company, and where said developers addressed
an issue which required a fix/enhancement in a reasonable timeframe?

See above. And if you can pay, it does happen. (Not that I can, but I have
friends who've gotten decent support when their company paid for the support
calls.) Perhaps this is making your point about tech support, but I don't
agree that it goes any farther than tech support. I don't see why any
company would be expected to spend any more time on tech support than on
other *potentially* unprofitable operations like R&D. They make their own
internal judgements, and, as long as it's free to us, the decision is not
only less pleasant for us, but also varies somewhat depending on who makes
the decision. After all, the decisions the managers make are then somewhat
insulated from the market, so they have fewer cues as to what the "right"
amount is.

But how is this relevant to the problems we're having (whatever those might
be)? Is someone here unresponsive? Perhaps this part should be off-list?


Michael

[Pete Batard]

Post by Michael Plante
I did not see this bug mentioned on the list, but I may have missed it. I
heard someone make a passing reference to it recently, but saw no
description...

That's because this bug was reported privately when Graeme started
having an application he could test with libusb0.sys.

I'll try to post some details later on.

Basically, we're seeing a lot of unexplained wake ups for an application
that has 2 thread, where one has no reason to be woken up.

tarting 1000 ms wait for 3 handles...
libusb:debug [] will use interface 0
libusb:debug [] dynamic_fds: fd_update event
libusb:debug [] poll() returned -1
libusb:debug [] next timeout in 0.999791s
libusb:debug [] poll() 2 fds with timeout in 1000ms
libusb:debug [] fd[0]=3 (overlapped = 003C3D08) got events 0001
libusb:debug [] fd[1]=5 (overlapped = 013A9E00) got events 0001
libusb:debug [] dynamic_fds: added 0 extra handles
libusb:debug [] starting 1000 ms wait for 3 handles...
libusb:debug [] add fd 6 events 1
libusb:debug [] next timeout in 0.999651s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999651s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999581s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999581s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999512s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999442s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999442s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999372s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999372s
libusb:debug [] another thread is doing event handling
libusb:debug [] next timeout in 0.999302s

Those wake up calls don't seem to come directly from poll, or at least
not from an fd.

Post by Michael Plante
Customer satisfaction is one aspect of enhancing revenue. But
that's all it is or should be. If Company X's customers are satisfied
enough to give them money, when we may consider what they're doing
unsatisfactory, who's losing sleep, us, the [other] customers, or the
company?

Well, the discussion was about commercial doing a better job at ensuring
customer satisfaction than non-commercial. Looks like you agree that if
company X receive enough money from customers without caring too much
about customer satisfaction, they'll go for it, which was pretty much
the point I was trying to make.

Post by Michael Plante
Nowadays, they have monitored forums and
such, which very well may be the correct answer. As long as the devs can
monitor when they want, and only have to answer the questions they want, you
get a situation somewhat more like you have with volunteer development.

As long as devs/tech support are actively involved in these public
forums, that's fine with me. But not all software companies have that
and it's been a really long time coming for those who do. And yes, I
also consider that this is how support should work, provided that the
company employees participating in these forums have time allocated to
do so during their regular workday, rather than something extra and
potentially discouraged (because it is seen as taking time away from
other activities).

Post by Michael Plante
Yes and no. Direct access would prevent the dev from doing any actual work,

Forum with active developer involvement is direct access to me. On the
other hand, and as you point out, a lot of open source projects leave
the developer's e-mail accessible, and don't seem to suffer that much
from it. But support through e-mail is quite pointless if it remains
private.

Post by Michael Plante
Are you suggesting companies do the same?

Well, that model can work for open source. Why shouldn't it work for
commercial as well? You'd need relevant e-mail discussions rendered
public one way or another though, so that repetition is avoided. An
active forum is definitely the best way, as you also get the benefit of
pull vs push (i.e. not as disruptive as e-mail).

Post by Michael Plante
And if you can pay, it does happen.

Aha, but the price of customer satisfaction, which results in more sales
(and not just from the single customer) *should* cover the cost of
providing support in the first place, just like it is meant to cover R&D.
If one in ten satisfied customers brings something like 2 more customers
to the table, that's 2 extra sales you wouldn't have gotten in the first
place, for negligible manufacturing cost => "free" money for support,
R&D, whatever.
Of course, estimating what a satisfied/disatisfied customer is really
worth in terms of positive or negative sales is yet another exercise.

Post by Michael Plante
But how is this relevant to the problems we're having (whatever those might
be)?

I don't think it goes farther than a discussion about the respective
qualities of commercial vs FOS software with regards to customer
satisfaction, and customer support being used as a window to how
commercial companies treat customer satisfaction.
Just an interesting side discussion, but one that bears no relevance to
the problem at hand.

Regards,

/Pete

[Pete Batard]

libusb:debug [] dynamic_fds: fd_update event

(...)

libusb:debug [] dynamic_fds: added 0 extra handles

OK, it looks like Graeme is using the DYNAMIC_FD option with a mod that
unconditionally adds calls to usbi_fd_notification() after the call to
usbi_add_pollfd().

I advised to move usbi_fd_notification() outside of the poll layer's fd
creation, as it should intervene after libusb has been made aware of the
new fd. This is something I'm going to patch in master as well.

But I think we'll need to see a log where DYNAMIC_FD is disabled as the
2 options are meant to be mutually exclusive.

Regards,

/Pete