Jde o to, co kompilujete. Pojďme se podívat 30 let zpátky a programujme hru pro počítač Commodore Amiga. Máme na výběr několik jazyků, ale to není zajímavé. Zajímavé je, že máme na výběr, co bude výsledkem.
V téhle době je nejčastější volbou "binární image". Výsledkem je tedy posloupnost bytů, které se zapíší na disketu. Po startu počítače se načte základ OS z ROM. Z něj je zajímavá jediná věc - a sice že "olizuje" disketovou mechaniku a čeká, zda do ní někdo nějakou disketu vsune. Pokud ano, pak z ní načte první sektor do RAM a zkusí ho spustit jako binární kód.
Při výrobě diskety je tedy potřeba napsat si zavaděč, který se umístí na disketu. Ten si naprogramujeme třebas tak, že načte prvních 150KB z diskety, uloží je od adresy RAM 250000 a skočí na začátek. Ten zavaděč i těch 150KB je potřeba na disketu nějak zapsat, ale na to je celá řada programů. První chyták - nejsou to soubory. Nemáme žádný OS, který by tušil, co na disketě je. Pomocí obslužných rutin v ROM skutečně čteme konkrétní stopy a bloky, nikoliv soubory.
Vyrobit těch 150KB pak obnáší napsat si ten program, překladači říci, že bude uložen na adrese 250000 a nechat ho přeložit. Při psaní jste na tom jako s tím zavaděčem - máte jen základní ovládací rutiny v ROM. A v nich není skoro nic. Takže pokud chcete zobrazit černou obrazovku a uprostřed ní bílý kruh, pak si musíte nastudovat jak se ovládá grafický koprocesor. A hezky ručně mu nastavit hodnotu registrů, vygenerovat si bitmapu, nastrkat na správné místo v paměti a máte hotovo. Potřebujete přehrát zvuk? Tak opět příručku ke zvukovému koprocesoru a to dáte. Potřebujete něco složitějšího, například nakreslit na obrazovku okénko a kurzor, který jde ovládat myší? No tak jak se ovládá grafický koprocesor už víte, jak vytvářet bitmapovou grafiku si už nastudujete snadno. No a myš je snadná, je mapovaná na nějaké HW porty, tak si opět jen nastudujete na jaké a jak s ní komunikovat.
No a když už vám to funguje na vašem počítači, tak je čas začít řešit počítače jiné. Ty mohou mít více disketových mechanik a tak musíte zjistit, ve které vlastně vaše disketa je. A pak číst z té správné, nebo se prostě jen kousnout s chybou "sorry jako ale tohle jde spustit jen z FD0". A co více myší? Nebo jinak rozložená paměť? Chip RAM vs FAST RAM, aneb konflikt Amiga 500+ vs Amiga 500 + RAM modul.
Taková perlička, co některým na první pohled nedochází - na počítači běží váš program. Jen a pouze váš program. Jak doběhne, tak se počítač rebootuje a pak je možné spustit nějaký jiný program.
No, tak to máme "kompilujeme jako binární kód pro počítač". Nyní si proberem "kompilujeme jako spustitelný program pro operační systém". Vaše situace je v mnohém lepší - OS vám nabízí rovnou celou škálu ovladačů. Už nemusíte studovat jak ovládat konkrétní HW. A nemusíte ani studovat, jaký HW vlastně máte. Ani o natažení do paměti se starat nemusíte, to OS udělá za vás, včetně relokace programu na volnou adresu. I s tou disketou je práce rázem snadnější, protože váš program je soubor! A co víc, vy si můžete na disketu dát souborů víc a váš program si je pak za běhu může volně číst! Stačí mu k tomu znát název souboru, vůbec nemusí řešit na kterém bloku začíná a na kterém končí.
Co dál vám OS nabídnul? Třebas GUI! Nemusíte si programovat vlastní ovladač, vlastní rasterizaci, generování bitmap apod. Prostě jen zavoláte funkci OS a rázem máte na obrazovce okénko. Luxus! A co víc, tím okénkem jde hýbat, jde zvětšit, zmenšit, minimalizovat. A to vše bez nutnosti si to naprogramovat. A víte co? Těch oken je na obrazovce více a dokonce i z jiných programů! Vážně, už tam nejste sám.
Ale má to i stinné stránky. Najednou si nemůžete dělat co chcete a musíte respektovat pravidla. Když potřebujete kus RAM, tak si řeknete OS a on vám řekne kde a kolik jí máte k dispozici. Úleva je v tom, že si nemusíte z HW zjišťovat kolik a kde je RAM a pak si sledovat její využití. Přítěž v tom, že si nemůžete jen tak říci kde ji chcete mít a navíc ani tu RAM nemusíte dostat - buď už není dost volné pro vás, nebo (častěji) není volný takový kus v celku.
----
A teď do současnosti. Programy prvního typu se dnes prakticky nepíší. Když budete chtít pár příkladů, tak LILO, GRUB nebo VMware ESXi. Vy ale takový program psát nebudete, protože je to nad vaše síly. A navíc by to uživatele dost iritovalo - málokdo by dneska chtěl rebootovat jen proto, aby spustil váš program.
Prakticky vše je dnes ten druhý případ, spustitelný soubor pro nějaký OS. Ten soubor začíná instrukcemi pro OS. Tedy jaké části toho souboru vzít a kam je nakopírovat. Pak adresu, na kterou se má převést řízení. OS podle instrukcí vytvoří proces, zarezervuje RAM, vykopíruje kusy souboru na správné místo a nakonec zavolá ten binární kód. Samotný program pak, podle konvencí OS, volá služby OS. Dříve se to řešilo třebas tabulkou přerušení - do registrů jste napsal co potřebujete a vyvolal přerušení, na což zareagoval procesor přechodem do módu supervizoru a vyvolal obsluhu přerušení, což byla součást OS. Dnes se to prakticky vždy řeší tím, že ve vašem programu použijete nějakou hotovou knihovnu, například libc. Takže pro váš program je to defakto jen volání funkce. Co se děje na pozadí a jak vlastně k volání OS dojde už vás nezajímá. To za vás udělá ta knihovna. Jenže právě ta je v každém OS jiná. Win32, msvcrt.dll, libc, glibc atd.
Koukněte se sem:
https://wiki.osdev.org/VGA_Hardwarehttps://files.osdev.org/mirrors/geezer/osd/graphics/modes.cA pak si upřímně odpovězte na otázku, zda by se vám tohle chtělo programovat, nebo to raději necháte na OS a jeho ovladačích?