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 not
to 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.
The grandaddy of all API, more or less. It defines software commands and behavior in order for software written for UNIX to be compatible across its variants. POSIX is so in depth, simply following it allows one to create an OS and complying with it 100% makes it a bona-fide UNIX OS. Otherwise, it's a UNIX-like OS, which may have behave similar to, but not strictly the same as a UNIX OS. Related to POSIX is the ANSI C standard, which POSIX compliant OSes implement.
Win16, Win32, Win64
Windows' API for 16-bit, 32-bit, and 64-bit software respectively. This is the core API a program must comply with in order to retain compatibility across various Windows versions. In fact, a 16-bit application that came with Windows 2.0 will work in 32-bit versions of Windows 7 or even 8 (though they won't work on 64-bit versions, as 64-bit versions drop Win16 support).
Mac OS X's API for its applications in addition to compliance with POSIX.
A new set of API from Microsoft launched with Windows 8. It was designed in order to ease portability of applications across all Windows enabled devices, which included Windows 8 itself, Windows Phone 8, and Windows RT (which shares this API's other name).
The first most widespread graphics API. It was developed by video card maker 3dfx for use in their cards. It was one of the most widely used APIs until about 1998 or so, when DirectX and OpenGL were mature enough and the fact the API only worked on 3dfx cards, while NVIDIA and ATI were coming out with their own hardware.
Much love still remains for this API, with people creating "Glide Wrappers" for games that don't officially support it.
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), of which Direct3D is just one member.
The current popular versions of DirectX are 9.0c and 11. Direct X
9.0c survives because the Xbox 360
runs on it and many ports
from the 360 to Windows run on it, and thus Windows XP. DirectX 11 requires Windows Vista SP2 (with some further updates), Windows 7, or Windows 8 and compatible video cards. 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. Direct3D 12 is due in 2015, offering closer-to-metal programming similar to AMD's Mantle.
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 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. However 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 nowadays the API of choice, many consumer-oriented graphics cards have horrible OpenGL support (although this is usually the fault of the card's driver - the card itself has no real concept of Open GL
or Direct X
, only the machine language supported by the GPU. This is the reason why the same card may have excellent Open GL
performance if run in Linux than on Windows). Earlier ATI and Intel embedded graphics chips in particular might run a DirectX game well, but crawl when using OpenGL or not even support it at all. 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.5. For older hardware (hardware limited to DirectX 10), there is version 3.3. For REALLY old hardware that is (huge fake GASP) 5+ years old, there is OpenGL 2, which roughly corresponds with DirectX 9. And then there's OpenGL 1, used recently only by Intel in their jokes of pre-HD Graphics integrated video cards. Only on Linux (yes, really) did these cards get OpenGL 2 support, and even then, it was spotty.
For embedded applications, such as cell phones and even the PlayStation
3 and Vita, there's a special version of OpenGL called OpenGL ES. It's currently on version 3.0 and contains similar features the OpenGL of the same version.
Other Graphics API
- MeTal: An obsolete API used by S3 Graphics for their Savage series of 3D cards, released shortly after Glide came out. Needless to say, the S3 cards' poor 3D performance and the popularity of Glide overshadowed it, and very few games supported it. Nowadays it's only remembered for the extremely-efficient S3TC texture compression algorithm that was part of the API.
- Metal: This time spelled properly, is Apple's mobile 3D graphics API that is unique to iDevices running iOS8.
- Mantle: An upcoming cross-platform graphics API spearheaded by AMD. It is said to be very much faster than DirectX and OpenGL by simplifying the job the CPU needs to do (the CPU still needs to gather up jobs for the GPU to do), but only supports AMD hardware for obvious reasons. Due to the other manufacturers not wanting to license the API and many game developers ignoring it, AMD has declared the API a failure and obsolete in early 2015, and stop work on it.
- GDI: Microsoft's 2D API for drawing graphics in Windows. It was primarily used in Windows 3.0 up until Windows XP (although using an upgraded version called GDI+, which was also backported to Windows 9x, ME and 2000 for use with Microsoft's Office suite). It is supported in Windows Vista and beyond for compatibility reasons.
- DirectDraw: A 2D API that was part of DirectX, but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, DirectDraw is mostly used in 2D games. Like its successor, Direct2D, it offers hardware acceleration, albeit at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like its successor, Direct2D- understandable because compute-capable graphics cards doesn't exist at the time.
- Direct2D: GDI's and DirectDraw's successor. It offers better performance over GDI and allows for even hardware acceleration via compute-capable GPUs, but it is only available on Windows Vista and later.
- WinG: Microsoft's first foray into gaming graphics API, typically found on 16-bit Windows 3.1 systems. It never got popular and one event caused by it singlehandedly caused Windows to be branded a lousy platform for gaming until Direct X was created. Remember The Lion King for Windows Porting Disaster? Yeah, the core cause of all the BSODs in the game is this API, which the engine uses, combined with an untested graphics driver.
- Mac OS Classic has the Toolbox API calls, since most of the graphical code resided within the Macintosh BIOS itself.
- There is also QuickDraw which is an accelerated graphics API for Classic Macs. Like DirectDraw, it supported special accelerator cards. Also available for OS X under Carbon, but has been deprecated.
- Quartz: The Macintosh API for rendering graphics. Unsurprisingly, it is only available on Apple Macintosh computers running OS X. A revised version with hardware acceleration called Quartz Extreme was introduced with OS X 10.2 and persists to this day.
- Cocoa, a GUI API framework that sits atop Quartz.
- Carbon: A transitional API meant to help Classic developers port their code to Cocoa before Classic was depreciated fully. Carbon itself was depreciated with the death of Classic.
- SDL: The Simple DirectMedia Layer- a large API for handling graphics (with delegation of 3D rendering to OpenGL), sound, input and networking. Highly favored by commercial game companies due to ease of use and that porting games that are written around the Direct X API to other platforms using SDL requires very little effort note . Valve Software's Linux port of Steam and various Steam games, for example, use this API heavily.
- GGI: General Graphics Interface- another API specialized in rendering graphics, with a sister library, GII, the General Input Interface, for handling input. Programs that uses it are less common than SDL, but due to its speed, it has a fanbase.
- Curses: An API for drawing GUI elements like text boxes, check boxes and menus in ASCII. Superseded by:
- NCurses: The New Curses library, which is basically an improved version of the Curses API.
- Actually, Unix systems are just full of separate APIs that handle drawing GUI elements, due to the Choice is good mantra (see this page's quote). All of them being methods that sit above the X Windows, Mir or Wayland GUI server, which also consists of a server, a set of tools, and an API.
- wxWidgets, formerly wxWindows: Used by the popular open source audio editor software Audacity, among many others.
- Motif and its spinoffs LessTif and OpenMotif: The former is usually found on commercial Unix systems, while the latter two is less commonly used outside of by a small circle of Unix veterans.
- GTK+: A very commonly used Unix Graphics API. Around half of the mainstream programs written for Unix platforms tend to use this API, or at very least support rendering to this API, and several desktop environments (notably Gnome, XFCE and Mate) are written around the API. It has also been ported over to Windows and Mac OS X (and used to help port Unix software to said platforms- thanks to GTK+, you can run a ported version of the excellent GIMP image editor on Windows and Macs if you're one of those who just dislike Adobe).
- Qt: Most programs written for the KDE desktop environment uses this. However, some Windows program uses it too- notable users include children toy manufacturers like Leap Frog for their Leapfrog Connect software for managing and customizing smart toys put out by said company, V-Tech for their Learning Lodge software for the same reason as Leapfrog, and several mobile broadband modem manufacturers (i.e. Huawei and ZTE) for their driver's UI. And of course, Nokia note uses it for their smartphone management software, Ovi Suite, up until Microsoft bought their phone division. Also, EA uses it for Origin's user interface.
- GnomeUI, which is actually an expansion built atop GTK+
- XAW: the X Athena Widgets API. Ships out of the box with most X Windows server distributions to provide a defacto API for the GUI of the utilities and sample applications that shipped with X Windows.
- AAlib: The ASCII Art Library - An API used for displaying images on a text-based terminal, using the very clever method of ASCII Art. In reality, it's mostly used by hackers to watch videos in a text based terminal just for the geek cred.
- libCACA: Unfortunate name aside, the API improves on AAlib by being able to display color ASCII Art (AAlib is only capable of black and white).
The DirectX component that is responsible for rendering sound in 3D and 2D spaces, as well as mixing audio. Supported in all Windows versions before Windows Vista, where Microsoft rewrote the audio subsystem.
One mixing API that heavily relied on DirectSound was Creative Lab's EAX.
Originally developed in 2000 by Loki Software (of SDL fame mentioned above) to help port Windows games to Linux. Loki shuttered due to the poor sales of it's ports and it was picked up by Creative Technology with support from Apple and a few other groups. It used an open source license until version 1.1, when it became proprietary. The most exposure people probably had with OpenAL is with the ALChemy software in Creative's cards. This was due to Microsoft axing DirectSound support in Windows Vista and the software was used as an OpenAL wrapper.
Despite its proprietary status, it has several forks, including an open source one.note
OSS is the defacto API standard (and driver set) for most Unix
flavors, except under Linux where it has been superseded by ALSA (and OpenBSD, also out of licensing spite, which even though is using a driver API that is binary-compatible to the official OSS API, is not maintained by the official OSS team.note
). Both OSS and ALSA actually maintains a friendly competition for each other and actually have compatibility libraries to allow support for the competing API (OSS comes with optional libraries to allow for ALSA API compiled programs support- should you decide to throw ALSA out in favor of sticking to OSS on Linux for whatever reason, while ALSA also comes with optional libraries to support programs compiled against the OSS API). And then there's the bunch of Mixer APIs (see Mixer API
below) that sit above it perform audio mixing since OSS has no ability to do that on their own yet.
A competing standard and driver set found on most modern Linux distributions, which was created due to a licensing dispute with the creators of OSS note
. However, even with the dispute, the ALSA team are actually in friendly terms with the OSS team and even offers a compatibility layer to let programs that require OSS to run on ALSA systems, and allow OSS to offer a compatibility library for providing ALSA program support in OSS. Like OSS, there is a bunch of Mixer APIs that sit above it (again, see Mixer API
below) to do mixing as ALSA has no ability to do mixing by its own yet either.
The Macintosh API for handling audio, found on Classic Mac OS Systems. Also available for OS X under Carbon, but like QuickDraw is deprecated. Again, exclusive to Apple Macintosh
The Macintosh API for handling audio, found on Mac OS X Systems. Still, exclusive to Apple Macintosh
The classic Windows API for handling audio, having existed since at least Windows 3.0 and probably not going away anytime soon. Commonly called waveOut after what the function names for playing sound all start with.
A portable wrapper API - it just passes everything on to whatever your system's real API is, but largely hides the differences from the program using it.
A subclass of the Audio API, Mixer APIs act as a higher level API that provides the ability to mix audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in Unix
systems due to OSS and ALSA being incapable of handling multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.
Some of them are also used for routing audio to a sound card on a different computer on the network, allowing for some interesting scenarios (for example, a thin terminal with X and NAS support is able to actually stream audio and video from a remote server, much like VNC
or Windows Remote Desktop
- NAS: The Network Audio System. Primarily found in Sun's SunOS (for which it was initially developed for) and Solaris systems, although it can be compiled and run on other Unix systems that uses OSS or has OSS compatibility.
- ESD: The Enlightened Sound Daemon: Largely forgotten nowadays, it was the predecessor of Gnome's own PulseAudio system, and largely abandoned after the schism between Gnome and the Enlightenment Project.
- aRts: The mixer daemon and API used by KDE prior to version 4.
- PulseAudio: The mixer daemon and API found in Gnome 2.10 and higher, replacing ESD. Comes with a set of ESD compatibility libraries to ensure older programs written for ESD will still run on it.
- Phonon: The mixer daemon and API found in KDE 4 and higher, replacing aRts.
- JACK: A low latency mixer daemon and API targeted at applications that requires fast audio mixing, for example professional music and audio programs like RoseGarden and Hydrogen. Very CPU intensive and works best with special realtime kernels in most Linux distributions.
- SndIOd: Found in BSD systems like OpenBSD, just because they do not agree with the licensing used by the other mixers.
One of the first API specifically made for general purpose GPU support developed by NVIDIA. They were pretty big pushers for the GPGPU idea after releasing the Ge Force
Initially developed by Apple with support from AMD, IBM, Intel, and NVIDIA. It was later submitted to the Khronos Group (who maintain OpenGL). This is largely CUDA's main competitor in terms of GPGPU compute API.
Microsoft's answer to both CUDA and OpenCL, although it's not frequently used since GPGPU is a technology mostly used by experimental supercomputing server farms, which usually prefers Unix
that OpenCL and CUDA natively supports.
It however enjoys usage in games to perform things such as physics calculations and post-processing antialiasing, mostly because it's already part of the DirectX library.
- DirectInput: The DirectX component that is largely responsible for handling input. Partially superseded.
- XInput: The new API that has partially superseded DirectInput. Has a Broken Base due to the fact that the gamepad part of the API is specialized for the Xbox 360 controller and thus does not work well with other USB gamepads, particularly those with more buttons and axes compared to the Xbox 360 controller.
- Video For Windows: An early API for Windows 3.1 meant to be used to display videos in programs. Many third party programs and games relied on it. It was eventually replaced by:
- ActiveMovie: You may have heard of it- it was a short-lived API that was meant to be used to implement FMV cutscenes in games among other things. It was later rechristened DirectShow. Egregiously, games that used earlier versions of the API will have problems playing back their FMV on systems that run later versions of DirectX. It has since been replaced by:
- Media Foundation: A new API for media playback in programs.
- QuickTime is widely known as Apple's media player for Macs, but it also provide a set of APIs to allow for third party programs and games to use it for playing back FMV cutscenes, videos or even other media types. Myst is one game that's known to have used the API heavily. Like many other APIs from the Classic Mac OS days, this API is deprecated in favor of:
- QTKit: A short-lived 64-bit capable wrapper around QuickTime released around the time of Mac OS X Tiger (which came out in the era of the G5 Macs, which were 64-bit systems), and later:
- AVFoundation: a new API for multimedia features first released with Mac OS X Lion.
- FFMpeg: A popular API used by many Media Player and Multimedia Editing programs in Unix, and also used by some games for the platform. It has also been ported to other Unix platforms, as well as to Windows and Mac OS.
- SMPEG: (Simple MPEG) From Loki Software (creators of the abovementioned SDL and OpenAL frameworks), this API-video codec combo was created to simplify implementation of FMV playback in games, but could also be used to create MPEG-1 playback software (for example, for playing the not-popular-in-the-USA VideoCD format). Due to the fact that this API was licensed very differently from the SDL and OpenAL (it was sold as opposed to OpenAL and SDL which were freely given away), it failed to gain popularity and developers took to using the freely-licensed GStreamer and the abovementioned FFMpeg framework) instead.
Running foreign 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.
- For those who likes living in the 80s, there is DJGPP, which is a port of the Unix-like environment to DOS-based systems. However, it has not been updated for years.
- 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 its 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.
- ARDI Executor allows you to run old Mac software (pre-System 7) on an operating system of your choice. Originally a paid app, it is now free and open source. Development seems to have crawled to a halt, with no one picking up the project. What differentiates this from similar software is the fact that it also emulates a 68k processor used in older Macs if the computer didn't have one, as opposed to requiring said processor in the computer (so it is in fact a semi-emulator).
- There was once talks of implementing a Mac OS Classic translation layer for PowerPC Linux systems (for example, newer Amiga boxes, Macs converted to run Linux, and IBM workstations), like Wine for Intel Unix boxes. It was to be called Mace. The project apparently went nowhere and quickly died when Mac OS X was released, and was totally forgotten when Apple ditched the Power platform for x86. note
- Now, we have Darling, a project for Linux and BSD that aims to achieve what Wine did for Windows programs in Linux, with Mac OS X programs. Let's wish them luck as this will at least give those who need to run that rare Mac-exclusive app but don't want to buy a Mac or build a Hackintosh a third alternative to getting said app to run.
- Mono and MoonLight are runtimes for Unix-based systems to run software written using Microsoft's .NET framework. It is developed separately from Wine and can run .NET executables without needing Wine, although an adapter can be installed in Wine to allow hybrid code (programs written in a combination of traditional Windows-native code code and .NET) to run inside Wine.
- BlueStacks is a free-but-commercial Android Runtime implementation that allows Android programs to run natively under Windows.
- IcedRobot: An Open Source version of the Android Runtime for Unix-based systems, designed to use the GNU GCC's fully open sourced Java runtime compiler and interpreter set. While it had a promising start (to the point of being able to run some of the more simpler apps that targeted Android Froyo), development died in late 2012 and it has been abandoned.