Misplaced Pages

KDE Platform 4

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

In computer systems a loader is the part of an operating system that is responsible for loading programs and libraries . It is one of the essential stages in the process of starting a program, as it places programs into memory and prepares them for execution. Loading a program involves either memory-mapping or copying the contents of the executable file containing the program instructions into memory, and then carrying out other required preparatory tasks to prepare the executable for running. Once loading is complete, the operating system starts the program by passing control to the loaded program code.

#310689

48-507: KDE Platform 4 was a collection of libraries and software frameworks by KDE that served as technological foundation for KDE Software Compilation 4 distributed under the GNU Lesser General Public License (LGPL). KDE Platform 4 was the successor to KDElibs and the predecessor of KDE Frameworks . KDE Platform 4 is the only version of KDE Platform, and in 2013 it was replaced by KDE Frameworks 5 . KParts

96-414: A library is a collection of resources that is leveraged during software development to implement a computer program . Historically, a library consisted of subroutines (generally called functions today). The concept now includes other forms of executable code including classes and non-executable data including images and text . It can also refer to a collection of source code . For example,

144-402: A modular fashion. When writing code that uses a library, a programmer only needs to know high-level information such as what items it contains at and how to use the items – not all of the internal details of the library. Libraries can use other libraries resulting in a hierarchy of libraries in a program. A library of executable code has a well-defined interface by which the functionality

192-468: A Communication Pool (COMPOOL), roughly a library of header files. Another major contributor to the modern library concept came in the form of the subprogram innovation of FORTRAN . FORTRAN subprograms can be compiled independently of each other, but the compiler lacked a linker . So prior to the introduction of modules in Fortran-90, type checking between FORTRAN subprograms was impossible. By

240-559: A feature called smart linking whereby the linker is aware of or integrated with the compiler, such that the linker knows how external references are used, and code in a library that is never actually used , even though internally referenced, can be discarded from the compiled application. For example, a program that only uses integers for arithmetic, or does no arithmetic operations at all, can exclude floating-point library routines. This smart-linking feature can lead to smaller application file sizes and reduced memory usage. Some references in

288-415: A large number of editing options, but for a conventional application only a few of these are commonly employed. The load module format includes an initial "text record", followed immediately by the "relocation and/or control record" for that text record, followed by more instances of text record and relocation and/or control record pairs, until the end of the module. The text records are usually very large;

336-445: A load module of any practical size, and in the minimum possible time. Dynamic linking loaders are another type of loader that load and link shared libraries (like .so files , .dll files or .dylib files) to already loaded running programs. Where such shared libraries can be shared by multiple processes, with only one single copy of the shared code possibly appearing at a different (virtual) address in each process's address space,

384-587: A minimum memory model (as small as 44 KB on some versions of the OS, but 88 KB and 128 KB are more common). The OS's nucleus (the always resident portion of the Supervisor) itself is formatted in a way that is compatible with a stripped-down version of IEWFETCH. Unlike normal executables, the OS's nucleus is "scatter loaded": parts of the nucleus are loaded into different portions of memory; in particular, certain system tables are required to reside below

432-436: A program are loaded from individual shared objects into memory at load time or runtime , rather than being copied by a linker when it creates a single monolithic executable file for the program. Shared libraries can be statically linked during compile-time, meaning that references to the library modules are resolved and the modules are allocated memory when the executable file is created. But often linking of shared libraries

480-466: A program could use a library to indirectly make system calls instead of making those system calls directly in the program. A library can be used by multiple, independent consumers (programs and other libraries). This differs from resources defined in a program which can usually only be used by that program. When a consumer uses a library resource, it gains the value of the library without having to implement it itself. Libraries encourage code reuse in

528-589: A program or library module are stored in a relative or symbolic form which cannot be resolved until all code and libraries are assigned final static addresses. Relocation is the process of adjusting these references, and is done either by the linker or the loader . In general, relocation cannot be done to individual libraries themselves because the addresses in memory may vary depending on the program using them and other libraries they are combined with. Position-independent code avoids references to absolute addresses and therefore does not require relocation. When linking

SECTION 10

#1732790312311

576-544: A program's code are not actually copied into memory until they are actually used, and unused code may never be loaded into memory at all. In Unix , the loader is the handler for the system call execve() . The Unix loader's tasks include: In Microsoft Windows 7 and above, the loader is the LdrInitializeThunk function contained in ntdll.dll , which does the following: Some operating systems need relocating loaders , which adjust addresses (pointers) in

