[C# / X# ] Cosmos - C# Open Source Managed Operating System
 

Ciao a tutti!

Questo è il thread ufficiale di Cosmos un nuovo sistema operativo scritto in C# e in X# (il nostro assembler di alto livello).

Cosmos può essere considerata la versione Open Source dei sistema operativi di ricerca della Microsoft Singolarity e Midori: un sistema operativo scritto in C# con integrato il runtime .NET.

Come per Linux il termine sistema operativo è improrio Cosmos è un kernel che può essere esteso (letteralmente) dallo sviluppatore per ottenere un sistema operativo completo.
Attualmente quello che si ottiene è un sistema operativo a linea di comando come il DOS: non aspettatevi subito di vedere il Linux del futuro o il nuovo Windows!

Ci sono due parti diciamo complicate del progetto:

1. Benché il 99% di .NET sia stato scritto in C# ci sono punti in cui è chiamato codice nativo che alla fine va ad effettuare chiamate al kernel di Windows (o dell'OS sottostante). In tutti questi casi è necessario scrivere un "plug" per sostituire la chiamata C++ con codice C#. Un esempio banale Console.WriteLine() alla fine per scrivere sulla Console chiama... la printf()!
2. IL2CPU il nostro compilatore che converte codice IL in assembler. Alcuni opcode o non sono implementati o non funzionano correttamente. Abbiamo creato un nostro linguaggio (!) chiamato X# per semplificare la scrittura dell'Assembler, ma è sempre Assembler... X86 per giunta!

Mentre con IL2CPU probabilmente non ci dovrete andare a sbattere aspettatevi invece di dover scrivere dei "plug" anche per cose apparentemente banali tipo getHashCode() (ma è davvero banale ;) ? Come si fa a fare l'hash code di un enum? Vi ricordo che per un enum potete definire il tipo sottostante... un enum potrebbe essere anche un long! Ma voi volete fare solo myEnum.gatHashCode(), vero? C# deve usare Reflection per calcolare quell'hashcode!).

Differenze tra Cosmos e un Sistema Operativo classico:

