Aan de slag

Op de eerste plaats is het ontwikkelen van een besturingssysteem waarschijnlijk een van de meest uitdagende dingen die je op een computer kunt doen (naast het doden van de eindbaas in Doom op de moeilijkheidsgraad Nightmare). Het samenstellen van een besturingssysteem vereist veel kennis over verschillende complexe gebieden binnen de informatica. Je moet begrijpen hoe hardware werkt en de complexe assembleertaal kunnen lezen en schrijven, evenals een taal op hoger niveau (zoals C, C++, of Pascal). Je geest moet in staat zijn om abstracte theorieën te doorgronden en een groot aantal gedachten vast te houden. Voel je je al ontmoedigd? Vrees niet! Want al deze dingen zijn ook de dingen die OS programmeren leuk en onderhoudend maken.

Er gaat niets boven het gevoel van voltooiing wanneer je, eindelijk, na uren worstelen, het probleem oplost. En na enige tijd ben je in staat om terug te kijken en alle dingen te zien die je hebt gemaakt vanuit het niets. Je handgeschreven systeem is in staat om op te starten, voert magie uit tegen de hardware, en geeft de gebruiker een gebruikersinterface en programma’s om mee te spelen.

Er is geen absoluut pad dat je moet nemen bij het maken van een OS. Als je eenmaal je eerste systeem draaiend hebt (en dat doe je door de juiste tutorials te vinden), kies je de weg die je daarna wilt volgen. Jouw OS is precies dat–van jou. Jij hebt de ultieme controle, en de sky is the limit!

• 1 De harde waarheid
• 2 Verantwoordelijkheid
• 3 Vereiste kennis
• 4 Organiseer uw plannen
• 5 Kiezen van uw ontwikkelomgeving
  • 5.1 GNU/Linux
  • 5.2 Windows
  • 5.3 MacOS
• 6 Het testen van uw besturingssysteem
• 7 Het beschermen van uw code
• 8 Gemeenschappelijke startpunten
• 9 Het verkrijgen van verdere kennis
• 10 Zie ook
  • 10.1 Artikelen
  • 10.2 Threads
  • 10.3 External Links

De harde waarheid

Hooplijk ontmoedigt het basisfeit dat besturingssysteemontwikkeling een gecompliceerd en doorlopend proces is, u niet. De waarheid is dat het ontwikkelen van een besturingssysteem werkelijk ongeëvenaard is, omdat het het uiterste aan geduld en zorgvuldig code-ontwerp vereist, en het geeft weinig tot geen “onmiddellijke voldoening” die je krijgt van het ontwikkelen van dingen als spelletjes en web-based scripting.

Je bent redelijk gewaarschuwd voor het harde werk dat je te wachten staat, maar als je nog steeds geïnteresseerd bent, ga dan verder in het rijk van de besturingssysteemprogrammeur. Bereid u voor op incidentele vlagen van verwarring, ontmoediging, en voor sommigen van ons…tijdelijke krankzinnigheid. Na verloop van tijd, en met genoeg toewijding, zul je jezelf terugvinden onder de elite weinigen die hebben bijgedragen aan een werkend besturingssysteem. Als je onderweg ontmoedigd raakt, verfris jezelf dan met de inhoud van dit boek. Hopelijk herinnert het u eraan waarom u in de eerste plaats aan zo’n waanzinnige reis bent begonnen.

In dit stadium zou het ook de moeite lonen om de Beginnersfouten pagina te lezen. Gebruikers op het forum hebben gemerkt dat veel van deze fouten in de loop van de tijd worden herhaald, en het vermijden ervan is een geweldige manier om jezelf niet voor gek te zetten.

Verantwoordelijkheid

Mensen hebben de neiging om te beweren dat het OK is om inefficiënte software te schrijven, door te stellen dat computersystemen tegenwoordig zo snel zijn, dat je de impact niet zult zien. Dit soort mentaliteit is gevaarlijk bij het ontwerpen van besturingssystemen. Het is misschien OK om slordige code te schrijven als je een eenvoudige applicatie maakt, maar als het gaat om kritieke code die duizenden keren per seconde kan worden aangeroepen, moet je alle overhead eruit halen die je kunt. Het besturingssysteem moet de computer leveren als een basisbron voor de draaiende applicaties, met zo weinig mogelijk complicatie, abstractie en overhead.