624-486: A single API. The current solution uses udev , NetworkManager and BlueZ (the official Linux Bluetooth stack). However, any and all parts can be replaced without breaking the application, making applications using Solid extremely flexible and portable. Work is underway to build a Solid backend for the Windows port of KDE based on Windows Management Instrumentation . Library (computing) In computer science ,

672-407: A suffix of .a ( archive , static library) or of .so (shared object, dynamically linked library). Some systems might have multiple names for a dynamically linked library. These names typically share the same prefix and have different suffixes indicating the version number. Most of the names are names for symbolic links to the latest version. For example, on some systems libfoo.so.2 would be

720-440: Is created (static linking), or whenever the program is used at runtime (dynamic linking). The references being resolved may be addresses for jumps and other routine calls. They may be in the main program, or in one module depending upon another. They are resolved into fixed or relocatable addresses (from a common base) by allocating runtime memory for the memory segments of each module referenced. Some programming languages use

768-413: Is invoked. For example, in C , a library function is invoked via C's normal function call capability. The linker generates code to call a function via the library mechanism if the function is available from a library instead of from the program itself. The functions of a library can be connected to the invoking program at different program lifecycle phases . If the code of the library is accessed during

816-430: Is performed during the creation of an executable or another object file, it is known as static linking or early binding . In this case, the linking is usually done by a linker , but may also be done by the compiler . A static library , also known as an archive , is one intended to be statically linked. Originally, only static libraries existed. Static linking must be performed when any modules are recompiled. All of

864-500: Is postponed until they are loaded. Although originally pioneered in the 1960s, dynamic linking did not reach the most commonly-used operating systems until the late 1980s. It was generally available in some form in most operating systems by the early 1990s. During this same period, object-oriented programming (OOP) was becoming a significant part of the programming landscape. OOP with runtime binding requires additional information that traditional libraries do not supply. In addition to

912-781: Is the component framework for the KDE Plasma desktop environment . An individual component is called a KPart . KParts are analogous to Bonobo components in GNOME and ActiveX controls in Microsoft's Component Object Model . Konsole is available as a KPart and is used in applications like Konqueror and Kate . Example uses of KParts: Solid is a device integration framework for KDE Platform 4 and its successor, KDE Frameworks . It functions on similar principles to KDE's multimedia pillar Phonon ; rather than managing hardware on its own, it makes existing solutions accessible through

960-540: Is theoretically possible to load and to relocate an entire executable within one revolution of the DASD media (about 16.6 ms maximum, 8.3 ms average, on "legacy" 3,600 rpm drives). For load modules which exceed a track in size, it is also possible to load and to relocate the entire module without losing a revolution of the media. IEWFETCH also incorporates facilities for so-called overlay structures, and which facilitates running potentially very large executables in

1008-541: The UNIX world, which uses different file extensions, when linking against .LIB file in Windows one must first know if it is a regular static library or an import library. In the latter case, a .DLL file must be present at runtime. Load-time All operating systems that support program loading have loaders, apart from highly specialized computer systems that only have a fixed set of specialized programs. Embedded systems typically do not have loaders, and instead,

SECTION 20

#1732790312311

1056-599: The z/Architecture mainframes. In OS/360 and descendant systems, the (privileged) operating system facility is called IEWFETCH, and is an internal component of the OS Supervisor, whereas the (non-privileged) LOADER application can perform many of the same functions, plus those of the Linkage Editor, and is entirely external to the OS Supervisor (although it certainly uses many Supervisor services). IEWFETCH utilizes highly specialized channel programs , and it

1104-576: The NOP CCW following the Read will be changed to a TIC, and loading and relocating will proceed using the next buffer; if not, then the channel will stop at the NOP CCW, until it is restarted by IEWFETCH via another special IOS exit. The three buffers are in a continuous circular queue, each pointing to its next, and the last pointing to the first, and three buffers are constantly reused as loading and relocating proceeds. IEWFETCH can, thereby, load and relocate

1152-514: The build of the invoking program, then the library is called a static library . An alternative is to build the program executable to be separate from the library file. The library functions are connected after the executable is started, either at load-time or runtime . In this case, the library is called a dynamic library . Most compiled languages have a standard library , although programmers can also create their own custom libraries. Most modern software systems provide libraries that implement

