Очень старый .NET VB compiler bug

Это эту неделю написал несколько классов на C++ для работы с телом .NET IL метода. Данный код жизненно необходим в новом dotTrace для line-by-line & coverage profiling. Прошло 1.5 года с того момента, когда я нашел несоответствие кода порождаемого .NET VB compiler спецификации Ecma-335, Partition II (Metadata Definition and Semantics), 25.4.5 (Method data section). После нескольких .NET Framework Service Pack и выхода VS2008 ничего не поменялось - эта bug живет и здравствует.

Суть проблемы в том, что поле DataSize для структур IMAGE_COR_ILMETHOD_SECT_FAT и IMAGE_COR_ILMETHOD_SECT_SMALL содержит длину секции БЕЗ УЧЕТА заголовка секции (4 байта). По спецификации значение должно быть 4+24*n или 4+12*n соответственно.

Особенности реализации стандартных API функций в WindowsMobile

MSDN for WindowsMobile 5.0

"... If the thread is making a kernel call, SuspendThread fails. An application might need to repeat the SuspendThread several times for it to succeed. ..."

В семье не без урода

.NET Compact Framework есть существо обделенное не только функциональностью, но и интеллектом. Целый день ковырял странный exception о том, что тип не загружен. Мало того, что не говорится какой именно тип не загружен, но и возникает он в станном месте, где по идее ничего криминального нет. Обидно еще то, что отладчик напрочь отказался коннектиться к приложению на симуляторе. Пришлось отлаживать итерационным методом: исправил, запустил, проверил, что сюда дошли и так по кругу...

Расковырял: оказалось, что любой exception в статическом конструкторе подменяется exception о незагрузке типа без указания что же блин произошло там внутри. Простенько и со вкусом. Дальше больше: код ассембли был скомпилирован для .NET Framework v1.0, а запускался он на .NET Compact Framework v3.5. Так вот в коде были случайно использованы классы и методы (из System.dll) отсутствующие на .NET Compact Framework. Естественно при порытке обратиться к отсутствующему классу программу посылали, но как красиво: сборка System, Culture=null, Version= бла_бла_бла, Token=бла_бла_бла, ... НЕ НАЙДЕНА !!!

Мудёр

Вчера обнаружил очень приятную особенность компилятора С++ от VisualStudio 2008 для x86 - он автоматически удаляет блок try/catch если во всех вызовах функций между ними (в том числе и дочерних) не может возникнуть exception.

How much does Exception Handling cost, really?

Чувак (он же Kevin Frei) толково рассказывает про то как устроен SEH / C++EH мир для x86 и x64. Что, почем и какого дъявола происходит. Тем, кто еще не забыл С++ и еще может читать по слогам ассемблер посвящается...

Короче, установи PowerPoint и тыкай сюда.

Новое в Visual Studio 2010

Я за то чтобы языки программирования развивались в сторону упрощения конструкций, удобства использования, ну и естественно не в ущерб скорости. Особенно это касается С++. Давненько тут не было ничего принципиально нового. Так, по мелочи, что-то менялось и все, но в основном полировались старые и создавались новые библиотеки.

И вот наконец-то появилось что-то новенькое и вкусное для меня - С++ lambda. Все это конечно как бы есть в boost и stl, но кто этим пользовался меня поймет: пишется ну очень много никому не нужных букв для простецкого действия.

На всем этом жиждется еще одна новая фича - паралельные вычисления. Об этом складно и долго вещал чувак из MS на PDC2008. Есть две версии паралельных вычислений: для Managed и для С++ разарботчиков. В VS2010 интегрирована поддержка этого дела - сильно модифицированы отладчик и профайлер, ну и компилятор естественно.

От чего вдруг такая забота? На мой взгляд очень просто - 2 или 4 ядра у проца сейчас норма. А в большинстве случаев программа в один момент времени занимает только один процессор. Программерам просто влом писать параллельный код - работы много и шеф не погладит по головке за убитое время, а результат простому глазу особенно не виден. А тут на тебе 1 функция и дело в шляпе. Быстро удобно и думать почти не нужно. Это то о чем так мечтали большевики... Правда не понятно с накладными расходами на это дело. Вот разгребу накопившиеся дела, поставлю VS2010 и попробую...

Приколы ARM ассемблера

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

E3A03116    mov r3, #0x16, 2
E3830901    orr r0, r3, #1, 18
E12FFF1E    bx lr

Первая команда берет 0x16 и циклически сдвигает вправо на 2 бита - резульат 0x80000005 вторая команда берет 1 и сдвигает циклически вправо на 18 бит, потом делает OR с результатом первой команды. Получаем 0x80004005 в r0 (возвращяемое значение функции).

Вот как эта функия выглядит на C++:

HRESULT Class::Func() { return E_FAIL; }

Эволюция ошибок

Сегодня было проведены полномаштабные dotTrace-маневры в обстановке приближенной к боевой. Незамедлительно я отметил для себя удивительную закономерность: предыдущая версия частенько кидала "Out of Memory" (эта стандартная болезнь почти всех профайлеров), а новая похоже будет частенько кидать "Low Disk Space"... Не смешно! Как вам размер снапшотика в 36 Гигабайт? А ведь это всего 20% теста... Другими словами, снапшотик в 180 Гигабайт - это наша объективная реальность. Не смешно, два раза! С другой стороны, один снапшот - это один винчестер. На лицо удобство транспортировки...

P.S. А теперь скажем об этом официально.