Application Programming Interface


  • Main
  • Wikipedia
  • All Subpages
  • Create New
    /wiki/Application Programming Interfacework
    The wonderful thing about standards is that there are so many of them to choose from.
    —The UNIX-HATERS Handbook

    An API, or Application Programming Interface, is a communication protocol between two sets of code. It's like a language; both parties agree that words have a particular meaning, so that they can talk to each other.

    Why? Because Software is Hard.

    Hardware makers do their best to not agree on how hardware should be made. Power requirements & connections have to be standardized, but how do you think they could actually make such a great XYZ5000 if they actually told you how they did it?

    A driver implements a particular API that the operating system requires for interfacing with a certain kind of hardware. So hardware makers write 'software drivers' that allow your lowly computer to understand & communicate with the awesomeness that is their XYZ5000, at least on a basic level.

    So your computer can now handle the hardware, be it Microsoft Windows, Mac OS, or UNIX.

    However, Microsoft, Apple, or the various makers of the various *nix's are not stupid; they know there's malicious (or just poorly written) code out there. They are not just going to let any old program willy talk to drivers. Especially drivers relating to drawing stuff on the screen. The OS needs to know about this sort of thing, and it needs to manage access to that hardware.

    So the OS exposes an API that allows other programs to talk to the hardware.

    OpenGL and Direct3D are the two available APIs for dealing with 3D graphics. An interesting aspect of both APIs is that, because they directly access hardware, their features are very reliant on the underlying code. Previous graphics cards may work, as there's usually a built-in render path using older versions, but you usually won't see the new features. There are also programs which implement the API in software, although the featureset and performance is always well under what you can find in hardware.

    Frequently, how efficiently these pieces of Hardware work with APIs depend not only on the hardware, but on how nicely they play with APIs (part of software drivers). The amount of work put into this, in part, is determined by how much money they expect to make from them. In the future. So old hardware slowly migrates to the great big garbage dump in the sky, because there is no money to be made.

    There have also been cases of newer graphics cards omitting or otherwise breaking little-used features that some games during the Direct3D 7 and prior era used, either at the driver or hardware level, so don't expect perfect backwards compatibility. Sometimes you might just have to build an old computer to run a suitably old game well, or even at all.

    Direct3D

    Direct3D is Microsoft's baby, and, thus, it's only available through Microsoft Windows operating systems, the Xbox consoles, and through very careful and questionably legal reverse engineering schemes. It is often referred to as DirectX even though DirectX is an entire suite of APIs for dealing with more than just rendering (sound, input).

    The current popular versions of DirectX are 9.0c and 11. Direct X 9.0c survives because the Xbox 360 runs on it, with a few custom features. DirectX 11, however, requires Windows Vista SP2 (with some further updates) or Windows 7. While DirectX officially only operates in Windows and on the XBox systems, WINE and Cedega groups have gotten some features to work fairly well on Linux.

    In case you're wondering where's DirectX 10, it was released with Windows Vista. Since it offered very few quality advantages over DirectX 9.0c and was only compatible with Windows Vista, nobody really cared about it.

    OpenGL

    OpenGL is Direct3D's primary competitor, and in many ways the tool of choice for cross-platform gaming (though, in truth, it is the only tool for cross-platform game development). OpenGL is a graphics API, so it only technically competes against Direct3D, the 3D portion of DirectX; most Windows games that use OpenGL use the non-graphics part of Direct X for other tasks, while other operating systems use different APIs for other tasks (for example, OpenAL for audio acceleration). Many individuals feel it's much easier to program in than DirectX. The open standard certainly made it more expandable, and many OpenGL games such as City of Heroes are made up of more extensions than original standard code.

    While OpenGL can work with a variety of operating systems, it does have some downsides. Since DirectX is the API of choice for games created for Windows, many graphics cards have horrible OpenGL support. Earlier ATI and Intel embedded graphics chips in particular might run a DirectX game well, but crawl when using OpenGL. After AMD got ATI, though, having fresh cards work with any fresh software eventually ceased to be a problem.

    The latest version of OpenGL is 4.4. For older hardware (hardware limited to DirectX 10), there is version 3.3. For REALLY old hardware that is (huge fake GASP) 3+ years old, there is OpenGL 2, which roughly corresponds with DirectX 9.

    Running alien software

    An API is an interface, so it's only natural that people tried to let a program interact with a translation layer, resembling an OS sitting on top of the native OS - thus allowing a program to work under an OS it wasn't made for, as long as less flexible things (like CPU commands) are all the same. Naturally, x86 is the most interesting for a majority of users, as Windows and Unix (Linux and OS X) are the most desirable targets. True emulators and virtual machines eat a lot of resources, but API translators are much less voracious. Results are good, though this approach isn't a universal silver bullet and some performance is always sacrificed for translation.

    • Cygwin is a Unix-like environment for Windows. It's not a way to run native Linux apps on Windows. You have to rebuild your application from the source if you want it to run on Windows. However, apps for Linux tend to be open source, so "rebuild" usually means just one or two extra commands as part of the installation process. It's free and open source.
      • Then, there's MinGW, Minimalist GNU for Windows. Theoretically, it functions the same way as Cygwin does (although technically, there is one major difference that hampers its compatibility). Of course, in the open source world that Linux resides in, friendly competition is good.
    • andLinux, on the other hand, is an actual Linux environment for Windows. Unlike Cygwin, it can actually run Linux programs on Windows, as it actually runs a modified Linux kernel as a compatibility layer. andLinux is based on Ubuntu Linux, and is able to use the same packages. It's free and open source, as befits a Linux distribution.
    • Wine is a translation layer (a program loader) capable of running Windows applications on Linux and other POSIX compatible operating systems (including post-2005 Intel Macs). It naturally has OpenGL and even limited DirectX support. Application Database has information on more than 10,000 applications' compatibility with Wine. It, too, is free and open source.
    • Cedega (formerly known as WineX) is a commercial "run Windows games on Linux" translation software, naturally focused on DirectX support. It also has some sort of limited, but free, open source demo version. Cedega was retired in February 2011, but it's back-end was rechristened Game Tree Linux and became completely free (albeit still requiring one to sign up for the service). The company behind Cedega, Transgaming, also offers a technology called "Cider" to quickly port PC software to the Mac OS X platform.
    • CodeWeavers' CrossOver products were Cedega's primary competitor. Like Cedega, they offer Wine distributions that have been modified with proprietary code. Unlike Cedega, they offer different versions of their software for different purposes. They also offer a version of their product that allows Intel Mac OS X users to run windows apps without an emulator or dual-booting. CodeWeavers is quite popular in the open-source community, as much of their proprietary code are often released back into the open-source WINE project.
    • OpenGL does not sit and wait for better support, there are extensions that translate or emulate DirectX functionality (mainly aimed for Wine), up to translation of DXBC code to GLSL, with the long-term goal of converting any D3D shaders into GL.


      This article is issued from Allthetropes. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.