Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can Multiple Versions of a DLL be Used Simultaneously ?

29 views
Skip to first unread message

Mikus Grinbergs

unread,
Oct 5, 2001, 3:32:44 PM10/5/01
to
I have several versions of a browser installed, in SEPARATE
directory trees. Normally I run only one browser at a time.
As an experiment, I started the latest browser, then tried
to ALSO start the previous-version browser. It got a SYS2070
error (to me indicative of a confusion between varying levels
of a calling program and a called dll).

My question: If one session has already loaded \new\xxxx.dll
into OS/2 memory, and then another session calls
\old\xxxx.dll, will the second session be routed
to the xxxx.dll that is in memory (i.e., the one
that is \new\xxxx.dll), or would \old\xxxx.dll
ALSO be loaded into OS/2 memory ?

mikus

William L. Hartzell

unread,
Oct 5, 2001, 4:36:50 PM10/5/01
to
Sir:

The theory is if one uses SET LIBPATHSTRICT=T;, then any applications
can call itown version of a dll and not have the system give it the
first loaded version. The requirements for this to work is the
application must give an exact path to the dll and according to Ilya
that the .; must not be in libpath statement. The Mozilla code fails on
the first requirement, but it should be an easy fix it they wish to do
so. I don't know of any code currently uses this ability so have
nothing with which to test. Why do not you try this on a recent source
for Mozilla and tell us what happens? A kernel published since
September 2000 is required, ie. 14.062... Sure Mike will accept your
patches if you get this to work.
--
Bill
<Okay, you win>

Ilya Zakharevich

unread,
Oct 6, 2001, 10:54:12 AM10/6/01
to
[A complimentary Cc of this posting was sent to
William L. Hartzell
<wlhar...@home.com>], who wrote in article <3BBE19E2...@home.com>:

> > My question: If one session has already loaded \new\xxxx.dll
> > into OS/2 memory, and then another session calls
> > \old\xxxx.dll, will the second session be routed
> > to the xxxx.dll that is in memory (i.e., the one
> > that is \new\xxxx.dll), or would \old\xxxx.dll
> > ALSO be loaded into OS/2 memory ?

E2LITTLEINFO. The latest info from IBMers is that if you load the DLL
*by its path*, you *always* get what you asked for (*and* there is no
8+3 restriction on the name).

The problems arise only if you load by the module name ("MYDLL" as
opposed to "f:/new/mydll.dll") - but then to see different DLL loaded
you need either different BEGINLIBPATH, or have '.' in your LIBPATH.
Then see below (which is applicable *only* to loading-my-the-module-name).

> The theory is if one uses SET LIBPATHSTRICT=T;, then any applications
> can call itown version of a dll and not have the system give it the
> first loaded version. The requirements for this to work is the
> application must give an exact path to the dll and according to Ilya
> that the .; must not be in libpath statement.

Unfortunately, this requirement is (*) very binding, since one cannot
(*) have '.' in BEGINLIBPATH.

(*) I have no after-Sept-1-2000 systems to test myself, and nobody
reported results when I asked other people to test things...

Ilya

Rich Walsh

unread,
Oct 6, 2001, 1:51:27 PM10/6/01
to

I'm afraid that the two other replies to your query that I saw were
sort of ..umm.. muddled, so I haven't quoted them. Instead, here's
a quote from Dave Blasche(sp?) of IBM from Feb 1st or 2nd, 2001:

SET LIBPATHSTRICT=T and DosSetExtLIBPATH('T', LIBPATHSTRICT)
both enable a newly-added feature which allows different
processes to load different global DLLs with the same name.
Setting to F disables this feature so that things will work
the way the used to prior to this feature.

When this feature is enabled and your program loads a DLL
globally, the loader will process BEGINLIBPATH, LIBPATH, and
ENDLIBPATH looking for the DLL EVEN IF ANOTHER GLOBAL DLL WITH
THE SAME NAME IS ALREADY LOADED, so it is possible to load a
copy different from the one already loaded even though the DLLs
share the same name. Before this feature was enabled, the
loader would simply attach your program to the copy of the
already-loaded global DLL without checking the LIBPATHs.

