Discussion:
DLL loading problem
(too old to reply)
Jonathan de Boyne Pollard
2011-03-07 06:03:09 UTC
Permalink
Raw Message
The real problem is that these lists are system-wide on IBM OS/2,
rather than per-process. They're per-process in other operating
systems, which is why the behaviour is different there. Even
DOS-Windows 9x, for example, will happily modname match against DLLs
loaded in the same process, but won't modname match against DLLs
loaded in other processes. But IBM OS/2's design hails from the time
of DOS-Windows 2.x, when global tables were the way that DLLs were
tracked.
I can understand the reluctance to fix this. It's a fairly
fundamental overhaul to the way that IBM OS/2 does its bookkeeping.
(LIBPATHSTRICT isn't really the full overhaul. The global tables are
still there. The rules for searching them simply change, with this
and other undesirable side-effects as the fall-out.) That's a lot of
work to justify even in 2001.
Probably won't be changed, but if I were doing it I'd allow the
application to specify loading as a global or local. If the default
were global the system behavior wouldn't change.
The thing is: Global modname matching across all processes is almost
never what one wants. I'm hard pressed to come up with an example of a
use for it. IBM OS/2 in the late 1980s had a global DLL table, though,
just like DOS-Windows 2.x did at the same time. The problem here is
that second system effect, which gave us the behaviour of DOS-Windows 9x
and Windows NT when it was realized that per-process semantics were the
sensible ones (because they allow one to have per-process DLL search
paths that don't have crazy behaviour, for one thing), hasn't really
been fully applied to the first system. The whole
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that retains
the global tables, but changes the rules for searching them so that one
*almost*, but not quite, gets the per-process semantics that everyone
has concluded are the sensible ones. It's an easy bodge that doesn't
change the underlying bookkeeping.

So really there's no need for such an API option as you describe, nor
really a need for a compatibility mode as you describe. To most people,
the original behaviour isn't what they even designed their applications
to expect in the first place. I know that when I first read the books
on OS/2 programming, I expected DLLs to be handled per-process. Much
was made early onof the fact that OS/2 didn't load DLLs into a shared
address space with one copy across all processes like Windows 2.x/3.x
did. From that, programmers expect that the semantics of DLL searching
are, in general, per process rather than global. And there's really
only a small hint in the CP reference that things are otherwise.

I don't know what the OSFree people did, or even if they got as far as
supporting DLLs properly at all, but I would expect that anyone writing
a system like this would opt for the per-process semantics similar to
those of Win32 when it comes to modname matching. It's evident from
this incident alone that they are what programmers expect. M. Ihle
didn't expect OS/2 to have different semantics.

But that's rather the point. The likes of the OSFree crowd, cloning
OS/2, get to do what they like. Whereas someone working for IBM on the
*original* operating system has to justify the work, and there's a lot
of it to change this. Even in 2001, when the fuss was first kicked up
about this, that would have been a hard case to make. A complete
overhaul of the module table, probably several months of work and
regression testing, just to satisfy people who do (from the point of
view of people who haven't read the fine print of the CP reference)
crazy things like expect DLLs to be found and loaded even when they
aren't actually on the library path? Try getting that past a manager.
Especially a manager who would like OS/2 to go away.
Peter Flass
2011-03-07 13:18:39 UTC
Permalink
Raw Message
On 3/7/2011 1:03 AM, Jonathan de Boyne Pollard wrote:
...
Post by Jonathan de Boyne Pollard
The thing is: Global modname matching across all processes is almost
never what one wants. I'm hard pressed to come up with an example of a
use for it.
I come from more of a mainframe background, but I feel the opposite.
Global matching is the norm -- think libc, for example -- and
per-process should be the exception to handle the cases where a DLL is
not upward-compatible. Of course, for microsoft this *is* the norm.
Post by Jonathan de Boyne Pollard
IBM OS/2 in the late 1980s had a global DLL table, though,
just like DOS-Windows 2.x did at the same time. The problem here is that
second system effect, which gave us the behaviour of DOS-Windows 9x and
Windows NT when it was realized that per-process semantics were the
sensible ones (because they allow one to have per-process DLL search
paths that don't have crazy behaviour, for one thing), hasn't really
been fully applied to the first system. The whole
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that retains
the global tables, but changes the rules for searching them so that one
*almost*, but not quite, gets the per-process semantics that everyone
has concluded are the sensible ones. It's an easy bodge that doesn't
change the underlying bookkeeping.
Again maybe this is me, but search paths _should_ have nothing to do
with DLL name matching. The tables should match as much of the name as
the caller specifies, expanding stuff like './' in the pathname. If he
asks for 'abc' he gets the first 'abc' in the search path or the first
one in the table. If he specifies 'c:\myapp\mysubdir\abc' he gets that
one, which would only be loaded if not already present.

Two caveats -- First, I'm relatively unknowledgable about the specifics
of how OS/2 handles this; you doubtless know more. Second, as I said,
this is only an academic discussion, since the system does what it does.

...
Post by Jonathan de Boyne Pollard
But that's rather the point. The likes of the OSFree crowd, cloning
OS/2, get to do what they like.
I think their intention is to reproduce the behavior of OS/2 as it is.
...
Post by Jonathan de Boyne Pollard
A complete
overhaul of the module table, probably several months of work and
regression testing, just to satisfy people who do (from the point of
view of people who haven't read the fine print of the CP reference)
crazy things like expect DLLs to be found and loaded even when they
aren't actually on the library path?
Yup, that would be me. All the fine print is there for a reason, but
unless you've run into a situation you can't diagnose it often doesn't
get read.

Interesting discussion, I've learned some things.
Jonathan de Boyne Pollard
2011-03-11 04:02:48 UTC
Permalink
Raw Message
Post by Peter Flass
Post by Jonathan de Boyne Pollard
The thing is: Global modname matching across all processes is almost
never what one wants. I'm hard pressed to come up with an example of
a use for it.
I come from more of a mainframe background, but I feel the opposite.
Global matching is the norm -- think libc, for example -- and
per-process should be the exception to handle the cases where a DLL is
not upward-compatible. Of course, for microsoft this *is* the norm.
Not just for Microsoft. For *most people* this is the norm, Unix
included. Think libc for example. Yes, libc. You chose what is,
ironically, an exact counterexample. Have you ever looked to see how
many different versions of it there are? GNU libc has versions 2.0 to
2.13 over the past decade or so, for one. Every program needs a
particular version of libc and they aren't all binary compatible. Hence
the existence of things like Red Hat's compat-glibc package. Local
matching is the norm on Linux and on Unices just as with Microsoft and
IBM operating systems. One doesn't get any old module named "libc" that
just happens to have been loaded into some other process at some point
before. There's no global module table in the kernel that's searched.
The dynamic library loader searches the library path, finds a file (or a
symbolic link to a file) with the library, and loads it; and this
happens separately in each individual process.
Post by Peter Flass
Post by Jonathan de Boyne Pollard
IBM OS/2 in the late 1980s had a global DLL table, though, just like
DOS-Windows 2.x did at the same time. The problem here is that second
system effect, which gave us the behaviour of DOS-Windows 9x and
Windows NT when it was realized that per-process semantics were the
sensible ones (because they allow one to have per-process DLL search
paths that don't have crazy behaviour, for one thing), hasn't really
been fully applied to the first system. The whole
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that
retains the global tables, but changes the rules for searching them
so that one *almost*, but not quite, gets the per-process semantics
that everyone has concluded are the sensible ones. It's an easy bodge
that doesn't change the underlying bookkeeping.
Again maybe this is me, but search paths _should_ have nothing to do
with DLL name matching. The tables should match as much of the name
as the caller specifies, expanding stuff like './' in the pathname.
If he asks for 'abc' he gets the first 'abc' in the search path or the
first one in the table. If he specifies 'c:\myapp\mysubdir\abc' he
gets that one, which would only be loaded if not already present.
The latter doesn't work in the presence of Unix-like fileystem
semantics. If the DLL image file is unlinked and replaced by a new file
with an updated DLL, then obviously even though the pathname hasn't
changed the new DLL should be found, not the old one, even if processes
still running are using the old DLL. This is a problem with the whole
idea of matching DLLs in any table, global or per-process, by name.
There's always a way in which that name can end up pointing to something
different, and "the same name" stops being equivalent to "the same
library". The only sensible way for a kernel to declare two dynamic
libraries to be "the same" is if their vnodes match.

Which brings us to the former statement of yours. It's on the right
lines, but not quite pointing in the right direction. If the only
sensible way for a kernel to declare two dynamic libraries to be "the
same" is if their vnodes match, then really there *should be no* DLL
name matching going on *anywhere*. DLLs loaded by an unqualified
basename should be *neither* matched by their modnames *nor* matched by
generated pathnames. Rather, an unqualified basename is simply passed
through the library path mechanism, to yield as its result an open file
handle (or file mapping handle) that is, effectively, the vnode of the
library; and any sort of global matching that happens in order to match
an already loaded DLL and increment its reference count happens by
comparing that vnode to the vnodes of existing loaded DLLs. So search
paths have nothing to do with DLL name matching by simple dint of the
fact that there *is no* DLL name matching *at all*. Everything funnels
through the library path searching mechanism, and there are no magic
shortcuts, where names are matched, that bring with them the
possibilities of the wrong DLL ending up being used.

Viewed from another angle, one can equally say that the idea that one
*can* match DLLs by name, modname or pathname, is one of the reasons
that the likes of OS/2 and Windows NT retain their prohibitions on
deleting the DLLs and EXEs of executing programs. If, say, one DLL is
considered to match an already loaded DLL because they both have the
name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes go
around deleting and replacing that file whilst it is in use; because
that would violate the matching guarantee. This can be extended to a
logical conclusion, too. If one DLL is considered to match an already
loaded DLL because they both have the modname CMDCRT, then one really
cannot permit processes to do anything that violates that guarantee,
which would include (a) deleting and replacing the loaded CMDCRT.DLL
image file, (b) adding a new CMDCRT.DLL somewhere else on the process'
library path, and even (c) changing the process' library path so that a
different CMDCRT.DLL is found. And again, by a different route, we
reach the point of realization that name matching, pathname *or*
modname, is simply a bad idea in toto because of what desirable
functionality has to be prevented in order to make it work reliably in
all circumstances.

Microsoft's current answer to this whole conundrum with Win32 is to
instruct programmers simply not to use anything but qualified pathnames
when loading DLLs, and to warn that if one does use unqualified
basenames, one won't necessarily actually end up with the DLL that one
intended. (See the documentation for LoadLibrary(), LoadLibraryEx(),
and Dynamic Link Library Security in the MSDN Library.) In other words:
Avoid the tricky parts of the whole design that really don't quite work
right.

IBM's answer with LIBPATHSTRICT enabled is a fairly reasonable
alternative: You can use unqualified basenames, but don't expect
modname matching to work all of the time or to be able to load/query
DLLs that aren't on your library path in the first place.
Jonathan de Boyne Pollard
2011-03-12 03:53:14 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Viewed from another angle, one can equally say that the idea that one
Post by Jonathan de Boyne Pollard
*can* match DLLs by name, modname or pathname, is one of the reasons
that the likes of OS/2 and Windows NT retain their prohibitions on
deleting the DLLs and EXEs of executing programs. If, say, one DLL is
considered to match an already loaded DLL because they both have the
name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes
go around deleting and replacing that file whilst it is in use;
because that would violate the matching guarantee. This can be
extended to a logical conclusion, too. If one DLL is considered to
match an already loaded DLL because they both have the modname
CMDCRT, then one really cannot permit processes to do anything that
violates that guarantee, which would include (a) deleting and
replacing the loaded CMDCRT.DLL image file, (b) adding a new
CMDCRT.DLL somewhere else on the process' library path, and even (c)
changing the process' library path so that a different CMDCRT.DLL is
found. And again, by a different route, we reach the point of
realization that name matching, pathname *or* modname, is simply a
bad idea in toto because of what desirable functionality has to be
prevented in order to make it work reliably in all circumstances.
I think the reason for preventing deletion of a DLL that is in use by
one or more processs is not the one you state. It is the necessity to
page in code/read-only data from the DLL in order to avoid having to
load the complete DLL.
You think wrong, more on which in a moment.
Post by Jonathan de Boyne Pollard
That was the point when IBM invented function "DosReplaceModule" that
does exactly that:[...]
No. The point of DosReplaceModule() was to give some equivalent to
functionality that is simply *there* on Unix. It exists because EXEs
and DLLs (and indeed any sort of open file) cannot be deleted. The
prohibition doesn't exist because of it. In fact the prohibition
pre-dates the existence of OS/2 and goes back to MS/PC-DOS. To think
that the function inspired the prohibition is exactly backwards.

The idea that paging necessitates this is wrong. Deleting a file
doesn't stop it from being accessible on a Unix-like operating system.
On such a system deleting an in-use DLL or EXE won't stop processes from
being able to read pages in from it, because deleting the file whilst it
is open doesn't make it actually disappear. It's still perfectly
accessible to any process that has it open, and it continues to exist
until all processes that had it open close it. The fact that one can
quite happily use deleted files from a running process on such systems
completely disproves any idea that deleting a file makes it impossible
to use it as the program image for a DLL or an EXE of a running
process. The fact that one can do exactly that on Unices says otherwise.

The reason that one cannot delete open files on IBM OS/2 is manifold,
one part of which is, as I said, that letting things be otherwise
reveals a large flaw in the whole "These two DLLs have the same name
therefore they must be the same DLL." logic of the process loader.
Other reasons include, in no particular order: application backwards
compatibility and the fact that API considers every open module to
possess a name of some kind (c.f. DosQueryModuleName()).

People really, really, want the abilities to just simply install
upgraded programs over the top of running stuff, leaving it running,
that Unix has. That's why we received DosReplaceModule(), which is a
special-purpose bodge to provide just enough, of the capabilities that
would otherwise be achieved with ordinary filesystem manipulation system
calls, to keep people, who really only want a specific subset of the
overall range of things that can be done, happy. To go further, and
actually make the ordinary filesystem manipulations work in toto for
open files and in-use executable program images, is to kick out a stone
that underpins a fair amount of this corner of the design of IBM OS/2.
The knock-on effects of it are, as I mentioned before, changes to the
guarantees provided by DosLoadModule(), which can no longer do any
matching by *any* type of name, significant changes in the
specifications of the likes of DosQueryModuleHandle() and
DosQueryModuleName(), and other stuff as well (Any form of delayed
import binding is significantly affected, for example.).

Put another way: Making IBM OS/2 work "Sensibly, like Unix works." for
all of the programmers who say that they want that, breaks the
applications of the Ruediger Ihles of this world, who design their
programs on the assumption that IBM OS/2 has the same global module
table with globally unique modnames that it and DOS-Windows 2.x had back
in the late 1980s. (-: They may not know that that's their
assumption. Often it's more the case of "Well I happen to know that if
I use that trick, it works.". But the tricks are usually predicated
upon the operating system implementation, such as a global system module
table (or a global socket handle table, or device filenames in every
directory, or maintenance of a separate current directory for every
drive ...). *That's* (one part of) why these things exist, not
unfounded hypotheses about paging to deleted files. That's why the
Win32 personality on Windows NT 6.1, right now in 2011, still has the
prohibition on deleting in-use files inherited from MS/PC-DOS, even
though Windows NT has always, from pretty much its very inception, at
the actual operating system kernel level had the ability to delete
in-use files. The Ruediger Ihles of this world want OS/2 to work
"Sensibly, like Win32 does." so that they don't have to have separate
code for OS/2 with different semantics to Win32, and Win32 programmers
in their turn want Win32 to work "Sensibly, like DOS-Windows 2.x does.".
t***@antispam.ham
2011-03-12 04:19:34 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
No. The point of DosReplaceModule() was to give some equivalent to
functionality that is simply *there* on Unix. It exists because EXEs
and DLLs (and indeed any sort of open file) cannot be deleted.
One of the problems I've encountered is that open files cause
problems for backup programs. I really think there ought to be
a way to copy a file even while it's open. I hate to have a
backup program "successfully" complete, only to have a bunch of
files missing from the backup because they were open at the time.
Yes, I know an open file is subject to change, so the backup
may not be the same as the file could be a moment later, but
better than nothing at all.
Ilya Zakharevich
2011-03-12 07:39:39 UTC
Permalink
Raw Message
Post by t***@antispam.ham
Post by Jonathan de Boyne Pollard
No. The point of DosReplaceModule() was to give some equivalent to
functionality that is simply *there* on Unix. It exists because EXEs
and DLLs (and indeed any sort of open file) cannot be deleted.
One of the problems I've encountered is that open files cause
problems for backup programs. I really think there ought to be
a way to copy a file even while it's open.
There is no problem with copying a file which is open. Probably, you
mean a file file which read-locked? There must be a reason for
that, right?
Post by t***@antispam.ham
I hate to have a
backup program "successfully" complete, only to have a bunch of
files missing from the backup because they were open at the time.
Yes, I know an open file is subject to change, so the backup
may not be the same as the file could be a moment later, but
better than nothing at all.
No, it is not better. It would be better if they were "stored
separately" as unreliably-copied, so restore would require a manual
intervention. Does any backup program do it?

Ilya
Ilya Zakharevich
2011-03-12 07:34:50 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
This is just an illustration how much "inverted" your logic is.
Nobody in their right mind would call the way Unix works "sensible"
(at least w.r.t. DLL resolution) - unless all they know is Unix, and
they know no other architecture. Especially taking into account that
there is no such thing as "Unix".

On Unix, when you call foobar(), you never know whether you got the
function you meant to call, or a function in an unrelated DLL, or -
worst of the case - a non-function (data) in another DLL. It is a
russian rulette, and the only viable solution for any program of
non-trivial size is to use a unique symbol prefix for every library.

IMO, the OS/2 (or AIX [which gives you yet more flexibility]) way is
significantly more "sensible".

Hope this helps,
Ilya
Jonathan de Boyne Pollard
2011-03-12 16:18:35 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
Post by Jonathan de Boyne Pollard
Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
This is just an illustration how much "inverted" your logic is.
No, it's an exhibition on your part of the Usenet tendency to hit that
reply button before even getting to the end of a sentence. Here's the
Post by Ilya Zakharevich
Making IBM OS/2 work "Sensibly, like Unix works." for all of the
programmers who say that they want that, breaks the applications of
the Ruediger Ihles of this world, who design their programs on the
assumption that IBM OS/2 has the same global module table with
globally unique modnames that it and DOS-Windows 2.x had back in the
late 1980s.
Indeed, there's a whole paragraph there, including various "Sensibly"s
of different stripes, providing a context to the quote that you decided
to hit reply before reading beyond. Pretty much the whole of what you
said, being based upon such Usenet nitwittery, is thus quite wrong. Go
back and read.
Ruediger Ihle
2011-03-12 08:57:21 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
for all of the programmers who say that they want that, breaks the
applications of the Ruediger Ihles of this world, who design their
programs on the assumption that IBM OS/2 has the same global module
table with globally unique modnames that it and DOS-Windows 2.x had
Did I mention, that I didn't design anything here ? This is a
port of an existing application that is currently available on
Windows, Linux and MacOS. Any critics on the general approach
should be directed to someone at http://developer.qt.nokia.com/
Post by Jonathan de Boyne Pollard
The Ruediger Ihles of this world want OS/2 to work "Sensibly, like
Win32 does." so that they don't have to have separate code for OS/2
with different semantics to Win32
Of course I want to the keep OS/2-specific changes / extensions at
an absolute minimum. Especially, when it comes to code that is not
part of the lower level OS abstraction layer. OS/2 is not a major
platform and as such it can be very hard to convince the projects
maintainers to accept those type of changes...
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
Jonathan de Boyne Pollard
2011-03-12 17:34:03 UTC
Permalink
Raw Message
Post by Ruediger Ihle
Post by Jonathan de Boyne Pollard
Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
for all of the programmers who say that they want that, breaks the
applications of the Ruediger Ihles of this world, who design their
programs on the assumption that IBM OS/2 has the same global module
table with globally unique modnames that it and DOS-Windows 2.x had
Did I mention, that I didn't design anything here ?
I actually rather took it for granted that you were working within a
framework set by someone else, given that you said that you were writing
plug-in DLLs. (-: That's why I phrased it like that, trying to make it
clear that I wasn't laying this at your door specifically, but that
rather you were an example of the desire, the motivation, the want, the
pressure. This is all about how applications programmers want and press
for the operating system to behave, which is, as I said, "Sensibly, like
Unix does", "Sensibly, like Win32 does.", or "Sensibly, like DOS-Windows
2.x.". If you're about to comment that they all conflict, then you're
getting one of the points made. (-: But another point is that it's the
people who think that the things that they grew up with on DOS and
Windows are "sensible" (including things like the side-effects of an
operating system implementation that uses global module tables, global
socket handle tables, device names in every directory, and so forth) who
are the inertia that frustrates those who say "It's been 30 years.
Can't we finally lose this CP/M-inspired rubbish and do things right, now?".
Post by Ruediger Ihle
Of course I want to the keep OS/2-specific changes / extensions at an
absolute minimum. Especially, when it comes to code that is not part
of the lower level OS abstraction layer. OS/2 is not a major platform
and as such it can be very hard to convince the projects maintainers
to accept those type of changes...
I suspect that a great many of us have experienced the same thing. You
are not alone. But again what this is about is the knock-on effects of
that. You want to keep platform-specific code for OS/2 to a minimum.
So you want OS/2 to work as much like Win32 as possible. So you want to
be able to use tricks like those used on Win32. But the Win32 tricks
themselves, like the OS/2 behaviour, have their roots in two and a bit
decades of backwards compatibility for the sake of applications that
expect IBM OS/2 1.0 and DOS-Windows 2.x with their global module
tables. The world learned better after a few years of experience of
that, and Second System Effect gave us DOS-Windows 9x with per-process
module tables and Windows NT. (IBM OS/2 still has the global module
table.) And the world tries hard now to give sensible semantics to
these things, that work *right* and do *not* have the problems of (say)
accidentally importing entirely the wrong DLL because it just happened
to have the same internal name as something completely unrelated. (On
this point, see Raymond Chen's Win32 programming advice never to give a
DLL the name "Security.DLL" for an example.) But the IBMs and
Microsofts of this world are constrained by the fact that if one adopts
the sensible semantics *completely*, learning from experience of the
wrong design, it breaks the applications of the Ruediger Ihles of this
world, as you've discovered.

It's perhaps only the OSFrees of the world who are in a position to say
"We're going to be this compatible, and no farther, with the bad ideas
of the past.". The IBMs and Apples and Microsofts of the world get
moaned at by the Rich Walshes of the world for ten years when they try
to stop poor design choices from 1986 causing well-known problems, as
you can observe. (-:
Jonathan de Boyne Pollard
2011-03-12 04:19:27 UTC
Permalink
Raw Message
1.) reduce coding effort and reuse code that already exists
2.) enforce the same behaviour/look by providing the same piece of
code for everyone to use
3.) reduce memory usage by having code shared amongst multiple
processes, possibly even data
That would speak for the global approach. The fact that you run into a
4.) the binary interface of a DLL changes
5.) the search algorithm that does not know any better than to look
for filenames to find and load a DLL if necessary (at least the f/q
filename ensures uniqueness but then it is potentially "too much
uniqueness" from one system to the other so you will need to have
configuration files for base paths etc.) or for module names (where
the uniqueness of module names is not enforced in any way)
6.) 2 DLLs with the very same name but that have nothing to do with
each other
leads to all these workarounds where you effectively "roll back" what
you are trying to achieve with 1.)-3.)
Not really, unless one doesn't learn the Unix definition of "same" which
is "same vnode". Learn that, and one still gets the ability to share
multiple instances of the "same" DLL, but one's definition of what is
the "same" now accords with the filesystem's. The same vnode means the
same program image, which means the same library.
In any case, we have to live with what IBM has left behind for OS/2.
Not if the OSFree people get their act together. (-:
Allan
2011-03-13 18:50:49 UTC
Permalink
Raw Message
In any case, we have to live with what IBM has left behind for OS/2.
It sure would be nice with a better implementation in OSFree,
but that would require more programmers, if it should happen
in this century.
Currently, close to nothing is going on......
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
2011-03-15 15:59:18 UTC
Permalink
Raw Message
In any case, we have to live with what IBM has left behind for OS/2.
It sure would be nice with a better implementation in OSFree, but that
would require more programmers, if it should happen in this century.
Currently, close to nothing is going on......
More programmers isn't necessarily the answer.
Allan
2011-03-16 05:51:20 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
In any case, we have to live with what IBM has left behind for OS/2.
It sure would be nice with a better implementation in OSFree, but that
would require more programmers, if it should happen in this century.
Currently, close to nothing is going on......
More programmers isn't necessarily the answer.
Well, since there currently is less than 1 working on osFree,
I DO believe, that more programmers are needed :-)
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
2011-03-24 23:38:33 UTC
Permalink
Raw Message
Well, since there currently is less than 1 working on osFree, I DO
believe, that more programmers are needed :-)
How do you know the number? That's certainly not the number of people
that the Subversion change logs for the project indicate.
Allan
2011-03-25 01:28:41 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Well, since there currently is less than 1 working on osFree, I DO
believe, that more programmers are needed :-)
How do you know the number? That's certainly not the number of people
that the Subversion change logs for the project indicate.
We do talk together every day at
irc://efnet/#osfree
so I think I have a clue :-)

