ReactOS 0.4.9 (diskuse)

[otasomil]

Jo vzpominam pred lety jak jsem si hral a vidim ze doba pokrocila. Skoda jen ze dnes bych uz prakticky nevyuzil.
Taky zajimavy projekt je Menuet OS Kdoby tusil ze na jedinou disketu se vejde jakysi OS s GUI

[ed]

S Menuet OS som sa zabaval nejakych 15 rokov dozadu, ked som este nevedel o tom, ako dostat rozumny Linux na Pentium 133. Vtedy to pre mna bolo zaujimave.

Dnes sa mi z x86 assembly obracia zaludok a pri pomysleni na implementaciu ochrany pamate na Inteli ma chytaju mdloby. Programovanie sebevacsich aplikacii v assembleri je podla mna dnes ista forma sebatryznenia.

Veci, co sa vosli na jednu disketu bolo habadej. Namatkovo demo disketa QNX-u mala na standardnej 3,5" flopke svojho casu GUIko snad aj prehliadacom a cele to bezalo na sebevykonnejsej 386tke, co mala aspon 8 MB RAM. Kym mal Linux podporu bootovania z diskiet, tak slo na jednu/dve diskety dostat aj rozumnejsie skompilovany Linux spolu aj s GUI. Ale to uz bol dost masochizmus.

[xkucf03]

+1, mít to na jedné disketě nebo pouštět na prastarém hardwaru zajímavé je – ale to je tak všechno – z dnešního pohledu mi takový OS nedává smysl. A už vůbec ne psát to v assembleru – ono i to tradiční Céčko je na psaní OS hodně nízkoúrovňově¹ a zajímavý by dneska byl spíš OS psaný v nějakém vyšším jazyce (existují pokusy v Rustu, C++, dokonce i nějaká ta Java).

_{[1] on OS řeší i spoustu jiných věcí než přehazování bajtů z jedné hromádky na druhou a kontakt s hardwarem a jsou i jiné priority než extrémní výkon – kromě toho se ukazuje, že kompilátor odvede lepší práci než většina programátorů v assembleru – a pro céčko a vyšší jazyky to asi bude platit taky}

[ed]

C-cko je len tak nizkourovnove (citaj: hnusne) ako si ho programator spravi. Ze by bola nejaka velka vyhra tahat do pomerne nizkych (ale aj vysokych) vrstiev OS vyssie jazyky nez dajme tomu C++ (resp. obecne cokolvek, co ma tucny runtime environment alebo virtualny stroj) by som nepovedal. Staci sa pozriet aky dopad na vykon v specifickych scenaroch ma taka elementarna zmena ako monoliticky vs. mikrokernel.

Ale ked sa to raz napise v assembleri, tak je to proste cele na veky vekuce zadratovane na tej jednej platforme. Neexistuje nieco take, ze sa preportuje API a cele sa to prelozi na inu architekturu. Vsetko je treba pisat od nuly. Pouzitie assemblera zvadza k neexistujucim ABI a overly optimized runtime.

Co robi programy vo vyssich programovacich jazykoch pomale je podla mna kombinacia standardnej volacej konvencie C-cka tak, ako je pouzita na x86tke s velmi ubohym designom tejto architektury. V podstate pre ABI neexistuje iny rozumny a portabilny sposob, ako predavat argumenty, nez pouzivat zasobnik a to je pomale. V obmedzenej miere ide pouzit nieco ako fastcall, ale ten ma realny zmysel az na AMD64, kde je pouzitelne mnozstvo registrov.

Trocha slusny prekladac na AMD64 s Itanium ABI vygeneruje assembly s ktorym by mal ludsky programator dost vela roboty, aby z neho vymackal este nejaky vykon navyse bez toho, aby rozbil ABI. A rozbijanie ABI je cesta tak maximalne pri malych programoch, kde sa vykonovy zisk cely niekolko nasobne nevyplytva na vyvoj aplikacie.

