[Vorbis-dev] Re: win32 sdk

[Dimitry Andric]

On 2004-10-13 at 18:42:50 Glenn Maynard wrote:

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

Well probably readable, but you'll need to "upgrade" them to VC2003
format, and then they're of course not backwards compatible anymore.

I've already run into this with VC4, 4.1, 4.2, 5.0, 6.0 and so forth.
Of course, the newer versions have features which aren't supported, so
backwards compatibility is almost impossible.

An option which increases maintenance, but is workable, is to separate
the different compiler versions from the source, for example:

  .\dc5                   <-- project and object files for DevC++ 5
  .\ogg
  .\vc5                   <-- project and object files for VC++ 5.0
  .\vc6                   <-- project and object files for VC++ 6.0
  .\vc7                   <-- project and object files for VC.NET 2002
  .\vc71                  <-- project and object files for VC.NET 2003
  .\vorbis
  .\vorbis-tools
  .\win32-tools
  .\win32sdk

Then you'll have to refer to ..\ogg\src\bitwise.c, and so on, from
each project file, but at least the different versions stay out of
each other's directories.


> 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.

Microsoft has done the same thing with Office, for years now.  And
everybody keeps upgrading, for reasons unknown to me. ;)


> 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

Yes, I often seen people simply ignoring this warning, which really
should be a severe error. :)  And Microsoft even supplies the fatal
hint to use /nodefaultlib!  This can lead to extremely subtle bugs,
and no end to misery while debugging...


> 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.

I once generated (more or less) a bunch of vorbis project files for
VC++ 6.0, with ALL possible combinations:

  lib_ogg_d_md.dsp
  lib_ogg_d_ml.dsp
  lib_ogg_d_mt.dsp
  lib_ogg_s_md.dsp
  lib_ogg_s_ml.dsp
  lib_ogg_s_mt.dsp
  lib_vorbisenc_d_md.dsp
  lib_vorbisenc_d_ml.dsp
  lib_vorbisenc_d_mt.dsp
  lib_vorbisenc_s_md.dsp
  lib_vorbisenc_s_ml.dsp
  lib_vorbisenc_s_mt.dsp
  lib_vorbisfile_d_md.dsp
  lib_vorbisfile_d_ml.dsp
  lib_vorbisfile_d_mt.dsp
  lib_vorbisfile_s_md.dsp
  lib_vorbisfile_s_ml.dsp
  lib_vorbisfile_s_mt.dsp
  lib_vorbistools_s_md.dsp
  lib_vorbistools_s_ml.dsp
  lib_vorbistools_s_mt.dsp
  lib_vorbis_d_md.dsp
  lib_vorbis_d_ml.dsp
  lib_vorbis_d_mt.dsp
  lib_vorbis_s_md.dsp
  lib_vorbis_s_ml.dsp
  lib_vorbis_s_mt.dsp

Here the _d and _s suffixes stand for "DLL" and "static", and _md, _ml
and _mt for "using DLL runtime", "using static runtime" and "using
static multithreaded runtime", respectively.  As you can see, there's
a lot of project files to maintain. ;)


> (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 ...)

Yes, this also applies if you want to compile with different
optimizations, calling conventions or whatever.  But having some
prefabricated project files at least makes it easier to just "drag"
these into your existing workspace.

I don't really mind the extra build time of vorbis libraries, they're
not extremely huge, or something. :)


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

Why not, that's what DLLs were actually made for!  As long as you do
some proper version checking when installing, there should be no
problem.  If you are extremely paranoid about Microsoft's "System File
Protection" feature overwriting your newer DLL with an older one, then
just install it in the application directory.


> 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.

I'd rather like them to fix their dynamic linker. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 183 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20041013/56b76247/attachment.pgp