OT: Next Time you sing happy birthday

[Lennart Sorensen]

On Tue, Aug 14, 2007 at 10:11:13PM -0400, Ian Petersen wrote:
> The general "feel" of that article is nice, but the details in it are
> rather questionable.  From the article:
> 
> "[In a Linux-based OS there is] no such thing as a DLL, which Crawford
> described as the second most evil thing in Windows behind ActiveX."
> 
> Doesn't an .so serve the same purpose as a DLL?  I don't know much
> about DLLs, so there could be subtle differences in purpose that I'm
> unaware of, but I though DLL stood for "dynamic link library", or
> something similar, and is therefor basically the same as an .so
> (shared object, right?).

Certainly very similar.  The difference is mainly in how they are
handled.  

On linux when a program is loaded that requires a library, it loads the
library along with the program.  If another program is already using
the same library from the same file, then only one copy of the copy
is actually in memory (although any data space used by the library is
seperate for each instance).  If the file is replaced with a new version
of the library, then any existing programs continue to use the version
that is in memory, while any new programs will load the new version
instead (in which case there will be a copy of both versions of the code
in memory).

On windows, when a program is loaded that requires a library, the dll is
loaded into memory if it isn't already loaded.  While the library is in
use, you can not modify the file on disk.  This makes replacing dll's
on windows a real pain since you have to close all current users of the
dll first.  For many key system dll files this is imposible since the
GUI itself is using them.  The only way to replace the dll, is to
schedule a task to replace the files on the next boot before starting
the GUI.  This is the main reason updates on windows so often require
you to reboot.  To me that is the main part of that makes windows have a
dll hell.  Nothing wrong with shared libraries, just something wrong
with how windows deals with them.  A big part of what causes the problem
is that on windows you can not delete a file that is open.  On linux you
can delete it, but the inode of a file only goes away when all hardlinks
to the file are deleted and all open file handles to the inode are
closed.  So having a program use a library on linux and deleting it,
doesn't free the disk space, and the library can still be accessed as
long as the program needs it, and you can hence easily install a new
version of the library and start using it for new programs.  Since
windows won't let you delete or even change the file that is open and in
use, you get the annoying problems when trying to update files that are
in use.

The other part of what gives dll hell on windows, is that they have
historically been very bad at making sure the libraries kept a
compatible ABI between versions.  After all one would hope that a
library claiming to be version 3 should work with all programs compiled
against library version 3.  Linux tends to be very good at that.
Microsoft used to be very bad at it.  They would fix little bugs and
change suttle behaviours as part of minor upgrades, and break programs
that depended on that specific behaviour in the interface.

On linux each library is named libfoo.so.1.2.3 where 1.2.3 is the
version of the library.  A symlink named libfoo.so.1 will link to
libfoo.so.1.2.3 as an implementation of the version 1 ABI of libfoo.
Any program compiled against libfoo.so.1 should work with any version of
libfoo.so.1.x.y and almost always do.  They probably won't work with
libfoo.so.2.3.4, since that would indicate a major change to the library
interface.  But you can have both libfoo.so.1 and libfoo.so.2 installed
at once, so that isn't a problem.  You could even have libfoo.so.1.2.3
and libfoo.so.1.1.2 installed, and if a program for some reason (they
aren't supposed to) is linked against libfoo.so.1.1.2 specifically, it
can still use that file, although most programs with use the libfoo.so.1
symlink which would normally be a symlink to the latest version of
libfoo.so.1.x.y that is installed.

On windows each library is often just named foo.dll and any version
information is internal to the file in some header.  So a program can
say it needs at least version x.y.z of foo.dll, but if a program happens
to only work with version 1.2.3 and you have 2.1.0, then you are out of
luck because you can't install both files at the same time (you can
cheat by putting the specific version into the directory containing the
exe for the program, which almost always will cause it to load the local
copy of the dll rather than the system default version of the dll.)  In
some cases you will see different file names for different major
versions, such as vbrun300.dll, vbrun400.dll, etc.  The linux method
seems more flexible and more thought out.

> Also from the article:
> 
> "We also need to get the different distributions to work on a common
> release cycle,"
> 
> I suppose you might convince Suse, Red Hat, and Ubuntu to come up with
> some kind of general intention to _try_ to adhere to a common release
> schedule, but outside of that this suggestion seems like complete
> lunacy to me.

Fixed release schedules cause crappy software.  Releases that are done
when they are ready and have no serious bugs left are much better.  Any
time marketing/sales get involved in deciding when a release has to be
done is a mistake.  They can offer input on when they would like it, and
the feature set can be based on the expected amount of time to implement
and debug the feature set, but if it still has bugs by the expected
release date, well then the expected release date just won't be met (or
you will be releasing buggy software which is bad for your reputation).

> It may be the case that Vista is driving Windows users to Linux, but
> the article seems to have weak foundations....

--
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists