我只是想知道谁知道Windows,Mac OS X和Linux是由哪些编程语言组成的,以及OS的每个部分使用的语言(即:内核,插件架构,GUI组件等).
我假设每种语言都有多种语言,显然我知道Linux内核是用C语言编写的.
我完全猜测Mac OS X包含很多Objective-C代码,因为它是源自NeXT的Apple语言.
Windows,我听说包含C,C++和Intel Assembly.Linux或Mac OS是否包含任何汇编代码?
此外,操作系统开发人员是否使用Ruby,Python等脚本语言来编写操作系统的部分脚本?操作系统的哪些部分将用每种语言编写?
Windows:C++,内核在C中
Mac:目标C,内核在C中(IO PnP子系统是嵌入式C++)
Linux:大多数东西都在C语言中,许多用户态应用程序都在Python中,KDE都是C++
所有内核也将使用一些汇编代码.
Linux:C.汇编中的一些部分.
[...]它主要在C中,但是大多数人都不会打电话给我写的C.它使用了我能找到的386的所有可想象的特征,因为它也是一个教我386的项目.如前所述,它使用MMU,用于分页(不是磁盘)和分段.它的细分使得它真正依赖于386(每个任务都有64Mb代码和数据段 - 4Gb中最多64个任务.任何需要超过64Mb /任务的人 - 坚韧的cookie).[...]我的一些"C"文件(特别是mm.c)几乎和C一样多.[...]与minix不同,我也碰巧是LIKE中断,所以处理中断而不试图隐藏他们背后的原因.(资源)
Mac OS X:Cocoa主要在Objective-C中.用C编写的内核,汇编中的一些部分.
在内核层,Mac OS X主要是一个较老的免费操作系统,称为BSD(具体来说,它是Darwin,一种BSD,Mach和其他一些东西的混合体)......几乎完全是C,有点像抛出的汇编程序.(来源)
大部分Cocoa都是在Objective-C中实现的,这是一种面向对象的语言,它被编译为以令人难以置信的速度运行,但却采用了真正的动态运行时,使其具有独特的灵活性.因为Objective-C是C的超集,所以很容易将C甚至C++混合到Cocoa应用程序中. (资源)
Windows:C,C++,C#.汇编程序中的某些部分.
我们几乎完全使用C,C++和C#for Windows.一些代码区域是手动调整/手写组装.(资源)
Unix:C.汇编中的一些部分.(资源)
Mac OS X在某些库中使用了大量的C++,但它没有暴露,因为它们害怕ABI破坏.
我知道这是一篇旧帖子,但Windows绝对不是用C++编写的.其中有很多C++,但我们技术定义为操作系统的不是C++.Windows API,Windows内核(这两者本质上都是操作系统)是用C语言编写的.几年前,我给了Windows 2000和Windows XP一些泄露的代码.代码不够完整,无法编译内核或API,但我们能够编译单独的程序和服务.例如,我们能够成功编译Notepad.exe,mspaint.exe和spoolsv.exe服务(打印后台处理程序).全部用C语言编写.我没有再看过,但我确信泄露的代码仍然存在,因为那里的torrent文件可能仍然可用.
Windows:主要是C和C++,有些是C#
windows:C++
linux:C
mac:目标C.
android:JAVA,C,C++
Solaris:C,C++
iOS 7:Objective-C,Swift,C,C++
你是对的MacOSX的核心是Objective-C.
Windows C++
Linux C
关于脚本语言,不,它们非常高级.
我已经阅读或听说Mac OS X主要是在Objective-C中编写的,其中包含一些较低级别的部分,例如内核和用C编写的硬件设备驱动程序.我相信Apple"吃掉了自己的狗食" ",也就是说,他们使用自己编写的Mac OS X 的Xcode开发工具.的(GNU编译器集合)GCC编译器-连接基是unix命令行工具xcode的用于大多数其编译和/或可执行程序的链接的.在其他可能的语言中,我知道GCC编译来自C,Objective-C,C++和Objective-C++语言的源代码.
哇!!!9年的问题,但我刚刚碰到有关Windows命令行历史的一系列内部文章,我认为其中一部分可能与问题的Windows相关:
对于那些关心此类事情的人:许多人问Windows是用C还是C ++编写的。答案是-尽管NT是基于对象的设计-像大多数OS一样,Windows几乎完全是用C编写的。为什么?C ++在内存占用量和代码执行开销方面带来了成本。即使在今天,用C ++编写的代码的隐藏成本也可能令人吃惊,但在1990年代后期,内存成本约为60美元/ MB(是的……每个MEGABYTE 60美元!),vtables等的隐藏内存成本非常高。另外,虚拟方法调用间接和对象取消引用的成本可能导致当时C ++代码的性能和规模上的巨大损失。尽管仍然需要谨慎,但是现代C ++在现代计算机上的性能开销却很少受到关注,并且考虑到其安全性,可读性和可维护性的好处,通常是可以接受的折衷……这就是为什么我们稳定地将控制台的代码升级到现代C ++。