所以，从我的理解，有两种types的程序，那些是解释和编译。 解释的程序由解释器执行，该解释器是用于该平台的本地应用程序，并且编译的程序本身是其所在平台的本地应用程序（或系统软件）。
但是我的问题是这样的：除了CPU直接运行的内核之外，还有什么？ Windows可执行文件是“Windows可执行文件”，而不是x86或amd64可执行文件。 这是否意味着每一个不是内核的进程都被内核解释，就像浏览器解释Javascript一样？ 或者是内核把这些进程放在内核所处的“裸机”上？
如果他们是“裸机”，那么Windows如何知道一个程序是一个Windows程序而不是Linux程序，因为它们都是为amd64处理器编译的？ 如果是因为可执行文件的“格式”，那么该可执行文件如何能够在“裸机”上运行，因为对我来说，它被格式化为在特定操作系统上运行的事实意味着需要一些解释为它运行。
这个问题太复杂，堆栈溢出？
他们运行在“裸机”上，但它们确实包含特定于操作系统的东西。 一个可执行文件通常会向内核提供一些指令（可以说是“解释”了），程序应该如何加载到内存中，文件的代码将提供方法让它“挂接”到正在运行的操作系统，例如通过操作系统的API或通过设备驱动程序。 一旦这样一个不解释的程序被加载到内存中，它就运行在裸机上，但是继续与运行在裸机上的操作系统通信。
在单进程操作系统的日子里，可执行文件实质上是“抓住”整个计算机的控制，直接与硬件通信的。 像苹果这样的电脑[和Commodore 64就是这样工作的。 在Windows或Linux等现代多任务操作系统中，应用程序和操作系统通过复杂的多任务安排共享CPU的使用，应用程序通过内置于操作系统的API及其设备驱动程序中的一组抽象来访问硬件。 如果您有兴趣学习大量的细节，请参加操作系统设计课程。
从Junaid的回答中，内核阻止程序做一些“有趣的事情”的方式是控制内存的分配和使用。 内核需要通过API来请求和访问内存，从而保护计算机免遭“未经授权”的访问。 在单进程操作系统的时代，应用程序有更多的自由来直接访问内存和其他东西，而不涉及操作系统。 一个运行在旧苹果上的应用程序[可以读取或写入任何想要在整个计算机上的RAM中的地址。
编译的应用程序不会在另一个操作系统上“运行”的原因之一就是这些“钩子”对于不同的操作系统是不同的。 例如，知道如何从Windows请求分配RAM的应用程序可能不知道如何从Linux或Mac OS请求它。 当提到磁盘驱动器时，编译器会插入这些低级访问指令。
我认为你是混淆的东西。 编译的程序是机器可读的格式。 当你运行程序时，内核会分配内存，CPU等，并确保程序不会干扰其他程序。 如果程序需要访问硬件资源或磁盘等，内核将处理它，所以内核将始终在硬件和用户空间中运行的任何软件之间。
如果程序被解释了，那么相关的那个语言的解释器会把代码转换成机器可读的，而且内核仍然会提供像访问硬件一样的功能，并且确保程序不会像尝试访问其他程序存储器等
在“裸机”上运行的唯一东西是汇编语言代码，它是由操作系统和编译器中的许多层从程序员中抽象出来的。 一般来说，应用程序被编译为OS和CPU架构。 他们不会在其他操作系统上运行，至少不是没有兼容的框架（例如Linux上的Mono ）。
早在今天，就有很多代码是使用宏汇编器写在裸机上的，但在今天的PC上却几乎闻所未闻。 （甚至还有一些宏组装者。）