从语法上讲，它是 C 的超集。但是由于消息是在运行时发送和处理的，这意味着它不能是像 c 这样的纯编译语言，但它需要像 Visual Basic 或 .Net 运行时这样的运行时。
那么是什么阻止它通过将此运行时转换为 .NET Framework 或 Java JVM 之类的东西来移植到其他平台呢？
注意：当我说 VB 时，它当然是最后一个版本 6，它编译为字节码，所以你为什么要假装 Java 或 .Net 与 VB6 根本不同，除了可移植性，它是相同的原则：参见类似于 Java，Visual Basic 被编译成中间语言称为“字节码”。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。
阅读更多：http ://www.answers.com/topic/visual-basic#ixzz19iJd3wjA
与 Java 类似，Visual Basic 被编译成一种称为“字节码”的中间语言。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。
您似乎对语言特性的运行时支持的需求以及本机编译和 VM 编译（或解释）语言之间的区别感到困惑。
大多数高级语言都需要某种运行时支持。甚至 C 也有一个运行时库，尽管在许多平台上您可以选择不使用其中的一部分或全部。现代操作系统提供更多的运行时支持，并且许多语言提供集成这些的操作系统特定的扩展 - 考虑动态加载库......
此外，没有什么能阻止您在本质上不支持它的语言之上构建消息传递系统。由于这是非常常见的（尤其是为事件驱动平台编写的程序），将其集成到语言中可以被视为简单地将一些容易出错的繁忙工作从高级代码中分解到语言和运行时中。
最后，Java 和大多数 .NET 语言实际上都是经过编译的——它们只是编译成没有机器本机实现的字节码，需要使用虚拟机来实际执行它们。性能最高的 VM 在执行代码之前会再次编译代码- 这是一种非常有效的技术，已被用于构建快速高效的编译器工具链！
Visual Basic 在这里是一个红鲱鱼 -一些版本被解释，其他版本被编译，并且 VB.NET - 与其他 .NET 语言一样 - 被编译为字节码，然后在执行期间再次 JIT 编译（虽然表面上相似，但这往往会被实现与早期的 VB VM 非常不同）。如果不出意外，这应该告诉您，一种语言及其执行程序的方式并不像通常认为的那样紧密耦合......
回答您的最后一个问题：Objective-C 从来都不是可移植的，至少在 C 是可移植的意义上（也就是说，源代码可移植性）。Apple 使用 GCC 编译器，它已被移植到令人眼花缭乱的平台阵列中……但是，一旦您开始利用特定于平台的 API（这可能是开始在 Apple 平台上使用 Obj-C 的最佳理由之一。 ..) 您仅限于实现这些 API 的平台。理论上二进制可移植性是可能的，但我知道没有实现。
它根本不遵循无法编译消息传递。它仅意味着消息必须在运行时解析为方法调用。Objective-C当然是一种编译语言。
此处描述了该过程。确实，对方法的初始调用比 C++ 方法调用慢，但解析被缓存，因此后续调用更快。这种非确定性的行为会使 Objective-C 不适合某些应用程序。
Objective-C 作为 GCC 的前端提供，因此具有高度可移植性。然而，只有 OSX 及其前身 NextSTEP 和 iOS 具有 OS API，Objective-C 是其首选语言（即编写 OS API 的语言）。因此，虽然它可以在任何支持 GCC 的操作系统上使用，但它在此类平台上的用处是有限的。