1. In Cosmos non esiste una separazione hardware tra la memoria del Kernel e quella dei processi: c'è un solo grosso spazio di memoria a cui tutti possono accedere! La sicurezza viene garantita dal runtime stesso quindi per scrivere su un file non c'è nessuna syscall al kernel: il processo chiamando le opportune funzione della classe FileStream scrive effettivamente sul File (Zero Copy I/O!)
2. In Cosmos ci sono i Ring, ma non sono quello che credete! Sono implementati in software non in hardware, la scopo è però più o meno lo stesso (un processo a livello utente non ha accesso diretto all'hardware)
3. In Cosmos non può MAI per nessun motivo girare codice NON verificabile / non managed! Sì non potrete mai usare C o C++ su Cosmos questo taglia fuori tutta la tecnologia dei 50 anni precedenti! Sì sono passati 50 anni: è il momento di ricominciare da capo :D
4. La domanda del secolo: che tipo di kernel è Cosmos? E' un kernel monolitico? Adesso sicuramente visto che anche il Kernel è indistinguibile dall'applicazione! E' un exokernel? Certo visto che l'applicazione scrive direttamente sul file ed il kernel si occupa solo di allocare la memoria e fare da "mutex" tra le risorse! E' un microkernel? No, per ora no (ma in futuro lo sarà). Forse dovremo inventare una categoria nuova? Wikipedia classifica Midori come "language based OS" per ora accontentiamoci di questa classificazione.

Quindi perché il thread è aperto qui e non in "Sistemi Operativi"? Semplice non abbiamo bisogno di utenti, ma di sviluppatori! Le conoscenze richieste sono C# (ovviamente), ma si deve essere in grado di scrivere anche driver e in alcuni rari casi è richiesto anche di conoscere assembler.

Come scritto in firma se volete collaborare allo sviluppo unitevi alla chat!
Ovviamente avendo un thread in italiano di molte cose potremo parlarne anche qui...

Avendo intenzione di contribuire allo sviluppo a partire dalle prossime settimane, mi iscrivo! :D

Sicuramente l'idea deriva molto dai SO di ricerca della Microsoft Singularity e Midori.
Kudzu (uno degli sviluppatori) ha questo sogno che vuole un giorno portare su Cosmos:

http://www.codeproject.com/Articles/...re-on-the-move

Uno dei target sono i sistemi embedded, Internet of Things, VM (hyperV o Azure). Per questi scenari non serve una GUI, ma basta la linea di comandi quindi sono più "semplici" da realizzare.

C'è già un parziale supporto a VGA, quindi volendo qualcosa di grafico potete anche farlo con la grafica del 1980 (320x240@256 colori). IMHO non ne vale la pena molto più interessante fare un driver VBE che permetterebbe di arrivare anche 1920 x 1080!

Con la GUI uno potrebbe pensare ad altri scenari:

1. Mediacenter
2. SO per telefoni
3. In generale applicazioni "kiosk" varie per esempio bancomat
4. Si anche un SO desktop :p

Questa è la mia idea per il SO del futuro "OcAlot" (leggi Ocelot) a me piacerebbe fare in modo che il SO sia in grado sempre di avere la possibilità una sorta di GUI anche quando è a linea di comando senza che il codice sia cambiato se non c'è la modalità VGA appare una TUI come quelle del DOS "Commander", se c'è la VGA invece apparire una GUI via via più bella a seconda di risoluzione / colori.
Potremmo chiamarlo "Contuum everywhere" :p

Beh per ora siamo pochini... 4 nei giorni buoni! Questo è il nostro più grosso problema!
Se riesco a portare altre 2 finiamo per essere la maggioranza noi Italiani :p

Questa è una domanda da un milioni di €! Noi del team ovviamente ci speriamo, ma prevedere il futuro è sempre difficile. Di certo la licenza (MIT) è migliori di quella di Linux quindi se qualche corporation se ne interessa...

Attualmente il SO è ancora in fase Alpha quindi... 4 persone (noi stessi :D).

Mi sa che non ne sapete tanto di sistemi embedded...
Il fatto che manchi la gui non significa che siano più semplici da realizzare, anzi...
Hanno tutta una serie di problematiche che cozzano contro l'idea di un sistema operativo del genere.
Prima tra tutti la scarsità di memoria!
Aggiungo poi che tipicamente i sistemi embedded hanno bisogno di esecuzione real time, molto spesso hard real time... Come la gestite questa cosa con un sistema operativo totalmente managed in cui il programmatore non ha possibilità di gestire manualmente la memoria? Almeno fornite l'opzione di bloccare il garbage collector?
Senza contare il fatto che usando un sistema totalmente managed scartate a priori tutta una serie di ottimizzazioni che non è più possibile fare vista la natura dinamica del C#.

Forsa ha senso come sistema desktop, non capisco però perché proibire a priori l'uso di programmi compilati staticamente con C e C++.

Se pensate ad android:
- Dalvik compila il bytecode in codice nativo
- I processori ARM hanno un'unità chiamata jazelle che esegue nativamente il bytecode java.

È figa come idea e sicuramente un ottimo esercizio didattico, ma secondo me finisce come questo:
https://en.wikipedia.org/wiki/JavaOS

Il mio più semplice era inteso che se devi fare un sistema operativo desktop
devi avere almeno dei driver per la GPU decenti (esiste VBE, ma senza accellerazione hardware soprattutto se ti trovi con un ARM a 300 MHz non vai da nessuna parte!), poi devi studiare le API per disegnare tutti i componenti lato applicazione e visto che partiamo da C# ci si aspetta di poter usare XAML per disegnare la GUI...

Dipende da come è implementato il GC ci sono versioni meno invasive ed altre di più e poi il nostro compilatore (come quello di Midori) tra le variabili ottimizzazioni farà anche "Stack Escape Analysis" cercando il più possibile di allocare gli oggetti nello stack... come fanno alcune versioni di JVM.

E' una caso prevista da .NET:
http://stackoverflow.com/questions/6...period-of-time

quindi si potrà avere anche nel nostro caso.

Ma è sconsigliato dalla Microsoft secondo me se ti trovi ad usare quello hai codice scritto "male" non è colpa di C#, ma tua!

Cosa intendi con "natura dinamica"? C# non è mica javascript ha tipizazzione forte! Parli forse del "dynamic" aggiunto di recente per supportare Iron Python dentro .NET?

Comunque per essere chiari il runtime .NET e tutta l'applicazione in Cosmos viene compilata in assembler (AOT) non c'è nessuna macchina virtuale in Cosmos non nel senso classico! Certo c'è il Garbage Collector, ci sono le eccezioni, gli array hanno i bound check[1], ecc...

Per mia esperienza diretta il codice C scritto bene prevede che ogni funzione abbia il check dei parametri di input (cosa che in C# fai meglio con eccezioni e contratti) e le stringhe con dimensione a "caso" sullo stack sono cause di bug infiniti. Alla fine è "managed"... a mano, ma se non lo "maneggi" ti esplode in faccia, quindi...

La sfida è questa "safe native code":
http://joeduffyblog.com/2015/12/19/safe-native-code/
(è già stato fatto: può essere fatto di nuovo!).

Per due motivi:

1. Il kernel dovrà essere compilato per l'architettura target (ovvio visto che tutti gli IL opcode, i driver, ecc... dovranno essere per il nuovo target), ma le applicazioni no! E' C# "compile once, run everywhere"
2. Se apri la porta a codice "non verificabile" apri la porta agli hacker: uno sbordamento al punto giusto e bam mi sovrascrivi il kernel! Poi non voglio vedere schifezze come OpenSSL che per essere super veloce era scritto in C e così violava lo scopo per cui era scritta: la sicurezza! Uno se vuol farsi del male può usare C++/CLI comunque, ma nella versione "pure CLR" ovviamente.

Anche noi compiliamo codice nativo ;)
Ma questo non significa che Google ha perso tutti i vantaggi di un linguaggio Managed: JAVA c'è sempre: non c'è più la JVM!
Jazelle mi risulta non più presente negli ultimi processori ARM.

E' presto per dirlo! JavaOS era troppo avanti per i tempi IMHO ed è per questo che è fallito...

[1] Sempre che il compilatore durante la fase di ottimizzazione non decida di rimuovere il check come in questo caso banale:

Occhio che il discorso di OcAlot è il lontano futuro quando saremo ricchi (come Linus Torvalds e Richard Stallman :D) e famosi (come Bill Gates).
Per il momento manco son sicuro del nome, mi piace l'idea di un Ocelot ninja su un Tirannosauro, ma mi sa che è un'immagine che ho già visto da qualche parte :D

Allora su cosa stiamo lavorando al momento:

- Garbage Collector (RAT l'hanno chiamato... si è una sigla, ma non è una cosa troppo nerdosa tipo Linux IS Not Unix)
- Filesystem abbiamo una classe generica da cui abbiamo derivato l'implementazione della FAT16 / FAT32 (FAT64 / extFat temiamo sia sottoposta a copyright! E no, noi non violiamo il copyright altrui). Sopra a questa sono implementate (pluggate) tutti le classi di I/O tipiche di .NET così dal punto di vista dell'utente (sei tu che scrivi il Kernel! Non l'utente come s'intende di solito) nulla cambia. Ci sono ancora del lavoro da fare per esempio delete non so se funziona davvero. Anche aggiungere test a questo kernel è molto apprezzato: https://github.com/CosmosOS/Cosmos/b....Fat/Kernel.cs
L'idea è che finito il supporto a FAT si derivi dalla classe VFSManager e si realizzi un altro FS o uno nostro o un altro Open Source (non so quello di BeOS BeFs? Quello dell'Amiga? ISO, UDF? Se siete maligni anche Ext3...) questo dimostrebbe che la classe è "generica" e non fa assunzioni derivate da FAT
- Base Class Library di questa parte mi sto occupando io, in particolare sto lavorando sui Floating Point: alcune operazioni (cast) non funzionavano davvero / non erano implementate, ora molte lo sono! Anche in questo caso aggiungere test a questo kernel è molto apprezzato:
https://github.com/CosmosOS/Cosmos/t...iler.Tests.Bcl
- Zork Demo: l'intenzione è far vedere Zork che gira su Cosmos a qualche fiera dell'Open Source. Non ho capito se funziona o no... so solo che dopo che ce l'avevano messo dentro il mio codice non compilava perché "magicamente" dipendeva da Zork (?) :Prrr:

Quindi dove iniziare? Da qui direi:
https://github.com/CosmosOS/Cosmos/w...install-Cosmos
(lasciate perdere l'User Kit è troppo vecchio ormai partite usando sempre il DevKit)

se l'installazione va a buon fine (il .bat può rompere le palle all'AntiVirus, ma non preoccupatevi è tutto "normale") provate il kernel Guess se gira siete a cavallo. A quel punto puoi provare a installare l'UserKit (con il .bat) nei sorgenti e creare il tuo kernel: è uno dei modi per trovare che qualcosa manca / funziona male!
Poi vieni in chat, presentati e vedrai che qualcosa da farti fare lo troviamo sempre.

Per esempio io volevo che il mio OS assomigliasse a questo:



ma non riuscivo a selezionare il background / foreground (lo faceva ma in modo "strano") e il cursore non lampeggiava.
Son finito a guardare documentazione della VGA in modalità "BIOS" degli anni '70... ma ora il mio blu è come il C=64 e OcAlot e sempre "READY" e lampeggia impaziente pure! Però per esempio come fare da C# ad avere "xxx bytes free"? Ecco per esempio altro spazio in cui si potrebbe lavorare...

Un altra "demo" interessante dopo avere il driver della VGA funzionante potrebbe essere un emulatore di NES tipo portare questo:
https://sourceforge.net/projects/mynes/

ma potrebbe essere prematuro per ora: se la BCL ha dei "buchi" ed ovviamente vorrai anche l'audio a quel punto vero?

Ah un altra cosa che ho dimenticato se conoscete linguaggi "esotici" della famiglia .NET potete usarli senza problemi per scrivere il vostro OS per esempio se vi piace VB.Net nessuno vi impedisce di usarlo (ma non per il kernel quello è solo in C# / X#) ed anzi è un test interessante pure quello! Magari VB.NET o F# usano opcodes particolari che C# non usa?

Per embedded credo intenda i router, le smart tv e roba simile su cui gira Linux assolutamente non in real time. Dubito vogliano fare concorrenza a VxWorks, ThreadX e compagni.

Concordo. Ma è anche vero che è molto presto per pensare a soluzioni real-time.
Quello dell'Amiga lasciatelo perdere. Almeno per il momento, vi serve un filesystem "serio", come NTFS, BeFS, etc. che supporti journaling, metadati, dimensioni di partizioni e/o file generosi, nomi di file lunghi, compressione, criptazione, ecc.

Per il resto, evitate di sprecare tempo nel portare o scrivere emulatori et similia: c'è taaaaaanto lavoro da fare ancora a livello di kernel, driver, librerie.

Vedremo in futuro cosa riusciremo a fare :D

NTFS temo abbia il copyright per una cosa totalmente legale non potrebbe far parte di Cosmos, ma un OS da esso derivato previo pagamento di licenza alla Microsoft potrebbe implementarlo. La licenza è MIT quindi chiunque può forkare Cosmos e creare un "prodotto" se vuole: per esempio un Mediacenter tipo le cinesate che ora sono basate su Android o i ricevitori sat "evoluti" oggi basati su Linux / Enigma.

Forse dopo FAT ha senso provare ISO per leggere CD / DVD / montare immagini ISO?

BeFS comunque mi stuzzica parecchio! Be OS era un sistema operativo coi fiocchi vorrei che il mio OS fosse organizzato in quel modo...

Quella dell'emulatore era un'idea per una possibile applicazione di Cosmos: un OS con NES integrato: fai il boot e ti trovi dentro un "NES" virtuale che però assomiglia il più possibile al vero NES a partire dal fatto che il boot dure pochi secondi :D
Un po' per dare uno "stimolo" per fare il NES ci vuole un driver della VGA decente e quindi prima scrivi quello, poi fai anche l'audio e poi ti accorgi che ti serve altro..,

Alla fine cosa è un OS? Ciò che fa girare le applicazioni quindi tentare di far andare un'applicazione e ad aggiungere pezzi all'OS potrebbe essere un approccio... un po' strano forse... come dicono quelli che inventano in termini della fava? Top to bottom?

I brevetti scadono in 17-20 anni, se non ricordo male, per cui NTFS dovrebbe essere ormai implementabile liberamente.
Non credo che un'implementazione in un progetto open source sviluppato a titolo puramente gratuito possa rientrare nelle mire di Microsoft.

La licenza, eventualmente, la dovrebbe pagare chi USA quell'implementazione di NTFS in qualche prodotto commerciale.
Meno male che avete usato una licenza realmente libera. :)
Assolutamente sì.
Mi pare che BeFS fosse un po' complicato da implementare. Comunque se cerchi in giro c'è il libro di uno degli sviluppatori, che ha descritto completamente questo filesystem. Il PDF dovrebbe essere completamente gratuito.
Ecco, appunto: intanto pensate a un driver VESA decente, che è il minimo indispensabile. E poi l'audio AC'97 come minimo.
Pensateci dopo avere realizzare un minimo d'infrastruttura: kernel + filesystem (possibilmente journaled) + driver VESA + driver AC'97 + driver Ethernet sono il minimo indispensabile.

Anche se la Microsoft lo usa ancora nei suoi OS? Non è che la avranno rinnovato il brevetto?
Non lo avevano menato a Google e ai produttori di macchine fotografiche perché usavano la FAT sulle chiavette? Eppure FAT avrà quasi 30 anni :D

Sì ero a quello che mi riferivo! Quindi secondo te è possibile implemetarla nel kernel mettendo una sorta di clausola "se utilizzi NTFS in un prodotto commerciale devi pagare la licenza"? Le licenze sono un po' un casino...

Sì la licenza MIT è credo la cosa più importante, la GPL è così libera che non è libera affatto! Se hai "donato" i sorgenti devo poterne fare ciò che voglio...

Sì l'avevo letto! BeFS era davvero al passo coi tempi un database filesystem in cui le ricerche di file duravano millesecondi: certo erano semplicemente una query in un DB! Fu probabilmente uno dei primi filesystem ad usare gli attributi almeno in maniera così estesa per esempio per sistemare in modo sensato una collezione di MP3 in un OS classico hai bisogno di un database (così puoi fare le ricerche / creare cartelle virtuali per nome canzone, nome dell'autore, anno di produzione...) con BeFS tutte queste informazioni sono attributi del file! Sì anni dopo inventarono ID3Tag, ma in BeOS era integrato nell'OS e potevi farlo per qualunque tipo di file!
L'ideale per un Mediacenter!

