Les OS gérés sont probablement en quelque sorte des micro-noyaux - vous sacrifiez les performances au nom de la sécurité.
Il pourrait y avoir des problèmes similaires car cela nécessite de diviser le code en 2 parties:
- Noyau de bas niveau écrit en C / assembleur
- Noyau de niveau supérieur écrit en langage managé
Selon le coût d'entrée / sortie en toute sécurité du langage HL, cela peut imposer des problèmes similaires à ceux des micro-noyaux - peut-être un peu plus rapidement (quitter HL est plus rapide que le changement de contexte complet, mais IIRC par exemple JNI est assez coûteux).
L'application utilisateur aurait également probablement besoin de contextes distincts car de nombreuses applications sont écrites sur d'autres plateformes (disons C, Java ou .Net). Dans les mêmes cas, les applications peuvent être liées au processeur (compilateurs, convertisseurs de musique, etc.) et nécessitent même une optimisation de l'assembleur pour fonctionner à une vitesse suffisante. En outre - la protection MMU implémentée en langage HL ne sera probablement pas aussi rapide que celle matérielle, même si elle peut être beaucoup plus affinée.
Le langage HL ne maîtrise pas non plus les opérations de bas niveau. Bien que les logiciels soient généralement conçus avec de «bonnes» pratiques de codage, les pilotes ne sont pas nécessaires. Je ne pense pas qu'ils protègeront contre au moins certaines erreurs car les noyaux nécessitent parfois une mémoire à gestion manuelle.
Enfin, je ne pense pas qu'un tel système d'exploitation nécessiterait une machine virtuelle complète. Étant donné que le système d'exploitation ne peut pas être construit avec les principaux langages HL de compilation une fois exécutée partout (même avec GC & co.), Ce serait un meilleur candidat.
Par exemple, vous rendez soudainement obsolètes des pointeurs arbitraires.
Le système d'exploitation est intrinsèquement de bas niveau. Vous passez au matériel non seulement au «pointeur arbitraire», mais probablement à l'adresse physique plutôt qu'à l'adresse virtuelle. Certains DMA ne peuvent gérer que les 16 premiers Mo de mémoire. Bien que ce système d'exploitation puisse simplifier beaucoup, il ne supprimera pas les adresses.
Et si c'est bien écrit, vous vous débarrassez d'une tonne de crud hérité que la plupart des systèmes d'exploitation modernes ont actuellement.
- Il existe de nombreux matériels hérités. Bien plus que dans le logiciel. Vous commencez d'abord en mode réel, puis activez la porte A20 (ne demandez pas), passez en mode protégé puis en mode long.
- La compatibilité API / ABI est bonne. Disons qu'ils ont écrit un tel système d'exploitation - que feriez-vous? Firefox - non (C et C ++ utilisant WinAPI). Java - il avait probablement besoin d'être porté ou avait quelques problèmes mineurs via ikvm - à moins qu'il ne soit heureux d'utiliser JNI. Je suppose que MSSQL (et pour sûr Oracle, MySQL, Postgresql ...) n'est pas écrit en langage managé donc il ne conviendrait pas au serveur.
- Même la compatibilité des bogues est "bonne". AFAIK MS passe beaucoup de temps à tester et à vérifier si certains logiciels n'utilisent pas l'API de manière intelligente (lecture incorrecte). Comme le problème de l'utilisation du pointeur après
free
lorsque Windows a réellement commencé à libérer de la mémoire.
Je suppose que cela gagnera en popularité à peu près en même temps que les micro-noyaux.