[Spike]

Ale ked sa to raz napise v assembleri, tak je to proste cele na veky vekuce zadratovane na tej jednej platforme. Neexistuje nieco take, ze sa preportuje API a cele sa to prelozi na inu architekturu. Vsetko je treba pisat od nuly. Pouzitie assemblera zvadza k neexistujucim ABI a overly optimized runtime.

Né že bych tomu teda vůbec rozuměl a možná si to představuju jako Hurvínek válku… ale možná se to tomu trochu blíží? GopherCon 2016: Rob Pike - The Design of the Go Assembler

[ed]

To by *mozno* fungovalo v pripade projektu, ktory by bol od nuly zacaty v GoAsm. Pri projekte, ktory uz je napisany v nejakom konkretnom assembleri to treba jednak cele prepisat do GoAsm a druhak treba dufat, ze to ako projekt pouziva architekturu je vovnutri priestoru vyhradeneho obmedzeniami prenositelnosti GoAsm. A celkom by ma zaujimalo, ako sa ten goasm popasuje so SIMD instrukciami. A potom je tam tato trickery:

https://golang.org/doc/asm#unsupported_opcodes

Anyway. Dajme tomu, ze taky CAD je 1,5GB kodu vo velmi hustom C++ku. Kolko toho bude v assembleri (hoc portabilnom)? Onoho casu po nete kolovali zdrojaky DOSu 6.2. V tej dobe to vybalene zo ZIPu bolo cca take iste velke ako zdrojaky sudobeho Linuxoveho kernelu pre vsetky platformy. Nejakych 500 MB. Nebol to cisto len kernel, ale aj command.com a zda sa mi, ze par zakladnych "coreutils". Ale aj tak je tam brutalny nepomer vo velkosti vs. funkcnosti. Nehovoriac o tom, ze taky zdrojak treba spravovat a to je nocna mora.

[pc2005]

Onoho casu po nete kolovali zdrojaky DOSu 6.2. V tej dobe to vybalene zo ZIPu bolo cca take iste velke ako zdrojaky sudobeho Linuxoveho kernelu pre vsetky platformy. Nejakych 500 MB.

To se mi moc nezdá základní MSDOS 6.20 má nainstalovanej asi 5-6MB, takže pro jeden bajt binárky bys potřeboval průměrně 100 bajtů zdrojáku (a to ještě velké procento objemu zabírají help soubory, což je nějakej hypertextovej formát). Jedině ... že by to bylo současně se zdrojákama kompilátoru, tam se stovky MB nahrabat můžou.

[Cabrón]

Je to o řád vedle. Zdroják 6.0 je volně k dispozici [ftp] (login oscollect:oscollect), po rozbalení to má kolem 60 MB, skutečně většina je text (asm a c). Sloccount(1) říká:

Totals grouped by language (dominant language first):
asm:         424330 (65.03%)
ansic:       167857 (25.72%)
pascal:       59391 (9.10%)
php:            918 (0.14%)
awk:             39 (0.01%)
sed:              6 (0.00%)

Total Physical Source Lines of Code (SLOC)                = 652,541
Development Effort Estimate, Person-Years (Person-Months) = 180.45 (2,165.46)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 3.86 (46.29)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 46.78
Total Estimated Cost to Develop                           = $ 24,376,975
 (average salary = $56,286/year, overhead = 2.40).

[pc2005]

Jo to je věrohodnější velikost.

Týjo všechno v assembleru, to muselo bejt peklo v tom pracovat .

[deda.jabko]

Týjo všechno v assembleru, to muselo bejt peklo v tom pracovat .

To neni uplne presne. Vsechno v assembleru 8086, protoze Microsoft kvuli kompatibilite odmital pouzivat cokoliv novejsiho.

[pc2005]

Tak to mi spadl kámen ze srdce ... emm386 driver používal 8086 taky? o_O