Per la milestone 1 (SO a linea di comando) probabilmente dopo il filesystem la cosa che sarà da implementare è la rete e far vedere che si può connettere via telnet / ssh.

No, i brevetti non si possono rinnovare/allungare: dopo 17-20 anni terminano, e chiunque può implementarli liberamente senza dover dare un centesimo all'autore.
Ma FAT32/VFAT no. ;)

Secondo te perché giusto qualche anno fa Microsoft ha presentato exFAT? Per farlo diffondere e fargli prendere il posto di FAT32, i cui brevetti sono ormai scaduti o quasi. exFAT = nuovi brevetti = nuovo periodo di tempo in cui Microsoft può sfruttarli e farsi pagare. :D
Certamente. Guarda gli altri progetti open source, come FFMPEG o x264, che implementano codec blindatissimi con una caterva di brevetti e, soprattutto, un consorzio pronto a chiedere lo scalpo di chi li usa: nessuno ha fatto causa agli autori di questi progetti. ;)
Assolutamente d'accordo.
Però bisogna anche supportarlo, per cui devi costruirci sopra un'infrastruttura / GUI / CLI adeguata.
Benissimo.

Ricordo di aver seguito Singularity al tempo e c'erano alcuni punti che non mi sono mai stati chiari.

Si parlava di implementare la sicurezza via software. Possibile che sia più veloce e sicura di quella implementata in hardware?

