Linux内核升级后，我的VMWare服务器无法启动，直到使用vmware-config.pl进行一些重新配置工作（包括构建一些内核模块）。为什么我需要在Linux内核升级后重新编译vmware内核模块？
如果我用最新的Windows Service Pack更新我的Windows VMWare主机，我通常不需要做任何事情来运行VMWare。
为什么VMWare在Linux和Windows之间的工作方式不同？这种重新编译行为是否会在Windows平台上带来任何好处？
阅读The Linux Kernel Driver Interface。
这是为了解释为什么Linux没有二进制内核接口，也没有稳定的内核接口。请认识到，本文描述_in kernel_ interfaces，而不是用户空间接口的内核。用户空间接口的内核是应用程序使用的接口，即系统调用接口。该界面随着时间的推移非常稳定，并且不会中断。我有一些以前的0.9s内核构建的程序，在最新的2.6内核版本上仍然可以正常工作。这个接口是用户和应用程序员可以依赖的稳定接口。
它反映的Linux内核开发者很大一部分的观点： 自由在任何时候更改内核实施细则和API使他们能够更快，更好地发展。如果没有保证内核接口在发行版本之间相同的承诺，VMWare的二进制内核模块无法可靠地在多个内核上工作。例如，如果某个结构在新内核版本上发生变化（为了获得更好的性能或更多功能或其他原因），二进制VMWare模块可能会使用旧的结构布局造成灾难性的损坏。从源代码再次编译模块将捕获新的结构布局，因此可以更好地工作 - 尽管仍然不是100％，以防字段被删除，重命名或赋予不同的目的。
如果某个函数改变了它的参数列表，或者被重命名或以其他方式不再可用，甚至不会从相同的源代码重新编译。该模块将不得不适应新的内核。由于每个人（应该）都有源并且（可以找到某个人）能够修改它以适应。“向终端节点推送工作”是网络和自由软件中的一个普遍想法：由于Linux内核之外的开发人员的资源大于[骨干]/[ [Linux开发者]，让前者承担更多工作的权衡是可以接受的。另一方面，微软已经决定尽可能地保留二进制驱动程序的兼容性 - 他们没有选择，因为他们在专有世界中玩耍。从某种意义上说，这对于不再面对移动目标的外部开发人员以及对于永远不需要改变任何内容的最终用户来说更容易。不利的一面是，这会迫使微软保持向后兼容性，这对微软的开发人员来说（最好）是耗时的，并且（最坏的情况下）效率低下，导致错误并且阻止向前发展。
Linux没有稳定的内核ABI - 像数据结构的内部布局等事情从一个版本变为另一个版本。 VMWare需要重建以在新内核中使用ABI。
另一方面，Windows有一个非常稳定的内核ABI，不会从Service Pack更改为Service Pack。
要增加到bdonlan的答案，ABI兼容性是一个混杂的包。一方面，它允许您分发二进制模块和驱动程序，这些模块和驱动程序将与新版本的内核一起工作。另一方面，它迫使内核程序员添加大量胶水代码以保持向后兼容性。由于Linux是开源的，并且由于kernel developers even whether they're even allowed，分发二进制模块的能力并不被认为是重要的。另一方面，Linux内核开发人员在改变数据结构以改善内核时不必担心ABI兼容性问题。从长远来看，这会导致更干净的内核代码。
这是Linux和Windows在不同文化环境和期望下开发的结果：http://www.joelonsoftware.com/articles/Biculturalism.html。简而言之：Windows旨在适合用户，而Linux则适合开源开发人员。