DirectX

Microsoft DirectX is a collection of COM-based APIs for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms. 
Originally all API names started with "Direct" in their names (Direct3D, DirectDraw, etc.), thus the name DirectX was coined as a shorthand term for all of these APIs (the X standing in for the particular API names) and soon became the official name of the collection.
==WinG & DCI==
The first true attempt to bring fast video performance to Windows came in the Virtual Flat Framebuffer Device (also known as VFLATDhttps://www.os2museum.com/wp/undocumented-vflatd/ or DVA.386 – Direct Video Access), which shipped as part of Video for Windows (VfW), enabling the DrawDib functions to circumvent GDI and write decompressed video frames directly into VRAM. While it had some limitations to the size of framebuffer it could support, it did allow for much faster framebuffer access by using a page-fault handler to emulate linear framebuffers on banked display adapters. VfW also supported DISPDIB.DLL, which supported shutting off GDI to allow a program to write directly to the VGA framebuffer (KERNEL.EXE exported a selector for A0000h). On Windows NT, VfW used either a DIB section or DCI to draw to the screen, and DISPDIB is actually implemented on top of DrawDib.
Windows NT 3.5 added the CreateDIBSection API call to GDI, which allowed one to create an HBITMAP backed by a device-independent-bitmap in user-accessible memory (prior to this, the only method to display a DIB using GDI was via API calls such as SetDIBits, which converted a DIB to a DDB, which was a slow process) and thus have a device context with a DIB selected into it. As such, one could both use GDI calls to draw onto the DIB and draw the DIB onto the screen using speedy functions such as BitBlt. The reason for the naming of the API is that Windows NT memory objects are referred to as sections, and in fact you can create a DIB section around existing memory by passing a section handle; otherwise, GDI (really, CSRSS; the Client-Server Runtime Subsystem) will create one for you. The DIB section is in shared memory between your application and the subsystem server where GDI (and the display driver and its mapped memory) lives.
Windows 95 (then known as "Chicago") also added this API call, in conjunction with the introduction of the DIB engine (first detailed, along with the DIB DC-related API calls, in the 1992 Chicago specification, and implemented as early as July 1992). The DIB engine was designed to simplify development of Windows 95 display drivers, allowing video card vendors to simply ship a "minidriver" which provided code to set video modes and provide a pointer to the framebuffer, while the DIB engine would take care of everything else. The DIB engine was optimized for packed-pixel 8/16/24/32-bit framebuffer arrangements, since those framebuffers were the same format as Windows DIBs (while many prior cards had unusual framebuffer arrangements, including multi-plane graphics).
The DIB engine allowed GDI to treat the entire screen as one big GDI bitmap – one big DIB (and allowed both applications and GDI to access the same bitmap), and many drivers (particularly those for banked SVGA adapters) used VFLATD for this, but many drivers also used DCI, or the Display Control Interface, which was also part of the VfW technology wave. DCI expanded on VFLATD, allowing support for multiple offscreen surfaces and framebuffers above 1MB in size. DCI was designed primarily for digital video, and thus supports color spaces such as YUV as well as acceleration of video decompression and stretching. DCI was encumbered by legal action from Apple, who claimed that code used in DCI had been developed for them by a third-party company in an attempt to speed up video performance under QuickTime for Windows, and the same company later contracted with Intel.
DCI was implemented with display drivers (including DVA.386 and DCISVGA.DRV) implementing a "DCI provider", which communicated with the DCI Manager (DCIMAN.DLL / DCIMAN32.DLL) client DLL via message passing. In most cases, DCI clients would be libraries such as WinG or Video for Windows, but applications could call into the DCI Manager directly to open the DCI provider and access the framebuffer.
WinG was a port of an early version of the Chicago DIB engine to Windows 3.1x, and most of its functions are parallels to GDI calls added in Windows 95 / NT 3.5. On Windows 3.1, a WinGDC is distinct from an HDC, as is a WinGBitmap from an HBITMAP, and WinGBitBlt/WinGStretchBlt vs BitBlt/StretchBlt, since WinG uses its own video path despite hooking into GDI through WINGDIB.DRV, but on NT 3.50 / 95, they're interchangeable. This places some limitations on what you can do with WinG on Windows 3.1; standard GDI BitBlt functions cannot blit between WinG DCs and GDI DCs, and the DIB engine (WINGDE.DLL) acts as a GDI driver to allow standard GDI operations onto WinGDCs. Meanwhile, one must use WinG to blit from a WinGDC (with a DIB selected onto it) to a GDI (display/screen) DC, as WinG will then obtain a pointer to the framebuffer of the GDI DC and draw onto it, or fall back to StretchDIBits if required. 
Many early Windows 95 games, such as WinDoom and Fury 3, use WinG (often in conjunction with Win32s), but it was soon discontinued and replaced with DirectDraw. One well-known application using WinG acceleration is Microsoft Bob. 
Microsoft did port DCI to 32-bit Windows, including Windows NT 3.51 (to a limited extent), and DCI 2.0 evolved into DirectDraw (DirectDraw in fact identifies itself as DCI 2.0, and the APIs with the concept of onscreen and offscreen primary surfaces is the same, with the DirectDraw design team starting from DCI), with the DCI API being subsumed into DirectX (which used a COM-based interface as opposed to a C-based API), with some structures, enumerations, error codes, and return values being shared. When a DirectDraw driver is unavailable on a Windows 9x operating system, it can fall back to use DCI if available via the Hardware Emulation Layer (and then it will fall back to the DIB engine as a last resort). Additionally, OPENGL32.DLL (the software OpenGL 1.1 renderer for Windows) used DCI to draw to the screen, as did the original version of GDI+, because the same redistributable DLL file had to be able to work not only on NT systems, but also on the 9x family, where very old drivers without DirectDraw support could be installed. On Windows 9x, DirectDraw will also use DISPDIB.DLL to draw fullscreen graphics in any VGA-compatible modes (i.e. 320x200x256 Mode 13h or 320x240x256 Mode X).
Starting with Windows NT 4.0, Microsoft began stripping out DCI support from the operating system, removing several DCI-related exports from GDI32.DLL, removing support for DCI from display drivers, and reimplementing the DCI Manager APIs on top of DirectDraw and GDI. The reason for this was simple; NT 4.0's video architecture had been redesigned, moving large parts of GDI and USER (and the new DirectDraw, which started work on NT shortly after NT 4.0's development began) into the kernel-mode module WIN32K.SYS, meaning that the NT 3.x display drivers that implemented DCI directly would be incompatible, so a clean break could be made to supplant DCI. Several DCI functions closely map to DirectDraw equivalents, such as DCIBeginAccess being implemented on top of IDirectDrawSurface_Lock, and DCICreatePrimary mapping to IDirectDraw_CreateSurface. DCI surfaces are implemented as a thin wrapper over DirectDraw surfaces, but the API is heavily stripped down, only supporting a single surface. Meanwhile, Windows 95/98/Me continued to have full native support for DCI as a peer to DirectDraw, since DCI display drivers were still supported. Vestigial DCI Manager support remains in modern versions of Windows NT despite the absence of the lower-level components. DirectDraw development began in 1994 (after the early WinG betas) for Windows 95 as the first serious effort to make graphics performance on Windows competitive with DOS, enabling games to shift over to Windows.
Development on Video for Windows-related technologies and WinG as out-of-band updates to the operating system did not continue after Windows 95, at which point they were integrated into the OS as core components.
==OpenGL==
Starting with Windows NT 3.5, Microsoft integrated support for OpenGL 1.0, SGI's 3D graphics API. Support was provided through the OPENGL32.DLL library, which implemented a software renderer. Windows NT 3.51 added support for Installable Client Drivers (ICDs), which enabled hardware acceleration through the 3D-DDI. While OPENGL32.DLL still provided a software rasterizer, all of the OPENGL32 entry points were indirected through a jump table, with the entries filled with the ICD entry points if available, and the software rasterizer if not. The mechanism for this was that the entry points were based on the GL rendering context, which was based on a GDI display device context. The Win32 bindings which interacted with the USER32/GDI32 system were called wgl, and are comparable to GLX on UNIX systems. With Windows NT 4.0, support for OpenGL 1.1 features was added.
As of Windows 11, the only entry points exported by OPENGL32 are for OpenGL 1.1, and to obtain additional entry points, one must call wglGetProcAddress to obtain them from the ICD.
Due to the minimal support for Direct3D on versions of Windows NT prior to Windows 2000, Microsoft pushed OpenGL as a core part of the Win32 SDK until Windows 2000, when it was fully sidelined by Direct3D.
==Components==
DirectX is composed of multiple APIs,https://en.wikipedia.org/wiki/DirectX#Components the most commonly known ones as follows:
*Direct3D (D3D): Real-time 3D rendering API.
*Direct2D: Current 2D graphics API.
*DirectDraw: Deprecated 2D graphics API.
*DirectSound: Deprecated Audio API (replaced by XAudio2 and XACT3).
*DirectX Diagnostics (DxDiag): A tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers.
*DirectX Media for Audio/Video acceleration (deprecated).
*DirectWrite, a Text rendering API.
*DirectInput, an input API for interfacing with keyboards, mice, joysticks, and game controllers (deprecated).
*DirectPlay, a network API for communication over a local-area or wide-area network (deprecated).
*DirectX Ray Tracing (DXR): Light ray-tracing API.
*DirectShow: The streaming media technology intended to replace Video for Windows, originally known as ActiveMovie (deprecated)
==Versions==
DirectX 4 was never released. Raymond Chen of Microsoft explained that after DirectX 3 was released, Microsoft began developing versions 4 and 5 in parallel. Version 4 was planned as a short-termed release with minor changes, whereas version 5 would've been a bigger release. Due to the lack of interest from game developers in the DirectX 4 features it was soon canceled, and the large amount of documents that already distinguished the two new versions resulted in Microsoft choosing to not re-use version 4 to describe features intended for version 5.https://devblogs.microsoft.com/oldnewthing/?p=40963
*DirectX 1 (Q4 1995; 1.0 shipped with Windows 95 RTM)
*DirectX 2 (Q2 1996; 2.0a shipped with Windows NT 4.0 and then Windows 95 OSR2)
*DirectX 3 (Q3 1996; 3.0a shipped with Windows NT 4.0 SP3; last release for Windows NT 4.0)
*DirectX 5 (Q3 1997; 5.2 shipped with Windows 98)
*DirectX 6 (Q3 1998; 6.1a shipped with Windows 98 SE)
*DirectX 7 (Q4 1999; 7.0 shipped with Windows 2000 and introduced support for hardware T&L; 7.1 shipped with Windows Me; last release for PCs with 486 processors and last version to have built-in RGB software rendering support)
*DirectX 8 (Q4 2000; added support for shaders; 8.0a shipped with the August 2001 Update for Windows 95 OSR2.5; 8.1 shipped with Windows XP and Windows Server 2003; last release for Windows 95 and last version to have software rendering support in DxDiag)
*DirectX 9 (Q4 2002; 9.0b shipped with the Windows Security Update CD for Windows 98 build 1998A, Windows 98 SE build 2222B and Windows Me build 3000A from February 2004; 9.0c shipped with Windows XP SP2, Windows Server 2003 SP1 and R2; last version for all Windows versions below Vista and Server 2008; Windows 98 and Windows Me support already removed after the December 2006 revision)
*DirectX 10 (Q4 2006; 10.0 introduced alongside Windows Vista and Windows Server 2008)
*DirectX 11 (Q4 2009; 11.0 introduced alongside Windows 7 and Windows Server 2008 R2 and then backported to Windows Vista and Windows Server 2008 with the Platform Update; last version for Windows Vista and Server 2008; 11.1 introduced alongside Windows 8 and Windows Server 2012 and partially backported to Windows 7 and Windows Server 2008 R2 with the Platform Update; 11.2 introduced alongside Windows 8.1 and Windows Server 2012 R2)
*DirectX 12 (Q3 2015; 12.0 introduced alongside Windows 10 and Windows Server 2016, followed by DX12 Ultimate in 2020, which shipped with Windows 11)
==Gallery==
DirectX-Setup-June2010.png|Setup (9.0c, June 2010)
DxDiag-WindowsXP.png|Diagnostic Tool in Windows XP
Windows7-6.1.7601.17514sp1-DxDiag.png|Diagnostic Tool in Windows 7
DX5-ViewPoint-Collection-RelNotes.png|DirectX 5 ViewPoint Collection Release Notes, mentioning the cancellation of DirectX 4
==References==
Category:Microsoft
 
Category:Introduced in Windows 95