Talk:Comparison of operating system kernels

Latest comment: 5 months ago by MFNickster in topic is mklinux a kernel?

DOS edit

Anyone care to add DOS to the list? Khashishi (talk) —Preceding undated comment added 22:55, 3 May 2011 (UTC).Reply

include Windows Kernel in the list? edit

What about including Windows Kernel in the list? —The preceding unsigned comment was added by 82.50.31.90 (talkcontribs) 15:33, 25 January 2006 (UTC).Reply

The NT kernel is in the list; that's what's used in W2K (NT 5.0), WXP (NT 5.1 in 32-bit form and 5.2 in 64-bit form), and WServer2K3 (NT 5.2). The old "Windows OT" (W95, W98, WMe) kernel might or might not be interesting at this point; add it if you think it interesting. Guy Harris 19:40, 24 February 2006 (UTC)Reply

why i added a used in section edit

kenrel are a small part of a an operating system and alone they are useless

In order to be usefull some uttilities or api need to be ported to ther kernel

for example the GNu coreutils had to be ported to the Hurd kernel

and so some times some people port the kernel to several api/uttilities,such as the FreeBSD or the XNU kernnel

some kenrel are even capable to have different subsystem such as windowsNT and ReactOS kernel —The preceding unsigned comment was added by 213.189.165.28 (talkcontribs) 15:08, 25 April 2006 (UTC).Reply

is mklinux a kernel? edit

can we consider mklinux a full fetured kernel?

because i understood that mklinux was a port of the linux kernel to the mach kernel

it is like l4linux or colinux

if we it is true and we choose to keep it we must create another tab for the ported kernel in another section such as == == —The preceding unsigned comment was added by 213.189.165.28 (talkcontribs) 15:11, 25 April 2006 (UTC).Reply

Very old topic, but I suggest removing the line for MkLinux because it really is just a standard Mach kernel with a Linux compatibility layer. There's no real information on that line anyway, so it should be deleted and MkLinux should be added to the "used in" box for Mach. MFNickster (talk) 16:33, 18 November 2023 (UTC)Reply

"Multiple CPU support"? edit

So what does "multiple CPU support" mean? Does it mean "supports a machine with more than one CPU", which seems a bit redundant given that there's a column for SMP support, or does it mean "supports more than one CPU instruction set"? Guy Harris 23:44, 25 April 2006 (UTC)Reply

Further work on article edit

Someone could read this paper on TRIX and expand that and this article:

  • Ward, S.A. TRIX: a Network-oriented Operating System. COMPCON, Spring 1980, pp. 344-349.

- Lentower 00:43, 8 November 2006 (UTC)Reply

Linux Kernel and PE edit

Is it really suitable to list 'Yes' there for something that uses a totally third party application to perform? I feel this table will get pretty distorted when we're listing emulators as well. -- Andrz 09:21, 23 March 2007 (UTC)Reply

Agreed, I changed it to {{some}}, although I am not completely sure that's fair either. The only thing that kernel can do with PE executables is the capability of recognizing arbitrary executable headers through binfmt_misc and passing them on to the user space handler program. I am unsure if other OSes where Wine works on top of support this.
Also note that Wine is technically not an emulator — it's a native compatibility layer. -- intgr 08:42, 4 April 2007 (UTC)Reply

HURD edit

GNU's Hurd is not a kernel. Hurd is a collection of servers that runs on the Mach kernel. Read the website. 75.70.143.81 20:05, 25 September 2007 (UTC)Reply

Actually that they have ditched the Mach microkernel and are now moving to L4. While the "core kernel" itself indeed is an L4 or Mach, microkernels alone are in no way comparable to the monolithic kernels of today's operating systems — they can only do context switching and essential memory management. If you want to compare them, you need to compare them with all the services that actually provide the functionality. -- intgr [talk] 23:17, 25 September 2007 (UTC)Reply

Windows NT kernel and "UNIX binaries" edit

Can you check this article?: Comparison_of_kernels#Binary_format_support

Does WinNT support a.out, ELF (UNIX binaries), HUNK (AmigaOS bin) and Mach-O (OS X/NextStep/Darwin bin)? Maybe WinNT support COFF, because EXE PE is a modified version of the Unix COFF file format, but I don't that Windows support Linux, AmigaOS or MacOS X bianry formats. Windows NT have only partial support for POSIX API (and OS/2/NET/Win32), not for UNIX (and Amiga/Darwin) bin.

