Not a kernel guy

… in the Windows kernel team

Sunday, February 3, 2008

Кстати ещё одна причина, почему DllMain должна выполнять как можно меньше работы…

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

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

Posted at 4:40 pm •

Thursday, January 31, 2008

Возвращаясь к теме про фаззеры.

Вот код, которым я пользуюсь для написания стресс тестов и фаззеров в своих проектах. Класс EntropyGenerator – обертка вокруг генератора случайных чисел.

(more…)

Posted at 10:02 pm •

Wednesday, January 30, 2008

Пикник на обочине или не ходите, дети, в DllMain гулять, а то ноги оторвёт.

Точка входа в DLL, так же как и точка входа в программу, - это очень специальное место. Зона. В Зоне действуют свои правила касательно того, что можно делать, а что делать нельзя. В Зоне можно инициализировать локальные данные DLL, можно создавать критические секции. В Зоне нельзя динамически загружать другие Модули или создавать потоки. Любой Сталкер знает и следует правилам Зоны. Все остальные рано или поздно нарушают правила и расплачиваются за это.

(more…)

Posted at 9:01 pm •

Thursday, January 24, 2008

Хоть убейте меня – не понимаю!

… почему программисты, уже озаботившиеся ведением подробного журнала о том, что, где и когда случилось, никак не позаботились о том, чтобы фатальные ошибки находились сразу, простым текстовым поиском? Нет ну серьезно, уровни важности сообщений – есть. Вывод сообщения на каждый чих – есть. Ключевые слова (trace, info, warning & error) – есть! Но найти что именно сломалось в этом многомегабайтном монстре никак не получается. Сообщений об ошибках либо нет, либо их очень много и не по делу. Или еще хуже – финальное сообщение «Ой! Тут что-то поломалось!» есть, а чем оно вызвано – нет. Или есть, но пару десятков тысяч строк текста тому назад…

P.S. Agrhh!

Upd: Нашел что падало. Банальный Access Violation. В логах - ничего. От отладчика его тоже спрятали. Ууу! Сатрапы!

Posted at 10:28 am •

Sunday, January 20, 2008

Ведение дополнительных веток проекта отнюдь не бесплатно.

Структура репозитория исходников типичного проекта обычно представляет собой дерево:

Основная ветка, от которой отходят ветки подразделений, команд и отдельных подпроектов. Новый код или исправления старого производятся в самых нижних ветках. Затем накопленные изменения перебрасываются в ветку, находящуюся выше по иерархии. При этом код проходит различные проверки, начиная от банальной «проверки временем», до прогона через формальный набор тестов различной сложности. Сложность и скрупулёзность проверок, как правило, растет при приближении к основной ветке. По мере надобности, от основной ветки отпочковываются ветки выпускаемых версий. Именно в них вносятся последние исправления и собирается финальная сборка продукта.

(more…)

Posted at 5:30 pm •

Tuesday, January 15, 2008

Программирование для чайников.

А не подскажет ли кто хорошего курса уроков/лекций по Java или C#, подходящий для человека, далёкого от программирования? Рассказывающий об основах, безо всяких, лишних поначалу, подробностей и деталей. Можно по-русски, можно по-английски. Нам без разницы.

Posted at 10:29 pm •

Tuesday, December 25, 2007

И кнопочку «Повтор» не забудьте!

Юнит тесты, в отличие от многих других видов тестирования, обладают одной замечательной особенностью. Они обеспечивают практически 100% (a в теории - так точно 100%) повторяемость результатов. Грубо говоря, после успешного прогона тестов можно с уверенностью говорить, что покрываемые тестами сценарии работают. Гарантированная повторяемость важна для обнаружения быстрого регрессий, рефакторинга кода и множества других вещей. Как обычно, окунание в реальность сильно портит эту радужную картину.

(more…)

Posted at 3:03 pm •
« Previous PageNext Page »

Powered by WordPress