Meet Neptune OS, an attempt to give seL4 a Windows personality transplant A new project dubbed Neptune OS intends to put a Windows-NT-compatible personality on top of the seL4 microkernel. The project is still under development and doesn't actually run anything yet, but is nonetheless an intriguing prospect. The secure embedded L4 microkernel – seL4 to its friends – is the fruit of microkernel …
It's easier than it might first appear because of the NT architecture. It is working at the system call level rather than the API level. The API level is the one with tens of thousands of calls making a large surface to emulate. The system call layer is AFAIK publicly undocumented but is believed to be far simpler, more in line with the few hundred on other systems - the documented API is what is exposed by the subsystem and libraries on top of it. In a very real sense there is no such thing as a "native" Windows app since you are always on one subsystem or another, whether it be the 64, 32 or 16 bit Windows, DOS, WSL or Interix/POSIX or even the old OS/2 subsystem.
Emulate the syscall layer and the original subsystems can run on top of it. In principle this is no different to e.g. lxrun for running Linux apps on other Unices, although there is admittedly less in common between the two system making the translation layer a bit thicker.
Like the planet, it's very interesting.
But like the sea god, this project sounds like it's underwater from the start and it needs a lot of things to go right if it is to emerge from the deep.
It needs lots of time and lots of dedicated developers to make it happen and I don't see a clear use case that will offer either one unless this is a university backed compsci project (the article doesn't make it clear who the developers are or who their current backers are).
All this effort to emulate and simulate a bad programming interface. It baffles the mind. And everyone is bent on reinventing the wheel in doing so.
I dare say they'd have been better off trying to migrate a useful user space like Ubuntu 20.x to run on their micro kernel instead of a stock Linux kernel. That at least might get traction, if there were clear benefits to their kernel and its implementation in the real world.
"...lots of users have existing software for it?"
To spin that, do you mean lots of people who are trapped? I don't think this project is useless, but it's a hell of a lot less useful since this isn"t 2002 anymore.
While I can't say it's useless, but I'm not sure what I'd use this for. Most commercial software requires by license to run on the real target OS, not some mock version.
The reason that seL4 doesn't already have a working Unix/Posix-shaped microkernel arrangement (like minix or Geode or GNU) is that their security thinking, of restricted communicating processes, really doesn't like the "inherit all the state" forking model of Unix. The "create a new process that just does this thing, with access to only these things" is closer to the Windows process model.
It's also the model used by Fuchsia, apparently, so they could have just gone with that? Not that Fuchsia has much in the way of application ecosystem yet.
Of course Unix is growing capability mechanisms too (such as Capsicum from Cambridge University, now in FreeBSD, and CHERI now getting hardware support from Arm), but I suspect that it's a bit of an up-hill battle.
"a bad programming interface".
As this is the NT kernel itself, not the Windows user-space, I don’t think Linux supporters should be shouting too loudly about bad interfaces. (x86 and x64 syscall numbering...?)
Actually, even in user-space, my fairly long experience of Linux development would still advise a more conciliatory attitude: once you get away from the core APIs and tools that were shared with Unix, Linux APIs get very inconsistent, and you see the same concepts modelled in different ways in different libraries. Whatever its deficiencies, Windows (and MacOS) user-space libraries are designed to a “house style” and the concepts learned from using one library are helpful when learning others.
Nothing’s perfect, and that inconsistency is the downside of the Linux development model whose large number of semi-autonomous projects with the freedom to do what they want allows fast feature improvement and bugfixes.
I largely agree. Getting people unhooked off the application-side of a badly designed programming interface is the key to getting rid of the badly designed interfaces.
I have nothing against the seL4 kernel, the concepts there are absolutely sound, and in fact a unified API and UI over the top of an incrementally developed set of kernel ideas would be welcome (as opposed to the uber-fragmentation we see elsewhere).
I still hope for Haiku to get somewhere but progress has been so damned slow. Haiku/Chromebook would appear to be a sensible development route, if Google were willing to accelerate it.
Wedge computers (think Amiga 500) seem to be such an obvious target to me - out-do the consoles by providing a much-better-than-a-console console.
We really do need something that will let us run old Windows stuff without having to resort to actually using Windows. Wine has limitations and many, many, many bugs (some of them courtesy of Nvidia drivers, but that's a different story).
Also, M$ won't release any of the related legacy source code in the foreseeable future, since stuff that only runs on Windows is the sole thing that locks in a huge number of customers
The point of using seL4 instead of something heavier like Mach or Linux or the Windows NT kernel is for security - it is small enough it is provably correct. That's why Apple uses it for its Secure Element.
Once you layer on a ton of APIs that make it a full featured computer you lose most of that benefit. Sure, when someone exploits one of the thousands of holes in Windows or whatever you run on top of it they can't exploit seL4 itself, but they'll still be able to get "Administrator" which lets you do almost as much damage.
I don't know what they think they're buying with this marriage made in hell between a secure true microkernel OS and the giant turd of the Windows API that is in any way better than laying that giant turd on some other base.
"I don't know what they think..."
Weekend project? In my opinion, it'd be better time spent developing HURD which is for all intensive purposes the grand daddy of all things Mach.
If you rrrrrerreally need to run that Windows software... just bite the bullet and buy a damn Windows license.
Good to see.
Windows compatible operating systems solve the problem of 32bit windows going officially end of life in 2025. Windows 10 32bit is the last 32bit mainstream desktop Windows OS from Microsoft, which one could therefore say is the last official one.
With WINE, major inroads have been achieved with running Windows applications without Windows.
But what about drivers? That to me is where a full alternative to Windows OS (or, at least something like that) appeals, rather than just a compatibility layer. Unless that layer includes driver support.
That's why ReactOS appeals (and maybe Neptune?) But it is not there yet - from personal experience - I can't get it to install on real hardware (yet) - reference: https://jira.reactos.org/browse/CORE-18045 . Maybe it works for hardware other than mine (I hope so). And I'm optimistic. I will cheer ReactOS on.
Good on "The register" for giving ReactOS coverage, too, that can add fuel to the cause.
Related: FreeDOS article and my post: https://forums.theregister.com/forum/all/2022/02/23/freedos_13/#c_4418876
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