Se non ricordo male Microsoft aveva realizzato strumenti di sviluppo appositi (Bartok?).
Come si scrive il runtime .Net usando .Net stesso? :fagiano:

C'erano molti limiti pratici alle sandbox: niente dynamic loading (eseguibili monolitici?), niente Jit.
Oltre a non poterci girare Java (e tutti gli altri linguaggi), non ci gira nemmeno un programma .Net standard, ma solo un suo subset. Il tutto per raggiungere quale obiettivo?

Vedi il fatto è che in un SO classico la "sicurezza" è implementata con il fatto che il kernel e tutto i processi vivono in aree di memoria separate e quando per esempio un programma utente deve scrivere su un file avvengono le seguenti operazioni:

1. 1. Il processo chiama una funzione per esempio la classifica write() del C
2. Viene triggerato un software interrupt al kernel. Questo in Linux si traduce in una syscall
3. Il buffer utente viene copiato e ci si sposta nello spazio di memoria del kernel
4. Il kernel - a sua volta - chiama una funzione di basso livello che l'equivalente della write dal punto di vista del driver dell'HDD
5. La memoria del kernel viene di nuovo copiata per scrivere i dati sul disco
6. Il disco smette di scrivere (magari anche nella cache) e ritorno la risposta al kernel: tipicamente 0 per successo, 1 per errore. Anche nel giro inverso quello '0' è copiato minimo 3 volte!

