Daniel Drake
16 years ago
Before I closed the SF tracker, Josh Perry created a ticket saying that
he'd started working on windows support. I just went in to dig out his
findings that he posted. Now saved at http://www.libusb.org/ticket/1
> I began an attempt to create a libusb backend for Windows using WinUSB
> which would give libusb support for >=WinXP. I began by creating a nulled
> out backend struct for WinUSB to get my development environment (MSVC)
> compiling properly. It turns out that though some of the functionality for
> USB device access has been abstracted away, there are a lot of dependencies
> that don't exist on Windows and coding semantics that aren't supported by
> MSVC.
>
> I think I've not finally got it compiling by finding or writing wrappers
> for the dependencies and changing some of the code semantics. I haven't
> tested my changes yet so I don't know if it still buil
>
> I thought I would hit the compatibility bullet points here, to see if there
> is a better way to abstract these incompatibilities:
> * pthreads - pthreads is used for its mutex and cond variable
> functionality; Windows has an incompatible set of syncro primitives, I
> worked around this with http://sourceware.org/pthreads-win32/ but this
> project hasn't been updated since '06
> * poll - Windows doesn't have poll, it has mechanisms for similar
> functionality such as WaitForMultipleObjects etc... I stole some code from
> glib to make a fake poll() using those windows funcs.
> * sys/time.h - This isn't even a POSIX header, it's BSD, the definitions
> are pretty simple so I just patched a time.h together from some defs in
> winsock2.h and the original.
> * stdint.h - I know this is in the C99 standard, but MSVC doesn't have it,
> I grabbed a copy made by paul hsieh
> http://www.azillionmonkeys.com/qed/pstdint.h
> * variadic macros - these are used for some logging functionality. I'm not
> familiar with the syntax for variadic macros in GCC but I changed these
> definitions to work in MSVC, I'll have to test them in GCC to see if it is
> compatible.
> * typeof - This is a GCC extension not supported by MSVC, I changed the
> list-walking macros that used this to just take a last parameter of the
> type.
> * pipes - again the WinAPI has a different piping API, I worked around this
> by using io.h that defines a _pipe function and a macro from glib that
> defines a compatible POSIX pipe. This is the only point I had to use an
> ifdef in the code to include io.h and fcntl.h instead of unistd.h on MSVC.
>
> I would love to maybe abstract these dependencies away instead of creating
> such a fragile framework of stand-ins. Perhaps using alternatives that are
> cross-platform, or pulling the platform specific pieces out into different
> source files so that the implementation can be swapped out easily.
>
> I'm going to see if I can rig something up for testing so that I can tell
> if this port actually works properly (it compiles! now whats a segfault?).
> Once I've verified the functionality I can send in a patch for the changes
> I've made.
>
> I would love to hear some input on how you guys think this should proceed,
> I really want to make libUSB work for my projects on all platforms!
>
> - Josh Perry
Some brief comments from me:
pthreads: only used internally, so we don't have to actually use
pthreads on windows. We just have to use an alternative that provides
the basic locking primitives.
poll and the file descriptor model: when designing the library early on,
I took a look at glib and noted that they have somehow managed to
emulate windows event sources as numbers that look like file
descriptors, so I figure we can do the same.
MSVC: this seems adventurous. Shouldn't we start with just being able to
get it compiled and working with gcc on windows? Or is that impossible?
I have very little knowledge of windows development practicalities.
Daniel
he'd started working on windows support. I just went in to dig out his
findings that he posted. Now saved at http://www.libusb.org/ticket/1
> I began an attempt to create a libusb backend for Windows using WinUSB
> which would give libusb support for >=WinXP. I began by creating a nulled
> out backend struct for WinUSB to get my development environment (MSVC)
> compiling properly. It turns out that though some of the functionality for
> USB device access has been abstracted away, there are a lot of dependencies
> that don't exist on Windows and coding semantics that aren't supported by
> MSVC.
>
> I think I've not finally got it compiling by finding or writing wrappers
> for the dependencies and changing some of the code semantics. I haven't
> tested my changes yet so I don't know if it still buil
>
> I thought I would hit the compatibility bullet points here, to see if there
> is a better way to abstract these incompatibilities:
> * pthreads - pthreads is used for its mutex and cond variable
> functionality; Windows has an incompatible set of syncro primitives, I
> worked around this with http://sourceware.org/pthreads-win32/ but this
> project hasn't been updated since '06
> * poll - Windows doesn't have poll, it has mechanisms for similar
> functionality such as WaitForMultipleObjects etc... I stole some code from
> glib to make a fake poll() using those windows funcs.
> * sys/time.h - This isn't even a POSIX header, it's BSD, the definitions
> are pretty simple so I just patched a time.h together from some defs in
> winsock2.h and the original.
> * stdint.h - I know this is in the C99 standard, but MSVC doesn't have it,
> I grabbed a copy made by paul hsieh
> http://www.azillionmonkeys.com/qed/pstdint.h
> * variadic macros - these are used for some logging functionality. I'm not
> familiar with the syntax for variadic macros in GCC but I changed these
> definitions to work in MSVC, I'll have to test them in GCC to see if it is
> compatible.
> * typeof - This is a GCC extension not supported by MSVC, I changed the
> list-walking macros that used this to just take a last parameter of the
> type.
> * pipes - again the WinAPI has a different piping API, I worked around this
> by using io.h that defines a _pipe function and a macro from glib that
> defines a compatible POSIX pipe. This is the only point I had to use an
> ifdef in the code to include io.h and fcntl.h instead of unistd.h on MSVC.
>
> I would love to maybe abstract these dependencies away instead of creating
> such a fragile framework of stand-ins. Perhaps using alternatives that are
> cross-platform, or pulling the platform specific pieces out into different
> source files so that the implementation can be swapped out easily.
>
> I'm going to see if I can rig something up for testing so that I can tell
> if this port actually works properly (it compiles! now whats a segfault?).
> Once I've verified the functionality I can send in a patch for the changes
> I've made.
>
> I would love to hear some input on how you guys think this should proceed,
> I really want to make libUSB work for my projects on all platforms!
>
> - Josh Perry
Some brief comments from me:
pthreads: only used internally, so we don't have to actually use
pthreads on windows. We just have to use an alternative that provides
the basic locking primitives.
poll and the file descriptor model: when designing the library early on,
I took a look at glib and noted that they have somehow managed to
emulate windows event sources as numbers that look like file
descriptors, so I figure we can do the same.
MSVC: this seems adventurous. Shouldn't we start with just being able to
get it compiled and working with gcc on windows? Or is that impossible?
I have very little knowledge of windows development practicalities.
Daniel