1200-460: The channel via a special IOS exit. At this point the processor enters the "disabled bit spin" loop (sometimes called "the shortest loop in the world"). Once that byte changes from its initialized value, the CPU exits the bit spin, and relocation occurs, during the "gap" within the media between the relocation and/or control record and the next text record. If relocation is finished before the next record,

1248-422: The code executes directly from ROM or similar. In order to load the operating system itself, as part of booting , a specialized boot loader is used. In many operating systems, the loader resides permanently in memory, though some operating systems that support virtual memory may allow the loader to be located in a region of memory that is pageable . In the case of operating systems that support virtual memory,

1296-556: The dependencies to external libraries in build configuration files (such as a Maven Pom in Java). Another library technique uses completely separate executables (often in some lightweight form) and calls them using a remote procedure call (RPC) over a network to another computer. This maximizes operating system re-use: the code needed to support the library is the same code being used to provide application support and security for every other program. Additionally, such systems do not require

1344-532: The engine would have a library of its own." In 1947 Goldstine and von Neumann speculated that it would be useful to create a "library" of subroutines for their work on the IAS machine , an early computer that was not yet operational at that time. They envisioned a physical library of magnetic wire recordings , with each wire storing reusable computer code. Inspired by von Neumann, Wilkes and his team constructed EDSAC . A filing cabinet of punched tape held

1392-459: The executable to compensate for variations in the address at which loading starts. The operating systems that need relocating loaders are those in which a program is not always loaded into the same location in the (virtual) address space and in which pointers are absolute addresses rather than offsets from the program's base address . Some well-known examples are IBM's OS/360 for their System/360 mainframes, and its descendants, including z/OS for

1440-536: The filename for the second major interface revision of the dynamically linked library libfoo . The .la files sometimes found in the library directories are libtool archives, not usable by the system as such. The system inherits static library conventions from BSD , with the library stored in a .a file, and can use .so -style dynamically linked libraries (with the .dylib suffix instead). Most libraries in macOS, however, consist of "frameworks", placed inside special directories called " bundles " which wrap

1488-433: The initial 64 KB, while other tables and code may reside elsewhere. The system's Linkage Editor application is named IEWL. IEWL's main function is to associate load modules (executable programs) and object modules (the output from, say, assemblers and compilers), including "automatic calls" to libraries (high-level language "built-in functions"), into a format which may be most efficiently loaded by IEWFETCH. There are

KDE Platform 4 - Misplaced Pages Continue

1536-439: The instantiated objects residing only in memory (although potentially able to be made persistent in separate files). In others, like Smalltalk , the class libraries are merely the starting point for a system image that includes the entire state of the environment, classes and all instantiated objects. Today most class libraries are stored in a package repository (such as Maven Central for Java). Client code explicitly declare

1584-958: The library to exist on the same machine, but can forward the requests over the network. However, such an approach means that every library call requires a considerable amount of overhead. RPC calls are much more expensive than calling a shared library that has already been loaded on the same machine. This approach is commonly used in a distributed architecture that makes heavy use of such remote calls, notably client-server systems and application servers such as Enterprise JavaBeans . Code generation libraries are high-level APIs that can generate or transform byte code for Java . They are used by aspect-oriented programming , some data access frameworks, and for testing to generate dynamic proxy objects. They also are used to intercept field access. The system stores libfoo.a and libfoo.so files in directories such as /lib , /usr/lib or /usr/local/lib . The filenames always start with lib , and end with

1632-463: The library's required files and metadata. For example, a framework called MyFramework would be implemented in a bundle called MyFramework.framework , with MyFramework.framework/MyFramework being either the dynamically linked library file or being a symlink to the dynamically linked library file in MyFramework.framework/Versions/Current/MyFramework . Dynamic-link libraries usually have

1680-532: The loader may not actually copy the contents of executable files into memory, but rather may simply declare to the virtual memory subsystem that there is a mapping between a region of memory allocated to contain the running program's code and the contents of the associated executable file. (See memory-mapped file .) The virtual memory subsystem is then made aware that pages with that region of memory need to be filled on demand if and when program execution actually hits those areas of unfilled memory. This may mean parts of

1728-501: The majority of the system services. Such libraries have organized the services which a modern application requires. As such, most code used by modern applications is provided in these system libraries. The idea of a computer library dates back to the first computers created by Charles Babbage . An 1888 paper on his Analytical Engine suggested that computer operations could be punched on separate cards from numerical input. If these operation punch cards were saved for reuse then "by degrees

