SkiftOS: Simple, handmade operating system for the x86 platform
github.com
github.com
Congrats for the work and the front-page, though you seem to live in alternative universe. The last time I checked, a project with ~2250 commits, ~30 contributors, a website and dozens of releases is by no means "small".
Sorry, I never work on any another project so I might lack a point of reference to judge the size of my project.
I wish there was a nice wrapper dedicated to abstracting hardware support better so developers can focus on the interesting parts instead of arguing with wi-fi cards.
Thinking about it, this is what the BIOS was originally for: to provide a bare minimum abstraction to the hardware. I hoped that UEFI would extend this abstraction in a meaningful way, making OS development easier. Instead it has made it even more complex.
UEFI, sadly, added support for raw x86 option ROMs, to some extent casting us back into the "old" world.
You bring up wi-fi cards and that is definitely one category of hardware with little standardisation/documentation (I suspect due to FCC regulations and such.) Wired ethernet is a bit better --- Realtek and Intel NICs are both quite well-documented, with the latter being more complex. The other difficult one is GPU acceleration (but a VESA framebuffer is usually available, which gets you at least a GUI if not a fast one.)
Are Linux device drivers not nice enough? Hell, why couldn’t one think, for that matter, of a minimal Linux kernel as some kind of BIOS. Incidentally, we already use it as a hypervisor, so you could probably even include support for the devices you want in the hypervisor itself.
The University of Utah had a research project back in the late 1990s which offered exactly that – the OSKit project [0]. A set of libraries for common (at the time) x86 hardware so OS developers and researchers could focus on what was original about their OS instead of writing yet another hard disk or Ethernet driver
Unfortunately, the research project ended circa 2000 and it is dead now. No support for contemporary devices like Wifi and USB. But, if you just want something to run in a VM (QEMU or VirtualBox or whatever) it probably still works.
How was OSkit different?
Linux gives no API stability guarantees for its internal APIs, only for the system call interface. By contrast, the OSKit developers intended the API of each component to be a stable documented interface. The Linux developers don't want Linux's internal APIs to be stable documented interfaces because that has a cost in that it slows down refactoring, which in turn reduces the various benefits that refactoring can produce (better performance, better maintainability, new features, etc)
It also has the "benefit" of making it extremely difficult to actually distribute stable device drivers that are closed source, or are simply not part of the actively-maintained kernel source tree.
Not really; also, the freedom to do something "different" in the device driver space is extremely limited: all you can do is decide on the packaging, kernel space vs. userspace and not much more.
So beyond the low level drivers that directly interact with hardware, an OS differs in how you ... drive the drivers. What your HAL looks like, and then what the abstractions above that look like.
It's by that definition that e.g. Android is considered a different OS from GNU/Linux. Same kernel, but the hardware is exposed much differently to end-user applications.
There is NopSys, about 3500 lines of C and 600 lines of assembler for booting, accessing device registers, and responding to interrupts. So you can write the rest of the OS on top of that. CogNOS is a Smalltalk system written on top of NopSys.
https://github.com/nopsys/nopsys
The NetBSD kernel has the ability to be built as a library, letting various drivers be used in other ways -- it's called a "rump kernel" [0]. I've never played with it myself but my understanding is that this would be sufficient to provide drivers in one's own kernel, given enough plumbing and shims and such.
(With enough shims one could borrow drivers from any kernel -- see ndiswrapper to use Windows network-card drivers in Linux -- but the rump kernel scaffolding is supposed to make it easier.)
[0] https://www.netbsd.org/gallery/presentations/justin/2015_Asi...
- OO support / modularity
- microkernel
If this decision was made and adhered to early then:
- new drivers could just import and inherit, filling in only the specifics
- new drivers would be self-contained and (hopefully) not affect stability of the system
I guess the problem is that most drivers have already been implemented in C and would require redesign or at least porting.
[0]: https://www.reddit.com/r/osdev/comments/ky7igd/my_handmade_w...
[1]: https://www.youtube.com/watch?v=Za0oHBFr9zo
[2]: https://github.com/skiftOS/skift/blob/main/apps/text-editor/...
[3]: https://github.com/skiftOS/skift/blob/main/libraries/libwidg...
[4]: https://github.com/skiftOS/skift/blob/main/libraries/libwidg...
[5]: https://github.com/skiftOS/skift/tree/main/libraries/libwidg...
Anyway, I will try this OS now! UI looks beautiful.
I don't understand why Apple and Microsoft feel stuck to one OS.
Momentum.
Look at every OS that's on the market right now. It solves a problem. Right now there are very few people who can't pick an OS off the shelf that will solve their particular problem. Be it an RTOS or a fancy gui that your grandma is comfortable with, the software already exists.
I guess what I'm really trying to say is that unless you can upend the current OS landscape while maintaining compatibilty, then a new OS for the masses doesn't solve a problem. It creates one.
I think you're right about momentum, MS isn't able to come out of it's momentum of the old into the new.
For example, Apple transitions to a new OS with confidence and takes the ecosystem with it in a blink of an eye because they are trying control their momentum instead of being driven by it.
Edit: Windows can maintain backward compatibility with its ecosystem if they did it well, like Apple has done.
Backwards compatibility with the ecosystem, especially the enormous ecosystem of software that doesn't have active maintainers chomping at the bit to test/patch/update with every single OS change, is a HUGE part of why people use Windows.
Apple really doesn't have this. Instead, they have a critical mass of software that is inside their RDF and actively updates to every breaking change they roll out. They have the "luxury" of not having to care if they break random bits of old software* in the process.
(* software that may be niche, may not have large individual user bases, but which might actually not have modern up-to-date drop-in replacements)
Trying to introduce Linux into Windows isn't one of these things. Doing a UI refresh is fine but trying to make Windows UI conform to spatial computing isn't going to help it or the ecosystem in the long term.
If you look at their app building documentation, it's extremely disconcerting. This much compatibility overhead isn't helping the ecosystem grow.
Linux compatibility has become more relevant than POSIX, and the easiest way to achieve it is just to bundle it for the ride.
In Microsoft's case, they want to cater to the market that buys Apple devices, to actually develop GNU/Linux software and couldn't care less about Apple's ecosystem, aren't happy with it, and don't bother to support Linux OEMs.
It seems to be working.
z/OS has only gained support for running Linux binaries quite recently, in z/OS 2.4 (released September 2019), which supports running z/Linux Docker containers (zCX). Prior to that, z/OS had no built-in support for running Linux binaries in any form. Microsoft released WSL1 in August 2016. So z/OS got this feature 3 years after Windows did.
You might be thinking of z/VM or PR/SM, both of which support running z/Linux virtual machines (but neither of which is z/OS); or of z/OS Unix System Services, which offers some degree of source compatibility with Linux (through its implementation of the UNIX 95 standard), but doesn't have any Linux binary compatibility.
Thanks for the correction.
IBM VM has supported Linux guests ever since Linux was first ported to IBM mainframes, circa 1999-2000. Indeed, it is quite likely the initial port was done using VM.
IBM offered two versions of AIX on mainframes, AIX/370 in 1998 and AIX/ESA in 1991. However, how much code did these have in common with AIX on RS/6000? In the later case, very little – AIX/ESA is actually a port of the Mach kernel based OSF/1 to IBM mainframes, with little or no code shared with RS/6000 AIX (which contemporary AIX descends from). It actually had more in common with Digital/Compaq/HP's discontinued Tru64 UNIX (which is another OSF/1 derivative) than with AIX on RT-PC / POWER. I get the impression that AIX/370 had little or no code in common with RS/6000 AIX either – it was developed by Locus Computer Corporation – but I don't know enough about it to be sure about that. Neither AIX/370 or AIX/ESA ever saw any great adoption – both were discontinued in the 1990s, they were replaced by MVS OpenEdition (later OS/390 OpenEdition, and now z/OS Unix System Services) and also later on also by Linux.
Typo: 1989 not 1998
You have cause and effect the wrong way there: Windows 10 is in limbo precisely because MS have acknowledged that massive new OS rewrites every few years isn't cost effective. Not because Microsoft can't work out how to ship a new OS. There was a press release about how Windows would adopt a different release cycle around the launch time of Win 10.
> I don't understand why Apple and Microsoft feel stuck to one OS.
I don't understand why you think Apple or Microsoft fragmenting their install base would be a good thing for business.
Writing an OS is a fiddly task to say the least. It's one thing to be motivated to create an OS regardless of language (such as this), vs let's create one to showcase a language. It's harder to recruit people for the latter frankly, and having written OS and kernel code, it's fiddly work that more people talk about then actually enjoy doing it over the long haul.
Also in defense of Redox, I think it has far different goals, rather than getting something up and running with interactivity quickly. SkiftOS is much more "toy"/fun hacking vibe.
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.
Sure, people avoid some parts of C++, however there is a reason why they use C++.
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.
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
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.
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.
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...
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.)