ExectOS – brand new operating system which derives from NT architecture

Saw this on their page:

"Unlike the NT™, system does not feature a separate Hardware Abstraction Layer (HAL) between the physical hardware and the rest of the OS. Instead, XT architecture integrates a hardware specific code with the kernel. The user mode is made up of subsystems and it has been designed to run applications written for many different types of operating systems. This allows us to implement any environment subsystem to support applications that are strictly written to the corresponding standard (eg. DOS, or POSIX)."

Please tell me you're working on this.

GitHub.com/cl91/NeptuneOS

Source: I wrote this.

By "modern OSes" here, are we talking GNU/Linux, which is older than NT and modeled after a system designed in the 60s? Or maybe macOS os iOS, whose foundations are found in FreeBSD, released in the same year as NT and with a direct lineage to that system from the 60s, plus a kernel from 1985? Using the word "modern" to describe Linux and the BSDs but not Windows NT strikes me as odd...

Now I use and like Linux and macOS and iOS, and I strongly dislike Windows. But I don't think I would find it difficult to find advantages to NT's approaches to certain problems over the UNIX-style approach to the same problems. For example, the idea that pipes send structured objects rather than text is interesting and has definitive advantages (and disadvantages) compared to UNIX's text-based pipe model. Its filesystem permissions layer is also way more flexible than UNIX's, with hooks for arbitrary programs to inspect file accesses, which has advantages (and disadvantages). And its GUI-first approach to everything, where everything is primarily configured through some GUI rather than a command line or text file, has obvious advantages (and disadvantages). And although I don't understand it very well (again, not a Windows user), what I hear from HyperV is pretty cool.

NT is super interesting as the only serious alternative to UNIX-style systems. There is value in studying it, even if I find the overall experience provided by Windows to be much, much worse than my Fedora desktop or my macOS laptop.

NT/VMS offers no immediately quantifiable advantage, but rather a different philosophy than Unix where everything-is-a-file-even-when-it-isnt-really. It's more of a batteries included system where the high-level and low-level parts combine to form a coherent whole. The HAL, dynamically loadable drivers, the registry, services, API personalities. It's a shame that all the good stuff about the design of NT takes a backseat to the modern Microsoft shenanigans.

NT kernel is IMO pretty good. Here’s a few points.

ABI for device drivers allows to add support for new hardware without recompiling the kernel.

First-class support for multithreading, Vista even added thread pool to the userland API.

Efficient asynchronous APIs for IO including files, pipes, and everything else. Linux only got this recently with io_uring, NT implemented IOCP decades go in version 3.5.

NT security descriptors with these access control lists and nested security groups are better than just 3 roles user/group/root in Linux. This makes launching new processes and opening files more expensive due to the overhead of access checks, but with good multithreading support it’s IMO a reasonable tradeoff.

Related to the above, CreateRestrictedToken kernel call for implementing strong sandboxes.

Good GPU support, Direct3D being a part of the kernel in dxgkrnl.sys. This enables good multimedia support in MediaFoundation framework because it allows applications to easily manipulate textures in VRAM without the complications of dma-buf in Linux.

Related to the above, GPU-centric 2D graphics (Direct2D) and text rendering (DirectWrite) in the userland API.

> modern OSes

Like NT? It is in fact the UNIX-likes that are compelled into a fairly ancient stream-of-bytes model; NT (and Windows atop it) understands that data needs to have structure, and imposes structure on that data at an OS level; everything is a manipulable handle, rather than an opaque block of memory to be written to/read from, arbitrarily.

I should probably do an updated talk/article/deck on io_uring.

I really do like NT internals though.

Interestingly io_uring was added to NT.

https://windows-internals.com/i-o-rings-when-one-i-o-operati...

The worst part about now in hindsight is how they probably could've moved to a work-list system like Vulkan or io_uring and kept it all in separate processes to retain that stability.

Yes, memory wasn't as plentiful back then and with single-core machines there still would've been more unavoidable context switches but with queues the context switches could've still been reduced in total as opposed to crossing the kernel boundary at all.

Graphics driver crashes don't result in BSODs anymore. Microsoft fixed that in... Windows 7? Vista? They just trigger a black flash of the screen for a few seconds and then everything is back up as it was - including active GPU contexts. You can have the driver crash & recover in the middle of playing a game and barely even notice, it's incredibly impressive tech.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

No, NT was a re-engineering of the kernel, mostly with Mach-microkernel influence, but also with input from VMS.

I think the point is that people who whinge (like here) about Unix are actually complaining about Unix filesystems and user-space. I'm not so sure they care about how exactly privileged execution is partitioned (or not).

It’s fun to implement if you haven’t. I read and implemented one from this book:

https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures...

What a strange comment. Ever seen the Open data portal at https://data.europa.eu/? And that’s really just one singular example.

