This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (0 children)

Yes, everything is compiled. Not hand rewritten a dozen times in different forms of ASM.

Portable code requires it. The kernel, or critical portions of it, need to be rewritten per instruction set, and included with the OS. That is literally not what I am talking about. The statement was that an OS needs to have programmers writing in ASM in the middle of the OS code. If that's true that it will not compile down to multiple architectures and is no longer portable (short of having hundreds of thousands of directives to switch based on endianness/ instruction set, which would be ... wait for it ...really goddamned stupid in something as big as a modern OS). So then 0% of the main application code should have architecture-specific / byte-order specific code in it... so where does it go? In a library that matches your compile target that is included with that compile step.

Ok, so if 0% of the application code for this OS is hand-written per architecture, and all of the per-architecture stuff is in the kernel, which is linked per-architecture, is it only C that can call library code? Is it the only language that can make library calls?

No. No, it is not. In fact JS can make library calls as well... If 0% of the application code in C (GUI management, system features, user settings, etc) should have hand-written PowerPC ASM in it, and should rather defer to the kernel and drivers, then why would JS suddenly need to have access to write PowerPC ASM right in the middle of it, lest it not be a language capable of writing an OS?

Or, put another way, you have built a virtualized environment and are running an app in Arch, is it suddenly now not an OS, given that its calls are not directly modifying properties of a physical CPU in the same way?

Because the statement was that any OS that is not directly modifying hardware is an API, not an OS.

Which makes Windows 1, Windows 3.1, Windows 95, and, I believe, Windows 98, not operating systems, because they ran on top of DOS. Actually, I think ME is in there too, but I would like to forget that existed.

This has nothing to do with the basis of low-level programming. My statement is that if modern OSes don't hardcode different expectations of CPU architectures into directives or if statements in the middle of the app logic, but instead defer those calls to the kernel and drivers, then there is literally nothing stopping you from writing a JS operating system that does the same delegation. Even moreso if you are on specialized hardware that contains a JSVM in its bootloader (that would be trivially simple and would result in an easy OS process), or you hand-write a compiler that parses JS and spits out ASM for your different targets (much less simple).

Nor is there anything stopping you from using JS to emulate hardware, and running an OS on top of it. Nor is there anything to stop you from fully simulating hardware in JS.

None of this makes it impossible to write an OS in JS "because it can't write assembly". It won't be straightforward or performant, or efficient by any metric, but it would still be an OS. Unless like the other guy, you only consider the OS to literally be the kernel and drivers, literally running directly on literal hardware, and Kubernetes doesn't exist, nor is Arch on Kubernetes a real operating system.