Kom igång

För det första är utvecklingen av ett operativsystem förmodligen en av de mest utmanande sakerna du kan göra på en dator (näst efter att döda slutbossen i Doom på svårighetsgraden Nightmare). Att komponera ett operativsystem kräver mycket kunskap om flera komplexa områden inom datavetenskap. Du måste förstå hur hårdvaran fungerar och kunna läsa och skriva det komplexa assemblerspråket samt ett språk på högre nivå (t.ex. C, C++ eller Pascal). Ditt sinne måste kunna svepa in sig i abstrakta teorier och hålla en myriad av tankar. Känner du dig avskräckt ännu? Var inte rädd! För alla dessa saker är också de saker som gör OS-programmering rolig och underhållande.

Det finns inget som känslan av prestation när du äntligen, efter att ha kämpat i timmar, löser problemet. Och efter en tid kan du titta tillbaka och se alla de saker som du har skapat från grunden. Ditt handskrivna system kan starta upp, utför magi mot hårdvaran och ger användaren ett användargränssnitt och program att leka med.

Det finns ingen absolut väg du måste gå när du skapar ett operativsystem. När du väl fått igång ditt första system (och det gör du genom att hitta lämpliga handledningar) väljer du vilken väg du vill ta härnäst. Ditt operativsystem är exakt det – ditt. Du har den yttersta kontrollen, och himlen är gränsen!

• 1 Den hårda sanningen
• 2 Ansvar
• 3 Nödvändiga kunskaper
• 4 Organisera dina planer
• 5 Välj din utvecklingsmiljö
  • 5.1 GNU/Linux
  • 5.2 Windows
  • 5.3 MacOS
• 6 Testa ditt operativsystem
• 7 Skydda din kod
• 8 Gemensamma utgångspunkter
• 9 Skaffa ytterligare kunskap
• 10 Se även
  • 10.1 Artiklar
  • 10.2 Trådar
  • 10.3 Externa länkar

Den hårda sanningen

Förhoppningsvis avskräcker inte det grundläggande faktum att utveckling av operativsystem är en komplicerad och pågående process dig. Sanningen är att utveckling av operativsystem är verkligen oöverträffad eftersom den kräver ytterst mycket tålamod och noggrann koddesign, och den ger mycket lite eller ingen ”omedelbar tillfredsställelse” som du får från utvecklingen av saker som spel och webbaserade skript.

Du har blivit rättvist förvarnad om det hårda arbetet som väntar dig, men om du fortfarande är intresserad, fortsätt då framåt in i operativsystemsutvecklarens sfär. Förbered dig på tillfälliga anfall av förvirring, modlöshet och för vissa av oss … tillfällig galenskap. Med tiden, och med tillräcklig hängivenhet, kommer du att befinna dig bland de få eliten som har bidragit till ett fungerande operativsystem. Om du blir avskräckt på vägen kan du uppdatera dig med innehållet i den här boken. Förhoppningsvis kommer det att påminna dig om varför du inledde en sådan vansinnig resa från början.

I det här skedet kan det också löna sig att läsa sidan Nybörjarmisstag. Användare på forumet har märkt att många av dessa misstag upprepas med tiden, och att undvika dem är ett bra sätt att inte göra bort dig.

Ansvar

Människor tenderar att hävda att det är okej att skriva ineffektiva programvaror, och hävdar att datorsystemen är så snabba nuförtiden att du inte kommer att märka effekterna. Denna typ av mentalitet är farlig vid utformning av operativsystem. Det kan vara OK att skriva slarvig kod när man gör ett enkelt program, men när det gäller kritisk kod som kan bli anropad tusentals gånger i sekunden måste man ta bort all overhead man kan. Operativsystemet bör tillhandahålla datorn som en grundläggande resurs för de program som körs, med så lite komplikationer, abstraktion och overhead som möjligt.