Sorry for my bad English, but it isn't my native language.

83.23.15.210 (talk) 12:31, 24 December 2007 (UTC)Reply

The claimed support for all the other executable formats was added on the 13th of December by an IP with only one other edit, presumably as vandalism; I've now reverted it. Thanks for pointing it out! -- simxp (talk) 15:34, 24 December 2007 (UTC)Reply

Bug with sorting the CPU table edit

If I click the sort sign next to the Intel header (so it will be sorted by the supported type of CPUs by Intel) the table gets all messed up instead of being sorted, should I file a report against MediaWiki? Yaron Shahrabani (talk) 21:08, 3 December 2009 (UTC)Reply

The existence of userland code that can load binaries doesn't necessarily mean the kernel can load them edit

If this is truly a comparison of operating system kernels, the list of executable image formats, etc. shouldn't list binaries that are purely supported in userland; this includes Preferred Executable Format in Mac OS X:

$ ps -ef | egrep Quicken
  501 26287   135   0   0:00.72 ??         0:04.16 /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007
  501 26290   242   0   0:00.00 ttys000    0:00.00 egrep Quicken
$ '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'
-bash: /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007: Permission denied
$ ls -l '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'
-rw-r--r--@ 1 gharris  staff  10563774 Dec  1  2006 /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007
$ chmod a+x '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'
$ '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'
-bash: /Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007: cannot execute binary file

Launch Services, when told to launch a PEF binary, runs LaunchCFMApp to start it:

$ file /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp
/System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp: Mach-O executable ppc
$ file '/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007'
/Applications/Quicken 2007/Quicken 2007/Contents/MacOS/Quicken 2007: header for PowerPC PEF executable

And, no, none of the Classic binaries count, either, as those are run purely from userland code.

If the kernel can recognize some particular executable image format and run it, even if it pulls in a userland helper, I might be willing to count that, so maybe executing PE binaries through Wine counts if the kernel recognizes them, so that an exec call can be used to run them. Guy Harris (talk) 07:17, 20 April 2011 (UTC)Reply

Windows NT kernel and UT edit

The Windows NT kernel does indeed support UT. Its a hidden feature prior to Windows Vista. Google setting UT on XP and 2000 provide registry settings to tweak this (HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal). This, as I understand it, is partly there for POSIX comparability. Issues with UT support come from software making bad assumptions in userspace. (24.246.27.22 (talk) 17:29, 28 October 2011 (UTC))Reply

ACLs? edit

The "Security" column in the "Feature overview" table lists ACLs for some kernels; the "File access control" column also lists ACLs. Does the reference to ACLs in the "Feature overview" table refer only to files, or does it refer also to objects inside the operating system that don't refer to files? Guy Harris (talk) 01:34, 9 February 2012 (UTC)Reply

QNX edit

Where is QNX? 147.209.216.245 (talk) 04:26, 6 July 2012 (UTC)Reply

Not in this table. Would you like to add it? Guy Harris (talk) 06:29, 6 July 2012 (UTC)Reply

AmigaOS Realtime? edit

Although there were no officially supported guaranteed response times, it's kind of common knowledge among "Amiga people" that the Exec actually has real-time characteristics, where no OS supplied interrupt handler takes more than a really short time to execute and the prioritizing of tasks/processes are absolute. Perhaps "partial" is a reasonable real-time status of AmigaOS <=3.x? (Sidenote: it's this combined with that the gui has higher priority than for example file system code and many other OS parts that makes people used to the Amiga complain about most other GUI's being sluggish...) — Preceding unsigned comment added by 78.70.109.74 (talk) 16:31, 17 October 2012 (UTC)Reply

The exec can not guarantee a response time. Applications can stop task scheduling at any time at any place. Xorxos (talk) 01:08, 18 October 2012 (UTC)Reply

BHyVe (KVM) edit

What means KVM?--141.24.71.10 (talk) 09:39, 12 February 2013 (UTC)Reply

NTFS edit

Given that there are multiple file systems for which Windows NT support is given as "Yes, additional driver needed", almost all of the kernels listed should have the same status for NTFS (in addition to any built-in support) — after all, ntfs-3g offers them near complete support. -- 188.194.184.143 (talk) 14:02, 10 June 2013 (UTC)Reply