Un processo in Singulary è un "Software Isolated Process" ovvero è NON è un processo, ma un thread che dal punto di vista della CPU ha gli stessi privilegi del kernel (certo è un pezzo del kernel!), il "kernel" espone l'equivalente dello File.Write() come funzione pubblica e quindi il nostro processo può usarla direttamente! Visto che siamo nello stesso spazio di memoria il buffer non viene copiato 3 volta, ma è lo stesso identico buffer che ha passato l'utente che è scritto sul disco. Non ci sono "software interrupt" o cose "esotiche" semplici chiamate a metodi!

Altro esempio visto che Singularity e Midori erano Microkernel (Cosmos lo sarà... un giorno!) è tipico in quei tipi di kernel che 2 processi si scambino messaggi e questo perché un microkernel funzioni correttamente deve essere veloce, se devi passare dal kernel ogni volta sei fritto: Singularity lo bypassava completamente e scriveva gli oggetti direttamente nella coda dell'altro processo (che è sempre un thread ricordiamocelo!).

Quindi cosa vuol dire che la sicurezza è via software? Che non puoi chiamare un metodo privato di un altro oggetto, andare a sbordare nella sua memoria, ecc... tutte cose che .NET garantisce di "suo".

In Cosmos abbia un ulteriore strato sempre software che è chiamato "ring" il ring 0 è quello più a basso livello dove persino assembler può vivere (satana!), il livello utente mi pare sia 4, sì l'utente è il SO che implementa il kernel, l'utente "classico" potrà avere privilegi ancora minori (ring 5!).

