|
You missed the boat and went off on a strawman fallacy based on a fundamental misunderstanding: Microsoft OS code and libraries, are implemented not just in C/C++/some asm but are also implemented in CLR languages. All that legacy crap in a variety of languages is a huge attack surface. Demanding pointing to closed source proof is an impossible, specious fools' errand. Have you ever done any Windows NT kernel driver development? Compared to OS X (xnu) kexts or Linux, it's a disaster. XNU and Linux extensions are also not that great because it follows the same, flawed insecure methodology of allowing kernel extensions to modify the kernel, which OpenBSD wisely eliminated. The other strawman you raise, trying put the wrong words in my mouth, rewriting a massive legacy codebase does not throw everything away. The lessons learned are the most important. Instead, OS and app virtualization can be used to run prior OS/apps while new apps can run in a new environment, sharing a filesystem as needed. That doesn't start over "from scratch, with inexperienced people", which is your incorrect presumption because that would be foolish. Otherwise, the Microsoft ecosystem will continue to accrue technical debt and job security which can never be paid off, because it's stuck in 1993. The kernel should be the kernel.. a tiny, mostly immutable thing which does just enough to provide process/thread isolation, IPC and such. Even better is capabilities-granted privilege requests to perform unsafe operations, so that drivers are demoted to least-privilege processes. QNX and MINIX loosely follow this, and it's a far more secure and robust benefits of reasonable microkernel architecture approaches. |
I have done NT drivers and linux kernel modules. I disagree with your statement. Can you be more specific?
I'm not saying there are no warts in NT, but your comment doesn't demonstrate any knowledge of where they are.