5 ms·

Not to belabor the point, but what OSes are actually written in C++? Most will avoid using many if any C++ features even if they ostensibly use a C++ compiler,

Not to belabor the point, but what OSes are actually written in C++? Most will avoid using many if any C++ features even if they ostensibly use a C++ compiler, and most OSes I've seen (Linux, Windows, Darwin) have kernels written in explicitly C. Skift appears (at a very quick glance) to be using more "C++-ish" features than typical, though it's still more "C-ish" than your average C++ code.

adamnemecek 6y ago
Both XNU and Windows have a decent amount of C++ in it. Sure, people avoid some parts of C++, however there is a reason why they use C++.
- spijdar 6y ago
  My understanding is the windows kernel is mostly C, with some highly-restricted C++ portions with most of the C++ runtime-dependent bits carefully avoided. XNU is entirely C except for IOKit AFAIK. My understanding is a lot of C++'s higher level features require pretty thick runtime support and complicate kernel level code to the point the traditional wisdom I've heard in both the hobby world and linux spheres is "Avoid C++ like the plague" or "use C++ but be careful to avoid using exceptions/RTTI/etc". It looks like Skift (and Haiku, apparently!) are mostly using the "watered down" C++, mostly for classes and templated generics, which is a good reason to use C++, yes.
cupofinsane 6y ago
Haiku is written in C++ and provides an object-oriented API. https://en.wikipedia.org/wiki/Haiku_(operating_system) https://en.wikipedia.org/wiki/Haiku_(operating_system)
monax 6y ago
Author here, skift was ported from C to C++, wich explain why most of the code is still "C-ish". The port was relatively easy thanks to the -Wc++-compat flags
pjmlp 6y ago
Darwin is also written in C++, unless you don't consider drivers part of the kernel. Windows has supported kernel code in C++ since Vista, hence why VC++ has the /kernel option on cl.exe. BeOS, Symbian, ARM mbed, Arduino, IncludeOS, Meadow, GenodeOS for example. Yes the set of C++ features one uses on the kernel isn't the full language, neither is C when used on the kernel.
skissane 6y ago
> Not to belabor the point, but what OSes are actually written in C++? IBM i – probably best known under its original name of OS/400, the operating system of the IBM AS/400. Its lowest layer is called LIC (Licensed Internal Code), and is written in C++. In the beginning, AS/400 used a proprietary CISC processor called IMPI (never publicly documented, but its instruction set apparently resembled somewhat that of IBM 370 mainframes, without being compatible with them.) User applications and higher-level OS components were not written in IMPI, but in a virtual machine bytecode called MI. LIC was responsible for translating MI code into IMPI and providing low level OS services. The LIC was written in a secret PL/I dialect (IBM has a few of those) called PL/MP. As part of the CISC-to-RISC translation, the PL/MP code of the LIC was rewritten in C++. The higher levels of the OS, which run inside the MI virtual machine, are written in a variety of languages – C++, PL/MI (another secret PL/I dialect) and Modula 2.
- spijdar 6y ago
  Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah. My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer. All disabled on openPOWER hardware, but still...
  - skissane 6y ago
    > Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah I think the whole thing in some way is less-sheltered (especially from other parts of IBM) than it at first appears. Originally IBM planned to replace the 360/370 mainframe line with a brand new platform called "Future Systems". The idea was killed, but it survived in the form of the System/38. So a lot of the novel technologies in S/38 originally came from the mainframe side of the business, albeit ideas they never actually shipped. Most of the lower-level code of S/38 was written in custom PL/I dialects (PL/MP, PL/MI) – something other parts of IBM were big on (much of z/OS is written in PL/X; some of the mainframe firmware was written in PL.8; the 8100 was written in PL/DS). The CISC processor of the original AS/400 had an instruction set inspired by the 370 mainframe architecture. RPG came from the 1400 series, and was supported on 360/370 as well, albeit never very popular there. And of course, EBCDIC. The developers who originally wrote OS/400 (and System/38 CPF before it) did the development work on VM/CMS, since OS/400 was never self-hosting. So a lot of the bits that went into the AS/400 originally came from other parts of IBM, or were consistent with what other parts of IBM were doing. As far as C++ goes, I think that was a deliberate decision to try to get away from writing code in secret PL/I dialects and move to an industry standard language. Parts of the OS were written in Modula 2, which was an earlier attempt at doing the same thing, albeit that attempt failed because Modula 2 didn't take off like some people thought it would. In more recent times, the biggest influence on IBM i has been AIX (with PASE) and Linux (with porting open source software to PASE). But it has drawn influences from various other sources over the year. If you have access to an IBM i box, check out the file /QIBM/include/os2.h, which provides (through the other headers it includes) a tiny subset of the OS/2 APIs. (I get the impression the plan, at one point, was to port a lot more of the OS/2 API to OS/400, but the plan died before they could port any more than a tiny subset of it.) > My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer POWER isn't the only architecture with memory tagging now. SPARC has had it since 2015 (SPARC ADI introduced in M7). ARM has an extension for it, MTE (I don't know if any hardware has shipped with it yet, but QEMU emulates it.)
deleted 6y ago
[deleted]

adamnemecek 6y ago

Both XNU and Windows have a decent amount of C++ in it. Sure, people avoid some parts of C++, however there is a reason why they use C++.

spijdar 6y ago
My understanding is the windows kernel is mostly C, with some highly-restricted C++ portions with most of the C++ runtime-dependent bits carefully avoided. XNU is entirely C except for IOKit AFAIK. My understanding is a lot of C++'s higher level features require pretty thick runtime support and complicate kernel level code to the point the traditional wisdom I've heard in both the hobby world and linux spheres is "Avoid C++ like the plague" or "use C++ but be careful to avoid using exceptions/RTTI/etc". It looks like Skift (and Haiku, apparently!) are mostly using the "watered down" C++, mostly for classes and templated generics, which is a good reason to use C++, yes.

cupofinsane 6y ago

Haiku is written in C++ and provides an object-oriented API. https://en.wikipedia.org/wiki/Haiku_(operating_system) https://en.wikipedia.org/wiki/Haiku_(operating_system)

monax 6y ago

Author here, skift was ported from C to C++, wich explain why most of the code is still "C-ish". The port was relatively easy thanks to the -Wc++-compat flags

pjmlp 6y ago

Darwin is also written in C++, unless you don't consider drivers part of the kernel. Windows has supported kernel code in C++ since Vista, hence why VC++ has the /kernel option on cl.exe. BeOS, Symbian, ARM mbed, Arduino, IncludeOS, Meadow, GenodeOS for example. Yes the set of C++ features one uses on the kernel isn't the full language, neither is C when used on the kernel.

skissane 6y ago

> Not to belabor the point, but what OSes are actually written in C++? IBM i – probably best known under its original name of OS/400, the operating system of the IBM AS/400. Its lowest layer is called LIC (Licensed Internal Code), and is written in C++. In the beginning, AS/400 used a proprietary CISC processor called IMPI (never publicly documented, but its instruction set apparently resembled somewhat that of IBM 370 mainframes, without being compatible with them.) User applications and higher-level OS components were not written in IMPI, but in a virtual machine bytecode called MI. LIC was responsible for translating MI code into IMPI and providing low level OS services. The LIC was written in a secret PL/I dialect (IBM has a few of those) called PL/MP. As part of the CISC-to-RISC translation, the PL/MP code of the LIC was rewritten in C++. The higher levels of the OS, which run inside the MI virtual machine, are written in a variety of languages – C++, PL/MI (another secret PL/I dialect) and Modula 2.

spijdar 6y ago
Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah. My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer. All disabled on openPOWER hardware, but still...
- skissane 6y ago
  > Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah I think the whole thing in some way is less-sheltered (especially from other parts of IBM) than it at first appears. Originally IBM planned to replace the 360/370 mainframe line with a brand new platform called "Future Systems". The idea was killed, but it survived in the form of the System/38. So a lot of the novel technologies in S/38 originally came from the mainframe side of the business, albeit ideas they never actually shipped. Most of the lower-level code of S/38 was written in custom PL/I dialects (PL/MP, PL/MI) – something other parts of IBM were big on (much of z/OS is written in PL/X; some of the mainframe firmware was written in PL.8; the 8100 was written in PL/DS). The CISC processor of the original AS/400 had an instruction set inspired by the 370 mainframe architecture. RPG came from the 1400 series, and was supported on 360/370 as well, albeit never very popular there. And of course, EBCDIC. The developers who originally wrote OS/400 (and System/38 CPF before it) did the development work on VM/CMS, since OS/400 was never self-hosting. So a lot of the bits that went into the AS/400 originally came from other parts of IBM, or were consistent with what other parts of IBM were doing. As far as C++ goes, I think that was a deliberate decision to try to get away from writing code in secret PL/I dialects and move to an industry standard language. Parts of the OS were written in Modula 2, which was an earlier attempt at doing the same thing, albeit that attempt failed because Modula 2 didn't take off like some people thought it would. In more recent times, the biggest influence on IBM i has been AIX (with PASE) and Linux (with porting open source software to PASE). But it has drawn influences from various other sources over the year. If you have access to an IBM i box, check out the file /QIBM/include/os2.h, which provides (through the other headers it includes) a tiny subset of the OS/2 APIs. (I get the impression the plan, at one point, was to port a lot more of the OS/2 API to OS/400, but the plan died before they could port any more than a tiny subset of it.) > My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer POWER isn't the only architecture with memory tagging now. SPARC has had it since 2015 (SPARC ADI introduced in M7). ARM has an extension for it, MTE (I don't know if any hardware has shipped with it yet, but QEMU emulates it.)

deleted 6y ago

[deleted]