поставил Intel C++ Сompozer XE 2011

с целью проведения всяческих бесчеловечных опытов. icl.exe пишет например

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.0.104 Build 20101006

Затем пересобрал на нем свою тестилку скорости хешей (на основе fehashmac) для 64бит:

• на vs2008 со стандартными ключами оптимизации
• на icl.exe со стандартными ключами оптимизации
• на icl.exe с оптимизациями, выкрученными на максимум - например были указаны генерация кода sse4.1, global optimization & interprocedural optimization

Результаты дико угарные. Размеры .exe:

• vs2008 - 317952 байт
• intel - 471040 байт. Просмотр кода показывает что были тупо развернуты все циклы с константыми счетчиками циклов
• intel opt - 472576 байт

Прирост производительности (запускалось все на corei7, цифры даны в мегабайтах в секунду)

wincheck rc4

скачать
Changelog:

• добавил поддержку xp with no SP (например на ней нет ф-ции RtlEncodePointer и другая W32pServiceTable)
• добавил проверку некоторых таблиц функций в win32k.sys
• добавил в udis86 инструкции lzcnt, movntsd & movntss
• пофиксил кое-какие баги, в том числе найденные PVS Studio. Критичных впрочем не нашлось кажется ни единого

ищем gapfnMessageCall

вот тут например Indy утверждает что

Поиск этих массивов столь сложен, что без построения и анализа графа фактически не возможен

Я думаю он несколько преувеличивает размер бедствия

Например можно найти gapfnMessageCall из тела ф-ции NtUserMessageCall - там всего одна такая примерно инструкция:

call    ds:_gapfnMessageCall[eax*4]

Граф понадобится на vista & w7 - построить цепочки переходов в этой ф-ции по jz/jb/jmp

Соотв-но таблица gapfnScSendMessage на тех 32битных windows, что я сегодня посмотрел, находится всегда непосредственно перед массивом gapfnMessageCall (исключением является w2k3 без sp). Размер обеих таблиц

• под xp/w2k3 0x38 указателей
• под w2k 0x35 указателей
• под vista 0x3d указателей
• под w7 0x40 указателей
• под w8 0x44 указателей

Остается еще один вопрос - как найти неэкспортируемую ф-цию NtUserMessageCall. Например из DriverEntry достать как аргументы к KeAddSystemServiceTable W32pServiceTable & W32pServiceLimit и по значению W32pServiceLimit в hard-coded словаре извлечь индекс NtUserMessageCall

P.S.: самая Ъ версия windows несомненно pure xp (без SP вообще). У нее в W32pServiceTable ровно 666 ф-ций, бгг

пережил нашествие с хабра

какая-то альтернативно-одаренная личность дала на говнохабре сцылку на мой старый псто
Результаты дичайше радуют

• 0 комментов
• с sf 0 скачиваний
• в том псто есть ссылка на более другой псто про то, что ecl в сущности как любой практически open-source - говно - у него 0 просмотров

Тупые, ленивые и нелюбопытные жывотные, чо. Успешные Стартаперы™, бгг

serious business

Klocwork всего три дня спустя прислал письмо на предмет пощупать их мега-продуктЪ:

Our min. configuration/price € 24.000 per year and it will include:
 - UP to 20 fixed user licenses (or 4 floating licenses) Single Language-Klocwork insight
 -1 fixed build license (server)
 -unlimited LOC (lines of code)
 -Maintenance & support for 12 month

All prices depends on the following choices :
 - Insight or Insight Pro license
 - fixed or floating license
 - single language  or all languages (C,C++,Java)

Ильфак в сравнении с занимается чистой благотворительностью по моему

прогнал сорцы wincheck

на PVS Studio
Нашло 2253 possible errors
Начну с плохих новостей

• оно работает дико медленно - на 2.5 метрах ~13 минут
• находит в основном всякий треш типа вот такого:

Dangerous magic number 4 used: UCHAR Tag[4]

Дико опасная ошибка, да. Я заметил что оно вообще всегда делает стойку на константы 4 и 32

• On 64-bit platform, structure size can be reduced from 48 to 40 bytes by rearranging the fields according to their sizes in decreasing order.

  Ну круто, чо. А как делать rearranging the fields то ? Хоть бы варианты какие предлагала
  
• И самое угарное - большинство таких структур находятся например в ntdll.h, бгг
• отчего-то вот такой вполне легальный кусок кода sizeof(PBYTE) * _countof(m_index_table) считается

  It is odd that a sizeof() operator is multiplied by sizeof()

• также раздражает что if ( memcmp(hash, old_hash, HASH_SIZE) ) считается как

  The 'memcmp' function returns 0 if corresponding buffers are equal. Consider examining the condition for mistakes

  ну и чо - проверил я хэши и если не совпали - мне нужно предпринять какие-то действия например
  

Хорошие новости

• нашла одно присваивание в if. Даже странно что visual studio ни слова не сказала
• нашлась пара printf с меньшим числом аргументов, чем указано в format string. 
• один printf соотв-но с большим числом аргументов, чем указано в format string.

bug in fehashmac

нашел давеча
Например поскольку длина у него хранится в битах то вместо

 memcpy (hashval, state->out, state->hashbitlen<<3);

должно быть

  memcpy (hashval, state->out, state->hashbitlen>>3);


Никогда не доверяй open-source, бгг

Update: автор библиотеки не страдает кровавым энтерпрайзом головного мозга - после непродолжительной переписки он не стал грузить меня необходимостью "поиска узких мест", "докупанием железа на сервере ", "недовольством Заказчика" и просто выпустил новую версию, бгг