Mensen die vandaag de dag besturingssystemen ontwerpen hebben de neiging om de “alles behalve de gootsteen” mentaliteit te hebben. Ze nemen het op zich om overal rekening mee te houden, wat natuurlijk goed is, maar het moet niet ten koste gaan van het laten floreren van slecht geschreven programma’s. Er zijn veel dingen die “onder de motorkap” gebeuren wanneer programmafouten optreden. Slecht geschreven programma’s kosten kostbare uitvoeringstijd en impliceren taakwisselingen die duur zijn in zowel geheugen als frequentie. Wij moedigen u aan om slecht geschreven software te ontmoedigen.

Vereiste Kennis

Hoofdartikel: Benodigde Kennis

Als u denkt dat u dit kunt overslaan, dan is deze pagina voor u.

Dit gedeelte is verplaatst naar een aparte pagina omdat er zo vaak naar verwezen wordt in forum discussies.

Organiseer uw plannen

Voordat u verder gaat, bedenk wat het is dat u wilt bereiken met het schrijven van een besturingssysteem. Wat zijn uw beweegredenen om aan dit project te beginnen? Er zijn veel mogelijke redenen om een hobby OS-project te beginnen, en de meeste os-devers hebben er meer dan een. Zelfs gewoon zeggen, “ik wil het gewoon” kan genoeg zijn, hoewel hoe meer u uw doelen en motieven overweegt en verduidelijkt, hoe meer u zich kunt concentreren op wat u werkelijk wilt.

Ben ook eerlijk tegen uzelf. Het is geen schande om grotere ambities te hebben voor je project, zelfs (of vooral) als ze niet het hoofddoel zijn. Probeer al je doelen te erkennen, niet alleen degene waarvan je denkt dat het je hoofddoel is.

Probeer vast te stellen in welke aspecten van OS-ontwerp je het meest geïnteresseerd bent of een noodzaak ziet om aan te werken. Het grootste deel van de ontwikkeling van een besturingssysteem, vooral in het begin, bestaat uit kernelontwerp en -ontwikkeling, maar de kernel zelf is slechts een klein onderdeel van de meeste besturingssystemen; als uw primaire interesse uitgaat naar UX, of netwerken, of driverprogrammering, moet u zich afvragen of u het echt nodig hebt (nu of in de toekomst) om uw eigen besturingssysteem te schrijven, of dat u net zo tevreden zou zijn met het ontwikkelen van die dingen op een bestaande kernel. Meer dan een paar mensen zijn OS-ontwikkeling gaan doen terwijl ze eigenlijk een desktop omgeving wilden ontwerpen, dus dit is een zeer belangrijke vraag om jezelf te stellen.

Probeer te denken aan niet-OS projecten die je misschien eerst, of tegelijkertijd, zou willen doen, vooral diegene die kunnen dienen als oefening of voorbereiding voor het OS project. Er is meestal geen noodzaak om nu al aan het OS project te werken, en hoe meer je van tevoren hebt voorbereid, hoe beter je af bent (tot op zekere hoogte, tenminste – voorbereiden is één ding, uitstellen is iets anders).

Zo ook, als je een bestaand ontwerp wilt forken om mee te experimenteren, of om aan te passen voor een specifiek doel, concentreer je daar dan op in plaats van op algemene ontwikkelingszaken. Bedenk welk deel van de bestaande code base je nodig hebt, en welke je wilt veranderen.

Probeer enkele van je specifieke projectdoelen uit te werken, en wees bereid om aparte projecten te plannen als dat helpt. Als u van plan bent gewoon wat te rommelen en te zien waar het u brengt, is dat prima; als het uw bedoeling is Microsoft omver te werpen, is dat ook prima (maar waarschijnlijk onrealistisch). Als u eenmaal weet wat u wilt doen, kunt u de details daarvan opsplitsen in specifieke doelstellingen, en uitwerken wat er nodig is om die te bereiken. Probeer niet te veel verschillende doelstellingen in één project te proppen-als je verschillende dingen wilt proberen met tegenstrijdige doelen, verdeel ze dan in verschillende projecten.

