From: Xiaofan C. <xia...@gm...> - 2010-08-08 01:46:01
|
On Fri, Aug 6, 2010 at 10:01 PM, Pete Batard <pb...@gm...> wrote: > On 2010.08.06 14:25, Xiaofan Chen wrote: >> I actually do not understand all the posts so far. But somehow I >> got the impression this is mainly a VC++ 6.0 problem. > > From what I read in the article pointed by Michael, I'm afraid it's not > (but currently not something we should run into, although we might soon). > > We have no means of telling the libusb-1.0.dll that it should use the > same MSVCR as the application that uses it, as that information is > "hardcoded" in the libusb DLL itself and in either case, according to > Microsoft current information (which we don't have any reason to believe > is inaccurate), if libusb-1.0.dll allocates a structure, provides it to > the xusb.exe, and lets xusb.exe free it, xusb will crash. Thanks for the summary. So all the discussion has nothing to do with the end users of libusb based applications. The end users will probably not needed to worry about debug dlls. Rather it has quite something to do with software developers/testers using libusb, especially those who use Visual Studios. I agree they are important users of libusb under Windows. I also think this can lead to some conclusions about the official dll generation method. I tend to think because of the above issues, it is not a good idea to use VS2005/2008/2010 as the compiler to build the official dll for end users. The best seems to be WDK with Win2k target which should have the best compatibility. MinGW is another possibility. For 64bit x64, maybe the WDK build with Win2003 x64 target will be the best bet and MinGW-w64 is the possible alternative. > Michael's solution is that a debug library should always have a suffix, > so that when a debug xusb (or another libusb based app) tries to link to > a libusb DLL, the use of the suffix should leave no doubt as to whether > that DLL can be safely used when debugging (_debug suffix), or should be > left well alone, because of the alloc/free issue. This of course > requires developers to be aware of the MSVCRT d/non_d issue and use > different names for the DLL they are linking to (but part of it is taken > care of automatically through dependencies in MSVC) I supposedly this can be done in the MSVC Solution/Project files, right? In that case, I think this is a good solution. They are developers who should be familiar with MSVC anyway. As for MinGW/Cygwin, I think the existing solution (no suffix) is good enough and I hope there are no changes for them. The developers using MinGW/Cygwin do not seem to need to worry about the issues. > My view is that we should ensure that we deal with alloc/free (by making > sure anything allocated by libusb is freed by libusb - which currently > doesn't seem to imply any changes to our code, but might require extra > care as we add future features), so that debug and release libusb DLLs > can be interchanged without having to bother about suffixes, and that if > people later want to add suffixes, they should do so in their own > development environment. Your view about alloc/free is of course correct. But somehow I am more inclined to Michael's solution for his use case. Again, this is just from my understanding on the surface, not that I deeply understand all the issues raised in this thread. ;-) -- Xiaofan |