Если вы думаете, что Windows 2000 умерла, это далеко не так, она прекрасно трудится на старом железе, пусть без патчей безопасности, но в домашней интрасети это простительно. Устаревшая система на устаревшем Pentium-4 что может быть прекрасней? Да и ностальгические чувства зачастую требуют вернуться к старому интерфейсу, чтобы ощутить себя на полтора десятка лет моложе.

Конечно, OS/2 смотрелась бы еще лучше, но c ней большие проблемы с современным софтом. На Windows 2000 проблем тоже хватает. Например, утилита по восстановлению удаленных файлов отказалась работать. Выдает якобы, что исполняемый файл не является приложением Win32. На Windows 7 при этом работает прекрасно.

В предыдущей статье, посвященной анализу производительности целочисленного умножения были получены удивительные результаты, требующие интерпретации, а именно — почему при генерации кода в VS2012 значительно (в 5,5 раз) падает скорость, а в VS2010 такого не наблюдается, в чем секрет быстрого кода?

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

Но команду ADC почему-то не любят компиляторы, причем настолько не любят, что нет простого способа заставить компилятор начать использовать команду ADC вкупе с флажком Carry. Можно, конечно, написать это на ассемблере. Но написание быстрого кода вручную — это непосильная задача, предусмотреть все тонкости и сделать что-то быстрее оптимизирующего компилятора практически невозможно. Еще есть проблема, что в Visual Studio C++ x64 зачем-то отказались от встроенной команды _asm, и чтобы воспользоваться ассемблерными вставками, нужно создавать отдельный ASM-файл, что делать очень не хочется.

На самом деле — нам бы очень пригодился явный intrinsic команды add-with-carry, но Microsoft hard-working создатели компилятора, когда у них спросили об этом напрямую, заявили что add-with-carry intrinsic имеет ограниченное применение и поэтому в текущем компиляторе его нет. Очень и очень зря.

Приступая к написанию тестовой программы для этой статьи я внутренне ожидал, что CPU Intel положит на обе лопатки AMD, так же как и одноименный компилятор без боя победит Visual Studio. Но не все так просто, может быть, на это повлиял выбор программного теста?

Для теста я использовал целочисленное умножение двух 128-ми битных чисел с получением 256-ти битного результата. Тест повторялся 1 млрд раз и занял всего от 12 до 85 секунд. Использовались процессоры AMD FX-8150 3.60GHz и Intel Core i5 2500 3.30GHz. Никакой мультипоточности, никакого разгона.

Использовались компиляторы Intel Parallel Studio XE Version 12.0.0.104 Build 20101006 его более новая реинкарнация 12.1.5.344 Build 20120612, Visual Studio 2010 SP1 и самый современный Visual Studio 2012 (с интерфейсом Metro и CAPSLOCK меню), он же С++ 11.0 Release Candidate. Про опцию -O2 не забываем, она включена у Visual Studio. А для Intel это необязательно, он оптимизирует с -O2 по умолчанию, для Intel включена опция -O3.

Я как-то никогда не задумывался над тем, что лучше использовать BOOL или BOOLEAN? Конечно же, BOOL — это и короче и во всех учебниках по Windows встречается именно BOOL. Как бы не так! Буквально вчера я битый час занимался поиском ошибки там, где ее не должно было быть.

Оказалось, что единственно истинный тип, впрямую связанный с типом bool, который определен стандартами языка С++, это именно BOOLEAN. А BOOL это не что иное, как «typedef int BOOL;» и находится в windows.h (точнее в WinDef.h, но это неважно)

Рассмотрим подробнее исходный код функции, сравнивающий два числа:

#include <stdio.h>
#include <windows.h>

bool CompareInt(int i1, int i2)
{
    if (i1==i2)
        return true; //UPD1: было TRUE
    else
        return false; //UPD1: было FALSE
}

typedef BOOL (*CallBack)(int, int);

void main(void)
{
    CallBack IsEqual = (CallBack)CompareInt;

    if ( !IsEqual(0x1234, 0x5678) )
        printf("Not equals");
    else
        printf("Equals");
}

После компилирования Visual Studio и запуска, имеем: Equals

Тогда поменяем BOOL на BOOLEAN:

typedef BOOLEAN (*CallBack)(int, int);

Компилируем, запускаем, получаем: Not equals (что и должно было получиться с самого начала)

Вывод: никогда не пользуйтесь BOOL, только BOOLEAN.

В связи с кризисным состоянием рынка жестких дисков все чаще стал задумываться, что сейчас самое время купить диск объемом 3Тб. Волей случая мой выбор пал на модель ST3000DM001. Стоимость этого чуда получилась немаленькая, но я заранее для себя решил, что буду гнаться за объемом, закрыв глаза на цену.

На работе воткнул свое приобретение в Windows 7 и без звука отформатировал его в новомодный GPT, который, в отличие от MBR, поддерживает диски более 2Тб. Но на домашней Windows XP возникли проблемы, диск виден, но доступа к нему нет — проблема с GPT. Устаревшая операционка отказывается принимать в строй новичка.

Стал гуглить, нашел обсуждение, сводящееся к тому, что нужно ставить Paragon GPT Loader. Но эта версия подходит только для Hitachi, для других моделей танцы с бубном, судя по форуму, превышают все разумные пределы.

Секреты создания CSP для Windows раскрыты в статье Ю.С.Зырянова.

Российские криптоалгоритмы ГОСТ реализованы в OpenSSL Gost.

