Discussion:
__stdcall vs __cdecl - new core API (invisible) modifier
(too old to reply)
Pete Batard
2010-03-02 20:18:55 UTC
Permalink
Following a discussion with the maker of LibusbDotNet, it appears that:

1. C#/.NET projects uses the "__stdcall" calling convention by default
(http://www.codeproject.com/KB/cs/cdeclcallback.aspx).

2. MSVC C/C++ uses "__cdecl" (/Gd) by default Microsoft:
http://msdn.microsoft.com/en-us/library/46t77ak2%28VS.80%29.aspx
This can be changed on the project itself.

3. DDK build uses "__stdcall"
(http://www.winvistatips.com/using-build-exe-compile-application-against-__cdecl-symbol-dll-t196428.html),
and it seems everybody advises against trying to modify the build options.

Now, we could set everything to __stdcall by default, but this would
probably mean more issues from people using the default MSVC options in
their project.

And while we do have an API_EXPORTED config option (for the visibility
__attribute__), it does not appear to be possible to conciliate the need
of __attribute__ to appear before the function declaration:
__attribute__((...)) int* f(...)
and the calling convention to appear between the return type and the
function name:
int* __cdecl f(...)

To be pedantic, yes gcc does have some flexibility for the placement of
__attribute___ (see the end of
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Attribute-Syntax.html), but
not enough to be able to place API_EXPORTED either between "int" and
"*f" or "int*" and "f" and keep everybody happy. MSVC will complain on
first once and gcc on second.

Plus, MSVC will also complain about functions that are prototyped
without a calling convention (as is the case in libusb.h, which does not
contain API_EXPORTED) while the implementation has one.

Therefore, I propose introducing a new WINAPI macro for all the exported
functions in libusb.h as well as in the core files, that would be
defined to a user configurable calling convention on Windows platforms.

With this, most exported libusb calls would become something like:
int WINAPI libusb_open(...);
in libusb.h and:
API_EXPORTED int WINAPI libusb_open(...)
in core.

Obviously, since this is a modification of core, I'd like to hear some
views on that before I proceed.

Regards,

/Pete
Orin Eman
2010-03-02 20:49:27 UTC
Permalink
Post by Pete Batard
1. C#/.NET projects uses the "__stdcall" calling convention by default
(http://www.codeproject.com/KB/cs/cdeclcallback.aspx).
http://msdn.microsoft.com/en-us/library/46t77ak2%28VS.80%29.aspx
This can be changed on the project itself.
3. DDK build uses "__stdcall"
(
http://www.winvistatips.com/using-build-exe-compile-application-against-__cdecl-symbol-dll-t196428.html
),
and it seems everybody advises against trying to modify the build options.
Now, we could set everything to __stdcall by default, but this would
probably mean more issues from people using the default MSVC options in
their project.
And while we do have an API_EXPORTED config option (for the visibility
__attribute__), it does not appear to be possible to conciliate the need
__attribute__((...)) int* f(...)
and the calling convention to appear between the return type and the
int* __cdecl f(...)
To be pedantic, yes gcc does have some flexibility for the placement of
__attribute___ (see the end of
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Attribute-Syntax.html), but
not enough to be able to place API_EXPORTED either between "int" and
"*f" or "int*" and "f" and keep everybody happy. MSVC will complain on
first once and gcc on second.
Plus, MSVC will also complain about functions that are prototyped
without a calling convention (as is the case in libusb.h, which does not
contain API_EXPORTED) while the implementation has one.
Therefore, I propose introducing a new WINAPI macro for all the exported
functions in libusb.h as well as in the core files, that would be
defined to a user configurable calling convention on Windows platforms.
Fine by me, but not with 'WINAPI'; it's already defined in windef.h as
__stdcall.

I think we should just define the macro as __stdcall for Windows platforms
for a couple of reasons.

Firstly, I'd like there to be a standard DLL build that can just be used by
anyone (I'd use the DDK build for it as it doesn't produce DLLs that are
dependent on side-by-side C runtimes that may or may not be there).

Secondly, if we explicitly use __stdcall, then we have fewer possible
versions to support! It's bad enough that the user can pick lib, dll,
c-runtime of choice and so on already!

Orin.
Pete Batard
2010-03-02 21:03:57 UTC
Permalink
Post by Orin Eman
Fine by me, but not with 'WINAPI'; it's already defined in windef.h as
__stdcall.
Agreed. I saw WINAPI used here and there, so that's what I picked up,
but it can be anything.
Post by Orin Eman
I think we should just define the macro as __stdcall for Windows
platforms for a couple of reasons.
Firstly, I'd like there to be a standard DLL build that can just be used
by anyone (I'd use the DDK build for it as it doesn't produce DLLs that
are dependent on side-by-side C runtimes that may or may not be there).
I don't know. By that reasoning, we should also just produce a 32 bit
DLL and forget about x64, because everybody can use 32 bit DLLs anyway.

I'd say, if we can give users choice with minimal effort, we should go
for it. You never know what kind of restrictions other applications
might impose on external DLLs, and providing a choice of calling
conventions is a bit like providing a choice of platform. The more we
have, the better.
Post by Orin Eman
Secondly, if we explicitly use __stdcall, then we have fewer possible
versions to support! It's bad enough that the user can pick lib, dll,
c-runtime of choice and so on already!
Or use MSVC6 to compile libusb... ;)

Again, if it doesn't take too much effort, I think we should go for it.

Regards,

/Pete
Orin Eman
2010-03-02 21:15:14 UTC
Permalink
Post by Pete Batard
Post by Orin Eman
Fine by me, but not with 'WINAPI'; it's already defined in windef.h as
__stdcall.
Agreed. I saw WINAPI used here and there, so that's what I picked up,
but it can be anything.
Post by Orin Eman
I think we should just define the macro as __stdcall for Windows
platforms for a couple of reasons.
Firstly, I'd like there to be a standard DLL build that can just be used
by anyone (I'd use the DDK build for it as it doesn't produce DLLs that
are dependent on side-by-side C runtimes that may or may not be there).
I don't know. By that reasoning, we should also just produce a 32 bit
DLL and forget about x64, because everybody can use 32 bit DLLs anyway.
OK, I should have said a standard DLL for 32 and one for 64bit...
Post by Pete Batard
I'd say, if we can give users choice with minimal effort, we should go
for it. You never know what kind of restrictions other applications
might impose on external DLLs, and providing a choice of calling
conventions is a bit like providing a choice of platform. The more we
have, the better.
Post by Orin Eman
Secondly, if we explicitly use __stdcall, then we have fewer possible
versions to support! It's bad enough that the user can pick lib, dll,
c-runtime of choice and so on already!
Or use MSVC6 to compile libusb... ;)
Again, if it doesn't take too much effort, I think we should go for it.
My concern is "What is that libusb-1.0.dll that someone has put in the
system32 (or sysWOW64 or both) directory?" Are you going to name the dll
differently for different calling conventions?

Orin.
Tim Roberts
2010-03-02 21:32:01 UTC
Permalink
Post by Pete Batard
I don't know. By that reasoning, we should also just produce a 32 bit
DLL and forget about x64, because everybody can use 32 bit DLLs anyway.
Now, now, that's very different. A 64-bit app can't link to a 32-bit
DLL at all.
Post by Pete Batard
I'd say, if we can give users choice with minimal effort, we should go
for it. You never know what kind of restrictions other applications
might impose on external DLLs, and providing a choice of calling
conventions is a bit like providing a choice of platform. The more we
have, the better.
I have to disagree with this. If I am handed a DLL binary, how will I
know which convention it's using? Without that knowledge, I can't use
the DLL.

(Yes, technically speaking, I can go dump the exports and use my secret
decoder ring knowledge of the name decoration scheme to figure this out,
but that's expecting a bit much.)

I have to stand with Orin on this. Choose one (__stdcall unless there
is a compelling reason to do otherwise), and make that the
"libusb-win32" standard. That's just one more choice the user doesn't
have to make.
--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.
Pete Batard
2010-03-02 23:57:45 UTC
Permalink
Post by Tim Roberts
Now, now, that's very different. A 64-bit app can't link to a 32-bit
DLL at all.
Fair enough. Actually, I never realized there were so many issues using
a 32 bit DLL with a 64 bit app
(http://www.dnjonline.com/article.aspx?id=jun07_access3264).
Post by Tim Roberts
I have to disagree with this. If I am handed a DLL binary, how will I
know which convention it's using? Without that knowledge, I can't use
the DLL.
(Yes, technically speaking, I can go dump the exports and use my secret
decoder ring knowledge of the name decoration scheme to figure this out,
but that's expecting a bit much.)
I have to stand with Orin on this. Choose one (__stdcall unless there
is a compelling reason to do otherwise), and make that the
"libusb-win32" standard. That's just one more choice the user doesn't
have to make.
Aha, but I never said we wouldn't pick one and set that as standard. I'm
definitely not planning to publish 2 versions of the DLLs. If someone
really wants to use __cdecl, they'll have to recompile it themselves,
and they'll pretty much be on their own with regards to conflicts, etc.
What's more, unless the user knows what they're doing, they won't really
have to make a choice in the matter. There won't be any prompt that asks
"please select between __cdecl or __stdcall now".

My plan is to just provide an easy option to change the default calling
convention, if a developer ever needs to do so. Granted, if they really
need that, they could just go buy a version of Visual Studio (I don't
think Express would work that well with a redistributable DLL) and
switch the global option, but, well, as I said, we can easily add that
selection in a config, so why not do it?

Besides, you never know what kind of attributes or qualifiers we might
need to add to the public API in the future, so having an option already
in place could come handy.

I really hate the idea of telling our users "Well, we could *easily*
have added an option that would have been helpful to you, but we
preferred forcing you down a specific road..."

I for one know that I can't predict how the future might turn out to be
with regards to calling conventions, and considering that Microsoft
can't seem to make up their mind either, I don't think I'd want to
venture casting anything in stone. Then again, maybe noone will really
use that switch.

But I think I'll sleep better knowing that, if someone really wants it,
it's there.

Regards,

/Pete
Peter Stuge
2010-03-03 00:39:58 UTC
Permalink
you never know .. the future
telling our users
we preferred forcing you down a specific road..."
Seriously, this is an open source library for device driver
developers. Anyone who accepts "being forced down a specific road" is
in the wrong place and has the wrong mindset. If such a device driver
developer finds that they need a different calling convention (I'm
not sure most will even know what that is!) then they can fix it up
and send a patch.
I can't predict .. the future
casting .. in stone
if someone really wants it, it's there.
I think this sounds an awful lot like bloat. KISS is really great,
especially for the users. If there are only a few knobs and the code
is smart, then man doesn't need to spend as much time on the knobs to
get the code to function.


//Peter
Pete Batard
2010-03-03 02:11:00 UTC
Permalink
Post by Peter Stuge
If such a device driver
developer finds that they need a different calling convention (I'm
not sure most will even know what that is!) then they can fix it up
and send a patch.
Well, this actually is not entirely proactive stuff, but stems from the
LibusbDotNet developer finding out that he couldn't use the 1.0 DLL we
produced with C#, and then finding out that the DDK version and MSVC
version of the DLL weren't using the same conventions.

Right now, he has switched to using __cdecl because that's the default
we produce with MSVC and he was asking if we could switch to __cdecl in
the DDK too, which is why I investigated the matter.
Post by Peter Stuge
To sum things up, update the WinDDK build so they use _cdecl instead
of stdcall and the problem is solved!
I think this sounds an awful lot like bloat. KISS is really great,
especially for the users. If there are only a few knobs and the code
is smart, then man doesn't need to spend as much time on the knobs to
get the code to function.
Point taken - I'll drop the whole thing then.


On another note, since I haven't seen a reply to my last e-mail about
knowing where we stand for the release, could you or Daniel please set
up an *official* (and advertised for) development git repository where
you would pick stuff up on regular basis (preferably within weeks) of
what you plan to integrate for the next release? This would be
especially helpful when especially when *a lot* of development has been
occurring over a period of many months.

While I believe your libusb-stuge tree is the closest we have for
official staging (because you explicitly stated so), I don't think
having a 3 month staging period with new development is really for the best.
Besides, for an external user looking at http://git.libusb.org/, it's
hard to tell where official testing is supposed to occur.

As you know, I've had (and still have trouble) trying to figure out what
it is exactly that you guys want out of the Windows backend, because,
after 3 months development, still none of the Windows specific code has
made its way into any official staging/testing branch that you maintain.
A little bit of active direction (through picking Windows commits on
regular basis, and advertising them for official testing) could go a
long way, and help prevent things like finding out, shortly before
release, that you don't plan to add xusb for instance.

There were plenty of milestones that, IMO, should have warranted some
kind of official integration, at least for a test/staging branch.
WinUSB completion was one. HID was another. Removal of pthread-win32 was
a 3rd. Even with a polling that doesn't behave as expected when used
with a timeout thread, or dodgy HID feature reports, there was ground
for release, especially as mainstream applications (like
openocd/libftdi) had been tested and confirmed working.

This is why, I think having an officially mandated and updated staging
branch for the Windows backend would really help.

Or is it possible to subscribe to KISS and not subscribe to "Release
Early, Release Often"?


Regards,

/Pete
Pete Batard
2010-03-03 16:49:57 UTC
Permalink
I just pushed a commit that change the calling convention to __stdcall
for all the Visual Studio 2008 project files (or maybe that's a bit
heavy handed, and we could leave the default __cdecl for anything but
the DLL?)

Since I'm pretty sure I'm going to screw things up if I try to modify
the other files manually, could people with MSVC6 and VS2005 send me a
patch for their project files as well?

Regards,

/Pete
Michael Plante
2010-03-02 23:01:28 UTC
Permalink
Post by Pete Batard
1. C#/.NET projects uses the "__stdcall" calling convention by default
(http://www.codeproject.com/KB/cs/cdeclcallback.aspx).
http://msdn.microsoft.com/en-us/library/46t77ak2%28VS.80%29.aspx
This can be changed on the project itself.
3. DDK build uses "__stdcall"
(http://www.winvistatips.com/using-build-exe-compile-application-against-__c
decl-symbol-dll-t196428.html),
Post by Pete Batard
and it seems everybody advises against trying to modify the build
options.
Post by Pete Batard
Now, we could set everything to __stdcall by default, but this would
probably mean more issues from people using the default MSVC options in
their project.
The options don't matter as long as we attach an attribute to the prototype.
Now the question is whether name decoration is enough of a hint for apps,
given that only the linker sees it. I suspect not, in which case the
prototype attribute is pretty much required. What about MinGW? Cygwin?
Post by Pete Batard
Post by Orin Eman
Secondly, if we explicitly use __stdcall, then we have fewer possible
versions to support! It's bad enough that the user can pick lib, dll,
c-runtime of choice and so on already!
Or use MSVC6 to compile libusb... ;)
Huh? Are VC6 DLLs not linkable with apps compiled with later compilers?
Post by Pete Batard
My concern is "What is that libusb-1.0.dll that someone has put in the
system32 (or sysWOW64 or both) directory?" Are you going to name the
dll differently for different calling conventions?
Does MinGW use .dll or .so? If the former, that's one more potential
conflict.
Post by Pete Batard
I can go dump the exports and use my secret
decoder ring knowledge of the name decoration scheme to figure this out,
but that's expecting a bit much.)
Even that may not work in some cases. The names don't have to be decorated
*@4, etc, as I understand. You'd really have to disassemble it and look at
whether the function clears its own arguments from the stack upon return.
But your point stands...
Post by Pete Batard
Obviously, since this is a modification of core, I'd like to hear some
views on that before I proceed.
I figured this would have to happen eventually, but it slipped my mind since
I changed to linking statically early on in lsusb/xusb to conform with what
you guys were doing. In any case, please try to make it a separate commit.


Michael
Pete Batard
2010-03-03 00:06:54 UTC
Permalink
Post by Michael Plante
Post by Pete Batard
Post by Orin Eman
Secondly, if we explicitly use __stdcall, then we have fewer possible
versions to support! It's bad enough that the user can pick lib, dll,
c-runtime of choice and so on already!
Or use MSVC6 to compile libusb... ;)
Huh? Are VC6 DLLs not linkable with apps compiled with later compilers?
This was tongue in cheek for "well, if we really want to have fewer
things to support in general, why not throw MSVC6 away as well?"

But don't worry, while I may sound annoyed at times about having to
support MSVC6, I'll fight tooth and nail to keep support there (as long
as it doesn't bring everything else down).
Post by Michael Plante
Does MinGW use .dll or .so? If the former, that's one more potential
conflict.
Regardless of this, I'd prefer not make any hypothesis with regards to
what MinGW of cygwin consider as the default calling convention for a
DLL. i think most of the time, they'd go through a library wrapper
generated by dlltool or something, so that might not be an issue, but
still...
Post by Michael Plante
In any case, please try to make it a separate commit.
Definitely.

Regards,

/Pete
Michael Plante
2010-03-03 00:20:44 UTC
Permalink
Post by Pete Batard
Post by Michael Plante
Does MinGW use .dll or .so? If the former, that's one more potential
conflict.
Regardless of this, I'd prefer not make any hypothesis with regards to
what MinGW of cygwin consider as the default calling convention for a
DLL. i think most of the time, they'd go through a library wrapper
generated by dlltool or something, so that might not be an issue, but
still...
I'm not sure I understand your answer. If it uses .dll, we might need to
rename it. If it doesn't, it doesn't matter. That wasn't really a question
about calling convention, but, rather, potentially another thing besides
calling convention that could require a rename.

Regards,
Michael
Pete Batard
2010-03-03 00:46:41 UTC
Permalink
Post by Michael Plante
I'm not sure I understand your answer. If it uses .dll, we might need to
rename it. If it doesn't, it doesn't matter. That wasn't really a question
about calling convention, but, rather, potentially another thing besides
calling convention that could require a rename.
If your question is about how xusb/lsusb are built with MinGW, then that
should be through the static lib, not the DLL.

Otherwise, I'm not sure I understand the question.

MinGW still seems to generate a DLL by default (internally I believe),
as this is the result of the listing of libusb/.libs/

1.4M Mar 3 00:37 libusb-1.0-0.dll*
3.0M Mar 3 00:37 libusb-1.0.a
109K Mar 3 00:37 libusb-1.0.dll.a
943 Mar 3 00:37 libusb-1.0.la
951 Mar 3 00:37 libusb-1.0.lai

My understanding is that only the .a is used, and the other files are
just byproducts.

Regards,

/Pete
Peter Stuge
2010-03-03 00:58:43 UTC
Permalink
Post by Pete Batard
1.4M Mar 3 00:37 libusb-1.0-0.dll*
3.0M Mar 3 00:37 libusb-1.0.a
109K Mar 3 00:37 libusb-1.0.dll.a
943 Mar 3 00:37 libusb-1.0.la
951 Mar 3 00:37 libusb-1.0.lai
My understanding is that only the .a is used, and the other files
are just byproducts.
Google mingw dll

.a is to gcc what .lib is to cl

.a can be both import library (109K libusb-1.0.dll.a) and static
library (3.0M libusb-1.0.a). If app is linked with import library
then dynamically linked library (1.4M libusb-1.0-0.dll) must be in
the DLL search path at run time.

The * is added by ls to indicate that the file is an executable.


//Peter
Xiaofan Chen
2010-03-03 01:22:38 UTC
Permalink
Post by Peter Stuge
1.4M Mar  3 00:37 libusb-1.0-0.dll*
3.0M Mar  3 00:37 libusb-1.0.a
109K Mar  3 00:37 libusb-1.0.dll.a
  943 Mar  3 00:37 libusb-1.0.la
  951 Mar  3 00:37 libusb-1.0.lai
My understanding is that only the .a is used, and the other files
are just byproducts.
Google mingw dll
.a is to gcc what .lib is to cl
.a can be both import library (109K libusb-1.0.dll.a) and static
library (3.0M libusb-1.0.a). If app is linked with import library
then dynamically linked library (1.4M libusb-1.0-0.dll) must be in
the DLL search path at run time.
The * is added by ls to indicate that the file is an executable.
I think Peter is right regarding MinGW.
On the other hand, the dll.a file is not necessary for some compilers
as far as I know.

Please also take a look at what libusb-win32 does. The DLL can
be generated by either MinGW or DDK. I believe the
release version is using MinGW. But then Stephan Meyer
provides different version of the lib file.

So there are only two DLLs, one for 32bit, one for 64bit.
There are at least three version of libs necessary,
MinGW32, MSVC 32bit, MSVC 64bit. The dynamic
version is also interesting.

C:\MCU\usb\libusb-win32-device-bin-0.1.12.2>dir bin
07/08/2009 12:53 AM 29,184 inf-wizard.exe
07/08/2009 12:53 AM 5,632 install-filter.exe
07/08/2009 12:53 AM 41,984 libusb0.dll
07/08/2009 12:53 AM 28,160 libusb0.sys
07/08/2009 12:53 AM 54,272 libusb0_x64.dll
07/08/2009 12:53 AM 32,256 libusb0_x64.sys
07/08/2009 12:53 AM 35,328 testlibusb-win.exe
07/08/2009 12:53 AM 29,696 testlibusb.exe

C:\MCU\usb\libusb-win32-device-bin-0.1.12.2>dir lib
03/03/2010 09:14 AM <DIR> .
03/03/2010 09:14 AM <DIR> ..
03/03/2010 09:14 AM <DIR> bcc
03/03/2010 09:14 AM <DIR> dynamic
03/03/2010 09:14 AM <DIR> gcc
03/03/2010 09:14 AM <DIR> msvc
03/03/2010 09:14 AM <DIR> msvc_x64

C:\MCU\usb\libusb-win32-device-bin-0.1.12.2\lib>tree/F
C:.
├───bcc
│ libusb.lib

├───dynamic
│ libusb_dyn.c

├───gcc
│ libusb.a

├───msvc
│ libusb.lib

└───msvc_x64
libusb.lib
--
Xiaofan http://mcuee.blogspot.com
Michael Plante
2010-03-03 00:55:14 UTC
Permalink
Post by Pete Batard
If your question is about how xusb/lsusb are built with
MinGW, then that should be through the static lib, not the DLL.
No, I'm not asking about examples. I'm asking if there is a .DLL (or .SO)
target in MinGW, and, to the point below, if it is effectively part of "make
install" (if there is such a thing). If there's no DLL/SO target, then
disregard this. If there is, then it might wind up in system32, and people
might not know if it came from msvc or mingw.
Post by Pete Batard
MinGW still seems to generate a DLL by default
Ok, but its extension is what? You put an asterisk on the end, which
obscures the answer...
Post by Pete Batard
(internally I believe),
This is key. If it's never made available to be used, then there's no
problem.
Post by Pete Batard
as this is the result of the listing of libusb/.libs/
1.4M Mar 3 00:37 libusb-1.0-0.dll*
3.0M Mar 3 00:37 libusb-1.0.a
109K Mar 3 00:37 libusb-1.0.dll.a
943 Mar 3 00:37 libusb-1.0.la
951 Mar 3 00:37 libusb-1.0.lai
What is the asterisk? Is that a substitute for color in 'ls', or are you
abbreviating the listing? I guess I'm asking what would happen if the dll
got copied to system32 by some installer... (or whatever the 64-bit folder
name is)
Post by Pete Batard
My understanding is that only the .a is used, and the other files are
just byproducts.
Was that your decision, or is that always the case with MinGW?

Michael
Pete Batard
2010-03-03 02:31:05 UTC
Permalink
Post by Michael Plante
No, I'm not asking about examples. I'm asking if there is a .DLL (or .SO)
target in MinGW
No that I know of, because both cygwin and MinGW build their Makefile in
exactly the same fashion as Linux/Darwin, and I believe that
Linux/Darwin only produce static libs (?)

Truth is, since things worked fine without modification for both MinGW
and cygwin, I haven't had a look at what was going on behind the scenes.

As long as it produced exes I could test my code against, that's all I
asked. I might have tried linking with the .a once or twice, to see if
it worked as a static lib, but that was it.
Post by Michael Plante
Ok, but its extension is what? You put an asterisk on the end, which
obscures the answer...
No extension. As Peter pointed out, for some reason, MinGW flags the DLL
as executable (or at least, x equivalent for an emulated bash ls)
Post by Michael Plante
This is key. If it's never made available to be used, then there's no
problem.
No idea there. I'd rather have someone else look into it if possible.
Post by Michael Plante
Post by Pete Batard
My understanding is that only the .a is used, and the other files are
just byproducts.
Was that your decision, or is that always the case with MinGW?
Again, didn't decide anything - just reused Makefile.am that was used
from the other platforms, and it just worked.

Regards,

/Pete
Xiaofan Chen
2010-03-03 13:16:00 UTC
Permalink
Post by Pete Batard
No that I know of, because both cygwin and MinGW build their Makefile in
exactly the same fashion as Linux/Darwin, and I believe that
Linux/Darwin only produce static libs (?)
As Michael mentioned, that is not true.
Post by Pete Batard
Truth is, since things worked fine without modification for both MinGW
and cygwin, I haven't had a look at what was going on behind the scenes.
As long as it produced exes I could test my code against, that's all I
asked. I might have tried linking with the .a once or twice, to see if
it worked as a static lib, but that was it.
I tried the .a file quite a bit and it works. But then I have not
use the dll.a file and it seems not really necessary.
Post by Pete Batard
This is key.  If it's never made available to be used, then there's no
problem.
No idea there. I'd rather have someone else look into it if possible.
Post by Pete Batard
My understanding is that only the .a is used, and the other files are
just byproducts.
The dll and .a file are essential. The define file (libusb-1.0.def)
may be useful as well. Some say the dll.a file is useful but I have
not really used it.
Post by Pete Batard
Was that your decision, or is that always the case with MinGW?
Again, didn't decide anything - just reused Makefile.am that was used
from the other platforms, and it just worked.
This link may be a bit old, but might be useful.
http://www.willus.com/mingw/yongweiwu_stdcall.html

Please also take a look at the Makefile of libusb-win32
(no dll.a file generated) for use with MinGW.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/Makefile?revision=160&view=markup
--
Xiaofan http://mcuee.blogspot.com
Michael Plante
2010-03-03 02:38:44 UTC
Permalink
and I believe that Linux/Darwin only produce static libs (?)
In Linux:

~/libusb-mplante/libusb/.libs$ ls
libusb-1.0.a libusb-1.0.so.0 libusb_1_0_la-io.o
libusb-1.0.la libusb-1.0.so.0.0.0 libusb_1_0_la-linux_usbfs.o
libusb-1.0.lai libusb_1_0_la-core.o libusb_1_0_la-sync.o
libusb-1.0.so libusb_1_0_la-descriptor.o


I see an .so.

Regards,
Michael
Travis
2010-03-03 08:13:42 UTC
Permalink
Post by Pete Batard
Well, this actually is not entirely proactive stuff, but stems from the
LibusbDotNet developer finding out that he couldn't use the 1.0 DLL we
produced with C#, and then finding out that the DDK version and MSVC
version of the DLL weren't using the same conventions.
Yes, actually a bug in LibUsbDotNet where the transfer callback function was
missing the calling convention attribute and was defaulting to __stdcall.
When this was fixed the DDK builds no longer worked, but the MSVC builds
did. Oddly it is only the callback functions which throw an exception when
the wrong calling convention is used.
Post by Pete Batard
Right now, he has switched to using __cdecl because that's the default
we produce with MSVC and he was asking if we could switch to __cdecl in
the DDK too, which is why I investigated the matter.
Yes, but I don't necessarily need the DDK builds. I just assumed that DDK
would be used to build the official binaries for the windows-backend.

The LibUsbDotNet JIT 'binaries' are platform-independent. I am assuming
that all platforms would use __cdecl. It this is not the case then someone
please let me know.

Regards,
Travis
Graeme Gill
2010-03-10 14:10:59 UTC
Permalink
Post by Pete Batard
1. C#/.NET projects uses the "__stdcall" calling convention by default
(http://www.codeproject.com/KB/cs/cdeclcallback.aspx).
http://msdn.microsoft.com/en-us/library/46t77ak2%28VS.80%29.aspx
This can be changed on the project itself.
3. DDK build uses "__stdcall"
(http://www.winvistatips.com/using-build-exe-compile-application-against-__cdecl-symbol-dll-t196428.html),
and it seems everybody advises against trying to modify the build options.
Therefore, I propose introducing a new WINAPI macro for all the exported
functions in libusb.h as well as in the core files, that would be
defined to a user configurable calling convention on Windows platforms.
One way of fixing this is simply to add
386_STDCALL=0
to the dll and examples sources files to select __cdecl.
(This is what the libusb-win32 DDK build does.)

Graeme Gill.
Pete Batard
2010-03-10 14:19:31 UTC
Permalink
Post by Graeme Gill
One way of fixing this is simply to add
386_STDCALL=0
to the dll and examples sources files to select __cdecl.
Yes, I saw Tim Robert's post in one of the link I previously provided
(http://www.winvistatips.com/using-build-exe-compile-application-against-__cdecl-symbol-dll-t196428.html).

However, Tim's post clearly indicates that this is not the "RIGHT"
solution, which is why I didn't want to use it.

Regards,

/Pete
Graeme Gill
2010-03-10 14:43:20 UTC
Permalink
Post by Pete Batard
However, Tim's post clearly indicates that this is not the "RIGHT"
solution, which is why I didn't want to use it.
It's what libusb-win32 uses, and it fixes the problem, so that's
"Right" enough for me.

Graeme Gill.

Loading...