Talk:Loader (computing)

What a "loader" is

A "loader" can also be a piece of code that handles loading the rest of a long program into memory, e.g. on 1980s home computers like Commodore 64 and ZX Spectrum where there might be music or graphical effects during a (several minutes long) loading from cassette tape. This deserves a mention. 86.131.103.69 01:16, 1 February 2007 (UTC)[reply]

does not loader comes after linking for programs for loading to program memory area for execution?

—Preceding unsigned comment added by unknown (talk • contribs)

A loader is simply a part of operating system that is responsible for loading programs from executables to memory, prepare them for execution and then execute them. It is usually a part of the operating system's kernel and usually is loaded at system boot time and stays in memory until reboot/shutdown/poweroff (some operating systems with a pageable kernel may have the loader in the pageable part of the kernel and thus the loader may be swapped out of memory sometimes). Each operating system that supports program loading must have one (there are some embedded operating systems in highly specialized computers that have no program loading capabilities and thus no loaders, for example the operating system that runs on the computer that controls your HIFI). The thing described in the article is called "linking loader" and I also have seen name "program interpreter" (from the 'readelf' program) or "helper program for shared library executables" that refers to a component of the loader that performs the shared library linking performed at runtime.

I didn't updated the article since a lot of investigation needs to be done, especially to identify the sources and the proper names for the various loader types.

--Jozue 19:44, 24 January 2007 (UTC)[reply]

In unix and in general modern OSes' context the loader is part of the OS, or bootloeader (and mostly not part of the OS, since it runs pre kernel), but the c=64 bit illustrates that in embedded and older OS contexts things are different.

Classic Mac OS is also a nice example that things are not always that black and white as the strict bios-bootloader-OS from the PC, since there ROM and loaded OS parts work in unison, and loaded parts can override parts of the ROM, but the ROM will still be used to boot etc etc. Overriding can even take place on a per model basis (if the ROM is known to be buggy for that model). The OS is the combined ROM and loaded OS parts. 88.159.79.148 (talk) 11:34, 20 January 2016 (UTC)[reply]

As I think I added to the article, on OS/360 and successors the "loader" is not part of the operating system, but a separate program. An OS service called "program fetch" can be used alternatively to load already-linked programs. I think this is still true with zOS, although PDS/Es have undoubtedly caused changes. There are also stand-alone loaders, such as used on the PDP11 to load a program from paper tape, or to load a hex program assembled on another system, but these might be considered boot loaders. Peter Flass (talk) 15:43, 20 January 2016 (UTC)[reply]

Not always "part of an operating system"

Indeed, one the various loader types is boot loader, which (usually) loads the operating system itself. –Wbm1058 (talk) 13:36, 18 April 2012 (UTC)[reply]

Needs much more work

Terminology: I could do with some help in clarifying usage of English terms. The process of either starting executables or loading libraries and binding them into processes often involves umpteen other stages, and I would like to discover what the consensus is about how many stages of the process are considered part of a loader itself. Examples might be; in Windows NT, checking the exe or library is permitted to run against the rules of software restriction policies (SRP), checking the exe's acl for both read and execute permissions, checking certificates in the case of a device driver or where SRP requires certificate checks.

Amplifying the article: Loading device drivers is not mentioned and it certainly should be. There should be clear mentions of library loading, executable loading in process startup, device drivers and also loaders in a non-o/s context such as virtual machine interpreters or programming language interpreters which load and pre-parse or JIT-compile code. We should also mention the case of systems where decompression of the exe is carried out, and talk about systems where a loader has to check that dependencies can be satisfied before execution even starts, such as where required libraries are declared in the exe data structures.

What about talking about for example Java and .Net component loading too?CecilWard (talk) 19:09, 15 July 2009 (UTC)[reply]