Platform (computer)

from Wikipedia, the free encyclopedia
Basic concept of a platform: any platform (blue) at the top, which is placed on three different "surfaces"

A platform - also known as a layer or level - describes a uniform basis in computer science on which application programs can be executed and developed. It is located between two components of a computer system . The component below is not visible to the component that uses the platform . The same component can therefore be operated on different "subsurfaces" via one platform. There are a variety of platforms and platform concepts in the IT sector.

Goal setting and methods

The idea behind a platform is the abstraction of complicated details for application software or its developer.

On the one hand, these details can be unknown properties of the execution environment in which application software will be used in the future that are or may not be known at the time the application is developed. These properties of the execution environment can be, for example, the exact type and performance of the hardware components or with which operating system the application will be operated by the user at some point.

On the other hand, the motivation for an abstraction can also be known complexity (e.g. unstandardized hardware, competing manufacturer APIs ) that is to be reduced in order to enable developers to develop applications faster, cheaper or easier.

This simplification can be achieved by providing the application developer with a more abstract functional model of concrete functionality, typically in the form of a programming interface (API), which envelops the underlying functionality . For the resulting application, this is typically done in the form of a dynamically interpreted runtime environment (e.g. JRE , browser ) or a binary ABI for known software functions (e.g. Win32 , DirectX ).

One quality that these abstraction layers can offer is generality, usually referred to as compatibility . This can refer to the breadth , i.e. the amount of different, abstracted details, as well as to the stability of the platform over time. Compatibility over time can mean ensuring downward compatibility in the case of a further development of a platform or the manufacturer's assurance that with the emergence of new abstractable "details" (e.g. new operating systems, new hardware) these will be integrated into the platform ( upward compatibility ).

Platform types

Possible components of a platform are a computer architecture , programming language , libraries and runtime environments.

Hardware platform

When it comes to platforms, a distinction can be made between software and hardware platforms. A hardware platform and the machine level called describes a specific computer art or [Processor] family . The machine level is mainly given by a specific computer or processor architecture and, from a logical point of view, is at the very bottom - below the application level .

A processor architecture platform uses a single machine language , data word size, byte order , etc. An example of this is the widespread x86 - architecture .

How the individual commands of this machine language are processed internally in the microprocessor (e.g. with micro-ops ) can, however, differ greatly within the same platform. Only the end results that the commands provide remain the same.

Hardware platforms can roughly divided into CISC - and RISC - architectures are divided. With current processor architectures, however, the boundaries between these two types of architecture are becoming increasingly blurred.

Software platform

The so-called software platforms , also known as the application level or layer (see also OSI model ), are distinguished as follows.

Binary interface-based platform

Compatibility over time can be achieved, for example, via stable binary interfaces of function libraries with which the platform is accessed. If the platform is further developed, only the platform provider must ensure that compatibility is maintained. He then has to distribute the new version of his platform library ; changes to the application program ( recompilation or adaptation) by application developers or configuration changes by users are not necessary.

Source code based platform

In addition to the above concept of a platform based on binary compatibility, which enables software that has been created to run further, there is also the concept of compatibility via the portability of the source code of an application program. Here, no long-term or broad-based executability of the application program compilations is guaranteed, but compilability with a wide range of underlying hardware, program libraries and software APIs, also called platform independence. Disadvantages are that the compilation process then has to be carried out more frequently and above all by the user or application developer, which is sometimes a complex and error-prone process. Creating portable software for such a platform is also a problem. Likewise, the need for the source code to be available to the user can be an obstacle since, for example, disclosure of proprietary software is uncommon. This is why this concept of source code-based compatibility is predominant, especially in the open source area and with Unix-like operating systems , while binary compatibility is dominant in the case of Windows or Mac operating systems , for example .

Operating system as a platform

For example, it allows a software platform - as the Win32 API and other similar integrere in operating systems interfaces - software developers , applications to write that on varying hardware such as processors from different manufacturers, different graphics cards , various peripherals , etc. are functional. Typically, however, such applications are compiled into binary programs consisting of machine commands , so they can only function on specific hardware, i.e. they are based on this hardware platform. This procedure can be viewed as a compromise between efficiency and degree of abstraction, as it saves time- consuming conversion at runtime .

Runtime environment as a platform

In the case of dynamically interpreted runtime environments, the application is further abstracted from the hardware. This means that commands and data are transferred to a runtime environment or a service and are only interpreted there at runtime or translated into the corresponding machine language. Furthermore, various underlying operating systems , i.e. other software platforms, can also be abstracted away with a runtime environment (e.g. JRE or web browser ) .

Non-technical aspects of platforms

marketing

For advertising, brand names are often summarized in a simplistic way, as platforms that actually need to be differentiated from a technical point of view. A well-known example of this is the “ Macintosh platform”, the technical platforms of which can differ fundamentally depending on the generation. This simplistic view has partially passed into linguistic usage and public perception.

So advertises z. B. Apple with the “ Macintosh ” or “Mac” platform, although over the entire period of existence practically all platforms that make up the Macintosh have been replaced (sometimes several times). From a technical point of view, Macintosh consists and consisted of very different and sometimes incompatible hardware and software platforms. (Macintosh used or uses 680x0 , POWER and x64 . Software interfaces and standards used by Apple operating systems are or were Carbon , Cocoa , POSIX , SUS , GNU software environment , JRE etc.). In order to guarantee users a smooth change of platforms, Apple used temporary approaches such as fat binaries or emulators . As a result, the entire product family continued to be perceived by the public as a uniform platform.