Sorry, I couldn't begin to tell you what fixpaks include
this feature...

Note that there is *no* mention of any prohibition on having a "."
at the beginning of your LIBPATH, nor can I see any reason why
there should be.

For apps that keep their dlls in the same directory as their exe,
the combination of SET LIBPATHSTRICT=T and "." should eliminate
the problem of mismatched dlls and the need for an explicit
SET BEGINLIBPATH= entry (assuming you set the current directory
to the exe's path).

OTOH, the downside of leaving LIBPATHSTRICT=T in effect at all
times is that the system may end up loading multiple copies of
identical (or at least, compatible) dlls. Beside wasting physical
memory, this also reduces the available linear address space
available to *all* processes for their dlls.

Overall, this is probably best handled as a use-when-needed
feature implemented via a cmd file that sets it up, then launches
the app that won't run otherwise.


--
== == almost usable email address: rlwalshATpacket.net == ==
___________________________________________________________________

| - DragText v3.3 -
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://www.e-vertise.com/dragtext
___________________________________________________________________

William L. Hartzell

unread,
Oct 6, 2001, 2:06:52 PM10/6/01
to
Sir:

New info and enlightment is welcomed. You can get the latest kernel and
it will work with Warp 4 fp 15 system, but I believed that fp15 had a
post Setpember 1, 2000 kernel. Al Savage has links to the latest
kernels on his web page, since they are no longer on testcase.

Ilya Zakharevich

unread,
Oct 6, 2001, 2:20:40 PM10/6/01
to
[A complimentary Cc of this posting was sent to
William L. Hartzell
<wlhar...@home.com>], who wrote in article <3BBF483C...@home.com>:

> New info and enlightment is welcomed. You can get the latest kernel and
> it will work with Warp 4 fp 15 system, but I believed that fp15 had a
> post Setpember 1, 2000 kernel. Al Savage has links to the latest
> kernels on his web page, since they are no longer on testcase.

I'm completely W4-free. ;-) So unless you know a source of fp47 (or
somesuch ;-), I will not be able to use it.

Ilya

Ilya Zakharevich

unread,
Oct 6, 2001, 2:29:15 PM10/6/01
to
[A complimentary Cc of this posting was sent to
Rich Walsh
<your...@127.0.0.1>], who wrote in article <zzdHjdPQunhi-p...@1Cust6.tnt6.tpa2.da.uu.net>:

> Sorry, I couldn't begin to tell you what fixpaks include
> this feature...
>
> Note that there is *no* mention of any prohibition on having a "."
> at the beginning of your LIBPATH

Exactly; it is not said that '.' in LIBPATH is subject to
LIBPATHSTRICT. If you believe this (but I do not believe anything
coming from IBM, they have no history of good docu), having '.' in
your LIBPATH would beat the whole purpose of LIBPATHSTRICT=T.

> nor can I see any reason why
> there should be.

I explained this a couple of times already.

> OTOH, the downside of leaving LIBPATHSTRICT=T in effect at all
> times is that the system may end up loading multiple copies of
> identical (or at least, compatible) dlls.

Not an issue unless you *have* identical DLLs. Which you should not -
unless you run multiple versions of DLL-rich packages - and then you
*want* DLLs to be loaded separately.

The combination of LIBPATHSTRICT=T and a possibility of having no '.'
in LIBPATH would make OS/2 semantic of DLL loading into a killer API.
All you need for this is either make '.' on LIBPATH subject to
LIBPATHSTRICT=T, or allow '.' in BEGINLIBPATH.

Ilya

Rich Walsh

unread,
Oct 7, 2001, 4:33:44 AM10/7/01
to
On Sat, 6 Oct 2001 18:29:15, Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> Rich Walsh <your...@127.0.0.1>], wrote:
> >
> > Note that there is *no* mention of any prohibition on having a "."
> > at the beginning of your LIBPATH
>
> Exactly; it is not said that '.' in LIBPATH is subject to
> LIBPATHSTRICT. If you believe this (but I do not believe anything
> coming from IBM, they have no history of good docu), having '.' in
> your LIBPATH would beat the whole purpose of LIBPATHSTRICT=T.
>
> > nor can I see any reason why there should be.
>
> I explained this a couple of times already.

