Re: c code reusability

Richard Heathfield wrote:
Ian Collins said:


Richard Heathfield wrote:

Dynamic linking has its advantages, but it also has a great many
disadvantages. You have already identified one of them. Another is that
it becomes too easy to introduce fresh bugs into a previously working
program.

How so? The program can carry on using the library it was built against.


Program X uses DLL Y. DLL Y is "improved", and a bug is introduced. New
version of DLL Y, with same name as before, is installed on system. Program
X now uses buggy version of DLL Y. Program X is now buggy.

Yes, you can avoid this if you're careful. No, not everyone is careful.

And it might not even be a "bug" - it might just be a change in
functionality that breaks program X. You can find some very relevant war
stories at http://www.heise.de/ct/english/99/01/070/

Ah, we are talking windows, I was thinking real shared libraries :)

Unfortunately, on some OSs you don't have much choice but to use dynamic
linking for at least some aspects of the program (e.g. Windows system
calls almost invariably resolve to a DLL call, which is a big shame), but
you can minimise the problems by using static linking as much as
possible.


At least one OS I use (Solaris) has deprecated static linking for all
system libraries. It's way easier to fix a library bug with a patch
than it is to fix every application on the system that statically links
it.


That's fine if the system is well-managed. Indeed, it is the preferred
strategy not only in pizza parlours but also in dinosaur pens. But on
Windows, it's a recipe for disaster.

I thought they added the appropriate 70s technology to fix DLL hell?

--
Ian Collins.
.

Relevant Pages

  • Re: Memory increasing even when in debug-break
    ... another test machine that is running the app under .Net 1.1 is still ... I'm left wondering whether this bug is even related. ... leak occurs in a process that uses Corperfmonext.dll in the .NET Framework ... to do this whole DLL injection thing for apps that query performance data... ...
    (microsoft.public.vsnet.debugging)
  • Problem with locales in unloaded DLLs
    ... We are making a plugin (DLL) for some application. ... locale crash") didn't come up with something. ... this bug. ... I'm Schobi at suespammers dot org ...
    (microsoft.public.dotnet.languages.vc)
  • Problem with locales in unloaded DLLs
    ... We are making a plugin (DLL) for some application. ... locale crash") didn't come up with something. ... this bug. ... I'm Schobi at suespammers dot org ...
    (microsoft.public.vc.stl)
  • Re: c code reusability
    ... an already-buggy program, this is a wash. ... Just fix the bug and ship the executable, which is no harder than fixing the bug and shipping the DLL. ... If your dll is used by several client executables, you can't ship the executable, they would have to relink with a new version of the ...
    (comp.lang.c)
  • Re: code within libraries vs code within same project
    ... Is this a bug in System.Diagnostics.StackTrace? ... //the .dll do not appear to have all the info, particularly filename. ...
    (microsoft.public.dotnet.languages.csharp)