Re: dia 0.91 for win32 cant read settings

[Hans Breuer <Hans Breuer org>]

At 23:04 28.03.03 +0100, Ben Hetland wrote:
> Hi Steffen,
>
> Steffen Macke wrote:
> > > Why is it mixing those versions, and why should this pose a problem?
> >
> > It's mixing those versions because MSVC 7 doesn't allow me to link against
> > msvcrt.dll which is used by the gtk+ libraries distributed by Tor
Lillqvist.
> Strange... Does it mean it cannot always compile "old" MSVC6 projects
> either?
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].
Internally both functon map the fd ('unix' file descriptor, a small
number) to a file HANDLE via a runtime internal array. But this
array isn't shared between the two runtimes - so the real file 
handles are unrelated.

> (MSVC7 is the same as .NET isn't it?)
Yepp.

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

> [...]

> And if I may ask; is there a reason noone set up a MSVC project file
> yet? I know they look really ugly as makefiles, but they would be much
> simpler to use from Dev.Studio than compiling every directory manually.
> :-)
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.
- 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.
- the whole build process - described to some extent in 
  glib/README.win32 - would break. At the moment it is reasonable
  easy to keep dependencies up to date, without getting RSI ;-)
- you can simply write a batch file to compile all Dia with one
  command :

cd lib
nmake -f makefile.msc
cd ..

cd app
nmake -f makefile.msc
cd ..

cd objects
nmake -f makefile.msc
cd ..

cd plug-ins
nmake -f makefile.msc

cd python
nmake -f makefile.msc
cd ..

cd ..

  A master makefile in dia's top level dir could do the trick 
  as well. There is none cause I usually need to compile stuff 
  in smaller chunks anyway to fix build glitches. Nowadays it
  would collide with Steffens copying makefile.msc

- 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

Regards,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert