Windows API

De Windows API is een set API's (application programming interface) die het besturingssysteem Windows aanbiedt aan programma's. Vroeger noemde men deze de Win32 API. De naam Windows API is echter een betere beschrijving aangezien ondertussen ook 64 bit-Windowsversies ondersteund worden. Bijna alle Windowsprogramma's integreren met de Windows API.

Een softwareontwikkelaar kan gebruikmaken van de Microsoft Windows-SDK (Software Development Kit), die documentatie en tools voorziet om de Windows API en andere Windowstechnologieën te gebruiken.

De werking van de Windows API kan verdeeld worden in 8 categorieën:

Basisservices

Zij voorzien toegang tot de fundamentele bronnen die voor een Windowssysteem beschikbaar zijn. Enkele voorbeelden zijn bestandssystemen, hardware, processen, threads en foutverwerking. Deze functies bevinden zich in de bestanden kernel.exe, krnl286.exe of krnl386.exe voor een 16 bit-Windows, en de bestanden kernel32.dll en KernelBase.dll op 32 bit- en 64 bit-Windowsversies.

Geavanceerde services

Deze voorzien toegang tot de werking die een toevoeging is aan de kernel. Enkele voorbeelden zijn het Windowsregister, het systeem opstarten of herstarten, een Windows-service starten/stoppen/aanmaken en gebruikersaccounts beheren. Deze functies bevinden zich in het bestand advapi32.dll op een 32 bit-Windows.

Graphics Device Interface

Voorziet de werking om grafische inhoud weer te geven op beeldschermen, printers en andere uitgangsapparaten. Deze interface bevindt zich in gdi.exe op een 16 bit-Windows en in gdi32.dll op een 32 bit-Windows in gebruikersmodus. Ondersteuning voor kernel-mode-GDI is voorzien door win32k.sys, hetgeen rechtstreeks met de grafische driver communiceert.

Grafische Gebruikersinterface

Voorziet de werking om vensters te maken en beheren en de meeste basisbewerkingen zoals knoppen, schuifbalken, muis- en toetsenbordinvoer ontvangen, en andere werkingen die te maken hebben met het GUI-deel van Windows. Deze functies bevindt zich in user.exe op een 16 bit-Windows versie, en in user32.dll op een 32 bit-Windows. Sinds Windows XP bevinden de basisbewerkingen zich in comctl32.dll, samen met de common controls (Common Control Library).

Common Dialog Box Library

Voorziet de standaard dialoogkaders om bestanden op te slaan, kleur en lettertype te kiezen etc. De bibliotheek bevindt zich in het bestand commdlg.dll op een 16 bit-Windows, en comdlg32.dll op een 32 bit-Windows. De bibliotheek valt onder de User Interface-categorie van de API.

Common Control Library

Geeft applicaties toegang tot sommige geavanceerde functies die voorzien zijn door het besturingssysteem. Bijvoorbeeld statusbalken, menubalken en tabbladen. Deze bibliotheek bevindt zich in een DLL-bestand dat comctrl.dll heet in een 16 bit-Windowsversie, of comctl32.dll op een 32 bit-Windowsversie. De bibliotheek valt onder de User Interface-categorie van de API.

Windows Shell

Een component van de Windows API die toepassingen toelaat de functionaliteit die de shell van het besturingssysteem biedt aan te spreken en deze functionaliteit ook te veranderen en te verbeteren. Dit onderdeel bevindt zich in shell.dll op een 16 bit-Windowsversie, en in shell32.dll op een 32 bit-Windows. De Shell Lightweight Utility Functions zitten in het bestand shlwapi.dll. Deze component wordt ook gegroepeerd onder de User Interface-categorie van de API.

Netwerk Services

Geven toegang tot de verschillende netwerkmogelijkheden van het besturingssysteem. Zijn subcomponenten bevatten onder andere NetBIOS, Winsock, NetDDE, RPC.

De webbrowser Internet Explorer kan ook beschouwd worden als onderdeel van de Windows API, aangezien deze verschillende API's biedt die vaak gebruikt worden door andere toepassingen. Internet Explorer zit mee in het besturingssysteem sinds de tweede editie van Windows 98 en biedt webgerelateerde services aan toepassingen sinds Windows 98. Specifieker wordt het gebruikt:

• als embeddable webbrowsercontrole (in shdocvw.dll en mshtml.dll)
• als URL-monitorservice (in urlmon.dll) die COM-objecten voorziet aan toepassingen die URL's verwerken
• om bibliotheken te voorzien die meertalige en internationale tekstondersteuning bieden (mlang.dll)
• voor DirectX-transformaties, een set van afbeeldingfilterscomponenten
• voor XML-ondersteuning (de MSXML-componenten bevinden zich in het bestand msxml*.dll)