Lo so che fa venir mal di testa, ma come il C è scritto in C... .NET è scritto in C# (anche quello classico che è installato su Windows) solo piccole parti sono in C++ o in assembler. Bartok in realtà veniva dopo ed aveva il compito di trasformare l'IL in assembler. In Cosmos noi facciamo lo stesso con IL2CPU.

Del dynamic loading non so perché non fosse presente in Singularity, il JIT proprio perché non si voleva avere la VM o meglio il kernel e la VM .NET condividevano lo stesso spazio di memoria e giravano come codice nativo.

Comunque credo che Midori fosse andato molto più avanti ad un certo punto danno l'impressione che girasse Windows (!) parlano di Skype e persino di un browser! Peccato che il codice probabilmente giace in qualche soffitta e non vogliano renderlo pubblico...

Cosmos in questo sarà diverso (non guardare quello di ora in cui gira uno ed un solo programma: non abbiamo ancora implementato i thread :Prrr: ) un'applicazione scritta in qualunque linguaggio .NET (quindi C#, VB.NET, F#) girerà su Cosmos in un modo simile a NGEN:

1. L'applicazione è compilata con Visual Studio: è una normale applicazione .NET che gira su Windows e pure su Linux (con Mono)
2. Viene copiata su un sistema Cosmos
3. Al primo run (o durante l'installazione) viene compilato per il codice nativo della macchina su cui sta girando. Visto che ora "sappiamo" tutto della CPU possiamo - volendo - ottimizzare per SSE, AVX, NEO, ecc...
4. Il compilato o viene salvato in una qualche directory "bin-cache" o in maniera più elegante dentro l'eseguibile stesso (se non sbaglio è ciò che fa NGEN / .NET Native)
5. L'applicazione gira senza problemi come ha fatto su Windows e su Linux
6. Le volte successive - ovviamente - l'applicazione parte più velocemente visto che è già stata compilata

Se il dispositivo è sfigato (per esempio è un telefono) si può fare come fa la Microsoft nel suo store con .NET Native: lo sviluppatore consegna l'applicazione in formato .NET alla Microsoft che provvede a pre-compilarla ed è la versione compilata che l'utente installa sul suo telefonino.

In realtà basta avere come target IL e tutti i linguaggi potranno girare su Cosmos:

1. Java potrebbe pure girarci con l'aiuto di IKVM basta installare su Cosmos l'IL ottenuto
2. Python è OK basta usare IronPython
3. Javascript dovrebbe esistere js.net
4. ... beh tutti questi qui: https://en.wikipedia.org/wiki/List_of_CLI_languages

C'è persino C++ nella versione C++/CLI, ma lì è per modo di dire visto che sarebbe la versione completamente managed e non credo che nessun codice C++/CLI sia completamente managed: è stato creato proprio per essere il ponte tra .NET e il codice nativo. Scrivere un'applicazione in C++/CLI invece che in C# mi pare un po' una tortura forse l'unico vantaggio sarebbe la deallocazione della memoria più controllabile?

Microkernel senza distinzione fra kernel e userspace (immagino che giri tutto in ring-0 a questo punto) mi ricorda il s.o. dell'Amiga. :sofico:

Ma questa volta fatto bene, visto che quest'ultimo è ben noto per le Guru Meditation. :p

Sì non è diverso solo che appunto il linguaggio su cui è basato è C# non C, quindi, appunto niente "guru meditation" :D

Anche VxWorks non credo sia molto diverso, comunque...

L'idea alla base di Singularity mi sembrava buona all'epoca, ma poi incappai in questo post http://web.archive.org/web/201503181...l-performance/

I punti principali sollevati dall'autore sono:

1. il codice della sola VM di Singularity e' piu' grande di quello di tutto L4
2. i runtime checks finiscono per pesare piu' dei mode switch

Con l'avanzare della tecnologia dei microprocessori, gli switch hardware sono diventati sempre piu' rapidi, il che ha reso ancora piu' inutile il non uso della modalita' protetta.

Quando si parla di compilare in nativo in questo caso si parla di un qualcosa tipo MSIL o di vero e proprio codice macchina?
Nel secondo caso, se tutto gira in ring 0 cosa impedisce di andare ad eseguire istruzioni x86 privilegiate e fare danni in giro?

Per quanto riguarda la scrittura del .Net in C# (che è un linguaggio .Net) come si gestisce deterministicamente la memoria in C#?
Perchè il runtime gestisce la memoria in maniera deterministica, differentemente da un programma scritto per girare nel runtime.

Infine come si fa da C# ad accedere ai registri? Se sei un OS l'accesso ai registri è pane quotidiano. A maggior ragione se devi fare tutti i controlli sui permessi di accesso lato software senza basarti sulle funzionalità hardware.

Codice macchina, puro e semplice!

I livelli (che sono un'implementazione software dei ring) non ti permetteranno di fare questo:

https://github.com/CosmosOS/Cosmos/b...rnel/Levels.md

un'applicazione sarà sempre a livello 3 e quindi non potrà chiamare nessuna istruzione privilegiata (non puoi scrivere codice assembler a livello 3 e nemmeno codice unsafe probabilmente).
Certo uno "monello" potrebbe scrivere un SO "malvagio" che è un virus, ma questo cosa ti garantisce che una distribuzione Linux non possa fare lo stesso?

Perché dovresti gestirla "deterministicamente" c'è il garbage collector una nostra versione (non quello classico di .NET).

Beh nei casi in cui sia necessario anche C# permette di allocare nello stack usando stackalloc.

Infatti tra quadre ho messo anche X# che il nostro High Level assembler per X86:

https://en.wikipedia.org/wiki/X_Sharp

qui siamo molto a basso livello (debug su porta seriale):
https://github.com/CosmosOS/Cosmos/b...ub/SerialIO.xs

dobbiamo ancora studiare come embeddare X# dentro C# per ora facciamo così, ma non ci soddisfa affatto:

https://github.com/CosmosOS/Cosmos/b...2CPU/IL/Add.cs

(tutto quello che inizia con XS è codice X# dentro C#)

probabilmente in futuro useremo qualcosa di simile a GCC:

Per esempio quando ho implementato Conv.R.Un non mi ha soddisfatto come dichiarare le costanti questo dovrebbe essere più semplice, molto più semplice di come è ora... è anche molto difficile passare un valore da C# a X#.
Abbiamo ancora un po' da lavorare su questo.

Personalmente trovo l'inline di GCC molto più semplice di X#.
Ma l'obiettivo di progetti come Singularity e Cosmos non è strettamente quello di evitare context switch e/o l'uso della modalità protetta.

Invocare velocemente un'API che è disponibile solo in kernel mode, o usare la modalità protetta, non ti mette al riparo da buffer overflow et similia, che possono succedere ugualmente.

Comunque il link che hai postato è interessante, ma non mi è chiaro come abbiano fatto i test per la spedizione di messaggi.