I frequently find it difficult to understand both your language and
your logic, but in this case I stand corrected. I did some testing
and found that the "." is ignored when LIBPATHSTRICT is in effect
and a second copy of a dll is in the current directory.

The test:

First, I opened my primary copy of pmseek. Both its exe and dll are
in \os2\apps, which is not on my LIBPATH. In this case, it was clear
that the "." was used to locate and load the first instance of its dll.

Then, I copied both exe and dll to \temp. I opened an OS/2 window,
set its cwd to temp, entered SET LIBPATHSTRICT=T, then ran it again
from there. Theseus/4 showed separate instances of the exe, but only
one instance of the dll: the one in \os2\apps.

I then closed the second instance and entered SET BEGINLIBPATH=\temp.
After restarting the exe in \temp, I checked T/4 again and found
that there were now two instances of the dll: one in apps and one
in temp.

Conclusion: for LIBPATHSTRICT to be effective, you must explicitly
identify the location of the alternate dll you wish to load by using
BEGINLIBPATH. You cannot rely on the presence of a "." in your
LIBPATH to cause a second instance of a dll to be loaded from the
current directory.

Ilya Zakharevich

unread,
Oct 7, 2001, 12:44:34 PM10/7/01
to
[A complimentary Cc of this posting was sent to
Rich Walsh
<your...@127.0.0.1>], who wrote in article <zzdHjdPQunhi-p...@1Cust215.tnt1.mia1.da.uu.net>:

> > I explained this a couple of times already.
>
> I frequently find it difficult to understand both your language and
> your logic

Probably because I rarely discuss things which are too simple... ;-)

> but in this case I stand corrected.

> Conclusion: for LIBPATHSTRICT to be effective, you must explicitly
> identify the location of the alternate dll you wish to load by using
> BEGINLIBPATH. You cannot rely on the presence of a "." in your
> LIBPATH to cause a second instance of a dll to be loaded from the
> current directory.

The solution may be to put '.' in BEGINLIBPATH. Unfortunately, on the
system I tested (W3 w fp17 and fp42), '.' is *removed* from
BEGINLIBPATH (I set it with the Dos* API, then test with Dos* API - I
do not trust cmd.exe to do this).

Could you also test/report whether this is fixed in later kernels, please?

Ilya

Buddy Donnelly

unread,
Oct 7, 2001, 1:30:11 PM10/7/01
to
On Sun, 7 Oct 2001 16:44:34, Ilya Zakharevich <nospam...@ilyaz.org>
wrote:

> [A complimentary Cc of this posting was sent to
> Rich Walsh
> <your...@127.0.0.1>], who wrote in article <zzdHjdPQunhi-p...@1Cust215.tnt1.mia1.da.uu.net>:
> > > I explained this a couple of times already.
> >
> > I frequently find it difficult to understand both your language and
> > your logic
>
> Probably because I rarely discuss things which are too simple... ;-)

1. Oh boy it's good to see a discussion develop this well between the
two of y'all. I generally read everything each of y'all has to say,
generally much to my advantage, but y'all must know there has been a
prickliness visible in your past dialogues together that sometimes
seems to get in the way of useful technical discussion.

2. Separate from that, I, too, have found it difficult to stay with
Ilya in some of his items, but I don't normally assume he's talking
above my head. When I can't mark it off to a somewhat contentious
predisposition (which I've often encountered at certain levels of
academia) I probably just assume there may be some residual problem
related strictly to use of language. Without knowing anything at all
about his heritage but like any good WASP I would therefore be
presuming by his name that he may not have been born a native English
speaker. Whether this is true or not, and I don't assume it is, I'm
sure there are others who take the quicker, easier way, assume it is,
and go on without trying to understand it. Which puts a slight
additional burden on Ilya as he's composing his statements. (I doubt
that Ilya has only encountered that here in these groups.)

