Portál AbcLinuxu, 20. prosince 2025 20:28
Byla vydána verze 0.4.9 svobodného operačního systému ReactOS (Wikipedie). Přehled novinek i s náhledy v oznámení o vydání a v ChangeLogu. Videoukázka na YouTube.
Tiskni
Sdílej:
23.7.2018 22:31
xkucf03 | skóre: 49
| blog: 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ě1 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
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
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.
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).
.
Týjo všechno v assembleru, to muselo bejt peklo v tom pracovatTo neni uplne presne. Vsechno v assembleru 8086, protoze Microsoft kvuli kompatibilite odmital pouzivat cokoliv novejsiho.
... emm386 driver používal 8086 taky? o_O
)
23.7.2018 20:42
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ší.
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.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.