ivan wrote:
On Tue, 7 Jun 2016 04:54:46 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:
JPEG DLL v8.something still is documented frequenty, but there's also
some newer v9.a.
Is this a case/exception where v8.something is the recommended
default/official version, and that v9.a (JPEGLIB-9A.ZIP @ Hobbes)
should only be used when it's really, really required by a specific
app?
--
That is the BIG question.
We have now descended into the DLL hell - will a program that used an
older version run with the newer version?
This has forced us to setup several test machines to run 'the latest
and greatest' versions against clients and our standard use software,
exactly as sysadmins have to do with windows updates - the reason we
never went down the windows path.
It used to be that a new OS/2 program could be installed and it would
just run. Now that is impossible and we have to be very careful and
test everything before we recommend updates to our clients. Not a
good way of doing things.
One of the problems is that they're acting like this is Linux, which it
isn't.
We use DLLs, primitive DLLs which are limited to 8.3 names which makes versioning hard, though they have now patched libtool (part of the auto
tools that builds the libraries) to put out versioned names. Generally
anything that is linked against a major version should work with any
other release with the same major version. Unluckily not all developers/projects worry about preserving API/ABI compatibility and
should be statically linked on our platform.
Linux uses shared libs that serve the same function as DLLs but are
subtly different. Linux also has a bunch more ways to handle their
shared libs. You can hard code where the shared lib will be, you can
version the functions in a shared lib and support both old and new
programs from the same shared lib. You can use symlinks so foo.so points
to foo.5.so which points to foo.5.21.2.so which simplifies maintenance.
There's other tricks too which make shared libs work better then DLLs in
some circumstances.
Some amount of DLLs are desirable for various reasons, eg Mozilla should probably have between 3 and 6 dependencies (libc, mmap which doesn't
work statically linked, perhaps fontconfig and pango which is supposed
to dynamically load some stuff, and the FFmpeg DLLs along with exceptq,
both of which aren't requirements but bring more functionality.) perhaps
more for test versions or until some libraries stabilize.
Dave
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)