3. So, the lesson plan goes on to say, it behooves all of us (you know
as I write that I still don't think I ever want to be getting "hooved"
whatever the root etymology of that word is) [and yes thanks in
advance that was rhetorical and I do know it's from the O.E., and yes
thanks I also know that "root etymology" appears redundant] to work
with each other towards, rather than away from, perfect communication
of the technical facts, ideas, and experience we're trying to share.
Speaking as one who may be better at communicating ideas than
understanding them as well as Rich or Ilya.

4. We do seem to be getting better at this here, unless my filters are
working perfectly.

(etc. snipt because it's not to my point)
--
Good luck,
Buddy
Buddy Donnelly donn...@tampabay.rr.com

Mikus Grinbergs

unread,
Oct 7, 2001, 12:31:40 PM10/7/01
to
Thank you all who answered. LIBPATHSTRICT gives a solution.

On Sat, 06 Oct 2001 17:51:27 GMT your...@127.0.0.1 (Rich Walsh) wrote:
> ...


> here's a quote from Dave Blasche(sp?) of IBM from Feb 1st or 2nd, 2001:
>
> SET LIBPATHSTRICT=T and DosSetExtLIBPATH('T', LIBPATHSTRICT)
> both enable a newly-added feature which allows different
> processes to load different global DLLs with the same name.
> Setting to F disables this feature so that things will work
> the way the used to prior to this feature.
>
> When this feature is enabled and your program loads a DLL
> globally, the loader will process BEGINLIBPATH, LIBPATH, and
> ENDLIBPATH looking for the DLL EVEN IF ANOTHER GLOBAL DLL WITH
> THE SAME NAME IS ALREADY LOADED, so it is possible to load a
> copy different from the one already loaded even though the DLLs
> share the same name. Before this feature was enabled, the
> loader would simply attach your program to the copy of the
> already-loaded global DLL without checking the LIBPATHs.

As the Premier said to Sherlock Holmes:
"There is more in this than meets the eye."

Using SET LIBPATHSTRICT=T, I *was* able to start the new-version
browser in one session, and then start the old-version browser
in another session. HOWEVER, putting SET LIBPATHSTRICT=T in my
config.sys was __not__ effective. I launch each browser from a
REXX script (.cmd file) which issues the OS/2 command 'SETLOCAL'.
I found it necessary to put the SET LIBPATHSTRICT=T __inside__
that .cmd file before OS/2 would load separate old-version DLLs
for the old-version browser session.


What I was wishing for with my question was trying to run two
copies of new-browser simultaneously from two separate directory-
trees, where the resources stored in those directory-trees were
not the same. Apparently, the browser DETECTS when a copy of
itself is already running. __No__ browser remained in my second
session when I invoked its start-up script (which specified the
second directory tree, whose browser_module had the same code).
Instead, the first-session browser opened up a second window
(still using the first-session resources), and the second session
came back to the command prompt.


Thanks for everybody's help, mikus

Mikus Grinbergs

unread,
Oct 7, 2001, 6:21:35 PM10/7/01
to
Three things I've found out (the HARD way) about LIBPATHSTRICT=T :

- I call the application (which I want to run simultaneously
with another version) from a .cmd file. I *must* put the
SET LIBPATHSTRICT=T __inside__ that .cmd file. Just having
the SET statement in my config.sys did not cause that .cmd
launched application's own DLL files to be loaded (in
addition to the {same name, but different directory} DLL
files already in OS/2 memory).

- The SET LIBPATHSTRICT=T that I set within my .cmd file was
still in my environment after my .cmd file ended. In other
words, the OS/2 'ENDLOCAL' within my .cmd file did not
restore my environment to be identical to how it was when
OS/2 'SETLOCAL' was executed.

