[Vorbis-dev] Re: win32 sdk

[Glenn Maynard]

On Wed, Oct 13, 2004 at 04:52:50PM +0800, illiminable wrote:
> If it's purely cost, the command line compiler for VS2003 is free (of 
> course that means make files).... but also there is a free version of VC++ 
> 2005 express beta 
> (http://lab.msdn.microsoft.com/express/visualc/default.aspx)... i'm unsure 
> if these express products will be free post-beta... if not they will be 
> very cheap (sub $100). I haven't installed them as i don't want to risk 
> screwing up my current installation... but i'd be 99% sure they will open 
> VS2003 project files.

VC2003 project files have similar problems: VC2003's project files are not
(AFAIK) readable by VC2002.

Conspiracy theories are entertaining, at least: it feels like they're forcing
incompatibility to force upgrades.  More seriously, though, this incompatibility
causes a chicken-and-egg problem: I can't upgrade to newer VC's myself, since
there are other people I work with who use VC2002, so I can't upgrade until
they upgrade, and I can't force them to upgrade.

> In this SDK i have linked to Multithreaded Static so the distribution of 
> the runtimes you specify below is not required... however in my other 
> directshow project, i link to the DLL's simply because there are about 40 
> projects that link to them and it would be wasteful to use static libraries.

If you use the 6.0 runtimes, everyone will have them (MSVCRT.DLL).  (I
distribute VC7 DLLs and not VC6 DLLs, and I've never received any
reports of them not being present.)

That aside, there are a lot of little problems that people tend to hit
when linking libraries in VC.  A quick test building my static Ogg
library with "Multithreaded" (static), I get:

 MSVCRT.lib(cinitexe.obj) : warning LNK4098: defaultlib 'libcmt.lib'
 conflicts with use of other libs; use /NODEFAULTLIB:library

This is a serious warning; it means that multiple C runtimes are in use,
because a library was built against "multithreaded static" (libcmt,
"libc multithreaded") and my app was built "multithreaded DLL" (MSVCRT,
MSVC runtime).  Different runtimes can mean different malloc heaps,
for example, which would probably cause problems with vorbisfile
fclose()ing things opened by user code.

I'm not sure which runtimes use different heaps--it may just be separate
heaps for threaded/unthreaded and debug/release, but there could be any
number of other gotchas; having wasted many hours diagnosing these, I've
fallen back on "multithreaded DLL" for everything, even debug builds.

(In any case, it makes me somewhat leery of using prebuild libraries,
since everyone has their own practices and settings to deal with this
stuff ...)

> Microsoft recommends against installing them globally. They really 
> shouldn't be installed globally on any machine.

Microsoft also suggests that all programs start a tray app on boot that
forces its DLLs to be loaded, so if the program is ever actually used
it starts faster.  They make a lot of horrifyingly bad, wasteful suggestions.

-- 
Glenn Maynard