Microsoft voorziet sinds Windows 95 OSR2 elke Windows-installatie van de DirectX-API's. DirectX voorziet een los gerelateerde set van multimedia en gamingservices, zoals:

• Direct3D voor hardware-accelerated graphics
• DirectDraw voor hardware-accelerated toegang tot de 2D-framebuffer. Sinds DirectX 9 heeft deze component plaats moeten ruimen voor Direct3D, dat meer algemene grafische werking met hoge performantie voorziet (aangezien 2D-rendering onderdeel is van 3D-rendering)
• DirectSound voor toegang tot een low-level hardware-accelerated geluidskaart
• DirectInput voor communicatie met invoerapparaten zoals joysticks en gamepads
• DirectPlay als multiplayer-gaminginfrastructuur. Deze component is verouderd sinds DirectX 9 en Microsoft het gebruik ervan niet meer aanraadt voor gameontwikkeling
• DirectShow dat generische multimediapipelines maakt en draait. Het is vergelijkbaar met het Gstreamer-framework en is vaak gebruikt om in-gamevideos te renderen en mediaplayers te maken (Windows Media Player is erop gebaseerd). DirectShow is niet meer aangeraden voor gameontwikkeling
• DirectMusic van MIDI-bestanden afspelen, maar dit is verouderd

De Windows API houdt zich vooral bezig met de interactie tussen het besturingssysteem en een toepassing. Voor de communicatie tussen de verschillende Windowstoepassingen onderling heeft Microsoft een reeks technologieën ontwikkeld naast de hoofdzakelijke Windows API. Dit begon met Dynamic Data Exchange (DDE), dat vervangen werd door Object Linking and Embedding (OLE) en later door het Component Object Model (COM), Automation Objects, ActiveX Controls en het .NET-framework. Er is niet altijd een duidelijk onderscheid tussen deze technologieën en ze overlappen vaak.

De variëteit van termen is voornamelijk het resultaat van groeperen van softwaremechanismen die te maken hebben met een specifiek aspect van softwareontwikkeling. Automatisering in het bijzonder heeft te maken met het exporteren van de werking van een toepassing of component (als API) zodat deze door een andere toepassing of een menselijke gebruiker kan gebruikt worden.

Microsoft heeft verschillende wrappers ontwikkeld die sommige lagelevelfuncties van de Windows API overnamen en zo toepassingen toeliet op een abstractere manier te communiceren met de API. De Microsoft Foundation Class-bibliotheek (MFC) kapselt de Windows API-werking in in C++-klassen, en laat zo een meer objectgeoriënteerde manier van communiceren met de API toe. De Active Template-bibliotheek (ATL) is een templategeoriënteerde wrapper voor COM. De Windows Template-library (WTL) was ontwikkeld als een extensie voor ATL, en was bedoeld als een lichter alternatief voor MFC.

Ook opmerkelijk zijn sommige aanbiedingen van Borland. De Object Windows-library (OWL) werd uitgebracht als een concurrerend product van MFC en bood een gelijkaardige objectgeoriënteerde wrapper. Borland moest later plaatsmaken voor de Visual Component-library (VCL), die geschreven is in Object Pascal en zowel in de Delphi als C++ Builder beschikbaar is.

De meeste applicatieframeworks voor Windows kapselen (ten minste gedeeltelijk) de Windows API in. Vandaar dat zowel het .NET-framework, Java als alle andere programmeertalen in Windows een wrapperbibliotheek hebben of zijn. Windows API Code Pack for Microsoft .NET Framework is een .NET-wrapperbibliotheek voor de Windows API.

In de 64 bit-Windowsversies is dezelfde benaming gebruikt voor de DLL-bestanden.

De Windows API heeft altijd een groot deel van de onderliggende structuur van de Windowssystemen blootgelegd aan de programmeur. Dit geeft de programmeurs een grote flexibiliteit en macht over hun toepassingen. Het geeft de Windowstoepassingen echter ook een grote verantwoordelijkheid om verschillende low-levelhandelingen te verwerken die verband houden met een GUI.

Charles Petzold, auteur van de veel gelezen Windows API-boeken, heeft het volgende gezegd: "Het originele "hello world"-programma in de Windows 1.0-SDK was een klein schandaal. HELLO.C was ongeveer 150 lijnen lang en het HELLO.RC-bronscript telde een 20-tal lijnen. (...) Oudere C-programmeurs voelden vaak afschuw of hilariteit wanneer ze het Windows-hello-worldprogramma tegenkwamen."

