Windows API
De Windows API, ofte application programming interface, is een set API's die de Microsoft Windows besturingssystemen ter hun beschikking hebben. Vroeger noemde deze de Win32 API. De naam Windows API is echter een betere beschrijving gezien de eerdere 16-bit Windows versie en de ondersteuning voor huidige 64-bit Windows versies. Bijna alle Windows programma's interageren met de Windows API.
Een software ontwikkelaar kan gebruik maken van het Microsoft Windows SDK (Software Development Kit), dat documentatie en tools voorziet om de Windows API en andere Windows technologieën te gebruiken.
Overzicht
De werking van de Windows API kan verdeeld worden in 8 categorieën:
- Basis Services
- Zij voorzien toegang tot de fundamentele bronnen die voor een Windows systeem beschikbaar zijn. Enkele voorbeelden zijn bestandssystemen, hardware, processen, threads of error handling. Deze functies bevinden zich in de bestanden kernel.exe, krnl286.exe of krnl386.exe voor een 16-bit Windows, en het bestand kernel32.dll op 32-Windows versies.
- Geavanceerde Services
- Deze voorzien toegang tot de werking die een toevoeging is aan de kernel. Enkele voorbeelden zijn de Windows registry, 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.
- Grafics 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. Kernel-mode GDI ondersteuning is voorzien door win32k.sys, hetgeen rechtstreeks met de grafische driver communiceert.
- Gebruikers Interface
- Voorziet de werking om vensters te maken en beheren en de meeste basis bewerking 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 basis bewerkingen 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 library bevindt zich in het bestand commdlg.dll op een 16-bit Windows, en comdlg32.dll op een 32-bit Windows. De library 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 library bevindt zich in een DLL bestand dat comctrl.dll noemt in een 16-bit Windows versie, of comctl32.dll op een 32-bit Windows versie. De library valt onder de User Interface categorie van de API.
- Windows Shell
- Een component van de Windows API die toepassingen zowel toelaat om de functionaliteit die de shell van het besturingssysteem biedt aan te spreken als ze veranderen en verbeteren. Dit onderdeel bevindt zich in shell.dll op een 16-bit Windows versie, 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 o.a. NetBIOS, Winsock, NetDDE, RPC en vele anderen.
Web
De Internet Explorer web browser 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 2de editie van Windows 98 en biedt webgerelateerde services aan toepassingen sinds Windows 98. Specifieker wordt het gebruikt:
- als embeddable web browser control (in shdocvw.dll en mshtml.dll)
- als URL monitor service (in urlmon.dll) die COM objecten voorziet aan toepassingen die URL's verwerken
- om libraries te voorzien die meertalige en internationale tekst ondersteuning bieden (mlang.dll)
- voor DirectX Transformaties, een set van afbeelding filter componenten
- voor XML ondersteuning (de MSXML componenten bevinden zich in het bestand msxml*.dll)
Multimedia
Microsoft voorziet sinds Windows 95 OSR2 elke Windows installatie van de DirectX API's. DirectX voorziet een los gerelateerde set van multimedia en gaming services, 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 high-performance grafische werking 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 gaming infrastructuur. Deze component is verouderd sinds DirectX 9 en Microsoft het gebruik ervan niet meer aanraadt voor game ontwikkeling
- DirectShow dat generic multimedia pipelines maakt en draait. Het is vergelijkbaar met het Gstreamer framework en is vaak gebruikt om in-game videos te renderen en mediaplayers te maken (Windows Media Player is er op gebaseerd). DirectShow is niet meer aangeraden voor game ontwikkeling
- DirectMusic laat afspelen van MIDI bestanden, maar is verouderd
Programma interactie
De Windows API houdt zich vooral bezig met de interactie tussen het besturingssysteem en een toepassing. Voor de communicatie tussen de verschillende Windows toepassingen 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 software ontwikkeling. Automatisering in het bijzonder heeft te maken met de werking van een toepassing of component (als API) te exporteren zodat het door een andere toepassing of een menselijke gebruiker kan gebruikt worden.
Wrapper libraries
Microsoft heeft verschillende wrappers ontwikkeld die sommige lage level functies van de Windows API overnamen en zo toepassingen toeliet op een abstractere manier te communiceren met de API. Microsoft Foundation Class library (MFC) omkapselt de Windows API werking in C++ klassen, en laat zo een meer object georiënteerde manier van communiceren met de API toe. De Active Template library (ATL) is een template georië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. Object Windows library (OWL) werd uitgebracht als een concurerend product t.o.v. MFC en bood een gelijkaardige objectgeoriënteerde wrapper. Borland moest later plaats maken voor de Visual Component library (VCL), die geschreven is in Object Pascal en zowel in de Delphi als C++ Builder beschikbaar is.
De meeste application frameworks voor Windows omkapselen (ten minste gedeeltelijk) de Windows API. Vandaar dat zowel het .NET framework, java als alle andere programmeertalen in Windows een wrapper library hebben of zijn. Windows API Code Pack for Microsoft .NET Framework is een .NET wrapper library voor de Windows API.
In de 64-bit Windows versies is dezelfde benaming gebruikt voor de DLL bestanden.
Geschiedenis
De Windows API heeft altijd een groot deel van de onderliggende structuur van de Windows systemen blootgelegd aan de programmeur. Dit geeft de programmeurs een grote flexibiliteit en macht over hun toepassingen. Het geeft de Windows toepassingen echter ook een grote verantwoordelijkheid om verschillende low-level handelingen te verwerken die verband houden met een GUI.
Charles Petzold, auteur van de veel gelezen Windows API boeken, heeft hetvolgende 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 resource script telde een 20tal lijnen. (...) Oudere C programmeurs kronkelden vaak van weerzin of gelach wanneer ze het Windows hello-world programma 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 function calls, 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 benadrukt er op om software backwards compatible 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. Raymond Chen, een Microsoft developer die aan de Windows API werkt, heeft hetvolgende gezegd: "Ik zou waarschijnlijk voor maanden over enkel en alleen toepassingen die foute dingen doen en wat we hebben moeten doen om hen terug werkende te krijgen, kunnen schrijven (vaak ondanks hunzelf). Dit is waarom ik zeer kwaad wordt 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 werden 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 begonnen overgezet te worden 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 toelieten aan 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 libraries 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.
Versies
Bijna elke nieuwe versie van Microsoft Windows introduceerde zijn eigen toevoegingen en veranderingen aan de Windows API. De naam van de API echter, werd consistent gehouden tussen verschillende Windows versies, 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 al-omvattende 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 de exe- bestandsextensie zijn dit in feite dynamisch verbonden libraries.
- 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 system DLL-bestanden. De kern DLL-bestanden van Win32 zijn kernel32.dll, user32.dll en gdi32.dll. Win32 werd geïntroduceert 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" staan 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 (momenteel: AMD64 en IA64). Er zijn geen nieuwe user-mode functies specifiek aan het 64-bit platform, dus zowel 32-bit als 64-bit versies van een toepassing kunnen gecompiled worden van eenzelfde codebase, hoewel sommige oudere API's te verouderd zijn. Alle geheugen pointers zijn standaard 64-bit (het LLP64 model), dus de broncode moet gecontroleerd worden voor compatibiliteit met 64-bit pointer bewerkingen en indien nodig herschreven worden.
Andere implementaties
Hoewel Microsoft's 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 wine project is een poging om een Win32 API compatibiliteitslaag voor Unix-platformen te voorzien. ReactOS gaat een stap verder en een implementatie van het hele Windows besturingssysteem te voorzien en werkt nauw samen met het wine project om compatibiliteit van code en code hergebruik te promoten. DosWin32 en HX DOS-Extender zijn andere projecten om de Windows API te emuleren, om eenvoudige Windows programma's te draaien vanuit de DOS command line. Odin is een project dat probeert Win32 te emuleren bovenop OS/2.
Compiler ondersteuning
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 files die het interieur van de API functie namen onthullen, of moet deze dergelijke bestanden zelf kunnen voorzien. Voor bepaalde klassen van toepassingen moet het compiler systeem ook de IDL (interface definition language) bestanden kunnen behandelen. Samen zijn deze vereisten (compilers, tools, libraries 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 gebruik maakt van een stand-alone header file verzameling om het linken tussen Microsoft DLL's mogelijk te maken. LCC-Win32 is een "free for non-commercial use" C compiler, 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 gebruik maakt van de 32 bit Microsoft assembler met zelfgemaakte of omgezette headers en libraries van de Platform SDK.
Windows specifieke compiler ondersteuning is ook vereist voor de Structured Exception Handling toepassing (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 kernel toepassingen 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 werd geïntroduceert in Windows 95 en NT. De implementatie echter was ongedocumenteerd en moest dus voor het wine project en gratis compilers via reverse engineering achterhaald worden. SEH is gebaseerd op exception handler frames op een stack te duwen, en ze dan toe te voegen aan een lijst die opgeslagen is in de thread local storage (het eerste veld van de thread environment blok). Wanneer er een uitzondering voordoet, gaan de kernel en de basis libraries de stack running handlers en filter af wanneer ze zich voordoen. Uiteindelijk zal elke uitzondering, die niet behandeld wordt door de toepassing zelf, opgevangen worden door de standaard backstop, die de Windows common crash dialoog weergeeft.
Zie ook
Externe links
