Where should the OS's executable parser/loader be if not in the kernel? Are you proposing some sort of tiered bootstrapping scheme, where there's a baby loader

Where should the OS's executable parser/loader be if not in the kernel? Are you proposing some sort of tiered bootstrapping scheme, where there's a baby loader that's used at boot to load an executable containing the Real Executable Loader, and that lives in a long-running single process with root permissions responsible for loading any and every dll or exe file ever touched on the entire system? I assume you'd issue requests to it via RPC or something, and it'd need to run on multiple threads so that loading executables wouldn't bottleneck. To get back info on the .exe file like the name of the author, you'd probably need to fire off an async request to the Executable Loader Service to ask it to load foo.exe, then fire another request to ask it to RPC the author name back to you, then after all that copying and RPC has happened you gotta send another call back over to free the loaded executable handle. Oh and I guess the executable loader broker service also needs to verify that the process asking for an executable to be loaded has permissions to access the file, since the I/O is being done out of process now, can't forget that. And it needs to make sure that it doesn't let handles leak if the client process crashes in the middle of manipulating the .exe information, otherwise the executable loader broker service could run out of memory and take down the whole system. Seems good. Then you ask the broker to load this corrupt .exe file, and it crashes, and now your system (which hasn't bluescreened! hooray, we win!) can't run executables anymore. Under those circumstances, I would just take the OS down and generate a dump that someone can open up in a kernel debugger instead of letting it stumble along half-broken in a way that makes the problem hard to diagnose.