haileys

No, you can just rent a VPS with local NVMe storage if even renting bare metal is too much.

The hardware was virtualized, it's even in the name for drivers on Win9x: Virtual Device Driver

An O(n^2) parser is not fine for the mere reason that I don't know how one would make such a mess of the job in the first place.

A simple recursive-descent parser is easy to write by hand and runs in linear time.

I thought it was funny that the author used a variety of OCR tools with mixed success before spending a lot of time manually fixing up the output from the best one, rather than just typing it in

> DOS barely has any concept of processes

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.

Yes it's a riff on WSL. It wouldn't make sense to flip the naming around - people would then just be confused about the naming in the other direction.

> I'm not saying Windows 9x in particular had anything super interesting going on.

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 premise is incorrect and ignorant of the history - this is sticky sessions and the idea has been around longer than 20 years.

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.

This is correct. Win9x did have memory protection, it just made an intentional choice to set up wide open mappings for compatibility reasons.

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.

doslinux is some tricky sleight of hand where it looks like Linux is running inside DOS, but it's actually the other way around (even though DOS boots first).

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.

Well it did take me 6 years to follow that up!

I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.

Encoding a type name into an ID is never really something I've viewed as being about performance. Think of it more like an area code, it's an essential part of the identifier that tells you how to interpret the rest of it.

This is well understood - Hyrum's law.

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