3 ms·

> And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? I bet somebody has done that. https://www.google.c

> And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? I bet somebody has done that. https://www.google.com/search?q=os+kernel+in+javascript https://www.google.com/search?q=os+kernel+in+javascript Seems like a small number of hobbyists have attempted. I've heard of people doing this with other high level languages. Basically you need enough low level code to bootstrap a VM. Once you have that, you can make the high level language decide some logic that traditionally would be in C code, like manipulating page tables or whatever.

gwbas1c 9mo ago
Automatic Garbage Collection in a kernel probably won't work: I vaguely remember hearing about someone trying to use .Net in the Windows kernel. The big problem is garbage collection: If I remember correctly, the fact that "any" operation can fail with an out of memory exception was a huge problem. Another problem was that random pauses for garbage collections in the kernel had major stability issues. In short, I hope that the js kernel is for amusement and education; otherwise it would need a much more advanced garbage collector then earl 2000's .Net.
- asveikau 9mo ago
  > I vaguely remember hearing about someone trying to use .Net in the Windows kernel. Microsoft did that, it was called Longhorn. That release cycle was long delayed and they abandoned most of its ambitious projects, especially C# in the kernel, and the result was Windows Vista. GC was not the only reason for the failure of that project. Someone could write a book about it. A lot of it was actually more about the organization of people. I also had heard from insiders that lack of ahead of time compilation was an issue. The other issue I remember hearing about was a complaint that Windows components were not layered cleanly and they ended up with circular dependencies when they tried to rewrite them. I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. And I say that as someone who happens to think that a big issue with modern software is that too many programmers are spending their whole education and career to depend on GC without thinking about it carefully. That is to say I'm already a skeptic of high-level languages and GC, but I will still afford that it is technically possible.
  - anonymars 9mo ago
    > trying to use .Net in the Windows kernel. > Microsoft did that, it was called Longhorn Do you have any reference for that? Or are you confusing Longhorn with Singularity (https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)) / Midori (https://en.wikipedia.org/wiki/Midori_(operating_system) https://en.wikipedia.org/wiki/Midori_(operating_system))? I suspect you're referring to the shell/internals, though, not the kernel (https://longhorn.ms/the-reset/#:~:text=Why%20start%20over,reliability%20and%20security. https://longhorn.ms/the-reset/#:~:text=Why%20start%20over,re...)
    - asveikau 9mo ago
      My source for that is I was on the Windows team at Microsoft from 2008-2011. I learned a bunch of this history from talking to coworkers who were there. I specifically recall people talking about c# in the kernel.
    - deleted 9mo ago
      [deleted]
  - danudey 9mo ago
    Another part of it was, IIRC, that Longhorn was based off of the Windows XP core, i.e. the non-server stuff. While the Windows Server development continued apace, with lots of security and hardening to make for a reliable OS to build upon, the Windows Non-Server team continued with the existing mess of a codebase, not prioritizing security features or stability in favor of trying to manage feature creep. Longhorn was meant as a stopgap between XP and 'Blackcomb', but a lot of Blackcomb stuff started creeping backwards, bogging them down. When security and reliability were suddenly key issues for Microsoft (to the extent that they ever were), it was obvious that what the Longhorn team had built was never going to meet that bar so they started over building off the Windows Server codebase instead. Most of this story I remember from a video on YouTube of that old guy who worked at Microsoft since forever and left around the time of the Longhorn debacle, but a lot of it is corroborated in the Wikipedia article as well. https://en.wikipedia.org/wiki/Development_of_Windows_Vista https://en.wikipedia.org/wiki/Development_of_Windows_Vista
leoedin 9mo ago
You'd need to write an entire hardware abstraction layer to do anything useful. There's projects that do this for microcontrollers - eg MicroPython and Espruino.
- tracker1 9mo ago
  Should be able to do similar with MicroQuickJS or maybe just QuickJS...
- asveikau 9mo ago
  Yes, it would need support from lower level code. But then, so does C -- many things that an OS needs to do, such as installing interrupt handlers, changing the current page table pointer, jumping into a target process already in progress, etc., are not part of the C standard.

gwbas1c 9mo ago

Automatic Garbage Collection in a kernel probably won't work: I vaguely remember hearing about someone trying to use .Net in the Windows kernel. The big problem is garbage collection: If I remember correctly, the fact that "any" operation can fail with an out of memory exception was a huge problem. Another problem was that random pauses for garbage collections in the kernel had major stability issues. In short, I hope that the js kernel is for amusement and education; otherwise it would need a much more advanced garbage collector then earl 2000's .Net.

asveikau 9mo ago
> I vaguely remember hearing about someone trying to use .Net in the Windows kernel. Microsoft did that, it was called Longhorn. That release cycle was long delayed and they abandoned most of its ambitious projects, especially C# in the kernel, and the result was Windows Vista. GC was not the only reason for the failure of that project. Someone could write a book about it. A lot of it was actually more about the organization of people. I also had heard from insiders that lack of ahead of time compilation was an issue. The other issue I remember hearing about was a complaint that Windows components were not layered cleanly and they ended up with circular dependencies when they tried to rewrite them. I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. And I say that as someone who happens to think that a big issue with modern software is that too many programmers are spending their whole education and career to depend on GC without thinking about it carefully. That is to say I'm already a skeptic of high-level languages and GC, but I will still afford that it is technically possible.
- anonymars 9mo ago
  > trying to use .Net in the Windows kernel. > Microsoft did that, it was called Longhorn Do you have any reference for that? Or are you confusing Longhorn with Singularity (https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)) / Midori (https://en.wikipedia.org/wiki/Midori_(operating_system) https://en.wikipedia.org/wiki/Midori_(operating_system))? I suspect you're referring to the shell/internals, though, not the kernel (https://longhorn.ms/the-reset/#:~:text=Why%20start%20over,reliability%20and%20security. https://longhorn.ms/the-reset/#:~:text=Why%20start%20over,re...)
  - asveikau 9mo ago
    My source for that is I was on the Windows team at Microsoft from 2008-2011. I learned a bunch of this history from talking to coworkers who were there. I specifically recall people talking about c# in the kernel.
  - deleted 9mo ago
    [deleted]
- danudey 9mo ago
  Another part of it was, IIRC, that Longhorn was based off of the Windows XP core, i.e. the non-server stuff. While the Windows Server development continued apace, with lots of security and hardening to make for a reliable OS to build upon, the Windows Non-Server team continued with the existing mess of a codebase, not prioritizing security features or stability in favor of trying to manage feature creep. Longhorn was meant as a stopgap between XP and 'Blackcomb', but a lot of Blackcomb stuff started creeping backwards, bogging them down. When security and reliability were suddenly key issues for Microsoft (to the extent that they ever were), it was obvious that what the Longhorn team had built was never going to meet that bar so they started over building off the Windows Server codebase instead. Most of this story I remember from a video on YouTube of that old guy who worked at Microsoft since forever and left around the time of the Longhorn debacle, but a lot of it is corroborated in the Wikipedia article as well. https://en.wikipedia.org/wiki/Development_of_Windows_Vista https://en.wikipedia.org/wiki/Development_of_Windows_Vista

leoedin 9mo ago

You'd need to write an entire hardware abstraction layer to do anything useful. There's projects that do this for microcontrollers - eg MicroPython and Espruino.

tracker1 9mo ago
Should be able to do similar with MicroQuickJS or maybe just QuickJS...
asveikau 9mo ago
Yes, it would need support from lower level code. But then, so does C -- many things that an OS needs to do, such as installing interrupt handlers, changing the current page table pointer, jumping into a target process already in progress, etc., are not part of the C standard.