De personer som utformar operativsystem i vår tid tenderar att ha ”allt utom diskbänken”-mentaliteten. De tar på sig att ta hänsyn till allt, vilket naturligtvis är bra, men det bör inte göras på bekostnad av att låta dåligt skrivna program blomstra. Det finns många saker som händer ”under huven” när programfel uppstår. Dåligt skrivna program kostar dyrbar exekveringstid och innebär uppgiftsväxlingar som är kostsamma i både minne och frekvens. Vi uppmuntrar dig att avskräcka från dåligt skrivna program.

Krävda kunskaper

Huvudartikel:

Om du tror att du kan hoppa över det här är det bara för dig.

Det här avsnittet har flyttats till en separat sida eftersom det refereras till så ofta i forumdiskussioner.

Organisera dina planer

Innan du går vidare ska du fundera på vad det är du vill få ut av att skriva ett operativsystem. Vilka är dina motiv för att ta dig an det här projektet? Det finns många möjliga anledningar till att ta sig an ett hobbyprojekt för operativsystem, och de flesta os-utvecklare har mer än en. Det kan räcka med att bara säga ”jag vill bara”, men ju mer du funderar över och klargör dina mål och motiv, desto mer kan du fokusera på vad du verkligen vill.

Var ärlig mot dig själv också. Det är ingen skam att ha större ambitioner för ditt projekt, även (eller särskilt) om de inte är det primära målet. Försök att erkänna alla dina mål, inte bara det du tror är ditt huvudsyfte.

Försök att bestämma dig för vilka aspekter av OS-designen du är mest intresserad av eller ser ett behov av att arbeta med. Det mesta som ingår i utvecklingen av operativsystem, särskilt i ett tidigt skede, är kärnans utformning och utveckling, men själva kärnan är bara en liten del av de flesta operativsystem. Om ditt primära intresse är UX, nätverk eller drivrutinsprogrammering bör du fundera på om du verkligen behöver (nu eller i framtiden) skriva ett eget operativsystem överhuvudtaget eller om du skulle vara lika nöjd med att utveckla dessa saker på en befintlig kärna. Mer än ett fåtal personer har gått in i OS-utveckling när de egentligen ville utforma en skrivbordsmiljö, så detta är en mycket viktig fråga att ställa sig.

Försök att tänka på alla projekt som inte är OS-projekt och som du kanske vill ta dig an först eller samtidigt, särskilt sådana som kan fungera som övning eller förberedelse för OS-projektet. Det finns vanligtvis inget behov av att arbeta med OS-projektet just nu, och ju mer du har förberett dig i förväg, desto bättre kommer du att klara dig (åtminstone till en viss punkt – förberedelser är en sak, uppskjutande är något annat).

Samma sak, om du tänker arbeta med att forka en befintlig konstruktion för att experimentera med, eller för att modifiera den för något specifikt ändamål, fokusera på det snarare än på allmänna utvecklingsfrågor. Tänk på vilken del av den befintliga kodbasen du kommer att behöva och vilka du vill ändra.

Försök att utarbeta några av dina specifika projektmål och var beredd att planera separata projekt om det hjälper. Om du helt enkelt har för avsikt att bara rota runt och se vart det leder dig är det okej; om du har för avsikt att störta Microsoft är det också okej (även om det förmodligen är orealistiskt). När du väl vet vad du vill göra kan du dela upp detaljerna i specifika mål och räkna ut vad som krävs för att nå dem. Försök inte tvinga in för många olika mål i ett och samma projekt – om du har olika saker som du vill prova med motstridiga mål, dela upp dem i olika projekt.

Det kan vara till hjälp om du skriver en översikt över din planerade OS-design, med alla specifika krav eller detaljer som du tycker är anmärkningsvärda eller som skulle kunna förtydliga vad du behöver hjälp med, och lägg till den i ditt offentliga repository om du kan. Detta kommer inte bara att göra det lättare för andra att hjälpa dig, det kommer att hjälpa till att organisera och stabilisera dina planer, ungefär som att skriva en översikt för en berättelse eller en uppsats. Var beredd på att underhålla det när dina mål och planer förändras, men behåll en kopia av äldre versioner (eller ännu bättre, förvara dokumentet under versionskontroll) så att du kan se hur ditt arbete utvecklas med tiden.

