1. because we use WINAPI, the def file MUST have the @n aliases - there's no way around as MinGW's .o use decoration always for __stdcall, and this can't be turned off
2. our "dumb" autogen create_def() script simply creates the whole range of aliases (we might improve on this in the future)
3. dlltool must be called manually to create the import lib from the def, *with the --kill-at option*
4. a CREATE_IMPORT_LIB autotools variable is introduced to selectively run dlltool or not
added libusb-1.0.def (plus reference in MS projects)
removed LIBUSB_EXP/__declspec(dllexport) from libusb.h
removed LIBUSB_DLL_BUILD macros
added -Wl,--add-stdcall-alias linker option for MinGW/cygwin for DLL generation
added sed script in autogen to update the libusb-1.0.def
cast pointer to void* for safe_free
always use safe_strlen in lieu of strlen
avoid the use of a strlen parameter in a macro
don't feed negative values to min() in safe_strncat
set uninitialized DLL functions to NULL
Michael Plante pointed out that if 2 users call libusb_init(NULL) within
a process, we end up creating 2 default contexts, one of which is lost.
Add reference counting so that the default context is reused and
destroyed only after the last user.
9996ccaed7 introduced a problem in that mutexes could be destroyed
in the error handling codepath before they had been created.
Pointed out by Michael Plante.
This return code indicates that the device returned a data packet
less than the max packet size. In libusb backend terms, this is
a successful transfer.
This message was put in place to aid libusb-compat-0.1 users, who
may run into the change that libusb-0.1 allowed you to usb_open() a
device that you don't have write access to, but libusb-1.0 does not.
As explained on the ticket this change is dangerous so it should go through
the usual logging mechanism. I also added a similar regular log message
to libusb-compat-0.1.
Pete Batard