- When the directory tree for the (second simultaneous)
application was specified via ENDLIBPATH, the DLLs already
in memory (from the first application) were re-used. When
the directory tree was specified via BEGINLIBPATH, the set
of DLLs from that directory tree *were* loaded into OS/2
memory (in addition to the DLLs already there).
[I __do__ have '.' in LIBPATH in my config.sys.]

mikus

Al Savage

unread,
Oct 8, 2001, 4:13:11 AM10/8/01
to
On Sun, 7 Oct 2001 17:30:11, donn...@tampabay.rr.com (Buddy Donnelly)
wrote:

> 2. Separate from that, I, too, have found it difficult to stay with
> Ilya in some of his items, but I don't normally assume he's talking
> above my head. When I can't mark it off to a somewhat contentious

> predisposition . . .

Er, I just figgur'd that Ilya is either a bit, um, combative in his
writing (that is certainly the way s/he comes across) or that something
is lost in translation to English. Whatever, there is too much good
info being related in-between to make much of it.

Or, is that what you were saying ? :)

--
Regards,
Al S.

* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 0 days 03:15 hours

Rich Walsh

unread,
Oct 8, 2001, 5:30:03 PM10/8/01
to
On Sun, 7 Oct 2001 16:44:34, Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> Rich Walsh <your...@127.0.0.1>], wrote:
>
> > Conclusion: for LIBPATHSTRICT to be effective, you must explicitly
> > identify the location of the alternate dll you wish to load by using
> > BEGINLIBPATH. You cannot rely on the presence of a "." in your
> > LIBPATH to cause a second instance of a dll to be loaded from the
> > current directory.
>
> The solution may be to put '.' in BEGINLIBPATH. Unfortunately, on the
> system I tested (W3 w fp17 and fp42), '.' is *removed* from
> BEGINLIBPATH (I set it with the Dos* API, then test with Dos* API - I
> do not trust cmd.exe to do this).
>
> Could you also test/report whether this is fixed in later kernels, please?

I did a *lot* of testing (and rebooting). Here's what I found:

1- BEGINLIBPATH won't accept a ".", but it _will_ accept ".\."

2- You can put "SET BEGINLIBPATH=.\." in config.sys to achieve
the desired result when LIBPATHSTRICT=T is in effect. OTOH,
putting ".\." in LIBPATH is as ineffective for this purpose
as the standard "."

3- Putting "SET LIBPATHSTRICT=T" in config.sys has no effect.
You must turn on this feature in the target process, or in
the process from which you will start the target app. In
practical terms, you'll have to enter this at a command
line, then run the app from that same command line.

A word of explanation for onlookers: neither BEGIN/ENDLIBPATH nor
LIBPATHSTRICT are true environment variables. When BEGIN/ENDLIBPATH
were added to the base os, cmd.exe was modified to examine each SET
statement entered. If it is "SET BEGINLIBPATH=" or "SET ENDLIBPATH=",
cmd.exe calls the DosSetExtLIBPATH() API to set these values in its
process. Said values will be inherited by any process it starts.

Apparently, the base os was also modified so that when these statements
appear in config.sys, they are made global and are inherited by all
processes. It appears that when LIBPATHSTRICT was added, cmd.exe was
again modified but the base os was not. Thus, "SET LIBPATHSTRICT="
works when entered at a command line but not when entered in config.sys.

4- Until the base os is suitably modified, it seems that the only
way to make "LIBPATHSTRICT=T" global (or nearly so) is to create
a facility akin to my RWL util which can enter the shell process
(pmshell #1) and set it there. Since pmshell is the parent of
all processes started after it loads, this would have the desired
effect.

Ilya Zakharevich

unread,
Oct 9, 2001, 9:55:44 AM10/9/01
to
[A complimentary Cc of this posting was sent to
Rich Walsh
<your...@127.0.0.1>], who wrote in article <zzdHjdPQunhi-p...@1Cust15.tnt1.tpa2.da.uu.net>:

> I did a *lot* of testing (and rebooting). Here's what I found:
>
> 1- BEGINLIBPATH won't accept a ".", but it _will_ accept ".\."

LOL! Thanks!

Ilya

0 new messages