[deda.jabko]

A emm386 je v ktere casti MSDOSu? MSDOS.SYS, IO.SYS nebo COMMAND.COM?

[pc2005]

Já psal o zdrojácích celé distribuce MSDOSu verze 6.20 (dokonce tam je i zdroják dos's hellu - ten je už napůl v céčku )

[〹]

PHP?

[〹]

A interpreter toho vysokoúrovňového jazyka (například tedy té Javy) bude napsaný v čem? Protože taková VM pak bude do značné míry sama o sobě splňovat definici operačního systému – a to i v případě, že ten jazyk šíleně přiohneš a znásilníš tak, abys část JVM mohl psát v Javě, přičemž dokud ten kód neproběhne, tak máš k dispozici jen extrémně omezený subset té platformy, do kterého budeš muset nahackovat to, co by líp řešilo třeba to C.

V praxi tedy nějak tak, že by se v první stagi loadnul binární blob napsaný v nízkoúrovňovém jazyce, který nebude umět ani správu paměti a keyword new pro něj bude sprosté slovo (ne, že by byl problém paměť alokovat tupě někde ve volné RAM a neuklízet jí, nebo to dělat ručním voláním speciální metody, ale spíš to prostě nechceš). Ve druhé stagi bys pomocí nativních metod pro přímý přístup do paměti aj. doimplementoval zbytek té VM. Buď můžeš z toho subsetu Javy přímo generovat nativní kód do RAM a skončit tedy s tím, že máš v paměti kompletní nativní JVM, nebo prostě plnohodnotnou JVM naimplementovat v rámci toho tvého subsetu Javy (což pak ale znamená, že to budeš psát asi ještě víc křečovitě a navrch toho ten OS nepoběží pod jedním, ale rovnou dvěma interpretery, přičemž ten stage 1 rozhodně nebude mít JIT, jinak se celé tohle cvičení „minimalizovat low-level kód“ mine zadáním).

Pak teprve můžeš začít psát v opravdové Javě, kde bude GC, thready aj. Ten stage 1 nativní kód by musel implementovat dostatek nativních metod tak, aby s jejich pomocí bylo možné zabezpečit veškerou komunikaci s hardwarem apod. Z reálných výhod high-level jazyka bys začal těžit nejspíš až někde u úloh jako je implementace FS, kde budeš mít pod sebou dostatečnou vrstvu abstrakce na to, aby ses o nízkoúrovňové věci nemusel starat a rovnou měl metody jako readSectors apod.

Reálně jsem u Javy vzhledem k podstatě fungování (class loading, GC, …) dost skeptický, že by toto byla ta správná cesta. To už by bylo rozumnější napsat tu JVM rovnou celou v C, mít jednu stage místo dvou zmíněných výše, a teprve z pohodlí Javy si ohřívat šálky kávy a dělat ty věci, které můžou profitovat z větší míry abstrakce. Reálně bys ale nejspíš zjistil, že těch oblastí je relativně málo. Správu paměti (mj. GC, ale mám na mysli i inicializaci long modu apod.), scheduler a komunikaci s hardwarem bys stále řešil v C, až na to bys flákl pěkné objektové pozlátko. Efektivně by takto napsaná JVM plnila funkci kernelu. Moc by sis nepomohl.

Jiné vysokoúrovňové jazyky můžou dávat větší smysl, ale pro jiné než experimentální účely v tom smysl prostě nevidím. Přidá to akorát vyšší komplexitu, kód to nezpřehlední a reálně to k ničemu moc není. Snad leda bys na to šel nějak hodně kreativně a tu JVM třeba nějak generoval (staticky), nebo co já vím…

Osobně si myslím, že psát kernel v C a pak přesedlat na vyšší jazyky v userlandu je plně dostačující a celkově vhodnější.

[Spike]

Tady se třeba někdo domnívá, že podporou asm.js (dneska spíš WebAssembly?) v kernelu nás čekají světlé zítřky… The Birth & Death of JavaScript | A talk by Gary Bernhardt from PyCon 2014

[xkucf03]

Na škále mezi céčkem a Javou je toho ještě poměrně dost. Prakticky třeba ten Rust, ve kterém je napsaný skutečný OS. Teoreticky jakýkoli jazyk, který by mohl vzniknout a šel přeložit do nativního kódu. Nechce se mi věřit, že C je to nejlepší možné – ano, je dobré, jdou v něm psát OS, které jsou v praxi použitelné, ale nešlo by to jinak? C a C++ musí držet zpětnou kompatibilitu, což je dost omezuje a v případě C++ vede k tomu, že se pořád nabalují nové (byť užitečné) věci, ale staré se nevyhazují a celková komplexita roste.

[〹]

Určitě. Reagoval jsem na tu Javu proto, že jsi ji zmínil, a sám ji také velmi dobře znám. Ostatně jsem nad vývojem OS v ní i uvažoval (for fun). Na druhou stranu si nemyslím, že u jiných interpretovaných jazyků by byla situace fundamentálně jiná.

Pokud jde o jiné jazyky kompilované do nativního kódu, víceméně to vidím podobně. Pro vysokoúrovňové jazyky nevidím rozumné uplatnění ze stejných důvodů, jako jsem naznačoval výše. Použít jiný nízkoúrovňový jazyk je smysluplnější, ale nabízí se otázka, proč to dělat. Aby bylo možné deklarovat funkce keywordem fun, což sugestivně dává vědět, že programování v tomto novém hipsterském jazyce je fun a zvládne to i dement přicházející z JavaScriptu?

Pokud budeš psát v nějakém subsetu C99, myslím, že reálně můžeš mít docela pěkný a srozumitelný kód, kde historicky daná omezení nebo zpětnout kompatibilitu pociťuješ zcela minimálně. Namátkou mě napadají hlavičkové soubory, které ale ostatně používat nemusíš za cenu pomalejší kompilace. Šikla by se nějaká podpora výjimek (ovšem jednoduchých, low-level, ne žádné objektové šilenosti), aby nebylo nutné řešit to inkonzistentně a neprakticky používáním širších typů nebo struktur, nebo v horším případě globálními flagy. To se ovšem snadno řekne a hůř udělá, protože vymyslet to tak, aby to fungovalo dostatečně pěkně a programátor to nemusel používat, pokud nechce, je dost obtížné, nemluvě o tom, že jazyk s opravdu pěkně implementovanými výjimkami jsem ještě asi neviděl. Chvíli jsem věřil, že tím jazykem je Java, ale poměrně dost rychle jsem z toho vyrostl.

[Spike]

Jo ad ten Rust: Redox OS

Vypadá zajímavě. Hlavně to vypadá, že postupují docela rychle dopředu. Ale asi to jde líp od ruky, když si to píšou načisto, na rozdíl od ReactOS nebo Haiku OS, kde je základem dbát na kompatibilitu s existujícími (mnohdy proprietárními, desítky let starými) aplikacemi.

[jxjl]

Jestli se nepletu, tak o použití vysokoúrovňového jazyka se svého času snažil MS, kdy první verze Vist používaly silně .net ... jak to dopadlo, víme všichni.

Ono, osobně mi připadá, že pokud se rozumně navrhne nějaké API pro poloautomatickou správu paměti, tak použití třeba C++ nemusí být pro programátora až zase takové zoufalství, jak by se mohlo na první pohled zdát (např. parent systém v Qt). Nespornou výhodou je pak možnost výkonově kritické části psát plain C stylem, kde se člověk velice snadno dostane až na železo a u částí, kde na výkonu nezáleží typu čekáme, až se uživatel rozhodne, na které tlačítko klikne využít komfortu C++.

[pc2005]

Jj QNX s browserem na jedné disketě byl brutus.