[C++] OS geschreven in C++, hoe zit dat.

[robertpNL]

Het is jullie abosluut opgevallen: een gedeelte van de source code van Windows is uitgelekt naar het Internet. En wat wij al wisten, is Windows geschreven in C++ (de source code bestaan o.a. uit .cpp en .h bestanden als ik zo zag).

Nu heb ik wat basiskennis over C++ maar ik vroeg mij eigenlijk het volgende af. Hoe kan je nou een C++ programma als OS laten functioneren? Een source code compileren gaat toch altijd naar een .exe? Deze moet toch functioenren onder een OS? Of praten wij over echt iets anders. Misschien een speciale compilers die de code omzetten naar een assembly (want dat moet het toch uiteindelijk worden?). Ik ben eigenlijk wel benieuwd hoe dit in elkaar zit. Wie vertelt hier wat meer over?

[Reptile209]

Lees [rml][ Alg] Hoe werkt een OS en hoe schrijf ik er zelf een?[/rml] eens door.
In het kort komt het er op neer dat je een bootsector moet maken (in asm) en die moet dan een kernel (in C bijvoorbeeld) gaan laden.

[Edit] (moest ff lunchen )
De bootsector beging volgens een bepaalde standaard-indeling en wordt door het bios geladen. Op dat moment kan je alle (?) BIOS-functies gebruiken. Deze eerste bootstrap laadt een kleine kernel, die bijvoorbeeld naar protected mode springt en begint met wat geheugenindeling e.d. Dan komt de echte kernel die alle OS-specifieke zaken mogelijk gaat maken.
Het zal je overigens niet lukken om iets als

C:

#include <stdio.h>

int main(int) {
  printf("Hello world");
  return 0;
}

te compileren naar hallo.exe en als "kernel" te gebruiken: alle standaard libraries maken gebruik van bijvoorbeeld int 21h (DOS-interrupt) die in je eigen kernel nog niet bestaat. Oftwel: alle OS-specifieke zaken mag je zelf gaan schrijven...

[ Voor 62% gewijzigd door Reptile209 op 13-02-2004 13:29 ]

[Macros]

Het OS is eigenlijk gewoon een programma dat op een speciale manier gestart wordt en altijd draait. Zie bovenste reply.
Wat veel vreemder is, is dat bijna alle C++ compilers zelf in C++ zijn geschreven.

[BCC]

Dit is beter bekend als het bootstrap probleem

[_the_crow_]

Inderdaad. Je kan alle zogenaamde BIOS-interrupts gebruiken. Dat zijn de interrupts 0x00 tot 0x1F. Elke interrupt heeft een aantal services, waar je dan bijvoorbeeld dingen mee op het scherm kan schrijven of iets naar je harddisk kan schrijven.
Maar zoals Reptile209 al zegt, zal je de bootsector in ASM moeten schrijven.

[ Voor 16% gewijzigd door _the_crow_ op 13-02-2004 14:25 ]

[robertpNL]

Hee iedereen onwijs bedankt voor de uitleg. Het is voor mij duidelijker geworden.

Reptile209 dank voor je link en uitleg.

edit:
tikfoutje

[ Voor 15% gewijzigd door robertpNL op 13-02-2004 14:47 ]

[CH4OS]

robertpNL schreef op 13 februari 2004 @ 12:25:
Nu heb ik wat basiskennis over C++ maar ik vroeg mij eigenlijk het volgende af. Hoe kan je nou een C++ programma als OS laten functioneren? Een source code compileren gaat toch altijd naar een .exe?

Je kan in C(++) ook Dynamic Link Libraries maken, en dat zijn de DLL-bestanden Dus het hoeft niet per se een exe te zijn...

Macros schreef op 13 februari 2004 @ 14:18:
Het OS is eigenlijk gewoon een programma dat op een speciale manier gestart wordt en altijd draait. Zie bovenste reply.
Wat veel vreemder is, is dat bijna alle C++ compilers zelf in C++ zijn geschreven.

Op mijn school hadden we het hier ook over (soort van dan). Kregen een soort van "Kip of het ei-verhaal" en ik denk niet dat dat hier de bedoeling is.

[ Voor 36% gewijzigd door CH4OS op 13-02-2004 14:50 ]

[Verwijderd]

De compiler zit als volgt, de eerste programma's werden in machine code geschreven, direct enenen en nullen, of de hexadecimale representatie hiervan. Daarna kwam assembly, toen a toen b en uiteindelijk c. Telkens werd de eerste compiler in de voorganger geschreven. Daarna werden latere versie's van de compilers in de taal zelf geschreven.

[Soultaker]

