* 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. Phil
Attachment:
pgpnTuhyDnFjJ.pgp
Description: PGP signature