Windows NT kernel developer explains reasons for poor OS performance

    One of Microsoft's programmers anonymously spoke at the Hacker News forum and provided interesting details about the NT kernel development process. With his message, he wanted to confirm the thesis that the kernel is inefficient and in many respects inferior in performance to other OSs: see the original message (the author deleted it, frightened by harsh language) and a copy .

    The cause of the problems, according to a Microsoft employee, is social. The fact is that developers do not introduce into the kernel such optimizations that we see in the Linux world. At Microsoft, no one will praise a programmer if he optimized some process by 5%, if this is not within the scope of his main responsibilities. Such optimization is of no interest to anyone. Only in the case of some very significant progress can a programmer's work be noticed in neighboring development teams, which will positively affect his career. But this is more an exception than a rule. There is no incentive to accept change from outside your development team.

    Microsoft does not have a program to systematically improve Windows performance. In the days of Windows XP, the company began to pay great attention to security, because serious problems were discovered with this. However, no one paid attention to performance and did not pay much attention.

    Another problem is the deterioration of the OS performance situation - the leak of the most talented personnel. Google and other Silicon Valley companies are actively hunting for gifted programmers and do not hesitate to lure them from other companies. Due to staff turnover, new developers prefer to implement new functions instead of optimizing old ones. This is precisely the reason for the appearance of PowerShell: many wanted to improve cmd.exe, but did not have the opportunity.

    As specific examples, the developer calls the following:

    “We should not touch named pipes. Better add %INTERNAL_NOTIFICATION_SYSTEM%! And let it be incompatible with almost all other named NT primitives.

    We cannot show the %INTERNAL_NOTIFICATION_SYSTEM%rest of the world, because we do not want to do paperwork and lose sales, because only Win32 APIs of the 90s era are publicly available now.

    We cannot touch DCOM. So let's create another one %C#_REMOTING_FLAVOR_OF_THE_WEEK%!

    XNA What else can I say?

    Why would anyone need an archive format with support for files larger than 2 GB?

    Let's maintain symbolic links, but make sure no one can use them, so we won’t be accused of a security vulnerability. (Great! Now we look wise and responsible!)

    You can't touch Source Depot, so let's get the SDX (Secure Document Exchange) hacked together!

    You can’t touch SDX, so let's pretend for four releases that we are switching to TFS (Team Foundation Server) and we won’t change anything!

    God, NTFS code is a crimson horror novel written under opium in the Middle Ages that uses global recursive locks and controls the flow of a program using structured exception handling (SEH). Let's write ReFs instead. (And yes, let's start by copying the NTFS source code and removing half the functionality! Now we add checksums, because checksums are cool, and with checksums we are almost as cool as ZFS, right? And anyway, who needs quotas?)

    We are not able to implement support for C11 at all, and templates with a variable number of arguments are too complex to implement in a year. (But look, we turned "^" into a pointer-count operator! Oh, what is a reference loop?). "

    Also popular now: