Алексей Пахунов

За последнее время мне пришлось побеседовать со многими соискателями на место разработчика в нашей команде. Нужно сказать, это было очень познавательно. Иногда – даже слишком.

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

Read more…

Интервью, Программирование, Работа

Маленькое открытие. После RESET# x86 процессоры начинают выполнение команд в реальном режиме (AKA real mode). CS и IP при этом устанавливаются в 0xf000 и 0xfff0 соответственно. Значит первая инструкция должна находится в пределах первого мегабайта, по адресу 0×000ffff0. Правильно? Не правильно. На самом деле, первая инструкция живет по адресу 0xfffffff0, так как база селектора CS после сброса устанавливается в 0xffff0000.

Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3A: System Programming Guide, Part 1
8.1.4 First Instruction Executed:

The first instruction that is fetched and executed following a hardware reset is located at physical address FFFFFFF0H. This address is 16 bytes below the processor’s uppermost physical address. The EPROM containing the software-initialization code must be located at this address.

The address FFFFFFF0H is beyond the 1-MByte addressable range of the processor while in real-address mode. The processor is initialized to this starting address as follows. The CS register has two parts: the visible segment selector part and the hidden base address part. In real-address mode, the base address is normally formed by shifting the 16-bit segment selector value 4 bits to the left to produce a 20-bit base address. However, during a hardware reset, the segment selector in the CS register is loaded with F000H and the base address is loaded with FFFF0000H. The starting address is thus formed by adding the base address to the value in the EIP register (that is, FFFF0000 + FFF0H = FFFFFFF0H).

Ассемблер, Программирование, x86

В x64 сегментная адресация работает совсем не так, как в привычном x86. Прикладные программисты, живущие в плоском мире, могли бы этого не заметить, но, к счастью или несчастью, «уши» этих отличий торчат и в user mode.

Read more…

amd64, Программирование, Wow64

Не так давно попалась в руки одна ошибка. Проявлялась она в том, что некое приложение, общающееся с коллегой через TCP/IP соединение, жаловалось на то, что пересылка пакетов по сети занимает около получаса, и что, вообще, заставлять девушку ждать более 300 миллисекунд – неприлично. Впрочем, судя по тому, что приложение работало как ни в чем не бывало, – замечание про полчаса ожидания было легким преувеличением. Для полноты картины добавлю, что то приложение было в процессе переноса на другую платформу с целью «чиста позапускать» (и посмотреть, как оно там работает).

Read more…

Ошибки, Программирование

В очередной раз столкнулся с мифом, что, мол, release сборку невозможно отлаживать, так как символов нет. Значит так! Американцы на Луне были! Тьфу ты. В смысле, символы в release сборке включать: а) можно, б) нужно и в) полезно. Генерация отладочной информации не влияет на оптимизацию кода. Хотите, проверьте сами – сравните ассемблерные листинги с генерацией символов и без. Более того, случаи, когда это не так, однозначно трактуются как ошибки, которые можно смело отправлять в Microsoft. Мне, кстати, и самому было бы интересно посмотреть на тест-кейс воспроизводящий подобную ошибку.

Отладка, Программирование

Представьте, что где-то в коде есть такой кусок:

BOOL Res =
    ReadConsole(
        GetStdHandle(STD_INPUT_HANDLE),
        Buffer,
        sizeof(Buffer),
        &ReadChars,
        NULL);

Теперь, скажем, нам в какой-то момент нужно корректно прервать вызов ReadConsole() (из другого потока). Как это сделать?

Read more…

Консоль, Программирование, Windows

На днях пытался понять, отчего и почему крошечное приложение пухнет как на дрожжах при добавлении некоторых библиотек из Boost. Рассматривая сгенерированный map файл, выяснил, что утилита undname.exe поставляется вместе с Visual Studio и в состав Windows SDK не входит. Пришлось написать свою – там всего-то нужно вызвать одну функцию (UnDecorateSymbolName). По ходу дела нашел несколько интересных ссылок по теме:

• Схема, по которой кодируются имена:
  • Microsoft C++ Name Mangling Scheme.
  • C++ Name Mangling/Demangling.
• Tips: Visual C++ – упоминает, что UnDecorateSymbolName не умеет декодировать имена классов. Вместо неё предлагается использовать недокументированную функцию, предоставляемую самим компилятором – _unDName. Вот аналогичная жалоба на rsdn.ru.
• Исходный код _unDName из проекта Wine

Разница между UnDecorateSymbolName и _unDName меня совсем не удивляет. Эти функции происходят из двух разных проектов. UnDecorateSymbolName (dbghelp.dll) – это реализация из WinDbg (Windows Division). _unDName (msvcrt.dll) пишут разработчики компилятора (DevDiv). К счастью, новые версии WinDbg выходят гораздо чаще, чем новые версии Visual C++. Есть шанс, что найденные ошибки будет оперативно подправлены.

C/C++, Программирование, Mangling, Visual C++