Re: dia 0.91 for win32 cant read settings

[Ben Hetland <Ben A Hetland sintef no>]

Hans Breuer wrote:
> Sure it can. But you should also recompile all the libs it depends
> on. Or live with the problems of two runtimes.
> 
> The c-runtime from vc7 is called mcvr70.dll with corresponding
> msvcrt.lib. One gets problems with having two c-runtimes if
> there is an _open() in one component and a _read() in the other
> [Here dia.exe and glib.dll].

The general problem here is of course that the two routines are invoked
in different libraries. Sharing resources like this across library
boundaries is generally not a good idea in my experience (which is
especially true when it comes to memory management, where each of the
libraries might even be using different memory managers).

So modularizing such that glib also did _open/_close on the same file
resources that it did _read/_write to would eliminate this problem.

For instance, I once had this problem when building DLL binaries with
MSVC that did its own memory management (and msvcrt runtimes), which
were actually linked and used from different compilers including those
from Borland.


> >In MSVC6 I can at least tell it to ignore specific libraries, or even
> >ignore all standard libraries.
> >
> But if the progam needs functions from the c-runtime ?

Well, unless you actually use the new functions only present in version
7, I guess you are just fine linking to the version 6 runtime. (Of
course this is not the case when you tell it to ignore "all" standard
libraries...)

If fact we run into a similar problem when linking code from MSVC6 and
Compaq Fortran, as we easily get a missing or duplicate symbol if using
the wrong import libraries, or even worse with a combination of static
and DLL runtimes. (Compaq Fortran also uses a version of the msvcrt as
part of its runtime environment.)

We end up having linker instructions like
  /nodefaultlib:"dfconsol.lib" /nodefaultlib:"msvcrt.lib"


> Multiple reasons I haven't done it and don't even consider to do it :
> - You'll loose the benefit of interchangeable makefiles between
>   compiler version. MSVC can upgrade dsp files but older
>   versions can't read them. The hand written makefiles work from
>   vc5 to vc7.

Actually I think version 5 and 6 DSP files are interchangeable, being
the same format. (Thanks to those guys in Redmond being too lazy too put
in too much new stuff when they sell us a new version...) But anyway,
that doesn't make your point less important!


> - Having to maintain about 16 object dlls and about 14 plug-ins
>   from 30 dsp files would be a pain in the ass if done via gui.
>   Not to mention the app and lib directory.

Nah, that's what we have workspaces and interdependencies among projects
for... :-)
Except workspaces are machine dependent and cannot generally be shared.


> - If someone really wishes IDE integration one can simply
>   wrap the original makefiles with dsp files. IIRC try to open
>   as project one of the original makefile.msc

Yes, I think that works, but modifying the project (files/dependencies)
from within the IDE, and then exporting back to a makefile would
probably not be a good idea, as that just produces a mess of a makefile.


Regards,

-+-Ben-+-