Sure there might have been many people contributing something over
the last decade, but I doubt you'll find much more than one within the last
6 months.

Actually, looking at:
http://osfree.svn.sourceforge.net/viewvc/osfree/trunk/?sortby=rev&view=log
I think you can find 3 since 24 aug 2009
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
2011-03-25 17:37:16 UTC
Permalink
Raw Message
Post by Allan
Well, since there currently is less than 1 working on osFree, I DO
believe, that more programmers are needed :-)
How do you know the number? That's certainly not the number of people
that the Subversion change logs for the project indicate.
We do talk together every day at
irc://efnet/#osfree
So the reason that nothing is happening is that they're spending all of
their time talking to you day after day on IRC instead of working on the
project? (-:
Allan
2011-03-26 15:09:33 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Post by Allan
Well, since there currently is less than 1 working on osFree, I DO
believe, that more programmers are needed :-)
How do you know the number? That's certainly not the number of people
that the Subversion change logs for the project indicate.
We do talk together every day at
irc://efnet/#osfree
So the reason that nothing is happening is that they're spending all of
their time talking to you day after day on IRC instead of working on the
It sure looks that way, doesn't it ? ;-)

Anyway, as you can see, we really need more people to help out here,
if anything usefull from osFree project should be available in this
decade.
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Shmuel (Seymour J.) Metz
2011-03-13 23:52:45 UTC
Permalink
Raw Message
In <***@J.de.Boyne.Pollard.localhost>, on
03/11/2011
at 04:02 AM, Jonathan de Boyne Pollard
Local matching is the norm on Linux and on Unices just as with
Microsoft and IBM operating systems.
IBM has more than one operating system. In z/OS the LPA provides
global copies of load modules available to all address spaces, and
these are used if a fetch fails to find a local copy.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org
Peter Flass
2011-03-17 19:26:38 UTC
Permalink
Raw Message
Post by Peter Flass
Post by Jonathan de Boyne Pollard
The thing is: Global modname matching across all processes is almost
never what one wants. I'm hard pressed to come up with an example of
a use for it.
I come from more of a mainframe background, but I feel the opposite.
Global matching is the norm -- think libc, for example -- and
per-process should be the exception to handle the cases where a DLL is
not upward-compatible. Of course, for microsoft this *is* the norm.
Not just for Microsoft. For *most people* this is the norm, Unix
included. Think libc for example. Yes, libc. You chose what is,
ironically, an exact counterexample. Have you ever looked to see how
many different versions of it there are? GNU libc has versions 2.0 to
2.13 over the past decade or so, for one. Every program needs a
particular version of libc and they aren't all binary compatible. Hence
the existence of things like Red Hat's compat-glibc package. Local
matching is the norm on Linux and on Unices just as with Microsoft and
IBM operating systems. One doesn't get any old module named "libc" that
just happens to have been loaded into some other process at some point
before. There's no global module table in the kernel that's searched.
The dynamic library loader searches the library path, finds a file (or a
symbolic link to a file) with the library, and loads it; and this
happens separately in each individual process.
Post by Peter Flass
Post by Jonathan de Boyne Pollard
IBM OS/2 in the late 1980s had a global DLL table, though, just like
DOS-Windows 2.x did at the same time. The problem here is that second
system effect, which gave us the behaviour of DOS-Windows 9x and
Windows NT when it was realized that per-process semantics were the
sensible ones (because they allow one to have per-process DLL search
paths that don't have crazy behaviour, for one thing), hasn't really
been fully applied to the first system. The whole
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that
retains the global tables, but changes the rules for searching them
so that one *almost*, but not quite, gets the per-process semantics
that everyone has concluded are the sensible ones. It's an easy bodge
that doesn't change the underlying bookkeeping.
Again maybe this is me, but search paths _should_ have nothing to do
with DLL name matching. The tables should match as much of the name as
the caller specifies, expanding stuff like './' in the pathname. If he
asks for 'abc' he gets the first 'abc' in the search path or the first
one in the table. If he specifies 'c:\myapp\mysubdir\abc' he gets that
one, which would only be loaded if not already present.
The latter doesn't work in the presence of Unix-like fileystem
semantics. If the DLL image file is unlinked and replaced by a new file
with an updated DLL, then obviously even though the pathname hasn't
changed the new DLL should be found, not the old one, even if processes
still running are using the old DLL. This is a problem with the whole
idea of matching DLLs in any table, global or per-process, by name.
There's always a way in which that name can end up pointing to something
different, and "the same name" stops being equivalent to "the same
library". The only sensible way for a kernel to declare two dynamic
libraries to be "the same" is if their vnodes match.
Which brings us to the former statement of yours. It's on the right
lines, but not quite pointing in the right direction. If the only
sensible way for a kernel to declare two dynamic libraries to be "the
same" is if their vnodes match, then really there *should be no* DLL
name matching going on *anywhere*. DLLs loaded by an unqualified
basename should be *neither* matched by their modnames *nor* matched by
generated pathnames. Rather, an unqualified basename is simply passed
through the library path mechanism, to yield as its result an open file
handle (or file mapping handle) that is, effectively, the vnode of the
library; and any sort of global matching that happens in order to match
an already loaded DLL and increment its reference count happens by
comparing that vnode to the vnodes of existing loaded DLLs. So search
paths have nothing to do with DLL name matching by simple dint of the
fact that there *is no* DLL name matching *at all*. Everything funnels
through the library path searching mechanism, and there are no magic
shortcuts, where names are matched, that bring with them the
possibilities of the wrong DLL ending up being used.
Agreed.
Viewed from another angle, one can equally say that the idea that one
*can* match DLLs by name, modname or pathname, is one of the reasons
that the likes of OS/2 and Windows NT retain their prohibitions on
deleting the DLLs and EXEs of executing programs. If, say, one DLL is
considered to match an already loaded DLL because they both have the
name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes go
around deleting and replacing that file whilst it is in use; because
that would violate the matching guarantee. This can be extended to a
logical conclusion, too. If one DLL is considered to match an already
loaded DLL because they both have the modname CMDCRT, then one really
cannot permit processes to do anything that violates that guarantee,
which would include (a) deleting and replacing the loaded CMDCRT.DLL
image file, (b) adding a new CMDCRT.DLL somewhere else on the process'
library path, and even (c) changing the process' library path so that a
different CMDCRT.DLL is found. And again, by a different route, we reach
the point of realization that name matching, pathname *or* modname, is
simply a bad idea in toto because of what desirable functionality has to
be prevented in order to make it work reliably in all circumstances.
Microsoft's current answer to this whole conundrum with Win32 is to
instruct programmers simply not to use anything but qualified pathnames
when loading DLLs, and to warn that if one does use unqualified
basenames, one won't necessarily actually end up with the DLL that one
intended. (See the documentation for LoadLibrary(), LoadLibraryEx(), and
Avoid the tricky parts of the whole design that really don't quite work
right.
IBM's answer with LIBPATHSTRICT enabled is a fairly reasonable
alternative: You can use unqualified basenames, but don't expect modname
matching to work all of the time or to be able to load/query DLLs that
aren't on your library path in the first place.
Andreas Buchinger
2011-03-12 11:52:32 UTC
Permalink
Raw Message
The real problem is that these lists are system-wide on IBM OS/2, rather than
....

PLEASE Mr. Jonathan de Boyne Pollard, can you stop posting the same message in
different newsgroups? For someone with your skill set it should be rather easy
to check your newsreader setting and post answers only to the right group and
thread.

Thanks,
Andreas Buchinger
Jonathan de Boyne Pollard
2011-03-12 16:33:06 UTC
Permalink
Raw Message
For someone with your skill set it should be rather easy to check your
newsreader setting and post answers only to the right group and thread.
This is Usenet. Cross-posting is *proper* and the *norm*, here. And
discussions of OS/2 programming and OS/2 bugs are on-topic in newsgroups
for OS/2 programming and OS/2 bugs. It's not as though we're talking
about OS/2 programming and OS/2 bugs in alt.english.usage or something.
There are some 25 years of Frequently Asked Questions documents
explaining these, the basics of Usenet, for you. I'm too busy at the
moment to waste my time repeating such basic stuff for you. Find them
for yourself, read them, and learn.
Andreas Buchinger
2011-03-12 21:41:36 UTC
Permalink
Raw Message
For someone with your skill set it should be rather easy to check your
newsreader setting and post answers only to the right group and thread.
This is Usenet. Cross-posting is *proper* and the *norm*, here. And discussions
of OS/2 programming and OS/2 bugs are on-topic in newsgroups for OS/2
programming and OS/2 bugs. It's not as though we're talking about OS/2
programming and OS/2 bugs in alt.english.usage or something. There are some 25
years of Frequently Asked Questions documents explaining these, the basics of
Usenet, for you. I'm too busy at the moment to waste my time repeating such
basic stuff for you. Find them for yourself, read them, and learn.
You're to lazy to setup your newsreader correctly? And all others should stumble
over and over your same posts in various groups again and again? You creating
new threads in groups with your answers for questions no one asked in that
group? Your to busy for repeating something but post your comments to various
placed and steel others time with your posts till they encounter it's the same
thing you've posted at other places too?

I've politely asked you to stop this annoying behavior but it seems you're to
lazy to behave politely too. Luckily I can filter your egomaniac effluence and
that's what I'll do from now.
Steve Wendt
2011-03-12 23:33:11 UTC
Permalink
Raw Message
Post by Andreas Buchinger
You're to lazy to setup your newsreader correctly? And all others should
stumble over and over your same posts in various groups again and again?
It's actually Seamonkey that is doing things incorrectly:
https://bugzilla.mozilla.org/show_bug.cgi?id=43278
Andreas Buchinger
2011-03-13 09:47:06 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Andreas Buchinger
You're to lazy to setup your newsreader correctly? And all others should
stumble over and over your same posts in various groups again and again?
https://bugzilla.mozilla.org/show_bug.cgi?id=43278
I use Seamonkey and even do reply only to the group and message where it
belongs. Not other groups/threads too. Although it would be nice if Seamonkey
would work around such cross-postings, it's absolutely no problem to dedicate a
reply only to the proper group/thread.

Things have changed and people use the internet differently then in the nineties
of the last millennium. f.i. there are people who even read usenet via web
interface. Johnathan can resist to accept this and keep annoying people, or he
can think about if his behavior still matches the current situation. But I fear
he has decided to stay in his corner and try to convince people to do it the way
he thinks is the right one.

Anyway, although I tried it, it seems I'm not the one who can teach him social
behavior and so will not try again.

Regards,
Jonathan de Boyne Pollard
2011-03-15 15:51:57 UTC
Permalink
Raw Message
Post by Andreas Buchinger
Johnathan can resist to accept this and keep annoying people, or he
can think about if his behavior still matches the current situation.
But I fear he has decided to stay in his corner and try to convince
people to do it the way he thinks is the right one.
You're the person with the bizarre idea of what's right that's trying to
impose it on others here, not anyone else. Notice that it's *you*
telling *us* what to do, not us who came to you. Now get yourself off
to those 25 years worth of Frequently Asked Questions documents
explaining the basics, including how a good newsreader only shows a
single message once, and learn how Usenet works.
Shmuel (Seymour J.) Metz
2011-03-13 23:58:42 UTC
Permalink
Raw Message
In <***@J.de.Boyne.Pollard.localhost>, on
03/12/2011
at 04:33 PM, Jonathan de Boyne Pollard
Post by Jonathan de Boyne Pollard
This is Usenet. Cross-posting is *proper* and the *norm*, here.
So is starting the body with an attribution line.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org
Loading...