Not a kernel guy

Raymond Chen, оказывается, такой душка. На месте Exchange Server team я бы уже начал писать ругательное письмо.

… причем, судя по всему, несбыточная. Хочу чтобы Visual C++, Platform SDK и WDK (бывший DDK) можно было использовать как отдельные кирпичики, из которых можно составить нужное окружение для сборки программ. Ведь по сути каждый их них это набор из компилятора, библиотек и подсистемы сборки (nmake, build или Visual Studio IDE). Выбрать бы из этой россыпи нужную версию компилятора и требуемый набор библиотек…

Казалось бы все должно быть довольно просто, однако кругом рассыпано столько граблей, что просто руки опускаются. Вот, скажем, пытался я собрать небольшую DLL, написанную на Managed C++ с помощью свежего WDK. В WDK не входит mscoree.lib, однако её можно взять из Platform SDK. Добавляю её в TARGETLIBS и натыкаюсь на древнее как сам build.exe ограничение - запрет на использование пробелов в путях. Наверняка build.exe использовался для сборки самой Windows NT 4.0 которая вышла больше 10-ти лет назад и которая дружила с пробелами в путях с самого рожденья. За 10-то лет можно было побороть эту проблему?

Понятно, что можно использовать короткий путь, вместо длинного, либо создать символическую ссылку. Однако это ограничивает переносимость между разными машинами, поскольку требует дополнительной настройки каждого из компьютеров. Остаётся только использовать nmake или что-то стороннее вроде Boost.Build и городить кучу умных скриптов, которые будут анализировать конфигурацию и настраивать все более-менее автоматически. Эх!

Upd: запрет на пробелы в TARGETLIBS удалось таки обойти. Достаточно добавить вот такую строчку в SOURCES:

LINKER_OPTIDATA = \\
    "$(VS80COMNTOOLS)..\\..\\VC\\PlatformSDK\\lib\\mscoree.lib"

Значение LINKER_OPTIDATA пишется в файл ответов (response file) линкера как есть, без изменений. Это работает для WDK build 5759. Вечером попробую на 5600.

Как вы думаете, какой сообщение выведет нижеследующая программа, в случае если её запустить на Windows Vista 64 с правами обычного пользователя, т.е. пользователя, у которого нет прав на запись в каталог “C:\Program Files”?

#include <memory.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
    FILE* f = NULL;
    char cookie[] = { 'b', 'a', 'r', ' ' };
    char data[sizeof(cookie)] = { 'f', 'o', 'o', ' ' };

    f = fopen("C:\\\\Program Files\\\\foo.txt", "w");
    if (f)
    {
        fwrite(cookie, sizeof(cookie), 1, f);
        fclose(f);
    }

    f = fopen("C:\\\\Program Files\\\\foo.txt", "r");
    if (f)
    {
        fread(data, sizeof(data), 1, f);
        fclose(f);
    }

    if (0 == memcmp(data, cookie, sizeof(cookie)))
    {
        printf("Success!\\n");
    }
    else
    {
        printf("Something went wrong!\\n");
    }

    return 0;
}

(more…)

Со вчерашнего дня у блога появилось зеркало на blogs.gotdotnet.ru. Тyда будут копироваться заметки, посвяшённые разработке софта вообще и программированию под Windows в частности.

Отдельное спасибо Александру Ложечкину за приглашение и помощь в создании зеркала.

Хочу поделиться рецептом победы над коварным IShellLinkDataList (см. предыдущие посты COM marshalling. и Shortcuts, shell and COM apartments.)

Итак, исходная задача: вызвать метод локального интерфейса (интерфейса, помеченного атрибутом [local]) удалённо.

(more…)

Наткнулся сегодня на блог Александра Ложечкина и на его пост SAL - кое-что новое для С++ в частности. В двух словах SAL (Standard Annotation Language) - это способ дать компилятору немного больше информации о том, как та или иная функция использует переданные ей параметры: in/out аттрибуты, размеры буферов и т.п. Компилятор, используя эту информацию, может делать дополнительные проверки кода, находя, скажем, ошибки переполнение буфера. Более того, статические анализаторы кода, тот же PREfast, также могут использовать эту информацию, повышая тем самым эффективность и точность анализа. Так вот меня удивило количество, да и качество тоже, негативных комментариев. Как-то очень явно чувствуется отношение “нам это не надо, мы и сами умные”. Интересно, а кто тогда рассаживает баги, как не сами программисты?

Я даже разразился речью в комментариях:

Поздно наткнулся на этот блог, но не могу не высказаться.

Товарищи критикующие синтаксис и ратующие за спасительную абстракцию в виде STL в C++! Вы безусловно правы, но вы ни фига не понимаете, что такое работа над проектом с 5-10-15 летней историей и исходниками занимающими много много мегабайт. В условиях когда нужно и баги править и новую функциональность писать и уложиться в год или два, чтобы продать продукт. Я вам скажу, что в таких условиях все средства хороши и пренебрегать чем-либо даже не разобравшись что оно даёт очень неразумно.

Есть STL и алгоритмы? - нужно их применять и давать по шапке тем, кто тащит в код свой “улучшенный” вариант списка. Есть статический анализатор кода (lint, PREfast)? - пользуйтесь им и исправляйте найденные им ошибки. Есть runtime проверки обнаруживающие переполнение буфера и другие типичные ошибки? - включите их. Съэкономленный 1% процессорного времени вы всё равно потратите на поиски ошибок.

Все-таки, наверное, Европейский Суд не зря судит Microsoft за недостаточно хорошую документацию. Пытаясь разобраться как, все таки, написать proxy для интерфейса IShellLinkDataList (см. предыдущие посты: COM Marshalling. и Shortcuts, shell and COM apartments.), перечитал уйму документации, пока не нашел толкового описания того, что я хочу сделать на сайте Dr. Dobb’s. Если попытаться описать весь процесс “метаний”, то выглядело это так:

(more…)