Het kan helpen als je een overzicht schrijft van je geplande OS ontwerp, met alle specifieke vereisten of details die je opmerkelijk vindt of die kunnen verduidelijken waar je hulp bij nodig hebt, en voeg het toe aan je publieke repository als je kunt. Dit maakt het niet alleen makkelijker voor anderen om je te helpen, het helpt je plannen te organiseren en te stabiliseren, net als het schrijven van een uittreksel voor een verhaal of paper. Wees bereid om het te onderhouden als je doelen en plannen veranderen, maar bewaar een kopie van oudere versies (of beter nog, bewaar het document onder versiebeheer), zodat je kunt zien hoe je werk zich in de loop van de tijd ontwikkelt.

Ten slotte, bekijk de tijd en middelen die het project zal vergen, en beslis of ze haalbaar zijn. Als u weet dat u slechts een bepaalde hoeveelheid tijd aan het project kunt besteden, houd daar dan rekening mee, en wat u ook doet, leg u niet vast op een externe deadline, zelfs als u er zeker van bent dat u die kunt halen. OS ontwikkeling kost tijd – veel tijd – en proberen een volledig OS project in een semester af te ronden is niet realistisch.

Kies je ontwikkelomgeving

Je hebt een platform nodig om je nieuwe systeem op te ontwikkelen. Volgens de trends van de algemene informatica, de meest populaire is GNU / Linux, maar velen gebruiken Windows ook. Ontwikkelaars die een GNU/Linux systeem gebruiken hebben een klein voordeel in de beschikbaarheid van gereedschappen, maar dit kan worden opgelost op Windows met behulp van een systeem als Cygwin of MinGW.

• Binutils: Fundamentele gereedschappen voor het manipuleren van object bestanden.
• GCC: De GNU Compiler Collection. GCC bevat compilers voor onder andere C, C++, Fortran en Ada.
• Make: Voor het automatiseren van het bouwproces, wat erg handig wordt als je meer dan een handvol bestanden hebt.
• Grep en sed: Voor het doen van meer krachtige zoekopdrachten en zoeken-en-vervangen (nuttig bij het invullen van tabellen met gegevens).
• Diffutils: Ongelooflijk handig om de verschillen tussen twee bestanden te laten zien.
• Perl of Python: Een van deze twee scripttalen moet worden geïnstalleerd. Nuttig voor string manipulatie, onder andere. Perl was vroeger de aanbeveling, maar Python is nu vrij volwassen en is mogelijk gemakkelijker te leren. Beiden hebben honderden pakketten/modules beschikbaar om verschillende taken uit te voeren.
• Een Assembler: Bijvoorbeeld NASM of GAS. Dit varieert afhankelijk van uw doel CPU architectuur.
• Een editor: Voor het schrijven van uw Assembly, C, en andere (code) bestanden.

U zult misschien niet al deze tools gebruiken, maar het is het beste om ze bij de hand te hebben “voor het geval dat,” en te weten hoe ze te gebruiken, zelfs op een basisniveau. Maar als u besluit een andere taal te gebruiken, dan is de keuze van het gereedschap grotendeels aan u en misschien zal de bovenstaande lijst u op geen enkele manier helpen. Hieronder staat de informatie die vooral betrekking heeft op de C/C++ of Assembly ontwikkelaars.

GNU/Linux

Het meest aanbevolen systeem voor OS ontwikkeling is GNU/Linux. Bij gebruik van GNU/Linux, zijn de meeste GNU ontwikkelgereedschappen waarschijnlijk al aanwezig. Zo niet, gebruik dan de pakketbeheer tools van je distributie (APT, RPM, Portage, Pacman, Apk, etc.) om ze te installeren als dat nodig is. Nogmaals, het maken van een cross-compiler is vereist, om niet te linken in de runtime bestanden van het ontwikkelsysteem.

Gemeenschappelijke editors zijn Vim, Emacs, KDevelop, Komodo Edit, etc. Sommigen geven de voorkeur aan lichtgewicht editors in plaats van een IDE, zoals gedit, Geany en SciTE. Velen houden van Midnight Commander, die een Text UI en een ingebouwde editor (mcedit) heeft en daardoor extreem lichtgewicht en bliksemsnel is.