To add to your point, Microsoft had originally envisioned that vendors would write their own HAL.DLL’s to make Windows compatible with their hardware, but it turned out nobody really had the expertise needed to do that, and Windows started to depend more and more on implementation details of the most common one, and at this point the idea is dead. Hardware vendors target one single windows HAL for x86_64, and porting windows to another platform requires rewriting/rebuilding all sorts of stuff, not just the HAL. It was a cool idea at the time that didn’t really pan out.

The 'e' in 'Apple IIe' stood for Enhanced. Then they came out with the 'Apple IIe Enhanced'.

for most people, the browser is the platform. for a somewhat different "most", the phone is the platform.

none of those people care whether it's apache or nginx or something else handling the socket, or what kind of socket it is, or how app routing works, or how that app accesses storage, allocates RAM, etc.

i want an operating system fine tuned for performance from the ground up, needs to be atleast 10x faster than all the current operating systems. its kernel needs to be written from scratch keeping only modern hardware post 2015 in mind. It should have minimal bloat and absolutely spectacular benchmarks compared to the rest of all of them

If we follow your reasoning, then why have different programming languages? Why are people still spending time making new programming languages? We already have C. It built UNIX, databases, games.

Nobody cares what something is coded in.

Why do we have more than one database? In fact just storing data in the file system was more than sufficient Nobody cares how data is stored.

The answer is that they are all crucially important and we still have engineers and creators who want to innovate and push the borders of what is possible. invent new and improved ways to accomplish what we are doing and extend what we will be able to do.

*EdgyOS

Add to that the very next FAQ entry after that:

> Do you have any kind of tests to check if the code is working as expected?

> We don’t need tests. If it compiles, it is good enough; if it boots up, then it is perfect.

https://harmful.cat-v.org/software/GCC classic

Clang isn't better. It just has a more permissive license so it's what Apple uses.

Wow, A++ job on having white text on a white background for their gitea instance. I was curious if it was just some Firefox specific quirk or something but it seems the .css file is 404 (named "theme-arc-green", so maybe it's best it is 404)

Git history shows 2 years of development.

Can you share a bit more about the inappropriate and dirty reverse-engineering by ReactOS and what the deal with TinyKrnl is?

This response really only answers the question for a select few people familiar with the windows reverse engineering community drama.

You successfully answered why you would make a project that you haven't made, but that doesn't really answer the question, and the author already answered in the same subthread 30 minutes before your post.

To not get cease & desist'd to hell, great effort is spent to make sure every bit of code introduced to ReactOS has been properly clean-room engineered. The Windows source code leaks specifically have made a great job to stall ReactOS development. Also the potential legal issues and making an enemy of MS makes it hard to get sponsors. Hence project is entirely developed by unpaid volunteers.

It’s because all of the early React developers now have incredibly successful careers and don’t really have time to support it

> ReactOS must take the record for software with the longest gestation in history.

May I introduce you to GNU Hurd? First release happened 34 years ago.

https://www.gnu.org/software/hurd/

> Perhaps there's something about how the ReactOS project is run that I'm unaware of that puts people off.

My guess is that the intersection of people who don't need need bug for bug windows compat (so aren't are stuck on real Windows) and those who really care about the NT compatibility at the kernel level is about zero.

> having no alternative O/S to Windows is a real pain.

That really depends on what you count as an alternative, doesn't it? As far as regular applications are concerned Linux + Wine is a pretty good alternative.

I'm pretty confident is that a core problem is that people who develop OS's realize that linux or unix-like systems are plain superior, and end up just building on that, being well versed in their structure and syntax.

This is great and all, except that the linux experience is about a 3/10 for people who are trying to leave windows. Especially when the core of using linux is still so incredibly CLI heavy.

It's kinda like having professional race car drivers build cars. They end up being fast, efficient, nimble, and easy to repair. But driving them is difficult as hell, the drivers seat looks like an apache helicopter cockpit and the clutch is so stiff and throttle so sensitive that you almost always stall or lunge. But it does have an automatic "beginner" mode, never leaves first gear and the throttle becomes slush, but it will get you from A to B around town, mostly. Great for grandma.

> I've never figured out why the inordinate delay given that millions are unhappy with Windows and Microsoft generally. You'd reckon open source developers would be falling over themselves to join such a project but it seems not.

I think there is a strong misconception that there is this massive pool of open-source devs twiddling there thumbs just itching to jump in on some project were they can pour time and effort for nothing more than the "good of the community". I don't have any sources for this, but it my strong suspicion that the vast majority of "open source" contributions are actually done by contributors that are compensated either by a company that doesn't mind paying their employees to work on open source projects, or by a foundation behind the open source project. Take Go-lang for example, originally created by Google, then opened up. I am sure there are Google employees that still contribute (on Googles dime) to the project. Why would Google do this? Why not keep the Go just for themselves? Simple, if they open it up and can get other people/companies to use it, then they can make future hires where they don't have to train everyone on a proprietary language.

