From: Michael P. <mic...@gm...> - 2010-08-05 17:24:22
|
Pete Batard wrote: >> If you want to use both a release and a debug DLL from system32, at the >> same time, that's your problem, not libusb's. Not really. If you linked xusb and lsusb dynamically, I would ask the same thing of those programs. >> We don't see Linux/Darwin people asking us to ensure that a libusb debug >> library should be created with a different name so that they can copy >> both to /usr/lib. Why should it be any different for Windows? Because Linux/Darwin don't have debug/release heaps (AFAIK). Simple as that. It was Microsoft's choice. >> The way I see it is you want libusb to address a problem that it >> shouldn't be addressing. It's a problem every library that has both debug/release builds and uses msvcrt needs to address. It's not libusb-specific. >> If you need libraries with different names, you >> can rename them. If I rename them, I interfere with other users of those libraries on my system (i.e., other software developers; I am the only person physically logged in; that's not what I mean). Moreover, this also applies to any systems I distribute my software to. >> The default of MS development tools is to create debug >> and release libraries in different directories, but with the same name. Yes, and the default is also NOT to make install. When I don't rename my DLLs, NEITHER goes in system32. End of story. This of course creates the exact kind of path dependencies that people probably wouldn't like (relative path or otherwise). >> If having automated suffixes was that crucial to developers, I'd expect >> Microsoft to have done something about it by now in their defaults. No, because when you tell Microsoft that some project is a dependency, it links directly to wherever the library is located, on the assumption that it's NOT in system32. The entire problem arises because Microsoft has no interest in helping you copy the DLLs to system32. >> crucial system libraries >> that would be very inconvenient having to replace while the system is >> running (MSVCRT being one of them). Huh? What makes it crucial? For that matter, most systems I run into don't even have msvcrtd.dll. Changing it while the system is running is trivial, as it does not seem to be a "protected" file. So what makes it crucial? Or does it have nothing to do with windows file protection, and, if so, why do you have such a low opinion of libusb? >> You can easily go into system32 and replace the DLL, >> without other applications coming crashing down Actually not. That's what I was pointing out: you don't like with msvcrt.dll and the libusb-1.0_debug.dll, just like you don't link with msvcrtd.dll and libusb-1.0.dll. There's a one-to-one correspondence. If you don't rename them, then they cannot be safely installed system-wide. And if you rely on users to rename them, then all hell will break loose, because nothing will be standard. >> You're talking about linking whereas I'm talking about dropping a fully >> built debug DLL in system32 (which seemed to be your original problem). Same thing. It's called "dynamic linking". The loader does it. >> xusb.exe, it just works. So why is the suffix >> important again? You got lucky, or xusb doesn't (YET) exercise the exact functionality that would cause a problem. >> I'm not seeing having no suffix on the debug lib as preventing linking >> against msvcrtd.dll when buidling the app in debug mode. Or does a >> MSVCRT.DLL dependent DLL check its name at runtime to find out whether >> it should use MSVCRT or MSVCRTd? Nope, that's done at runtime. No, what the DLL uses and what the EXE use are determined at linktime, not runtime. Look at either in depends. It's hardcoded in the file by the linker. It is not based on the filename. You can recall that I was initially arguing for a "d" suffix, not a "_debug" suffix; you wanted the latter because you somehow saw it as some sort of "red flag" to even have the file (I disagreed, but the outcome was acceptable, so I didn't push it). In other words, the files could be named "libusb-1.0_foo.dll" and "libusb-1.0_bar.dll", as long as it's STANDARD, and we set that standard or no one does. >> So it all >> revolves around the inconvenience of having to rename a DLL manually in >> case you want to use the same DLL twice in the same directory. No, you're still missing my point. There's nothing inconvenient about it; the rename could happen in the copy operation. It's a problem of having nonstandard names in the system32 directory. As long as we standardize on something (and it must be two different names, of course, if you've been reading anything above), it's fine. Obviously what it's named should make some sense, but beyond that, whatever. But it has NOTHING to do with convenience. >> Again, does a debug dynamic library need to check its name to figure out >> what malloc it should use? No, but the DLL and EXE need to use the same version of msvc. I don't see how you got the name confused with that issue. Hopefully the stuff above clears this up? >> You don't usually share debug DLLs. I absolutely do. I could just as easily say "you don't usually share DLLs with toggleable logging". It's absurd! People need the debug DLLs to, well, debug their libusb programs! Yes I certainly do share them. >> You share a calling convention. I don't follow. Where is the parallel? A DLL is a file, and a calling convention is not. >> That's a major difference. Only if it's true, which it's not. >> Also, since when are our users expected to >> need to run both debug and release DLLs from System32 at the same time? >> Where's the common scenario for that? If their EXEs have debug AND release builds (which is an MS default), then then. Which is just about always. >> If someone needs to run a >> dynamically linked debug and release app at the same time, Define "same time". I would just say that they shouldn't have to remember which file they have installed to avoid crashes or leaks if they accidentally "test" the wrong configuration in visual studio. I don't imagine having both processes loaded at the same time, if that's what your suggesting. >> Or why not >> create a System32_debug for debug DLLs and instruct your debug >> application to search for DLLs in that directory as well? Ask Microsoft; they forced the decision on us. >> Do you know of other projects that provide different suffixes for debug >> and release? Yes, all the MFC libraries do it. You can look at the source, too, though it's not available unless you have a copy of msvc, so I can't link you. >> If I look at pthread-win32 for one, what I'm seeing is the >> Microsoft established way of using different directories with the same >> DLL name: >> ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/p thread.dsp >> (/out:".\pthreadVC2.dll" for both Release and Debug) Funny, I didn't get a dsp file when I obtained pthreads (at least the first time?), however the Makefile (for nmake) clearly has: # DLL_VER: # See pthread.h and README - This number is computed as 'current - age' DLL_VER = 2 DLL_VERD= $(DLL_VER)d I.e., a suffix. The Makefile is also what I'm using. >> What's good enough for pthread-win32 should be good enough for us. I suppose it depends on where that dsp file came from? I'm pretty sure it wasn't there when I started using pthreads, and maybe it got added later by a helpful contributor who hadn't thought things through? In any case, I use nmake to build pthreads, which does have a suffix, so, conditioned on that, I agree. Michael |