Over de jaren heen zijn er verschillende veranderingen en toevoegingen gedaan aan het Windows-besturingssysteem, en de Windows API veranderde en weerspiegelde dit. De Windows API voor Windows 1.0 ondersteunde minder dan 450 functieoproepen, terwijl moderne versies van de Windows API er duizenden ondersteunen. Over het algemeen bleef de interface echter vrij consistent; een oude Windows 1.0-toepassing zal nog steeds herkenbaar zijn voor een programmeur die gewoon is aan de moderne Windows API.

Microsoft doet inspanningen om software achterwaarts compatibel te maken en houden. Om dit te bereiken gaat Microsoft soms zo ver dat ze software ondersteunen die de API in een ongedocumenteerde of zelfs (voor de programmeur) illegale manier gebruikt. Raymond Chen, een ontwikkelaar bij Microsoft die aan de Windows API werkt, heeft het volgende gezegd: "Ik zou waarschijnlijk maanden kunnen schrijven over enkel en alleen toepassingen die foute dingen doen en wat we hebben moeten doen om hen weer werkende te krijgen (vaak ondanks zichzelf). Dit is waarom ik zeer kwaad word wanneer mensen Microsoft ervan beschuldigen met kwaad opzet toepassingen te beschadigen tijdens besturingssysteem-upgrades. Als er ook maar één toepassing niet meer werkte op Windows 95, nam ik dit op als een persoonlijk falen."

Een van de grootste veranderingen die de Windows API onderging, was de overgang van Win16 (te vinden in Windows 3.1 en ouder) naar Win32 (Windows NT, Windows 95 en hoger). Terwijl Win32 oorspronkelijk geïntroduceerd werd met Windows NT 3.1 en Win32s het gebruik van de Win32-subset al toeliet voor Windows 95, was het pas vanaf Windows 95 dat vele applicaties werden overgezet naar Win32. Om de overgang te vergemakkelijken, werd er in Windows 95, zowel voor de externe ontwikkelaars als voor Microsoft, een complex schema van zogenaamde 'API thunks' gebruikt, die het mogelijk maakten voor 32 bit-code om 16 bit-code aan te roepen en (in enkele gevallen) vice versa. Zogenaamde 'flat thunks' lieten 32 bit-code toe om 16 bit-library's aan te roepen, en het schema werd intensief gebruikt binnen Windows 95 om te vermijden dat het hele besturingssysteem in een keer naar Win32 zou moeten overgezet worden. In Windows NT was het besturingssysteem enkel 32 bit (behalve de delen voor compatibiliteit met 16 bit-toepassingen), en enkel 'generic thunks' waren beschikbaar voor de thunk van Win16 naar Win32, alsook voor Windows 95. De Platform SDK bevatte een compiler die de nodige code kon produceren voor deze thunks.

Bijna elke nieuwe versie van Windows introduceerde zijn eigen toevoegingen en veranderingen aan de Windows API. De naam van de API echter, werd consistent gehouden tussen verschillende Windowsversies, en naamsveranderingen werden beperkt tot grote structurele en platformveranderingen voor Windows. Microsoft veranderde uiteindelijk de naam van de toenmalige 'Win32 API' familie naar 'Windows API', en veranderde de naam zo in een alomvattende term voor zowel verleden als toekomstige versies van de API.

• Win16 is de API voor de eerste, 16 bit-versies van Microsoft Windows. Deze werd oorspronkelijk gewoonweg de Windows API genoemd, maar werd later hernoemd naar Win16 om een onderscheid te maken van de nieuwere 32 bit-versie van de Windows API. De functies van de Win16-API vind je voornamelijk in de kernbestanden van het besturingssysteem: kernel.exe (of krnl286.exe of krnl386.exe), user.exe en gdi.exe. Ondanks het exe-bestandsformaat zijn dit in feite dynamisch verbonden bibliotheken.
• Win32 is de 32-bit API voor moderne versies van Windows. De API bestaat uit functies die, net zoals bij Win16, geïmplementeerd zijn in systeem-DLL-bestanden. De kern-DLL-bestanden van Win32 zijn kernel32.dll, user32.dll en gdi32.dll. Win32 werd geïntroduceerd met Windows NT. De Win32-versie die bij Windows 95 kwam werd aanvankelijk Win32c genoemd, met de "c" die stond voor "compatibiliteit", maar deze term moest van Microsoft plaatsmaken voor de naam "Win32".
• Win32s is een uitbreiding voor de Windows 3.1x-familie van Microsoft Windows die een subset van de Win32-API voor deze systemen implementeerde. De "s" staat voor "subset".
• Win32 voor 64 bit-Windows, voorheen gekend als Win64, is de variant van de API geïmplementeerd op 64 bit-platformen van de Windows-architectuur. Er zijn geen nieuwe user-modefuncties specifiek aan het 64 bit-platform, dus zowel 32 bit- als 64 bit-versies van een toepassing kunnen gecompileerd worden van eenzelfde codebase, hoewel sommige oudere API's verouderd zijn. Alle geheugenpointers zijn standaard 64 bit (het LLP64-model), dus de broncode moet gecontroleerd worden voor compatibiliteit met 64 bit-pointerbewerkingen en indien nodig herschreven worden.