Удивлен, что на просторах Интернета не удалось найти подтверждения, что кем-то был создан интерфейс криптопровайдера ГОСТ под Windows с использованием вышеприведенных инструментов.

Можно подумать, что эта задача под силу только крупным коммерческим компаниям, имеющим большой опыт в сфере информационной безопасности, к примеру, таким как:

• ООО «Лисси»
• ОАО «ИнфоТеКС»
  
• ЗАО «Сигнал-КОМ»
  
• ОКБ САПР
  
• ну и конечно, ООО «КРИПТО-ПРО»
  

Опровергнуть, хотя бы частично, это утверждение и будет задачей данной статьи.

Работаю в техподдержке, в один прекрасный день столкнулся с проблемой запуска Архивации или Восстановления в Windows 7. У пользователя на компьютере при выборе в «Панели управления» вкладки «Архивация или восстановление» перестало работать нажатие на «Настроить резервное копирование». Чтобы не искать вкладку, можете просто запустить программу C:\Windows\System32\sdclt.exe

Поиск решения проблемы через Yandex/Google ни к чему не привел. О проблеме много говорят, но реально никто не знает, что происходит, кроме того, что советуют деинсталлировать CompareIt! или PowerISO, которые некорректно обрабатывают встраивание в Проводник через Shell Context Menu. Начал проверять, нет ли похожих программ в нашем случае и выяснилось, что действительно, недавно была инсталлирована одна полезная утилита, которая меняет контекстное меню Проводника, расширяя его возможности.

После деинсталляции этой программы проблемы с Архивацией исчезли. Обратился в техподдержку, меня переключили на разработчиков, которые ничего внятного сказать не могли, кроме того, что утилита была написана достаточно давно и не предназначена для работы с Windows 7. Кроме того, в приватной беседе выяснилось, что для встраивания в Shell Context Menu был использован OpenSource код с сайта CodeGuru.

CtxMenu, Copyright 1999, Smaller Animals Software
This code may be modifed and distributed free of charge or restrictions.
This code is provided as-is. If you use this code in any application, any bugs in the code are your responsibility.

Что же на самом деле происходит?

Научился делать на одном замечательном сайте как запускать WinWord и вставлять свои строки в документ: http://jmvidal.cse.sc.edu/csce790/PS4/

Что же здесь такого, спросите Вы, ведь технология Microsoft OLE Automation описана достаточно широко и используется уже более 10 лет. А удивительно здесь то, что когда функция DO_WORD была перенесена в другой проект, это приводило к возникновению ошибки, Word просто не хотел стартовать. Это несмотря на тот факт, что проект написан на С++, но, к сожалению, не использует технологию MFC. Почему же ничего не работает, ведь инициализация OLE проходит как указано во всех руководствах? Получается, одного этого недостаточно и нужно дополнительно инициализировать библиотеку MFC. Как же это сделать?

Изначально пост планировалось посвятить ошибке 64х-битового компилятора xlc которую я безуспешно отлавливал многие часы и которая имеет место быть на серверах фирмы IBM архитектуры AIX. Но так уж получилось, что подобная ошибка затрагивает многие компиляторы, не стал исключением и Visual Studio 2010 с установленным пакетом обновления SP1. Что в итоге кажется забавным, так как наводит на мысли, что специалисты Microsoft сотрудничают с разработчиками из IBM в деле создания оптимизирующих компиляторов.

Немного предыстории. Есть один научный проект, который был написан на С++ достаточно давно и сейчас успешно переносится на многие платформы, среди которых можно отметить мейнфреймы HP-UX, IBM AIX, Oracle Solaris. Перенос по большому счету состоит в том, что исправляются ошибки времени компиляции, запускается группа тестов и если все тесты проходят, то делается вывод о работоспособности кода.

Так как скорость выполнения математических процедур очень даже важна, компиляция проходит с включенным ключом оптимизации по скорости -O2. Но на архитектуре IBM AIX компилятор xlc почему-то не может создать работоспособный код, удовлетворяющий набору тестов. В то же время без ключа -O2 все работает нормально.

Я бы, конечно, мог попробовать отловить эту ошибку непосредственно на мейнфрейме IBM AIX, будь у меня в запасе достаточно времени, но за отсутствием отладчика (в debug mode ошибка не проявлялась) ловить приходилось по-старинке, методом вставки printf в участки кода. Удаленный доступ к IBM AIX мне так и не дали, приходилось работать непосредственно в дата-центре и за те несколько часов, проведенных за терминалом, ничего внятного понять не удалось, кроме того, что ошибка имеет место быть и достаточно устойчивая. В итоге, ошибка так и сидела в коде на протяжении долгого времени.

Так продолжалось до тех пор, пока я не попробовал перенести код на Visual Studio 2010 SP1.

Мне зачастую приходится чинить домашние компьютеры знакомым и друзьям. Благо есть опыт и кое-какие навыки. От обычных вирусов спасают антивирусы. Но когда только-только появился Trojan.Winlock, это было большой проблемой, потому что модификаций у него море и ни один антивирус не справлялся оперативно с таким потоком. Пришлось учиться делать очистку вручную. Чтобы с этим разобраться в первый раз, было потрачено достаточно времени, часов 5, но теперь вся процедура занимает от силы 10 минут.

Но недавно я столкнулся с чем-то необычным, что было очень похоже на очередное Trojan.Winlock вымогательство. Для пользователя это выглядело так, что все сайты открываются нормально, но вот с сайтом «Вконтакте» прямо беда — вместо обычного входа требуют прислать денег. Это явно фишинговая атака!

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