Excellent project name :)

https://en.wikipedia.org/wiki/Windows_Neptune

https://betawiki.net/wiki/Windows_Neptune_build_5111.1

I had copy of NeptuneOS from a questionable download source. I installed it on my barebone pc. To my excuse, young me was desperate to have something else then Windows ME. It was quite usable.

Yeah I named the project after the codename for Windows 2000, arguably the best OS that Microsoft has ever created :)

What? I can't find any codenames for 2000. All I can find is:

> Windows 2000 didn't have a codename "because Jim Allchin didn't like codenames," Thompson says.

https://web.archive.org/web/20170801163850/http://winsupersi...

Ok I misremembered. It was actually a pre-release of what would become Windows XP.

"The status of the project right now is that we have implemented enough NT primitives to load a basic keyboard driver stack, which includes the keyboard class driver kbdclass.sys and the PS/2 port driver i8042prt.sys, as well as a basic command prompt ntcmd.exe, taken from the ReactOS project."

Probably posted because 0.1.0001 was just [0] released 9 hours ago:

> Basic keyboard stack and a command line shell. All drivers run in the user space. Pretty much none of the commands actually work because we haven't implemented many things, but the keyboard stack works reasonably well. We also included a beep driver to make an annoying sound on the PC speaker.

[0]: https://github.com/cl91/NeptuneOS/releases/tag/v0.1.0001

> The main obstacle of achieving binary compatibility of kernel drivers is that many Windows kernel drivers do not follow the standard Windows driver communication protocol (ie. passing IRPs when you need to call another driver) and instead just pass pointers around and call into other drivers directly.

Does this mean drivers that are part of Windows itself or third party hardware manufacturers?

Because if it's the first one that seems shocking and like it was a shortcut that could end up becoming very difficult to maintain for the Windows team...

Microkernels definitely have the advantage of forcing communication via correct channels and processes.

Based on the code from ReactOS[1][2].

[1] https://reactos.org/

[2] https://github.com/reactos/reactos

Now that's impressive. All that reverse engineering.

How much isolation is there? Is each Win32 process an L4 process?

There is no reverse engineering because how Windows implements things internally is totally irrelevant. We only implement the public interfaces exposed by the NT Executive. The device drivers and user applications are all taken from ReactOS source code.

I don't think they've gotten to the point of NT processes. Looks like the currently load a couple simple NT drivers in sel4's user space.

Hi, I'm the author of this project (I didn't post this on HN someone else did). We have implemented NT processes. All device drivers and user executable are NT processes (created by NtCreateProcess or RtlCreateUserProcess). What we don't have is Win32 process, because there is no Win32 subsystem yet.

Ah, gotcha, I missed that. Thanks for the correction.

They can start an Native process (ntcmd.exe) but that's about it, as the commands available don't run due to missing bits.

The keyboard driver stack is working (we also have a PC speaker driver that makes an annoying beep). It's actually not as trivial as it seems, because passing IRPs across process boundary while maintaining the consistency of states is not that easy to get right, among other things. The goal of the very first release is to demonstrate that one can run Windows kernel drivers in seL4 user space and have a Windows (native NT, not Win32) application communicate with said Windows drivers via standard NT primitives (NtOpenFile and whatnot).

I have to ask: how did jinja2 become a dependency for an operating system?

It's a dependency for the build process.

Seems to be entirely different than

https://neptuneos.com/en/start-page.html

with the exact same name.

There was also osfree for os2