Os SOs gerenciados provavelmente são de alguma forma semelhantes aos microkernels - você sacrifica o desempenho em nome da segurança.
Pode haver problemas semelhantes, pois exige a divisão do código em 2 partes:
- Kernel de baixo nível escrito em C / assembler
- Kernel de nível superior escrito em linguagem gerenciada
Dependendo do custo de entrada / saída da linguagem HL com segurança, ele pode impor problemas semelhantes aos microkernels - possivelmente um pouco mais rápido (deixar HL é mais rápido que a troca de contexto completo, mas o IIRC, por exemplo, o JNI é bastante caro).
O aplicativo do usuário provavelmente também precisaria de contextos separados, pois muitos aplicativos são gravados em outras plataformas (como C, Java ou .Net). Nos mesmos casos, os aplicativos podem ser vinculados à CPU (compiladores, conversores de música etc.) e precisam de otimização de assembler para funcionar com velocidade suficiente. Além disso - a proteção MMU implementada na linguagem HL provavelmente não será tão rápida quanto a do hardware, mesmo que possa ser muito mais ajustada.
Além disso, a linguagem HL não é proficiente nas operações de baixo nível. Embora o software geralmente seja projetado com drivers de boas práticas de codificação, não é necessário. Eu não acho que eles se protejam contra pelo menos alguns erros, pois os kernels às vezes exigem memória de gerenciamento manual.
Finalmente, não acho que esse sistema operacional exigiria VM completa. Como o sistema operacional não pode ser construído com o princípio, as linguagens HL de compilação, uma vez que são executadas em qualquer lugar (mesmo com a GC & Co.) seriam melhores candidatos.
Por exemplo, você repentinamente torna obsoletos os ponteiros arbitrários.
O sistema operacional é inerentemente de baixo nível. Você passa para o hardware não apenas 'ponteiro arbitrário', mas provavelmente endereço físico e não virtual. Alguns DMA podem lidar apenas com os primeiros 16MiB de memória. Embora esse sistema operacional possa simplificar muito, ele não se livra dos endereços.
E, se bem escrito, você se livra de uma tonelada de dados antigos herdados da maioria dos sistemas operacionais modernos.
- Há muito hardware herdado. Muito mais do que em software. Você inicia primeiro no modo real e, em seguida, habilita o gate A20 (não pergunte) para o modo protegido e depois para o modo longo.
- A compatibilidade API / ABI é boa. Digamos que eles tenham escrito esse sistema operacional - o que você executaria nele? Firefox - não (C e C ++ usando WinAPI). Java - provavelmente precisava ser portado ou teve alguns problemas menores via ikvm - a menos que por acaso usasse JNI. Acho que o MSSQL (e com certeza Oracle, MySQL, Postgresql ...) não está escrito em linguagem gerenciada, portanto não seria adequado para o servidor.
- Até a compatibilidade de bugs é "boa". O AFAIK MS passa muito tempo testando e verificando se algum software não está usando a API de maneira inteligente (leitura incorreta). Como o problema de usar o ponteiro depois
free
dele quando o Windows realmente começou a liberar memória.
Eu acho que ele ganhará popularidade na mesma época que os microkernels.