Over welke distributies je zou moeten gebruiken, raadpleeg de lijst van Linux distributies. Ze zijn er in alle soorten en maten, en niet allemaal geschikt voor kernel ontwikkeling. Gebruik geen distro die een specifiek doel heeft, zoals beveiliging (Kali, Qubes, BackTrack, Parrot etc.), wetenschappelijke toepassingen (bijv. Scientific), firewalls en routing (bijv. DD-WRT), systeemherstel of embedded omgevingen (Knoppix, Rescatux, TinyCore) of specifiek gericht op beginners (zoals Linux Mint, Nitrux etc.) Hoewel een beginnersvriendelijke Linux zou kunnen voldoen, kies er een die een algemeen doel distro is. Gebruik ook een distro die up-to-date pakketten heeft, het beste is om er een te kiezen die rolling-release gebruikt. Debian is makkelijk te gebruiken, maar levert vaak oude, en gepatchte versies (de tools gedragen zich misschien niet zoals beschreven). Veel beginners houden van Ubuntu, wat prima is, maar er wordt gemeld dat het problemen heeft met sommige toolchains en compilatie-omgevingen (als je je eigen cross-compiler compileert in plaats van een geïnstalleerde te gebruiken, is dit geen probleem).

De beste distro’s voor kernel ontwikkeling zijn (maar houd in gedachten dat dit ook een kwestie van persoonlijke smaak is, dus deze distro’s zijn niet verplicht in plaats van aanbevolen, en ze vereisen meestal enige ervaring): Arch, Gentoo, Solus, Slackware, void etc. zelfs Puppy.

Als je niet zeker bent, probeer dan Ubuntu of Manjaro.

Windows

Om de benodigde tools te krijgen, zou je de Cygwin omgeving moeten installeren. MinGW of DJGPP zijn alternatieven, maar MSYS2 wordt sterk aangeraden omdat het de meest complete en compatibele omgeving is, en ook een package manager bevat om bibliotheken en tools te installeren.

Microsoft heeft onlangs (bij het schrijven) het Windows Subsystem voor Linux uitgebracht als een optionele functie voor Windows 10. Het is in principe een echte Ubuntu-opdrachtregel distributie die bovenop Windows draait ZONDER het gebruik van een VM. De nieuwste GCC en Binutils (6.1.0 en 2.27 vanaf dit moment) compileren en werken correct in deze omgeving. Met behulp van de Bash shell, kunt u toegang krijgen tot uw Windows harde schijven via /mnt/<drive letter>. Het voordeel van deze oplossing is dat u kunt werken met de Windows of Linux-gereedschappen die u nodig hebt, zonder uit te hoeven zoeken of ze werken in Cygwin. Veel van de benodigde gereedschappen kunnen worden geïnstalleerd met “apt-get”.

Voor al het bovenstaande wordt het sterk aangeraden om een cross-compiler te bouwen, niet alleen omdat de standaard compilers zich richten op verschillende uitvoerbare formaten, maar omdat het over het algemeen een goed idee is. Kijk op de GCC Cross-Compiler pagina voor details en instructies.

U heeft ook een editor nodig. Het gebruik van Notepad werkt, maar het is makkelijker als je een meer complete editor hebt. Bijvoorbeeld Notepad++ of Notepad2 worden door veel mensen gebruikt. Als u vertrouwd bent met Unix editors, kunt u er een kiezen uit de keuze die Cygwin biedt (waaronder bijvoorbeeld Vim en Emacs, die even wennen zijn, maar zeer krachtig).

Het is ook mogelijk om Visual Studio, of de gratis te downloaden Visual C++ Express Edition, te gebruiken om uw besturingssysteem te schrijven en te compileren. U hebt een speciaal configuratiebestand nodig, en u zult zeker in de minderheid zijn, maar het werkt vrij goed. U kunt zelfs de Windows SDK er bovenop installeren, waardoor 64 bit ontwikkeling mogelijk wordt. De enige valkuil is dat het geen Inline Assembly ondersteunt.

Andere programma’s zoals Watcom of Borland kunnen ook gebruikt worden, maar ze hebben elk hun eigen specifieke eisen en worden niet veel gebruikt voor dit soort werk.

MacOS

Omdat het onder de motorkap gebruik maakt van FreeBSD’s userland, is het volledig POSIX-compatibel. Alle gebruikelijke gereedschappen zijn beschikbaar (vi, bash, dd, cat, sed, tar, cpio, etc.) Bijna elke tutorial werkt out-of-the-box. De ontbrekende tools zijn meestal bestandssysteem gerelateerd: geen loopback device, geen fdisk, geen mkfs.vfat, noch mtools. Maar je kunt hiervoor diskutil gebruiken, of brew of macports om die missende tools te installeren.

