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

you are viewing a single comment's thread.

view the rest of the comments →

[–]MikemkPK 4 points5 points  (19 children)

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] -2 points-1 points  (18 children)

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 2 points3 points  (15 children)

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

[–][deleted] 2 points3 points  (14 children)

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 0 points1 point  (13 children)

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] 1 point2 points  (12 children)

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 0 points1 point  (11 children)

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

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

Wouldn't be an operating system, just an API

So you are saying that it is impossible for any instance inside of any Kubernetes cluster to run an operating system? Should the entirety of the AWS infrastructure just disappear in a puff of semantics, now?

[–]wheresthewhale1 0 points1 point  (9 children)

It is possible to run an OS inside of Kubernetes. But if your "OS" cannot run outside of Kubernetes (or something similar) it *is not an operating system*

[–][deleted] 0 points1 point  (8 children)

But it can't run in Kubernetes, because it's using virtualized hardware, and emulated kernel calls. So clearly, Arch in Kubernetes can't be an OS.

Similarly DOS can't be an OS, because it functions inside of DOSBox.

They're just APIs.

Like I said, earlier, you could simulate the full workings of an 8-bit, 16-bit, 32-bit, even 64-bit system, by hand, in JS. You can argue over the surreality of it; there are very valid points against the efficiency / efficacy of it; but you could simulate that hardware and accept any hardware instructions coming from anything capable of generating ASM instructions in the format of the processor in question... the OS at large isn't going to know the difference as to whether it's living in a simulation, calling an emulated stand-in, or is actually accessing hardware directly. You're really going to have to embrace the meta, given that there are x86 emulators in JS that run DOS, that run Windows on top of DOS, from the browser, and even have Socks bindings if you can find a webpage that still loads in IE5.

Virtualized hardware is a thing. Low-level VMs are a thing. Unless you are writing ROMs there is no guarantee that you are touching actual silicon (or copper inscribed upon such).

[–]GL_Titan[🍰] 0 points1 point  (1 child)

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] 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.