Question edit

Shouldn't an operating system "kernel" be called an operating system "nucleous" for the purpose of eliminating the possibility of people thinking you're talking about corn when you say kernel instead of actually realizing that you're talking about software?

In Romanian, we say "nucleul sistemului de operare". Translated into english it would mean: "operating system nucleous". — Preceding unsigned comment added by 76.115.25.117 (talk) 09:40, 4 October 2013 (UTC)Reply

Perhaps "nucleus" should have been chosen as the term rather than "kernel" - and some core part of OS/360 was called the "nucleus" - but, for better or worse, "kernel" is a term widely chosen in English. Quickly looking at the "other language" links for Romance and Germanic languages on the kernel (computing) page, the Romance languages tend to go for words cognate with "nucleus" (I'm guessing that the French "noyau" so translates, although it's a bit more different from the Latin than other Romance languages) and the Germanic languages tend to go for words cognate with "kernel", but the OED's etymology for "nucleus" says "early 18th century: from Latin, literally 'kernel, inner part', diminutive of nux, nuc- 'nut'", so I guess it's a choice between whether an operating system is like a nut or like an ear of maize. :-) (Slavic languages tend to go for variants of "yadro", which, from my not-much-remembered studies of Russian and from translate.google.com's translation of "jadro" in Slovak, is "core", so it's the same basic idea.) Guy Harris (talk) 17:41, 4 October 2013 (UTC)Reply
(And then there's "atomkern", which is, in English, "atomic nucleus". The second paragraph of the German Wikipedia article in question even discusses the Latin roots of "nucleus".) Guy Harris (talk) 08:23, 5 October 2013 (UTC)Reply

Windows 10 support for ELF might not be done in kernel mode edit

The CreateProcess() call in the Windows API isn't a simple NT system call. There is a native NtCreateUserProcess() call, but, according to Windows Internals, Sixth Edition (the edition of that series that describes Windows 7 and Windows Server 2008 R2), Part 1, in the "Flow of CreateProcess" section, NtCreateUserProcess() will open a PE executable and map it, but, for other executable types, the user-mode CreateProcess() library routine has to open the image itself and find a "Windows support image" to run the executable. This is somewhat like the way #! is handled on UN*Xes and binfmt_misc works on Linux.

So either 1) NtCreateUserProcess() might understand ELF images and load them itself, in which case the NT kernel itself understands ELF, or or 2) NtCreateUserProcess() might not understand them, and CreateProcess() might run a "Linux ELF helper" program, which itself would be a PE executable, through NtCreateUserProcess(), or connect to an existing process running that helper, and that process would load the image. We can't assume that the support for Linux ELF binaries means that the kernel itself knows about ELF binaries. Guy Harris (talk) 18:47, 31 March 2016 (UTC)Reply

Are you referring to the ELF support introduced in Windows Subsystem for Linux? That is implemented in the kernel (well, the LXSS kernel drivers) in order to allow the exec system call to function. Prior to Windows Subsystem for Linux, Windows did not support ELF files in any scenario. The older Unix Subsystem worked only with PE executables compiled from Unix-compatible sources. Zhuman (talk) 10:45, 28 March 2018 (UTC)Reply

CPU Architectures unsupported by all edit

It seems strange to me to include cpu architectures supported by none of the listed operating systems.Bepvte (talk) 23:07, 22 October 2018 (UTC)Reply

I see no solidly-red column in the table in Comparison of operating system kernels#Supported CPU instruction sets and microarchitectures. I see some columns that have no green cells, just a mixture of red cells and grey "?" cells, but that's different - that says none of the OSes are known, by anybody who's bothered to update the table, to support that architecture, but that doesn't mean that they're known not to support it. Guy Harris (talk) 06:33, 23 October 2018 (UTC)Reply
Either way, it seems like a waste of space and could make it much easier to scroll through the table. It just doesn't make sense to me to have columns for data we don't have yet.Bepvte (talk) 16:21, 23 October 2018 (UTC)Reply

Comparison needs new column: Programming Language edit

The chart direly needs a column to document what language the kernel is developed in. The language is a critical factor in determining OS reliability and ease of writing programs.