The same applies to the “ Windows ” brand advertised by Microsoft . Although the changes were never as extensive as they were with Macintosh, Windows is not a unified platform either. (It used or uses the platforms x86 , x64 , ARM , MIPS , PowerPC and Alpha and provides or provides the platforms DOS , Win16 , Win32 , Win64 , Native API , Windows CE , .NET , POSIX , OS / 2 and other applications Available.) For example, the Win32 and Windows CE APIs are only compatible to a very limited extent. All the DOS or Windows NT - kernel -building Windows products contain multiple platforms, which for applications backward compatibility of partially up to 30 years reached (in the case of Win16) was.

openness

Platform manufacturers have different approaches to the openness and closeness of their platforms. This concerns z. B. the development model, cost model or the degree of openness or freedom that is granted when using it at different levels.

Examples

Application interfaces and operating systems

As an application interface can essentially one by the operating system introduced or included programming interface ( English Application Programming Interface , short-API) are called. However, there are also cross-platform APIs that are available on multiple operating systems as a runtime environment and often have to be installed later.

Runtime environments

Server platforms

hardware

  • AMD Am29000
  • POOR
  • Atmel AVR
  • DEC Alpha (64-bit)
  • IBM 801
  • IBM System / 360 and System / 370 (24-bit addressing , 1964 and 1970)
  • IBM System / 390 (31-bit addressing, 1990)
  • IBM System z (64-bit addressing, downward compatible with System / 390, / 370 and / 360, 2000)
  • Intel 4004 (4-bit data width with 4-bit data bus, 12-bit address space with 4-bit address bus, 1971)
  • Intel 4040 (4-bit data width with 4-bit data bus, 13-bit address space with 4-bit address bus, 1974)
  • Intel 8008 (8-bit data width with 8-bit data bus, 14-bit address space with 8-bit address bus, 1972)
  • Intel 8080 (8-bit data width with 8-bit data bus, 16-bit address space with 16-bit address bus, 1974)
  • Intel x86 (Intel 80x86 and compatible processors)
  • Intel i960
  • Intel Itanium or IA-64 (64-bit data width, 64-bit address space, not compatible with IA-32 and 16-bit x86)
  • MIPS
  • Motorola 680x0 (from 2004 Freescale , from 2015 NXP )
    • 6800 and 6809 (Motorola, 8-bit data bus, 8-bit address bus, 1974)
    • 68000 and 68010 (Motorola, 16-bit data bus, 24-bit address bus, 1979)
    • 68008 (Motorola, 8-bit data bus, 20-bit address bus)
    • 68012 (Motorola, 16-bit data bus, 31-bit address bus)
    • 68020 and 68330 (Motorola, 32-bit data bus, 32-bit address bus, 1984)
    • 68030 , 68040 and 68060 (Motorola, 32-bit data bus, 32-bit address bus, from 1987)
    • ColdFire (Freescale, 68060 design, from 2004)
    • Dragonball (Freescale, formerly MC68328 from Motorola, from 1995)
  • Motorola 88000
  • OpenRISC
  • PDP-1 , PDP-4, PDP-7 , PDP-9 and PDP-15 (18-bit)
  • PDP-5, PDP-8 , PDP-12, PDP-14 and PDP-16 (12-bit)
  • PDP-6 and PDP-10 (36-bit)
  • PDP-11 (16-bit)
  • PA-RISC
  • power
  • SPARC
  • SuperH
  • VAX (32-bit)

See also

literature

Individual evidence

  1. ↑ Michael Simms: Handling misbehaving libraries in binary products ( English ) Linux Game Publishing . August 18, 2009. Archived from the original on February 22, 2014. Retrieved January 15, 2012: “ It is a bit of an arcane artform, making a game that runs on all Linux versions. […] [Libraries] will load their own dependencies in a way we cannot control. The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn't work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world. "
  2. ↑ Troy Hepfner: Linux Game Development Part 2 - Distributable Binaries ( English ) gamedev.net. October 1, 2007. Archived from the original on October 13, 2007. Retrieved on December 19, 2011: “ Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem [...] "
  3. ↑ Ian Murdock : On the importance of backward compatibility ( English ) January 17, 2007. Archived from the original on January 14, 2012. Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved January 4, 2012. @1@ 2Template: Webachiv / IABot / ianmurdock.com
  4. ^ Raymond Chen : What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? ( English ) In: The Old New Thing . October 15, 2003. Archived from the original on July 3, 2004. Retrieved on January 4, 2012.
  5. ↑ Simon Peter: AppImageKit Documentation 1.0 (PDF; 38 kB) PortableLinuxApps.org. Pp. 2-3. 2010. Archived from the original on November 29, 2010. Info: The archive link has been inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved July 29, 2011: " A critical distinction between the approach known from Windows and the Mac and the one known from UNIX and Linux is the" platform ": While Windows and the Mac are seen as platforms to run software on, most Linux distributions see themselves as the system that includes the applications. " @1@ 2Template: Webachiv / IABot / portablelinuxapps.org