操作系统内核是所有其他程序的解释器吗? [英] Is an operating system kernel an interpeter for all other programs?

问题描述

所以，据我了解，有两种类型的程序，一种是解释型的，一种是编译型的.解释程序由解释器执行，解释器是其所在平台的本机应用程序，编译程序本身就是它们所在平台的本机应用程序(或系统软件).

So, from my understanding, there are two types of programs, those that are interpreted and those that are compiled. Interpreted programs are executed by an interpreter that is a native application for the platform its on, and compiled programs are themselves native applications (or system software) for the platform they are on.

但我的问题是:除了内核之外，还有其他东西实际上是由 CPU 直接运行的吗?Windows 可执行文件是Windows 可执行文件"，而不是 x86 或 amd64 可执行文件.这是否意味着不是内核的所有其他进程都被内核以与浏览器解释 Javascript 相同的方式解释?或者内核是否将这些进程放在内核所在的裸机"上?

But my question is this: is anything besides the kernel actually being directly run by the CPU? A Windows Executable is a "Windows Executable", not an x86 or amd64 executable. Does that mean every other process that's not the kernel is literally being interpreted by the kernel in the same way that a browser interprets Javascript? Or is the kernel placing these processes on the "bare metal" that the kernel sits on top of?

如果它们在裸机"上，Windows 怎么知道一个程序是 Windows 程序而不是 Linux 程序，因为它们都是为 amd64 处理器编译的?如果是因为可执行文件的格式"，那么该可执行文件如何能够在裸机"上运行，因为对我来说，它被格式化为在特定操作系统上运行的事实意味着需要一些解释让它运行.

IF they're on the "bare metal", how, say does Windows know that a program is a windows program and not a Linux program, since they're both compiled for amd64 processors? If it's because of the "format" of the executable, how is that executable able to run on the "bare metal", since, to me, the fact that it's formatted to run on a particular OS would mean that some interpretation would be required for it to run.

这个问题对 Stack Overflow 来说是不是太复杂了?

Is this question too complicated for Stack Overflow?

推荐答案

它们在裸机"上运行，但它们确实包含操作系统特定的东西.一个可执行文件通常会向内核提供一些关于如何将程序加载到内存中的指令(可以说是解释的")，并且文件的代码将为其挂钩"到正在运行的操作提供方法系统，例如通过操作系统的 API 或通过设备驱动程序.一旦这样的非解释程序加载到内存中，它就会在裸机上运行，​​但会继续与也在裸机上运行的操作系统进行通信.

They run on the "bare metal", but they do contain operating system-specific things. An executable file will typically provide some instructions to the kernel (which are, arguably, "interpreted") as to how the program should be loaded into memory, and the file's code will provide ways for it to "hook" in to the running operating system, such as by an operating system's API or via device drivers. Once such a non-interpreted program is loaded into memory, it runs on the bare metal but continues to communicate with the operating system, which is also running on the bare metal.

在单进程操作系统时代，可执行文件基本上夺取"整个计算机的控制权并直接与硬件通信是很常见的.像 Apple ][ 和 Commodore 64 这样的计算机就是这样工作的.在 Windows 或 Linux 等现代多任务操作系统中，应用程序和操作系统通过复杂的多任务安排共享 CPU 的使用，并且应用程序通过操作系统 API 及其设备驱动程序中内置的一组抽象来访问硬件.如果您有兴趣了解很多细节，请参加操作系统设计课程.

In the days of single-process operating systems, it was common for executables to essentially "seize" control of the entire computer and communicate with hardware directly. Computers like the Apple ][ and the Commodore 64 work like that. In a modern multitasking operating system like Windows or Linux, applications and the operating system share use of the CPU via a complex multitasking arrangement, and applications access the hardware via a set of abstractions built in to the operating system's API and its device drivers. Take a course in Operating System design if you are interested in learning lots of details.

根据 Junaid 的回答，内核阻止程序做有趣"的事情的方式是通过控制内存的分配和使用.内核要求通过其 API 请求和访问内存，从而保护计算机免受未经授权"的访问.在单进程操作系统时代，应用程序可以更自由地直接访问内存和其他东西，而无需涉及操作系统.在旧 Apple 上运行的应用程序 ][ 可以读取或写入 RAM 中它想要在整个计算机上的任何地址.

Bouncing off Junaid's answer, the way that the kernel blocks a program from doing something "funny" is by controlling the allocation and usage of memory. The kernel requires that memory be requested and accessed through it via its API, and thus protects the computer from "unauthorized" access. In the days of single-process operating systems, applications had much more freedom to access memory and other things directly, without involving the operating system. An application running on an old Apple ][ can read to or write to any address in RAM that it wants to on the entire computer.

编译后的应用程序不能在另一个操作系统上运行"的原因之一是这些挂钩"对于不同的操作系统是不同的.例如，一个知道如何从 Windows 请求分配 RAM 的应用程序可能不知道如何从 Linux 或 Mac OS 请求它.正如 Disk Crasher 所提到的，这些低级访问指令是由编译器插入的.

One of the reasons why a compiled application won't just "run" on another operating system is that these "hooks" are different for different operating systems. For example, an application that knows how to request the allocation of RAM from Windows might not have any idea how to request it from Linux or the Mac OS. As Disk Crasher mentioned, these low level access instructions are inserted by the compiler.

这篇关于操作系统内核是所有其他程序的解释器吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！