Re: Gtkmm Windows installers available

[Armin Burgmeier <armin arbur net>]

On Fri, 2008-10-03 at 18:06 -0400, Philip Kovacs wrote:
> * Murray Cumming <murrayc murrayc com> [2008-10-03 18:14:15 +0200]:
> 
> > > > "The MSVC++ DLLs have been built with Visual C++ 2005 and are linked to the
> > > >  MS C/C++ runtime DLLs: MSVCR80.DLL / MSVCP80.DLL."
> > > 
> > > It's a Wiki. Feel free to improve things yourself.
> > > 
> > > > In my case, my Windows system has a later runtime environment: MSVCR90.DLL /
> > > > MSVCP90.DLL (MS Visual Studio 2008), so I have to recompile anyway. I think
> > > > cautioning people to verify which MS C/C++ runtime they have: 70/80/90, etc.
> > > > before using the binary installer would be a good thing.
> > > 
> > > I don't have too much experience with different runtimes, but I
> > > succeeded in building a small example application with Visual Studio
> > > 2008 against the binaries of the installer, which have been built with
> > > Visual Studio 2005. Doesn't this work in general?
> > > 
> > > I think the MSVCR80 runtime files are still shipped with Visual Studio
> > > 2008.
> 
> Mixing runtimes can work, but there are hazards that may cause strange errors 
> (and thus difficult bug reports).  If I have a project linked to runtime XX that 
> uses a gtkmm-linked to runtime YY, I have to be very careful not to extract the
> underlying runtime object from the gtkmm object and thereby move the runtime
> object across the XX/YY boundary.
> 
> For example, if I ask gtkmm/glibmm to create an object that has an underlying 
> file descriptor, that fd (integer) only has meaning in the runtime it was created,
> e.g. YY.  If I extract the fd from the object, I am essentially moving it into 
> the project environment's runtime, XX.  That can cause disasterous results.
> 
> That said, it can still "work" if the programmer is careful and doesn't mishandle
> objects created by the gtkmm/glibmm library.

We probably shouldn't rely on this, and I don't actually want to track
bug reports that result from incompatible runtimes, either. So I think
we'll just add separate MSVC 2008 binaries to the installer, to be safe.

> Phil

Armin