Slutligt, gå igenom den tid och de resurser som projektet kommer att kräva, och bestäm om de är genomförbara. Om du vet att du bara har en viss tid att ägna åt projektet ska du ta hänsyn till det, och vad du än gör ska du inte binda dig till en tidsfrist utifrån, även om du är säker på att du kan nå den. OS-utveckling tar tid – mycket tid – och att försöka avsluta ett helt OS-projekt på en termin är inte realistiskt.

Välja din utvecklingsmiljö

Du behöver en plattform att utveckla ditt nya system på. I enlighet med trenderna inom allmän databehandling är GNU/Linux den mest populära, men många använder också Windows. Utvecklare som använder ett GNU/Linux-system har en liten fördel när det gäller tillgången till verktyg, men detta kan lösas på Windows med hjälp av ett system som Cygwin eller MinGW.

• Binutils: Grundläggande verktyg för hantering av objektfiler.
• GCC: GNU Compiler Collection. GCC innehåller kompilatorer för bland annat C, C++, Fortran och Ada.
• Make: För att automatisera byggprocessen, vilket blir mycket användbart när man har mer än en handfull filer.
• Grep och sed: För att göra mer kraftfulla sökningar och sök-och-ersättande (användbart när du fyller ut tabeller med data).
• Diffutils: För att göra mer kraftfulla sökningar och sök-och-ersättande (användbart när du fyller ut tabeller med data): Otroligt användbart för att visa skillnaderna mellan två filer.
• Perl eller Python: Ett av dessa två skriptspråk bör installeras. Användbart för bland annat strängmanipulation. Perl brukade vara rekommendationen, men Python är nu ganska moget och är möjligen lättare att lära sig. Båda har hundratals paket/moduler tillgängliga för att utföra olika uppgifter.
• En assembler: Till exempel NASM eller GAS. Detta varierar beroende på din mål-CPU-arkitektur.
• En editor: Du kanske inte använder alla dessa verktyg, men det är bäst att ha dem till hands ”för säkerhets skull” och veta hur man använder dem, även på en grundläggande nivå. Men om du bestämt dig för att använda ett annat språk så är verktygen mestadels upp till dig och kanske är listan ovan helt enkelt inte till någon hjälp för dig på något sätt. Nedan finns information som främst gäller C/C++- eller Assembly-utvecklare.
  

  GNU/Linux

  Det mest rekommenderade systemet för utveckling av operativsystem är GNU/Linux. När man använder GNU/Linux finns förmodligen de flesta av GNUs utvecklingsverktyg redan tillgängliga. Om inte, använd din distributions pakethanteringsverktyg (APT, RPM, Portage, Pacman, Apk, etc.) för att installera dem vid behov. Återigen krävs det att man gör en tvärkompilator för att inte länka in utvecklingssystemets körtidsfiler.

  Gemensamma redigeringsprogram är Vim, Emacs, KDevelop, Komodo Edit osv. Vissa föredrar lättviktsredigerare i stället för en IDE, t.ex. gedit, Geany och SciTE. Många gillar Midnight Commander som har ett textgränssnitt och en inbyggd redigerare (mcedit) och därför är extremt lätt och blixtsnabbt.

  Om vilka distributioner du bör använda, se listan över Linux-distributioner. De finns i alla former och storlekar, och alla lämpar sig inte för kärnutveckling. Använd inte en distro som har ett specifikt mål, som säkerhet (Kali, Qubes, BackTrack, Parrot etc.), vetenskapliga tillämpningar (t.ex. Scientific), brandväggar och routing (t.ex. DD-WRT), systemåterställning eller inbäddade miljöer (Knoppix, Rescatux, TinyCore) eller som är specifikt inriktad på nybörjare (som Linux Mint, Nitrux etc.) Även om en nybörjarvänlig Linux skulle kunna duga, välj en som är en distro för allmänna ändamål. Använd också en distro som har uppdaterade paket, bäst är att välja en som använder rolling-release. Debian är lätt att använda, men levererar ofta gamla och patchade versioner (verktygen kanske inte beter sig som beskrivet). Många nybörjare gillar Ubuntu, vilket är bra, men det rapporteras ha problem med vissa verktygskedjor och kompileringsmiljöer (om du kompilerar din egen tvärkompilator i stället för att använda en installerad är detta inget problem).

  De bästa distroarna för kärnutveckling är (men kom ihåg att detta också är en fråga om personlig smak, så dessa distroar är inte obligatoriska snarare rekommenderade, och de kräver vanligtvis viss erfarenhet): Arch, Gentoo, Solus, Slackware, void etc. även Puppy.

  Om du är osäker kan du prova Ubuntu eller Manjaro.

  Windows

  För att få de nödvändiga verktygen bör du installera Cygwin-miljön. MinGW eller DJGPP är alternativ, men MSYS2 rekommenderas starkt eftersom det är den mest kompletta och kompatibla miljön och dessutom innehåller en pakethanterare för att installera bibliotek och verktyg.

  Microsoft har nyligen (i skrivande stund) släppt Windows Subsystem for Linux som en valfri funktion för Windows 10. Det är i princip en riktig Ubuntu-kommandoradsdistribution som körs ovanpå Windows UTAN användning av en virtuell maskin. De senaste GCC och Binutils (6.1.0 och 2.27 i skrivande stund) kompilerar och fungerar korrekt i denna miljö. Med hjälp av Bash-skalet kan du komma åt dina Windows-hårddiskar via /mnt/<drive letter>. Fördelen med denna lösning är att du kan arbeta med de Windows- eller Linuxverktyg som du behöver, utan att behöva ta reda på om de fungerar i Cygwin. Många av de nödvändiga verktygen kan installeras med hjälp av ”apt-get”.

  För alla ovanstående är det starkt rekommenderat att bygga en korskompilator, inte bara för att standardkompilatorerna är inriktade på olika exekverbara format, utan också för att det generellt sett är en bra idé. Se sidan GCC Cross-Compiler för detaljer och instruktioner.

  Du kommer också att behöva en editor. Att använda Notepad fungerar, men det är lättare om du har en mer komplett editor. Till exempel används Notepad++ eller Notepad2 av många. Om du är bekväm med Unix-redigerare kan du välja en av det utbud som Cygwin tillhandahåller (vilket inkluderar t.ex. Vim och Emacs, som kräver lite tillvänjning men är mycket kraftfulla).

  Det är också möjligt att använda Visual Studio, eller den fritt nedladdningsbara Visual C++ Express Edition, för att skriva och kompilera ditt operativsystem. Du kommer att behöva en speciell konfigurationsfil, och du kommer säkert att vara i minoritet, men det fungerar ganska bra. Du kan till och med installera Windows SDK ovanpå, vilket möjliggör 64-bitarsutveckling. Den enda haken är att detta inte stöder Inline Assembly.

  Andra verktyg som Watcom eller Borland kan också användas, men de har var och en sina egna specifika krav och används inte i stor utsträckning för den här typen av arbete.

  MacOS

  Då det under huven använder FreeBSD:s userland, är det helt POSIX-kompatibelt. Alla de vanliga verktygen finns tillgängliga (vi, bash, dd, cat, sed, tar, cpio, etc.) Nästan alla handledningar fungerar utan problem. De verktyg som saknas är mestadels filsystemrelaterade: ingen loopback-enhet, ingen fdisk, ingen mkfs.vfat eller mtools. Men du kan använda diskutil för dessa ändamål, eller använda brew eller macports för att installera de saknade verktygen.

  För att få gcc brukade du ha en mpkg på den andra installations-dvd:n för de äldre versionerna. Nyare MacOS-versioner (10.13 och uppåt) kan installera XCode på kommandoraden (inte IDE, bara verktygskedjan) genom att köra ”xcode-select –install” från en terminal. Detta kommer att installera gcc, binutils och make. Denna gcc är i själva verket en masquaraded CLang, men med tillräckligt många funktioner för att du ska kunna bygga din egen tvärkompilator utan problem. Det är att föredra att använda den officiella kompilatorn för att bootstrappa gcc än att installera en från brew eller macports.

  Testa ditt operativsystem

  Huvudartikel: Testning

  Ovanstående artikel går mycket på djupet när det gäller att välja hur du ska testa ditt operativsystem och hur du ska integrera det i din utvecklingsprocess. Både fysiska och emulerade testmiljöer diskuteras.

  Skydda din kod

  Under kodbyggandet kommer du att skriva hundratals, till och med tusentals rader kod. Du kommer att tillbringa ett obeskrivligt antal timmar och sitta uppe sent på natten och koda när du egentligen borde gå och lägga dig. Det sista du behöver är en diskkrasch eller ett dåligt skrivet ”rm”- eller ”format”-kommando som kastar bort allt ditt arbete.

  Vad du behöver är ett versionskontrollsystem. CVS har använts i ett antal år, men har fått mycket konkurrens från Subversion, Bazaar, Mercurial och Git på senare tid. Om du har möjlighet bör du sätta upp en fjärrdator eller server som versionskontrollserver, men om du inte har en sådan maskin tillgänglig kan du också vara värd för versionskontrollsystemet på din lokala utvecklingsdator. Kom bara ihåg att säkerhetskopiera din kod på CD eller FTP då och då.

  Vi kan inte nog betona detta: om du inte redan använder källhantering bör du börja göra det omedelbart. Du behöver bara göra ett allvarligt fel i din kod en gång för att inse hur viktigt det är att din kod är säkert versionerad och lätt att hämta. Även om det kan tyckas vara överdrivet för ett litet, privat hobbyprojekt, kommer du att undra hur du någonsin klarade dig utan det när du väl har vant dig vid att använda revisionskontroll.

  För Git kan du skapa ditt projekt på GitHub. Bitbucket är också ett bra alternativ eftersom det stöder både Git och Mercurial. Båda har gratis, privata arkiv.

  En ytterligare fördel med att använda versionskontroll på ett arkiv som är tillgängligt via nätverket är att det gör det mycket lättare att samarbeta med och få hjälp av andra. Detta kan vara ganska användbart, särskilt i forum, eftersom det kan undvika behovet av att ständigt lägga upp uppdaterade versioner av din kod i en meddelandetråd – du pekar helt enkelt konversationen mot ditt arkiv, och de andra i tråden får direkt tillgång till dina mest aktuella ändringar. Det är också avgörande om du i takt med att projektet växer börjar samarbeta med andra utvecklare i projektet (förvänta dig bara inte att det ska ske över en natt).

  Gemensamma utgångspunkter

  Det enklaste sättet att få igång en ”hello world”-kärna är Bare Bones-tutorialen. Ett annat tillvägagångssätt är att lära sig hur själva datorn startar, på sidan Boot Sequence.

  Det finns många andra handledningar tillgängliga också.

  Skaffa ytterligare kunskap

  Det finns en otrolig mängd kunskap om utveckling av operativsystem tillgänglig på Internet idag. Det är bara en fråga om att hitta den. Först och främst finns den här wikin själv. Här finns bland annat massor av handledningar. Eftersom du är här har du förmodligen redan hittat den. På den här webbplatsen finns också forumet, där många utvecklare umgås och kan hjälpa dig (men se till att du läser How To Ask Questions först). Det har skrivits en hel del böcker om utveckling av operativsystem. Ett antal av dessa finns på vår sida om böcker, och fler finns också på osdever.net.

  Se även

  Artiklar