Microsoft готова передать ФСБ шифровальный алгоритм Skype

Упс. Первый абзац не дописал. Должно быть так:

То есть, вы не считаете, что вызов функций 'в столбик', абзацы кода очень часто длиной всего в 3-4 строки, и прочее, в том числе и бессмысленные комментарии — это не метод увеличения количества строк?.. И там такое есть, постоянно. Вот просто первый попавшийся файл открыл в ntos/io

То есть, вы не считаете, что вызов функций 'в столбик', абзацы кода очень часто длиной всего в 3-4 строки, и прочее, в том числе и комментарии…

Не совсем понял, что такое «вызов функций 'в столбик'», но короткие абзацы и тщательное комментирование — это только плюс. В WRK этого комментария нет, но я тем не менее соглашусь, что бессмысленные комментарии вполне могут быть — просто их количество исчезающе мало.

Во-первых, известно, что для таймеров можно добиться сложности O(1) в худшем случае на всех операциях, кроме его создания.

Ну так здесь оно и есть. Не совсем понятно, что Вы имеете в виду под «созданием» — если просто выделение памяти то оно тоже может иметь (амортизированную) константную сложность. Если же вставку, то все зависит от ворклоада. В данном случае сложность зависит как от количества уже присутствующих таймеров, так и от того, сколько осталось времени до срабатывания, что на большинстве реальных ворклоадов даст сложность, близкую к константной для большинства таймеров (реальное распределение дать не могу)

Во-вторых, про таймеры, особенно KiInsertTimerTable… Не нашёл никаких упоминаний о указанных Вами таблицах.

Это из WRK (Server 2k3) — задолго не только до упомянутой Вами семерки, но и задолго до висты.

Но это список, и о каком логарифме идёт речь — не понятно. А для таймеров, вообще-то, стандартный примитив — это куча, а не списки или хэш-таблицы.

Для кучи опять таки имеем гарантированный логарифм на вставку (и, что еще хуже, на ИЗВЛЕЧЕНИЕ минимального элемента) при любом ворклоаде вместо гарантированной константы на извлечение и константы на вставку при реалистичном ворклоаде (и линейной сложности для худшего случая). Подобные компромиссы делаются кругом — вспомнить хотя бы очень популярный quick sort.

NTSTATUS'ы — это, насколько я понял, вообще никакие не цепочки…

Имелось в виду

if (!NT_SUCCESS(status)) {
	// cleanup
	return status;
}

И так во всех функциях по цепочке — полностью ручной менеджмент ресурсов — никаких исключений, только возврат/проверка статусов. Причина проста: обработка исключения — значительно более дорогая операция, чем возврат значения из функции.

Я действительно не понимаю, где происходит освобождение захватов в таких случаях (я так честно и написал — не понимаю, и это меня напрягает).

Блок finally гарантированно выполняется — хоть при исключении, хоть при обычном выходе из try блока. Все финализаторы (в том числе и освобождение блокировок) находятся там. Но, повторюсь, это крайне редкая штука (в Вашем же примере весь Ke модуль не содержит ни одного finally блока).

о что try-except редко или часто используются — это не важно (но вообще, 335 точек try-except — это солидно на 150 тысяч строк MS-кода. Во всём Half-Life 2 и то меньше.

А насколько часто «всему Half-Life 2» приходится проверять доступность блока памяти, переданной из untrusted источника? Основное применение, как я уже написал, это try {ProbeForRead/ProbeForWrite} except {return STATUS_ACCESS_VIOLATION;}
Более того, данная конструкция чаще всего завернута в if (PreviousMode != KernelMode) {} и лишняя работа не выполняется, если источник данных доверенный (ядро).

Важно то, как они используются… И я, сколько не копался, так и не нашёл мест освобождения захватов после исключений.

Можно хотя бы один пример? Я не смог найти примеров выбрасывания исключений с захваченными блокировками. Не потому, что такую ситуацию трудно обработать, а потому, что бросок/обработка исключения — относительно дорогая операция и совершенно необязательно удерживать блокировку в течение всего времени обработки. Аргументы чаще всего валидируются до того, как делается любая другая работа.

Вот пример освобождения ресурсов при броске исключения:

#if defined(_WIN64)
        if (requestorMode != KernelMode) {
            try {
            
                //
                // If this is a 32-bit asynchronous IO, then mark the Iosb being sent as so.
                // Note: IopMarkApcRoutineIfAsyncronousIo32 must be called after probing
                //       the IoStatusBlock structure for write.
                //

                IopMarkApcRoutineIfAsyncronousIo32(IoStatusBlock,ApcRoutine,FALSE);

            } except (EXCEPTION_EXECUTE_HANDLER) {
                
                //
                // An IRP could not be allocated.  Cleanup and return an appropriate
                // error status code.
                //

                IopAllocateIrpCleanup( fileObject, eventObject );                
                if (auxiliaryBuffer) {
                    ExFreePool( auxiliaryBuffer );
                }

                return GetExceptionCode ();
            }
        }
#endif

Если этот пример недостаточно показателен — дайте пример кода, в котором Вам непонятно где происходит освобождение ресурсов (в том числе захваченных блокировок, как одной из разновидностей ресурсов).

Ну, людей вообще-то на любую работу отбирают…

Но везде критерии отбора разные.

А вот Ваша уверенность в том, что Катлер — гений, интересна. Почему Вы так думаете?

По тому, насколько мало подвержен его дизайн гниению (design rot). На конец 80-х имеем: поддержку юникода в ядре, полностью асинхронный ввод/вывод, ACL-ы, поддерку SMP (полностью реентрабельное ядро с кучей воркеров), файловую систему с минимальным количеством различных сущностей и потрясающей расширяемостью (вот по качеству дизайна с этой ФС 20-летней давности могут соперничать разве что современный BTRFS/ZFS, а HFS+ и ext4 даже рядом не валялись).
Не говоря уже об очень изящном меморе менеджменте, отсутствии привязки к POSIX, даже при том, что POSIX-совместимость была в изначальных требованиях (забавно, что как раз Windows-совместимости в этих требованиях не было), отличной модульности (нет, речь не о загружаемых модулях) и куче прочих ништяков