Dat compiler-verhaal is vrij simpel: meestal wordt eerst een compiler voor een nieuwe taal Y geschreven in een bestaande taal X. Als die compiler goed (genoeg) werkt, wordt de compiler herschreven in taal Y en met de oude compiler (geschreven in taal X) gecompileerd. Vanaf dan bestaat er een Y-compiler geschreven in Y die zichzelf kan compileren.

edit:
Wat ultimate zegt dus.

[ Voor 6% gewijzigd door Soultaker op 13-02-2004 15:36 ]

[Macros]

Op den duur evolueren compilers zo, dat er geen werkende compiler meer bestaat in een andere taal, behalve de eigen taal. 1 Van de eerste C-compiler schrijvers had een back-door geschreven in zijn compiler, als iemand dan die backdoor wilde verwijderen door de source aan te passen van de compiler en het opnieuw te compilen, detecteerde de compiler zijn eigen source code en voegde de backdoor zelf weer toe (inclusief het voeg backdoor weer toe mechanisme). Pas toen er een andere compiler werd gebruikt kregen ze die backdoor eruit

[.oisyn]

robertpNL schreef op 13 februari 2004 @ 12:25:
Nu heb ik wat basiskennis over C++ maar ik vroeg mij eigenlijk het volgende af. Hoe kan je nou een C++ programma als OS laten functioneren? Een source code compileren gaat toch altijd naar een .exe? Deze moet toch functioenren onder een OS? Of praten wij over echt iets anders. Misschien een speciale compilers die de code omzetten naar een assembly (want dat moet het toch uiteindelijk worden?). Ik ben eigenlijk wel benieuwd hoe dit in elkaar zit. Wie vertelt hier wat meer over?

De compilers waar je het over hebt zetten code sowieso om naar cpu-uitvoerbare assembly-code. Veel C++ compilers hebben de optie om geen objectfiles te maken, maar assembly-files te outputten. Uiteindelijk zorgt de linker ervoor dat alle verschillende gecompileerde object files bij elkaar worden gevoegd en het geheel in een voor een OS uitvoerbaar fileformaat stoppen. Je zou zelf een linker kunnen schrijven die een ander formaat gebruikt (maar er zal altijd uitvoerbare assembly-code in staan).

Goed, als je dus zo'n linker hebt gemaakt, en de bootloader die al naar voren was gekomen, dan kun je dus vanuit je assembly code in de bootloader direct een C++ functie aanroepen die je hebt gecompiled met een reguliere compiler

[.oisyn]

Macros schreef op 13 februari 2004 @ 15:46:
Op den duur evolueren compilers zo, dat er geen werkende compiler meer bestaat in een andere taal, behalve de eigen taal. 1 Van de eerste C-compiler schrijvers had een back-door geschreven in zijn compiler, als iemand dan die backdoor wilde verwijderen door de source aan te passen van de compiler en het opnieuw te compilen, detecteerde de compiler zijn eigen source code en voegde de backdoor zelf weer toe (inclusief het voeg backdoor weer toe mechanisme). Pas toen er een andere compiler werd gebruikt kregen ze die backdoor eruit

Nee het zat anders. Geen idee of het trouwens ook een backdoor was of een virus, maar volgens mij was het sowieso theoretisch en dus niet echt gebeurd.

Je bouwt eerst een werkende compiler dat z'n eigen taal kan compileren, de sourcecode daarvan bewaar je. Dan ga je aan de source toevoegen dat ie aan elk gecompileerd programma een backdoor toevoegt. Compileer je nieuwe compiler met de huidige, deze compiler noemen we even C1. Alle executables gecompileerd met deze compiler krijgen automatisch een backdoor, maar de compiler zelf heeft nog geen backdoor. Gooi nu de aangepaste source weer weg. Compileer de oude source met C1 en het resultaat is C2, een compiler met een backdoor, dat tevens een backdoor toevoegd aan alle geproduceerde executables. Aangezien je de aangepaste source hebt weggegooid is er geen bewijs dat de compiler dat doet, je kunt de oude source compileren maar er komt altijd een compiler uit dat backdoors toevoegt. Het herkennen van de source is dus ook niet nodig, de backdoor hoeft er niet eens in te staan. De enige manier om hier vanaf te komen is te compileren met een andere compiler

[Macros]

Sorry .oisyn, dat is niet wat ik heb gelezen. Teneerste was het wel echt gebeurd en ten tweede voegde hij het alleen in de compiler toe, en niet bij alle programma's die het compiled. Hij deed het alleen bij zichzelf. Misschien vind ik de originele bron nog een keer.

[_Squatt_]

Link naar het artikel: Reflections on Trusting Trust