事件是否通过 OS 传递？
Are events passed through the OS?
首先，如果事件源自硬件输入，OS 如何检测这些事件？这是通过轮询还是通过 BIOS 实现的？那么 BIOS 将如何捕获这些事件？轮询？他们不能使用 API 因为它与硬件交互，或者他们可以吗？
其次，OS 是否将这些事件向上传递到链中，例如，浏览器将它们传递给更高级别的编程语言，如 javascript？
第三，是否所有的事件驱动模型最终都依赖轮询机制来检测OS/BIOS级别的事件？如果是这样的话，我们能否在事件驱动编程中拥有一个真正的 "push" 系统？
冒着过度简化的风险，现在大多数事件都是从中断开始的。硬件触发一个 CPU 中断，然后分派给中断处理程序。
然后中断处理程序决定如何处理它们。
如果一个进程以某种方式注册了中断通知，可能会发生两种情况：
OS可以触发软件中断。这会中断进程的正常 运行 并调用进程声明要处理的函数 "things." 一个进程通常可以有多个函数处理不同的中断。
OS 可以创建添加到事件队列的事件。该进程从队列中读取以弄清楚发生了什么（MS-Windoze/X Windows 编程模型）。
事实上，Windoze 使用了这两种机制。底层 NT 系统被设计为使用软件中断（使用表示管理器 UI）。 Windoze 3起飞后，M$切换到隐藏底层软件中断系统的WIndoze界面
轮询可用于某些类型的设备，但这种情况正变得越来越不常见。在过去，您必须反复轮询操纵杆以确定其在一个实例中的位置。飞行模拟必须反复轮询操纵杆以确定前进方向，为此，它必须轮询多次。
因此，通常的顺序是 OS 获取中断 > OS 处理中断 > OS 创建队列条目 > 应用程序从队列中挑选条目。
首先，如果事件源自硬件输入，OS 如何检测这些事件？这是通过轮询还是通过 BIOS 实现的？那么 BIOS 将如何捕获这些事件？轮询？他们不能使用 API 因为它与硬件交互，或者他们可以吗？
其次，OS 是否将这些事件向上传递到链中，例如，浏览器将它们传递给更高级别的编程语言，如 javascript？
第三，是否所有的事件驱动模型最终都依赖轮询机制来检测OS/BIOS级别的事件？如果是这样的话，我们能否在事件驱动编程中拥有一个真正的 "push" 系统？
冒着过度简化的风险，现在大多数事件都是从中断开始的。硬件触发一个 CPU 中断，然后分派给中断处理程序。
然后中断处理程序决定如何处理它们。
如果一个进程以某种方式注册了中断通知，可能会发生两种情况：
OS可以触发软件中断。这会中断进程的正常 运行 并调用进程声明要处理的函数 "things." 一个进程通常可以有多个函数处理不同的中断。
OS 可以创建添加到事件队列的事件。该进程从队列中读取以弄清楚发生了什么（MS-Windoze/X Windows 编程模型）。
事实上，Windoze 使用了这两种机制。底层 NT 系统被设计为使用软件中断（使用表示管理器 UI）。 Windoze 3起飞后，M$切换到隐藏底层软件中断系统的WIndoze界面
轮询可用于某些类型的设备，但这种情况正变得越来越不常见。在过去，您必须反复轮询操纵杆以确定其在一个实例中的位置。飞行模拟必须反复轮询操纵杆以确定前进方向，为此，它必须轮询多次。
因此，通常的顺序是 OS 获取中断 > OS 处理中断 > OS 创建队列条目 > 应用程序从队列中挑选条目。