Hoewel Microsofts implementatie van de Windows API gepatenteerd is, wordt het algemeen aanvaard in de Verenigde Staten dat andere verkopers Windows emuleren door een identieke API te voorzien zonder het patent te schaden.

Het project wine is een poging om een Win32-API-compatibiliteitslaag voor Unix-platformen te voorzien. ReactOS gaat een stap verder door een implementatie van het hele Windows-besturingssysteem te voorzien, en werkt nauw samen met het wine-project om compatibiliteit van code en codehergebruik te promoten. DosWin32 en HX DOS-Extender zijn andere projecten om de Windows API te emuleren, om eenvoudige Windowsprogramma's te draaien vanuit de DOS-command-line. Odin is een project dat probeert Win32 te emuleren bovenop OS/2.

Om software te ontwikkelen die de Windows API gebruikt, moet een compiler in staat zijn de Microsoftspecifieke DLL-bestanden en COM-objecten te verwerken en importeren. Ofwel moet de compiler overweg kunnen met de header-bestanden die het interieur van de API-functienamen onthullen, of moet deze dergelijke bestanden zelf kunnen voorzien. Voor bepaalde klassen van toepassingen moet het compilersysteem ook de IDL (interface definition language)-bestanden kunnen behandelen.

Samen zijn deze vereisten (compilers, tools, bibliotheken en headers) gekend als het Microsoft Platform SDK. Lange tijd waren de Microsoft Visual Studio-familie van compilers en tools en de Borland-compilers de enige tools die dit konden voorzien (toch in het geval van Windows, de SDK zelf is te downloaden apart van de gehele IDE-suite, van de Microsoft Platform SDK Update). Tegenwoordig voorzien het MinGW- en het Cygwin-project ook een dergelijke omgeving, gebaseerd op de GNU Compiler Collection, die gebruikmaakt van een stand-alone headerbestandverzameling om het linken tussen Microsoft-DLL's mogelijk te maken.

LCC-Win32 is een C-compiler onder de licentie "free for non-commercial use". Deze wordt in stand gehouden door Jacob Navia. Pelles C is een gratis C-compiler in stand gehouden door Pelle Orinius. Free Pascal is een GPL Object Pascal-compiler die in staat is software te schrijven, gebaseerd op de Windows API. MASM32 is een project ter ondersteuning van de Windows API die gebruikmaakt van de 32 bit-Microsoftassembler met zelfgemaakte of omgezette headers en bibliotheken van de Platform SDK.

Windows-specifieke compilerondersteuning is ook vereist voor de toepassing Structured Exception Handling (SEH). Dit systeem dient twee doelen: het voorziet een substraat waarop een taalspecifieke exceptionhandling kan worden geïmplementeerd, en dit is de manier waarop de kerneltoepassingen waarschuwt bij optreden van uitzonderlijke toestanden, zoals dereferencing van een ongeldige pointer of stack-overflow. De Microsoft-/Borland-C++-compilers hadden de mogelijkheid dit systeem te gebruiken vanaf het ogenblik dat dit werd geïntroduceerd in Windows 95 en NT. De implementatie was echter niet gedocumenteerd en moest dus voor het wine-project en gratis compilers via reverse engineering achterhaald worden. SEH is gebaseerd op het duwen van exception-handlerframes op een stack, en deze dan toe te voegen aan een gelinkte lijst die opgeslagen is in de thread-local-storage (het eerste veld van de thread-environmentblok). Wanneer er zich een uitzondering voordoet, dan gaan de kernel en de basisbibliotheken de stack af op zoek naar handlers en filters en voeren deze uit waar ze zich voordoen. Uiteindelijk zal elke uitzondering die niet behandeld wordt door de toepassing zelf, opgevangen worden door de standaard backstop die de common-crashdialoog van de toepassing weergeeft.

• Microsoft Foundation Classes
• Linuxkernel
• .NET Framework

• (en) Windows API-ontwikkelgids op MSDN
• (en) Straight C Win32 API Tutorial no MFC
• (en) ECMA-234 - ECMA-standaard voor een subset van de Windows API