That's not true - DOS lacks multitasking but it absolutely has a concept of processes. They're called PSPs (program segment prefixes, a struct containing data about that process) and the OS has a range of syscalls to manage them. Any program can spawn a child program and wait for its completion.

The memory allocation syscalls track which program owns each dynamically allocated block of memory (the block has a header which points to the PSP), and frees the blocks allocated by a program when it exits. The filesystem syscalls deal with file handles opened by processes in just the same way.

The famous "terminate and stay resident" syscall causes a program to exit and return to its parent process while keeping its PSP and dynamically allocated memory blocks intact.

16 bit Windows introduced multitasking but reused DOS's PSP based process model and would allocate a PSP for each Windows task, switching the current DOS PSP when switching between Windows tasks.

Oh it did though, it is a very interesting OS. Much more interesting than it usually gets credit for.

It's a proper 32 bit OS with pre-emptive multitasking and demand paging that is enough of a chimera with DOS that it still supports DOS programs, 16 bit Windows apps, and even your old DOS drivers - side-by-side with all the new 32 bit stuff.

The "cloud native" (as the author refers to it) idea that app servers should be stateless is actually the new idea.

The industry eventually reached consensus on sticky sessions being a bad idea a lot of the time. That's why stateless app servers became the norm.

WSL9x uses the same Win9x memory protection APIs to set up the mappings for Linux processes, and the memory protection in this context is solid. The difference is simply that there is no need to subvert it for compatibility.

It's got lots of very thorough documentation and sample code to dig through

WSL9x takes quite a different approach. Windows boots first, but once Linux starts both kernels are running side-by-side in ring 0 with full privileges. They are supposed to cooperate, but if either crashes then both go down.

You don't need encryption, a global_id database column with a randomly generated ID will do.

It's a classic length prefix. Repository has 10 chars, Tree has 4.

Rust restricts the shape of program you are able to write so that it's possible to statically guarantee memory safety.

> Does it require annotations or can it validate any c code?

If you had clicked through you would see that it requires annotations.

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

Your code will look great in your synthetic benchmarks and then it will end up burning CPU for no good reason in the real world.

It’s a speed bump that makes you pause to think, and tells reviewers to look extra closely. It also gives you a clear boundary to reason about: it must be impossible for safe callers to trigger UB in your unsafe code.

The point is to escalate capability only when you need it, and you think carefully about it when you do. This prevents accidental mistakes having catastrophic outcomes everywhere else.