From jan@swi.psy.uva.nl  Wed Jul 21 10:26:55 1999
Received: from gollem.swi.psy.uva.nl (jan@gollem.swi.psy.uva.nl [145.18.114.15])
	by swi.swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id KAA02310
	for <prolog@swi.psy.uva.nl>; Wed, 21 Jul 1999 10:26:55 +0200 (MET DST)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.8.8/8.8.8) id KAA03121;
	Wed, 21 Jul 1999 10:28:45 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
To: lutz.wohlrab@informatik.tu-chemnitz.de
Subject: Re: bug: MSCVRT.DLL?
Date: Wed, 21 Jul 1999 10:21:13 +0200
X-Mailer: KMail [version 0.7.9]
Content-Type: text/plain
Cc: prolog@gollem.swi.psy.uva.nl
References: <199907210444.GAA21883@mykonos.informatik.tu-chemnitz.de.informatik.tu-chemnitz.de>
MIME-Version: 1.0
Message-Id: <99072110284501.03078@gollem>
Content-Transfer-Encoding: 8bit

On Wed, 21 Jul 1999, Lutz Wohlrab wrote:
>Hi,
>
>> I don't think that will really help.  As far as I know, an application
>> loads the DLL from the directory the executable is in first, but
>> appearently I'm wrong, or does this depend on the Windows version!?
>
>> I don't think I can do much about it.  Recompile using MSVC 6.0 (do
>> the MSVCRT versions match the compiler major version?)?  We don't have
>> 6.0, but if you can get hold of it you may try to recompile the sources.
>
>> Anyone used to Windows DLL version problems with an idea?
>
>This is hell. Because, it depends not only on the version of Windows and
>MSVC, but also on the service packs installed. The recompiling stunt should
>solve the problem, at least I think so (I always build my SWI-Prolog from
>source, and I had no such problems so far). Both service packs for Windows
>as well as for MSVC are concerned.
>
>The DLLs are treated much like shared objects under modern UNIXes in that
>respect that the code is shared. So, if some version of the DLL is already
>loaded, it is used, AFAIK.

Appearently with one big difference.  If a Unix system has to load a
shared object (as they are called there), it searches for the file using
a predefined mechanism.  Only then, if the kernel finds out this file
is already loaded, the loaded copy is used (shared), if it finds a
different file it will load that file (or share it if someone else
is using it).  Thus, various processes can run different copies of
the same shared library located on different files.

This is a nightmare too, but at least different versions can coexist
and you can always make a specific application use a specific
combination of shared objects, so it functions independently of what
the rest demands.

>At the moment, we are in an uproarious hassle about these things at my
>working place. Windows (NT), MSVC, and Office97 need Service Packs (or
>Service Releases, as they are called for Office) for several reasons. Since
>each brings system DLLs, you have to be damn careful with the order in
>which to install these things. As you cannot look into these things
>beforehand, it is rather a trial and error business.

So, I leave that as an exercise to the user :-)

	--- Jan