ReactOS doesn't have a large foundation behind it, and it doesn't make sense for companies to allow their employees to develop and contribute to it on their dime.

Development is skilled labor, especially for an OS. Dev's need to eat, need a home, etc. I don't know a single dev that is itching to give away their skills for 0 compensation. The only time devs really do that is when it is a personal passion project.

> ReactOS must take the record for software with the longest gestation in history

I think that would be Project Xanadu, started in (depending upon what you consider as "starting") in 1961 or 1965.

I think the main issue is that there's just not much money in it.

Let me explain. I don't have hard numbers on this, but I'd venture to guess that a vast, vast majority of funding/code-time-donations towards Linux is specifically for making server infrastructure more stable. Fortunately for the community, these changes get pushed upstream and also fortunately a lot of them end up also benefiting the desktop environment as well.

Windows does have a server presence obviously, but I think if you're using a Windows server, you're not going to drop it and replace it with ReactOS (even if it were less unstable); you'd probably move to Linux with .NET Core. I don't think any company is going to fund the development of ReactOS on server, or as any key part of infrastructure, and so the only thing that React has is consumer desktops.

I don't think there's a lot of funding going towards consumer products; I'm not saying it's zero, but even for Ubuntu and Canonical or Fedora and Redhad, I always kind of figured that the desktop OS's were effectively loss-leaders for commercial clients. I think the final nail on the coffin is Valve and Proton; for awhile Microsoft still basically had a monopoly on games, regular Wine was hit or miss, but Proton keeps getting better and better, to a point where I almost never have to worry about a game not working on my Steam box. Valve can continue to work on SteamOS specifically because they have funding in the form of people using their platform to buy games.

I was rooting for ReactOS for quite awhile, but nowadays I'm not really seeing the point of it. Linux driver support is actually pretty decent nowadays (particularly with AMD GPUs), it runs reasonably fast, and most applications have moved to web-based stuff anyway.

Oh my, so many better options. D, Zig, Nim, to name a few. Even C++, for all its faults, would be a better choice than C!

> But surely those assumptions cease to hold if you're the one defining the memory model, and most of your code involves shuffling memory around inside of `unsafe` blocks.

True! But I think your characterization here of an OS kernel is incorrect. Certainly there will be more unsafe in an OS kernel than in your average user space application, but it should still be the minority of code. One thing that Rust documentation/tutorials frequently ram into your head in the chapters about unsafe is that you should be using unsafe only sparingly, to build small, auditable, hopefully-safe abstractions that the rest of your code -- safe code -- can use to get its work done.

That's just as true in a kernel context (and perhaps even more critical to understand and internalize there) as in user space.

> if those guarantees break, Rust will panic and crash, which - in a kernel - would mean bringing down the entire system [...] Linus Torvalds has noted some of his issues with Rust in kernel dev, and he's in a pretty good place to render his opinion.

And this is why the team working on The Rust-in-Linux project have been working with the Rust maintainers to provide alternate APIs that don't panic, and instead return errors, in these situations. Torvalds' feedback has been instrumental in driving these changes. The fact that Rust is in the kernel now is a testament to the fact that this feedback has been taken to heart, and Rust has seen improvements because of it.

> In a kernel context, even things like 'let' might fail

No, that's absolutely false, and breathless statements like these feel a bit disingenuous. Even `let s = String::new()` cannot fail, as all it does is move a stack pointer. I think perhaps you intend to mean that the expression on the rhs of a let statement can sometimes fail? Sure, and that's just like any other statement or expression. But, again, this is why we now have a bunch of "try_"-prefixed variants of common memory-allocating things that return an error instead of panicking.

> ... or you check for and try to catch these errors, which - well - is no different from C at that point

That's not even a little bit true. C has no built-in error checking mechanisms, or even a way to build safe, ergonomic error checking. If I call kmalloc() from C, I have to explicitly check for NULL. I can very easily forget to do so, and the compiler won't help me. If I call a similar "try_alloc()"-style function from Rust, it will return a Result, and the compiler will not let me do something with that allocated memory without explicitly handling a possible error.

> a better choice for a modern greenfield kernel would be one of the strictly functional languages: Haskell, OCaml, etc.

I suppose it depends on what your goals are. If you want to build the next Linux (or something more modest, but still quite popular), then probably not; you're not going to find enough people who are competent in or even interested in languages Haskell or OCaml to build a strong contributor base.

If you're instead doing research or are building something for niche use cases, then sure, that could work.

>>> keep accumulating cruft

Evidence?