Not a kernel guy

Предыдущий пост про параметры функций вызвал на удивление много споров, так что я еще покручусь немного вокруг этой темы. Заранее прошу прощения у тех, кому эта тема оскомину набила. Итак, как следует проверять параметры функции? Вернее даже так, что нужно и, самое главное, что не нужно проверять?

(more…)

Оказалось, что это была ошибка в документации. Её поправили и посмотрите, что получилось.

(more…)

…это возможность распараллелить код инициализации подсистем по разным процессорам. Учитывая скорость распространения многоядерных процессоров это становиться актуальной задачей. Вынести большую часть кода из DllMain и конструкторов статических объектов не сложно. Достаточно оформить доступ ко всем подсистемам через singleton-подобный интерфейс, защищённый критической секцией. Сложнее – выстроить зависимости между подсистемами так, чтобы инициализация выполнялась как можно позже, когда все рабочие потоки созданы и готовы к работе.

Не менее важно и не перестараться с отложенной инициализацией. 30 секундное шуршание головками винчестера в ответ на безобидный щелчок мышью может вывести из себя даже спокойного пользователя. Или ещё хуже, удаленное приложение может оборвать соединение, так и не дождавшись ответа.

Функцию GetRawInputDeviceList можно смело приводить в качестве антипримера правильно спроектированного API. Эта функция используется для получения списка описателей устройств ввода (raw input devices). Ничего сложного. Прототип функции тоже выглядит довольно невинно – всего три параметра, и, как кажется по началу, назначение каждого довольно очевидно.

UINT GetRawInputDeviceList(
    __out_opt PRAWINPUTDEVICELIST pRawInputDeviceList,
    __inout PUINT puiNumDevices,
    __in UINT cbSize
    );

(more…)

Понимаешь, до сих пор мне никто не может внятно сказать, почему нельзя было 64х приложения пихать в новый ключ Регистра, вместо перенаправления 32х на новое “место жительства”. Будь ласка, если это твоя специализация, обоснуй!

Итак, почему же Wow64 использует перенаправление реестра и файловой системы вместо того, чтобы просто закрепить старые ключи реестра и “%windir%\system32” за 32-х разрядными приложениями и позволить 64-х битным приложениям определить новые ключи и использовать, скажем, “%windir%\system64” для 64-х битных системных библиотек? Это было бы довольно логично, особенно если учесть, что нечто подобное уже было проделано при переходе с Windows 3.x на Windows 95/NT.

(more…)

Я уже упоминал несколько раз, что 64-х разрядные версии Windows используют два раздельных представления реестра – одно для 32-х разрядных приложений, а другое для 64-х разрядных. Как-то, я даже писал о том, как это делается. Ключевых моментов там всего ничего:

1. Разделён не весь реестр, а лишь некоторые из ключей;
2. Физически 32-х разрядные ключи помещаются в ветки с именем «Wow6432Node»;
3. Приложения могут выбирать представление реестра с которым они хотят работать с помощью флагов KEY_WOW64_32KEY и KEY_WOW64_64KEY (см. Accessing an Alternate Registry View).

(more…)

Microsoft серьёзно подходит к безопасности корпоративной сети. Помимо всего прочего, для авторизации при удалённом доступе обязательно использование smart карты, простой пары имя-пароль недостаточно. Впрочем, я собираюсь рассказать не о стандартах безопасности, а о том, как я однажды заблокировал свою smart карту из-за особенностей реализации этих стандартов.

(more…)