I think Windows also uses something similar to Linux memory overcommit (maybe call it "lazy page allocation"), but probably all the available virtual memory is backed by the page file, the OS has limit for the allocation size and all the edge cases are handled well under low memory conditions. For example, think about stack memory. Megabytes of stack space can be reserved for each thread, but since programs rarely use the whole stack, it's not rational to immediately allocate all the physical pages, it will waste a lot of memory (especially for multi-threaded programs). The stack grows on demand when the program hits a guard page.
In short, Windows partially does the same lazy thing but unlike Linux with its optimistic overcommit, it is stricter about commit/backing-budget reservation.
Yes, that was my point. But Windows might still allocate pages lazily (i.e. reserve them and actually allocate only when the program writes into them). The difference from Linux is that it will only reserve if the allocation has a reasonable size and the total committed allocation doesn't exceed certain safe limits / quotas, so it will be possible to safely swap on disk later under low memory conditions.
The reason you hear less about Window's OOM killer is simply because it works well.
The Linux Kernel OOM killer kills random things. Userspace OOM killers are meant to improve this, and they work well in a server situation when you already know in advance what is likely to go haywire and what is safe to kill. But they don't work well on desktop (some of them are improving but it doesn't seem to be a priority).
The Windows OOM killer by comparison usually kills something sensible (i.e. the program that is actually using all the memory), and asks the user for permission before killing it (when possible). You do see a lot of memes of situations where it fails.
Which, by default, is dumb for a presumably interactive system. Photoshop (or equiv) is going to be my "largest" process on a system. Because it's the one I'm interacting with.
You can always tell the system not to kill your Photoshop (or whatever else) by setting the OOM Score Adjust. This mechanism has existed for almost two decades and systemd has supported it for over a decade.
I think Windows doesn't do OOM kill, it just fails fast for unreasonably large memory allocations. If the allocation is succeeds, the committed virtual pages are backed up (or more precisely guaranteed to be backed up) by a page file.
damn, good observation, when my data analysis python script goes wrong and allocates 24 GB of RAM on a 32 GB computer, it crashes (gets killed) with "out of memory" error. I've never seen something else getting killed
In short, Windows partially does the same lazy thing but unlike Linux with its optimistic overcommit, it is stricter about commit/backing-budget reservation.