Talk:Comparison of operating system kernels

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

message: What about including Windows Kernel in the list?  —The preceding unsigned comment was added by 82.50.31.90 (talk • contribs) 15:33, 25 January 2006 (UTC)
replies: text: 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)
thread_title: include Windows Kernel in the list?

message: 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 (talk • contribs) 15:08, 25 April 2006 (UTC)
thread_title:  why i added a used in section 

message: 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 (talk • contribs) 15:11, 25 April 2006 (UTC)
replies: text: 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)
thread_title:  is mklinux a kernel? 

message: 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)
thread_title:  "Multiple CPU support"? 

message: 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)
thread_title: Further work on article

message: 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)
replies: text: 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)
thread_title:  HURD 

message: 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)
replies: text: 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)
thread_title:  Windows NT kernel and "UNIX binaries" 

message: 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)
thread_title:  Bug with sorting the CPU table 

message: 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)
thread_title:  The existence of userland code that can load binaries doesn't necessarily mean the ''kernel'' can load them 

message: 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)
thread_title:  Windows NT kernel and UT 

message: 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)
thread_title:  ACLs? 

message: Where is QNX? 147.209.216.245 (talk) 04:26, 6 July 2012 (UTC)
replies: text: Not in this table.  Would you like to add it? Guy Harris (talk) 06:29, 6 July 2012 (UTC)
thread_title:  QNX 

message: 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)
replies: text: 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)
thread_title:  AmigaOS Realtime? 

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

message: 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)
thread_title:  NTFS 

message: 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)
replies: text: 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)
replies: text: (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)
thread_title:  Question 

message: The  call in the Windows API isn't a simple NT system call.  There is a native  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,  will open a PE executable and map it, but, for other executable types, the user-mode  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)  might understand ELF images and load them itself, in which case the NT kernel itself understands ELF, or or 2)  might not understand them, and  might run a "Linux ELF helper" program, which itself would be a PE executable, through , 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)
replies: text: 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)
thread_title:  Windows 10 support for ELF might not be done in kernel mode 

message: 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)
replies: text: 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)

text: 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)
thread_title: CPU Architectures unsupported by all