Talk:Dynamic loading

Dynamic Loading vs. Dynamic Linking

This article doesn't make any difference between Dynamic Loading and Dynamic Linking. Actually, it tells about Dynamic Linking, not Dynamic Loading. See the difference between both in "Operating System Principles" from the author "Abraham Silberschatz" for example. —Preceding unsigned comment added by 83.35.174.59 (talk) 15:35, 10 July 2008 (UTC)

Firstly, Abraham Silbershatz is not the only authority on the subject. Secondly, it is impossible to change the article unless you provide a quote of the relevant text along with a citation (including the exact page numbers).

← Michael Safyan ^(talk) 19:40, 11 July 2008 (UTC)

Note that I am not the first author. However, I looked to find the referenced section and think that "Operating System Concepts" 7th Edition from Silberschatz, Galvin, Gagne ISBN 0-471-69466-5 (2005) is related to what the poster was talking about. Two Subsections on 280 pp. deal with 8.1.4 Dynamic Loading and 8.1.5 Dynamic Linking and shared libraries. I'll try to sum up/paraphrase the content/definitions of the authors:

Dynamic Loading deals with the loading of routines during runtime in general, it enables memory-savings by delaying routine-loading until it is actually called. The calling routine checks whether the callee routine is already loaded. Dynamic loading is implemented by the user but the OS may supply supporting functions.

With Dynamic Linking, linking is postponed to runtime instead of compile time and thus enables the concept of shared libraries in memory as well as on disk. A stub is placed during compile time, instead of the code, which contains information to locate the code in memory or load it. This normally requires OS support.Methossant (talk) 14:49, 10 July 2009 (UTC)

So I think the only big difference between the article and the book currently is that the article focusses more on libraries where the book mentions routines. However the article reflects more the actual current and relevant use that the OS supports Dynamic loading by first letting load the library and then individual functions.

However I do agree and suggest strongly that a "Dynamic linking vs dynamic loading" section is a must-have for the article to achieve its full usefulness.Methossant (talk) 15:12, 10 July 2009 (UTC)

Bad style in example

The example calls dlopen("libsdl.so"). This is bad, as this symlink is not going to exist if the development package of SDL is not installed, or it may point to an incompatible version. Please always call dlopen() with the full library SONAME. See more details at http://blogs.adobe.com/penguin.swf/2006/09/librarian.html#comment-36894. 90.151.141.28 (talk) 13:14, 28 February 2009 (UTC)

Delayed loading

The article says: "Unlike static linking and delayed loading, this mechanism allows a computer program to startup in the absence of these libraries..."

However with Microsoft Windows, an application that uses Delay-Loaded DLLs will start if the delay-loaded DLLs are absent. The DLLs are not required until the application actually calls a function in the DLL. If the DLL is not available at that point, the application can detect and handle the error. —Preceding unsigned comment added by Mitch Ames (talk • contribs) 13:28, 28 February 2009 (UTC)

I don't like the term either. I am very sure that "delayed loading" here meant the standard loading of libraries at application startup time, with "delayed" referring to the loading at runtime rather than compile time. Anyways, I think the term is not really fit for describing that process and not established. It also leads to confusion with the delay-loading mechanism of Microsoft that you cite, where I second your description and opinion. I replace that term therefore with "Loadtime Linking".Methossant (talk) 16:19, 23 May 2009 (UTC)

Reversion of edit 1234290353

My edit 1234290353 clarified the introduction paragraph, which omitted the simplest and most obvious way in which one program can use functionality from another. This is also immensely popular approach, consider just how many programs execute `less` or `$EDITOR` as a form of executing code from another software (I don't think I've ever seen a program dynamically link to less or anything alike).

I see that this was reverted and the intro paragraph is not incorrect/incomplete again. I don't want to get into reversing reversal without an actual exchange of thoughts here, and I'd appreciate some discussion on this. The description for the reversal is quite wordy but doesn't actually give an explanation for the reversal. Instead, the description it merely discusses the merits of the approach and some how this mechanism can fail in different ways, but that's an opinion on the technicalities of the approach itself.

HuGo_87 (talk) 13:42, 14 July 2024 (UTC)

way in which one program can use functionality from another If you define "program" as an executable image that can be directly executed, this page does not describe one particular way in which a one program can use functionality from another program; it describes a way in which one chunk of code can make a subroutine call to code from another chunk of code.

The description for the reversal is quite wordy but doesn't actually give an explanation for the reversal. Yes, it does; you just have to understand what it's saying. The first sentence says:

Limit this to using the other software *within the program*, to cover cases of direct procedure calls and the like.

"Within the program" means, at least in the context of operating systems in which each program runs in a single process, and each process has its own address space (UN*Xes and Windows, for example), "within the process's address space". If you link with a static library, the code is incorporated, at link time, in the executable image. If you link with a dynamic library, the code is loaded into the process's address space at process startup time or at the time the first call to a routine from the library is made (usually the former). If you dynamically load code, the code is loaded into the process's address space at the time the program calls the "load a library" call (dlopen() on most UN*Xes, LoadLibrary() on Windows).

If you run another program, or connect to a server process on the same or another machine, that's a different mechanism.

A page that's about the general concept of a program using code that's not part of the program as written, whether it's linked into the program's executable image from a static library, loaded into the process's address space from a dynamic library, loaded into the process's address space from a loadable module (e.g., a plugin), running in another program run by the program in question, running in another program - possibly running on another machine - not directly run by the program in question etc. might be a worthwhile code to cover all those forms of using other code. This page is about a much more specific topic.

(And, yes, I know it's a popular approach. A program for which I'm a long-time core developer supports both dynamic loading of plugins into the process (for packet dissection, capture file reading, and computing statistical information from a packet trace) and running the programs (to do capture from mechanisms not supported by the library that it uses for direct packet capture. In addition, the packet capture using that library is done by a program that's part of the same program suite, but separate from the main GUI or command-line packet analyzer programs, so that the capture program can run with privileges sufficient to allow it to capture traffic without the larger program having those privileges. Those two programs/processes communicate over a pipe. And speaking of the GU and command-line packet analyzer programs, the capture file reading and protocol analysis code that are part of the program suite are distributed in the form of shared dynamic libraries used by both of those programs.)

But, again, there's the broad topic, and there's the narrower topic of using other code via in-process procedure calls. The three mechanisms listed for doing the latter are sufficiently similar that little if any effort is needed by the programmer to switch between static and dynamic libraries (what effort is necessary is in setting up the build process, not in writing the code to put into the library or in calling code in the library), and the programming effort to use dynamically loaded code is in 1) adding the call to load the code module, 2) adding code to find pointers to functions in that module, and 3) calling those functions through the pointers rather than directly. Other forms of using "outside" code work differently; the one where the differences between in-process and out-of-process use are hidden best appears to be Microsoft's COM.

Software component might be the page that covers the topic at its broadest. Guy Harris (talk) 20:21, 14 July 2024 (UTC)