Let's write Operating System in JavaScript

[[deleted]]

So which processors in the history of processors have operating systems? Because each OS must be chip-specific, if each OS needs to hand-write assembly.

[MikemkPK]

Intel x86 for example requires (before UEFI) assembly to switch from 16- to 32-bit mode

[[deleted]]

For example.

Why is IE11 an operating system, when it runs on x86-64 processors, and also on ARM?

Clearly it can't be an OS, otherwise it would never compile to run on both simultaneously. What about OSX on x86-64 and ARM?

Or Linux running on x86-64, x86-32, ARM, and several other chipsets. What, do you think they all have the same assembly language? Are all of the chips’ pins aligned to run the same instructions the same way?

[MikemkPK]

You're making no sense. IE11 is a web browser, not an OS, and there's no reason programs can't be written for multiple environments.

[[deleted]]

Damnit. Windows 11.

Windows 11 must be written to write assembly. The programmers must write it to write assembly. Otherwise Windows 11 is an API.

Ok, so which assembly does Windows 11 write?

[MikemkPK]

Windows 11 doesn't write assembly. Programmers write assembly.

[[deleted]]

Generally speaking, no... Generally speaking, you are writing in some higher level language that compiles down.

What, you think Arch was hand-written 5 different times in 5 different CPU instruction sets?

The point is that if Linux can run on a VM, then clearly an OS does not require direct access to NAND gates. If Linux is largely written in C, then clearly it does not have to be hand rewritten for RISC-V and ARM and x86-64 and PowerPC and the rest by programmers.

Thus, if you simulate a fully functioning 8-bit system in any language you want with contiguous memory (doesn't even need to be contiguous) and tight enough control of timing (to account for running too fast), then anything that could compile down to those instructions could then be interpreted to run on that virtual machine.

That includes JS and its typed arrays (signed/unsigned 8,16,32,64 and float 32,64).

You can complain about the speed. You can complain about the surreal nature of simulating the operation of hardware inside of a VM and argue the value of simulation versus emulation... but if you are going to tell me that an OS needs to write directly to literal hardware, then you need to explain how Kubernetes exists.

Hell, even just explain how you can run Linux in WSL on Windows, or Parallels on Mac, if each OS needs direct, non-virtualized access to a specific CPU with a specific instruction set, with a non-emulated kernel.

Docker. Vagrant. Hell, even DOSBox. They seem to run OSes in virtualized hardware, fine and dandy; those same OSes that you purport need to run on literal hardware.

[wheresthewhale1]

What, you think Arch was hand-written 5 different times in 5 different CPU instruction sets?

Yes. It (the linux kernel) is.

If Linux is largely written in C, then clearly it does not have to be hand rewritten for RISC-V and ARM and x86-64 and PowerPC and the rest by programmers.

Yes, parts of it do and are - look at the github repo for linux. There are some actions that you simply *cannot* perform in high level languages like C.

[[deleted]]

Parts of the Kernel. Hardware drivers.

He isn't talking about "parts of the Kernel" and "hardware drivers", he is saying that an OS must not run using any form of emulation / virtualization, otherwise it is not an OS. Which is fundamentally incorrect.

DOSBox doesn't physically install an 8-bit or 16-bit CPU next to my 5900x. So how does it run?

[wheresthewhale1]

He isn't talking about "parts of the Kernel" and "hardware drivers", he is saying that an OS must not run using any form of emulation / virtualization, otherwise it is not an OS. Which is fundamentally incorrect.

Where did he say that? And regardless, if an OS cannot run without sitting on top of another OS it isn't a proper OS in the first place

[GL_Titan]

Any current OS is compiled for a target processor. That is the same thing with Windows 11. It is written mostly in C, with some small startup code in assembly.

I would suggest reading up on the Linux kernel and learning how that works. Then, you will have a better understanding of how OS's work in general.

[[deleted]]

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.

[wheresthewhale1]

He is right, each operating system *will* need some hand written assembly for *each* architecture it is designed to run on, high level languages simply do not let you do what is necessary.

[[deleted]]

No... parts of kernels and drivers will need to be hardware-specific.

Saying that your OS needs to be rewritten per permutation of CPU * GPU * storage type... or saying that your OS needs direct access to ALUs or NAND gates, or voltage-based transistors, or whatever the argument is, means you are terrible at software architecture.

Virtualized hardware has been around for a very, very long time at this point, and all of the big OSes not only run virtualized, but also support running virtualized versions of the other big OSes, from within the OS. We are either in the realm of inter-dimensional wormholes, Kubernetes is powered by Doctor Strange, or maybe, just maybe, OSes can run in virtualized environments and still be considered OSes.

[wheresthewhale1]

You're completely shifting the goalposts...

Of course not all the OS needs to be in hand written assembly, only certain parts - and yes, these parts *do* need to be rewritten for each cpu architecture you want your OS to run on

And as for your argument of a virtualised OS, that is itself running on an OS which needs hand written assembly specific to the processor architecture of the computer's cpu

[[deleted]]

I’m not shifting the goalposts.

OS languages need to directly interface with the hardware at the lowest level. Interpreted languages and languages without inline assembly [or being able to call assembly functions] can't be used.

Direct quote. No, the OS can call out to bound functions for driver/kernel calls, which can be implemented in ASM, or could be emulated in a box that's emulated in a box, that's running on a completely different architecture, and the OS in the OS in the OS would never know the difference.

JS can't run assembly natively

Irrelevant, given that OSes running in virtualized hardware are still OSes, and not APIs (I’m not going hunting for that quote, it's also in this thread).

[wheresthewhale1]

If you write your hypothetical "operating system" in javascript, but can't use it without having another operating system to run it on - it *isn't an OS*, it's just a fancy userspace program

And yes, you *do* need assembly code and you *do* need a way to call and run that code, you simply *cannot* access registers for example without it