Om gcc te krijgen, had je vroeger een mpkg op de 2e Installatie DVD voor de oudere versies. Nieuwere MacOS versies (10.13 en hoger) kunnen command line XCode installeren (niet de IDE, alleen de toolchain) door “xcode-select –install” te draaien vanuit een Terminal. Dit zal gcc, binutils en make installeren. Deze gcc is eigenlijk een gemasquaraded CLang, maar featurefull genoeg om je eigen cross-compiler te bouwen zonder problemen. Het verdient de voorkeur om de officiële compiler te gebruiken voor het opstarten van gcc, dan er een te installeren vanuit brew of macports.

Het testen van je besturingssysteem

Hoofdartikel: Testen

Het bovenstaande artikel gaat veel dieper in op de keuze hoe je je besturingssysteem gaat testen en hoe je dat integreert in je ontwikkelproces. Zowel fysieke als geëmuleerde testomgevingen worden besproken.

Het beschermen van uw code

Tijdens het bouwen van uw code zult u honderden, zelfs duizenden regels code schrijven. U besteedt een onnoemelijk aantal uren, en zit ’s avonds laat te coderen terwijl u eigenlijk naar bed zou moeten gaan. Het laatste wat je nodig hebt is een schijfcrash of een slecht geschreven ‘rm’ of ‘format’ commando dat al je werk weggooit.

Wat je nodig hebt is een versiebeheersysteem. CVS wordt al een aantal jaren gebruikt, maar heeft de laatste tijd veel concurrentie gekregen van Subversion, Bazaar, Mercurial, en Git. Als je kunt, zou je een externe computer of server moeten opzetten als versiebeheerserver, maar als je niet zo’n machine beschikbaar hebt, kun je het versiebeheersysteem ook hosten op je lokale ontwikkelcomputer. Vergeet alleen niet om af en toe een backup te maken van uw code op CD of FTP.

We kunnen dit punt niet sterk genoeg benadrukken: als u nog geen gebruik maakt van broncodebeheer, moet u daar onmiddellijk mee beginnen. U hoeft maar één keer een ernstige fout in uw code te maken om te beseffen hoe belangrijk het is dat uw code veilig is geversioneerd en gemakkelijk kan worden teruggevonden. Hoewel het misschien wat overdreven lijkt voor een klein, privé hobby project, als je er eenmaal aan gewend bent geraakt om revisiebeheer te gebruiken, zul je je afvragen hoe je ooit zonder hebt gekund.

Voor Git kun je je project aanmaken op GitHub. Bitbucket is ook een goed alternatief, omdat het zowel Git als Mercurial ondersteunt. Beide komen met gratis, privé repositories.

Een bijkomend voordeel van het gebruik van versiebeheer op een netwerk-toegankelijke repository is dat het een stuk makkelijker wordt om samen te werken met en hulp te krijgen van anderen. Dit kan heel nuttig zijn, vooral in forums, omdat je dan niet steeds bijgewerkte versies van je code in een berichtendraad hoeft te posten – je wijst het gesprek gewoon naar je repository, en de anderen in de draad hebben direct toegang tot je meest recente wijzigingen. Het is ook van cruciaal belang als, naarmate het project groeit, je begint samen te werken met andere ontwikkelaars aan het project (verwacht alleen niet dat dat van de ene op de andere dag gebeurt).

Gemeenschappelijke startpunten

De eenvoudigste manier om een “hello world” kernel op gang te krijgen is de Bare Bones tutorial. Een andere benadering zou zijn om te leren hoe de computer zelf opstart, op de Boot Sequence pagina.

Er zijn ook vele andere Tutorials beschikbaar.

Verdere kennis verkrijgen

Er is tegenwoordig een verbazingwekkende hoeveelheid kennis over besturingssysteemontwikkeling beschikbaar op het Internet. Het is gewoon een kwestie van het te vinden. Allereerst is er deze wiki zelf. We hebben onder andere veel Tutorials. Aangezien je hier bent, heb je die waarschijnlijk al gevonden. Ook op deze site is het forum, waar veel ontwikkelaars rondhangen en je kunnen helpen (maar zorg ervoor dat je eerst leest hoe je vragen moet stellen). Er zijn heel wat boeken over besturingssysteemontwikkeling geschreven. Een aantal daarvan zijn te vinden op onze Boeken pagina, en meer op osdever.net ook.

Zie ook

Artikelen