1776-528: The mid 1960s, copy and macro libraries for assemblers were common. Starting with the popularity of the IBM System/360 , libraries containing other types of text elements, e.g., system parameters, also became common. In IBM's OS/360 and its successors this is called a partitioned data set . The first object-oriented programming language, Simula , developed in 1965, supported adding classes to libraries via its compiler. Libraries are important in

1824-488: The modules required by a program are sometimes statically linked and copied into the executable file. This process, and the resulting stand-alone file, is known as a static build of the program. A static build may not need any further relocation if virtual memory is used and no address space layout randomization is desired. A shared library or shared object is a file that is intended to be shared by executable files and further shared object files . Modules used by

1872-472: The names and entry points of the code located within, they also require a list of the objects they depend on. This is a side-effect of one of OOP's core concepts, inheritance, which means that parts of the complete definition of any method may be in different places. This is more than simply listing that one library requires the services of another: in a true OOP system, the libraries themselves may not be known at compile time , and vary from system to system. At

1920-430: The program linking or binding process, which resolves references known as links or symbols to library modules. The linking process is usually automatically done by a linker or binder program that searches a set of libraries and other modules in a given order. Usually it is not considered an error if a link target can be found multiple times in a given set of libraries. Linking may be done when an executable file

1968-415: The relocation and/or control records are small as IEWFETCH's three relocation and/or control record buffers are fixed at 260 bytes (smaller relocation and/or control records are certainly possible, but 260 bytes is the maximum possible, and IEWL ensures that this limitation is complied with, by inserting additional relocation records, as required, before the next text record, if necessary; in this special case,

KDE Platform 4 - Misplaced Pages Continue

2016-424: The rough OOP equivalent of older types of code libraries. They contain classes , which describe characteristics and define actions ( methods ) that involve objects. Class libraries are used to create instances , or objects with their characteristics set to specific values. In some OOP languages, like Java , the distinction is clear, with the classes often contained in library files (like Java's JAR file format ) and

2064-424: The same time many developers worked on the idea of multi-tier programs, in which a "display" running on a desktop computer would use the services of a mainframe or minicomputer for data storage or processing. For instance, a program on a GUI-based computer would send messages to a minicomputer to return small samples of a huge dataset for display. Remote procedure calls (RPC) already handled these tasks, but there

2112-521: The sequence of records may be: ..., text record, relocation record, ..., control record, text record, ...). A special byte within the relocation and/or control record buffer is used as a "disabled bit spin" communication area, and is initialized to a unique value. The Read CCW for that relocation and/or control record has the Program Controlled Interrupt bit set. The processor is thereby notified when that CCW has been accessed by

2160-528: The status of the "next big thing" in the programming world. There were a number of efforts to create systems that would run across platforms, and companies competed to try to get developers locked into their own system. Examples include IBM 's System Object Model (SOM/DSOM), Sun Microsystems ' Distributed Objects Everywhere (DOE), NeXT 's Portable Distributed Objects (PDO), Digital 's ObjectBroker , Microsoft's Component Object Model (COM/DCOM), and any number of CORBA -based systems. Class libraries are

2208-521: The subroutine library for this computer. Programs for EDSAC consisted of a main program and a sequence of subroutines copied from the subroutine library. In 1951 the team published the first textbook on programming, The Preparation of Programs for an Electronic Digital Computer , which detailed the creation and the purpose of the library. COBOL included "primitive capabilities for a library system" in 1959, but Jean Sammet described them as "inadequate library facilities" in retrospect. JOVIAL has

2256-475: The suffix *.DLL , although other file name extensions may identify specific-purpose dynamically linked libraries, e.g. *.OCX for OLE libraries. The interface revisions are either encoded in the file names, or abstracted away using COM-object interfaces. Depending on how they are compiled, *.LIB files can be either static libraries or representations of dynamically linkable libraries needed only during compilation, known as " import libraries ". Unlike in

2304-467: Was no standard RPC system. Soon the majority of the minicomputer and mainframe vendors instigated projects to combine the two, producing an OOP library format that could be used anywhere. Such systems were known as object libraries , or distributed objects , if they supported remote access (not all did). Microsoft's COM is an example of such a system for local use. DCOM, a modified version of COM, supports remote access. For some time object libraries held

#310689