Привет всем. Люди, кто может помогите со следующей проблемой.
Я не знаю в какой именно надо было постить форум но думаю этот больше подходит. Пишу я дровину под Windows CE а именно под Smartphone 2002 и Smartphone 2003. Естественно отадка ведется с помощью ведения лога. Драйвер по сути создает логический том и мапит его в определенный файл при этом производя операции шифрования и дешифрования — в общем драйвер реализует виртуальный шифрованный том(тома). Кроме dll драйвера есть dll в которой находится код для работы с криптографией, наружу торчит один класс — криптоменеджер — который простой операцией new создается и удаляется естественно операцией delete. Все это замечательно работает до тех пор пока я не вызываю какие нибуть виртуальные функции этого класса или пока не вызываюся функции которые внутри вызывают виртуальные функции — в общем до тех пор пока не используется чудо изобретение языка C++ полиморфизм. При данных ситуациях дровина генерит access violation и естественно код заканчивается с ошибкой — в результати как таковых действий которые требуются от драйвера не происходит вообще. Сначала думал что это из за того что к dll драйвера статически прилинкована dll криптоменеджера — попробовал создать внутри dll драйвера код который создает объект класса который использует простейшие виртуальные функции — результат тот же. Как мне решить эту проблему, подскажите кто может, а то я уже долго уже е..усь с этой проблемой( сории за брань, но по другому это не назовешь ).

В помойку C++ и сделать тупой Сишный API для крипто. Простейший способ IMHO. Минимальное количество проблем.

Вообще стоит осторожнее относиться к Си++ в подобных задачах.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>В помойку C++ и сделать тупой Сишный API для крипто. Простейший способ IMHO. Минимальное количество проблем.
MSS>Вообще стоит осторожнее относиться к Си++ в подобных задачах.

Да я б это сделал на чистом С, или б минимально использовал С++ фичи( полиморфизм точно ), но дело в том что мой криптоменеджер представляет уже готовую библиотеку которуя я не могу изменять из некоторых причин. Самое загадочное то, что эта схема работает на PocketPC 2002 и PocketPC 2003 и в драйвере используется таже библиотека которую я пытаюсь прикрутить, почему то-же самое не работает на смарфоне убей не пойму

Здравствуйте, _BOBAH_,
Microsoft советует не писать драйвера на C++ — http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

Здравствуйте, mokc0der, Вы писали:

M>Здравствуйте, _BOBAH_,
M>Microsoft советует не писать драйвера на C++ — http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

This information applies for the following operating systems:
Microsoft Windows 2000
Microsoft Windows XP
Microsoft Windows Server 2003
The next client version of Windows, codenamed “Longhorn”

У меня драйвер под Windows CE — а она не входит в вышеупомянутый список. Как я уже писал — аналогичный драйвер под PocketPC использует эту же библиотеку и все замечательно работает

Здравствуйте, _BOBAH_,

Я тоже сталкивался с такой проблемой.

ИМХО, переходить на C -- не очень правильно. Лучше добавить поддержку C++ в свой драйвер. Для этого придется написать код для инициализации глобальных объектов, наподобие того, что делает CRT: можешь посмотреть в исходниках CRT.

Здравствуйте, mokc0der, Вы писали:

M>Здравствуйте, _BOBAH_,
M>Microsoft советует не писать драйвера на C++ — http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
--
Just for the record: "Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers". Это цитата из статьи по ссылке.

C уважением,
Геннадий Майко.

M>Microsoft советует не писать драйвера на C++ —
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

Да можно, если осторожно, и если не пользоваться exceptions и RTTI, для которых в некоторых контекстах — типа ядра НТ — может не оказаться runtime support.

Кстати, а разве в eVC++ нет пошаговой отладки на уровне ассемблера для WinCE apps? Может, это попробовать? или это драйверный контекст WinCE, в котором не бывает отладки?

S>ИМХО, переходить на C -- не очень правильно.

Чем? Меньше гиморов.

Здравствуйте, Maxim S. Shatskih, Вы писали:

S>>ИМХО, переходить на C -- не очень правильно.

MSS>Чем? Меньше гиморов.

1. operator new/delete вместо ExAllocatePool/ExFreePool
2. Нормальное наследование вместо идиотской эмуляции
3. Шаблоны
4. Не нужно, черт возьми, все локальные переменные писать вначале функции!
5. Более гибкое управление областями видимости
6. ...

Можно еще приводить тезисы, но уже достаточно, ИМХО.

Здравствуйте, Maxim S. Shatskih, Вы писали:

M>>Microsoft советует не писать драйвера на C++ —
MSS>http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

MSS>Да можно, если осторожно, и если не пользоваться exceptions и RTTI, для которых в некоторых контекстах — типа ядра НТ — может не оказаться runtime support.

MSS>Кстати, а разве в eVC++ нет пошаговой отладки на уровне ассемблера для WinCE apps? Может, это попробовать? или это драйверный контекст WinCE, в котором не бывает отладки?

Возможно есть, не буду утверждать, но я ниразу не слышал о такой возможности. Согласно Platform Builder'у отладка ведется с помощью банального trace, правдо немного расширенного, когда с сообщением указывется так называемая DebugZone, которую можно интерпретировать как категорию сообщения, а как реально отлаживать драйвера под CE( имеется в виду пошаговое отлаживание) к сожалению не знаю — знал бы гемора меньше было

>интерпретировать как категорию сообщения, а как реально отлаживать драйвера под CE(
>имеется в виду пошаговое отлаживание) к сожалению не знаю — знал бы гемора меньше

Практически никак. Максимум — собрать в PB платформу PDA (это НЕ Pocket PC никоим образом) и загрузить драйвер туда. Там будет пошаговый отладчик.

Несложно догадаться, что ни power mgmt, ни работу с Wi-Fi так не отладишь. Как и многое другое.

S>1. operator new/delete вместо ExAllocatePool/ExFreePool

А чем оно лучше? тем, что exceptions бросаются, а для них нету runtime support и вообще они являются злом в системах, где нужна надежность?

Состояние системы после exception — не определено. Продолжать работу в этой ситуации — нарываться на крах. Потому чем ближе к месту возникновения обслужить ошибку — тем лучше.

S>2. Нормальное наследование вместо идиотской эмуляции

Наследование запутывает код. Все начинает зависеть от всего, это плохо. Случаев, где наследование действительно нужно — немного.

S>3. Шаблоны

А для чего они нужны? Для контейнеров? а чем RTL generic table плоха?

S>4. Не нужно, черт возьми, все локальные переменные писать вначале функции!

А это минус. Потому как у нас размер стека ограничен в ядре. С++ жрет стек как мама не горюй.

Здравствуйте, sober, Вы писали:

S>Здравствуйте, Maxim S. Shatskih, Вы писали:

S>>>ИМХО, переходить на C -- не очень правильно.

MSS>>Чем? Меньше гиморов.

S>1. operator new/delete вместо ExAllocatePool/ExFreePool

учитывая сколько возможных вариантов выделить память, придется либо плодить классы с одинаковой функциональностью но с разными операторами выделения памяти — для вытесняемой, для невытесняемой, для кешируемой, для некешируемой. Либо переходить к шаблонам. Активное использование шаблонов (плавно переходим к п.3 ) может привести к нахождению багов в компиляторе — компилятор от VC 6.0 напрмер нелучшее средство для генерации кода с шаблонами.

S>2. Нормальное наследование вместо идиотской эмуляции
От чего собираемся наследоваться? Скорее всего, начнете писать свою библиотеку class MyDriver, class MyDevice. Тут надо заметить, что драйвер — это не MS Office. Пишет его обыно один человек, кода по сравнению с прикладными программами — в несколько раз ( десятков ) по объему меньше. Эффект от повторного использования кода — минимален ( хотя конечно, предотвращает копипаст ).

S>3. Шаблоны
уже говорил

S>4. Не нужно, черт возьми, все локальные переменные писать вначале функции!
Дисциплина при написании кода ядра не повредит.

S>5. Более гибкое управление областями видимости
Опять же — драйвер маааленькая программка — 50 kB исполняемого кода — это уже можно сказать драйвер-слон. Какие там области видимости? Кроме того, нужно смирится и не пытаться втянуть все известные библиотеки — boost, stlport и.т.д. После этого отречения от "светской жизни" сам вопрос пропадет

Житейский опыт:
Чтобы написать хороший код ядра, нужно очень внимательно просмотреть много чужого кода — хотя бы примеры из DDK (если есть возможноть, то и исходников NT). После по-настоящему внимательного просмотра, мне кажется и желание писать на С++ поуменьшится . Я лично в свое время проникся — красивый код. И зачем там какие то шаблоны и переопределенные операторы????

S>>4. Не нужно, черт возьми, все локальные переменные писать вначале функции!

MSS>А это минус. Потому как у нас размер стека ограничен в ядре. С++ жрет стек как мама не горюй.
--
Я бы сказал — писатели драйверов сами "жрут" стек
Достаточно посмотреть на реализацию практически любой функции AddDevice в исходных кодах DDK, а еще лучше — в WDF. Если бы они писали бы код в стиле С++, вводя переменные и сразу же инициализируя их только тогда, когда они нужны, то стек таки да бы экономился.

С уважением,
Геннадий Майко.

Здравствуйте, Maxim S. Shatskih, Вы писали:

S>>1. operator new/delete вместо ExAllocatePool/ExFreePool

MSS>А чем оно лучше? тем, что exceptions бросаются, а для них нету runtime support и вообще они являются злом в системах, где нужна надежность?

MSS>Состояние системы после exception — не определено. Продолжать работу в этой ситуации — нарываться на крах. Потому чем ближе к месту возникновения обслужить ошибку — тем лучше.

Причем здесь exceptions? Я переопределяю operator new так, как хочу:

FORCEINLINE void* CDECL operator new( size_t size )
{
    return ExAllocatePoolWithTag( NonPagedPool, size, POOL_TAG );
}

FORCEINLINE void CDECL operator delete( void* p )
{ 
    ExFreePool( p );
}

FORCEINLINE void* CDECL operator new( size_t size, POOL_TYPE poolType )
{
    return ExAllocatePoolWithTag( poolType, size, POOL_TAG );
}

FORCEINLINE void CDECL operator delete( void* p, POOL_TYPE poolType )
{ 
    UNREFERENCED_PARAMETER( poolType );

    ExFreePool( p );
}

И использую:

char* buffer = new( PagedPool ) char[ 256 ];

S>>2. Нормальное наследование вместо идиотской эмуляции

MSS>Наследование запутывает код. Все начинает зависеть от всего, это плохо.

Дело привычки

MSS>Случаев, где наследование действительно нужно — немного.

struct _KPROCESS {
 ...
};

struct _EPROCESS {
 _KPROCESS Pcb;
 ...
};

А не лучше ли:

struct _EPROCESS : public _KPROCESS
{
 ...
};

?

S>>3. Шаблоны

MSS>А для чего они нужны? Для контейнеров? а чем RTL generic table плоха?

Хеш-таблица во многих случаях лучше, чем сплей-деревья.

S>>4. Не нужно, черт возьми, все локальные переменные писать вначале функции!

MSS>А это минус. Потому как у нас размер стека ограничен в ядре. С++ жрет стек как мама не горюй.

На пару байт больше?! Не надо писать функции на 10 км!

Здравствуйте, TarasCo, Вы писали:

TC>Здравствуйте, sober, Вы писали:

S>>Здравствуйте, Maxim S. Shatskih, Вы писали:

S>>>>ИМХО, переходить на C -- не очень правильно.

MSS>>>Чем? Меньше гиморов.

S>>1. operator new/delete вместо ExAllocatePool/ExFreePool

TC>учитывая сколько возможных вариантов выделить память, придется либо плодить классы с одинаковой функциональностью но с разными операторами выделения памяти — для вытесняемой, для невытесняемой, для кешируемой, для некешируемой. Либо переходить к шаблонам. Активное использование шаблонов (плавно переходим к п.3 ) может привести к нахождению багов в компиляторе — компилятор от VC 6.0 напрмер нелучшее средство для генерации кода с шаблонами.

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

S>>2. Нормальное наследование вместо идиотской эмуляции
TC>От чего собираемся наследоваться? Скорее всего, начнете писать свою библиотеку class MyDriver, class MyDevice. Тут надо заметить, что драйвер — это не MS Office. Пишет его обыно один человек, кода по сравнению с прикладными программами — в несколько раз ( десятков ) по объему меньше. Эффект от повторного использования кода — минимален ( хотя конечно, предотвращает копипаст ).

см. предыдущий пост также.

P/S я говорил о том, как убого в C эмулируют наследование, а не о том, где это может понадобиться (это уже понадобилось, раз эмулируют).

S>>3. Шаблоны
TC>уже говорил

Если я буду реализовывать хеш-таблицу, то лучше сделаю это через шаблоны.

S>>4. Не нужно, черт возьми, все локальные переменные писать вначале функции!
TC>Дисциплина при написании кода ядра не повредит.

Конечно!

S>>5. Более гибкое управление областями видимости
TC>Опять же — драйвер маааленькая программка — 50 kB исполняемого кода — это уже можно сказать драйвер-слон. Какие там области видимости? Кроме того, нужно смирится и не пытаться втянуть все известные библиотеки — boost, stlport и.т.д. После этого отречения от "светской жизни" сам вопрос пропадет

Я не говорил ничего об STLPort и тем более boost.

Речь идет о том, что на члены класса не нужно навешивать префиксы => более короткие имена, более удобно. Хотя против префиксов (скажем, для API-функций) я ничего не имею, напротив, считаю, что они улучшают читаемость кода.

TC>Житейский опыт:
TC>Чтобы написать хороший код ядра, нужно очень внимательно просмотреть много чужого кода — хотя бы примеры из DDK (если есть возможноть, то и исходников NT). После по-настоящему внимательного просмотра, мне кажется и желание писать на С++ поуменьшится . Я лично в свое время проникся — красивый код. И зачем там какие то шаблоны и переопределенные операторы????

Я тоже проникся красивосью кода NT! Но отказываться от синтаксического сахара C++, а также от других удобств я не собираюсь. Можно использовать только часть средств C++.

Практически любая C-программа без изменений откомпилируется под C++. Так зачем же себя ограничивать?

S>>>1. operator new/delete вместо ExAllocatePool/ExFreePool

TC>>учитывая сколько возможных вариантов выделить память, придется либо плодить классы с одинаковой функциональностью но с разными операторами выделения памяти — для вытесняемой, для невытесняемой, для кешируемой, для некешируемой. Либо переходить к шаблонам. Активное использование шаблонов (плавно переходим к п.3 ) может привести к нахождению багов в компиляторе — компилятор от VC 6.0 напрмер нелучшее средство для генерации кода с шаблонами.

S>Достаточно пары вариантов (см. предыдущий пост). Для изощренных вариантов можно и обычные функции вызывать.

IMHO это очень плохая практика для C++ кода — смешанный стиль выделения памяти. В результате рано или поздно будет вызван оператор delete для объекта созданного не через new и.т.п.

А изощренных вариантов не надо придумывать. Начнем c класс для строк для режима ядра. Очевидно, что может понадобится как строка, находящяяся в PagedPool, так и в NonPagedPool.


S>P/S я говорил о том, как убого в C эмулируют наследование, а не о том, где это может понадобиться (это уже понадобилось, раз эмулируют).

Есть другие механизмы — например включение. Кто мешает писать, например так:

typedef struct OBJ_HEAD {
   LONG Ref;
} OBJ_HEAD;

typedef struct SOME_OBJ {
   OBJ_HEAD  Head;
}

S>>>5. Более гибкое управление областями видимости
TC>>Опять же — драйвер маааленькая программка — 50 kB исполняемого кода — это уже можно сказать драйвер-слон. Какие там области видимости? Кроме того, нужно смирится и не пытаться втянуть все известные библиотеки — boost, stlport и.т.д. После этого отречения от "светской жизни" сам вопрос пропадет

S>Я не говорил ничего об STLPort и тем более boost.

S>Речь идет о том, что на члены класса не нужно навешивать префиксы => более короткие имена, более удобно. Хотя против префиксов (скажем, для API-функций) я ничего не имею, напротив, считаю, что они улучшают читаемость кода.

Ага, префиксы будут навешиваться на имя переменной — экземпляра объекта

S>Я тоже проникся красивосью кода NT! Но отказываться от синтаксического сахара C++, а также от других удобств я не собираюсь. Можно использовать только часть средств C++.

S>Практически любая C-программа без изменений откомпилируется под C++. Так зачем же себя ограничивать?

А наоборот ? Я думаю, когда речь идет о сравнении C/C++ вопрос не ограничивается написанием по сути С кода в синтаксисе С++ ( с объявлениями переменных в любом месте, использованием инициализирующих конструкторов навроде int a(0); ). Я вообще против этого . Пишешь на С++ — так пиши на два ++ ))). А вот тут есть кой-какие подводные камешки.

PS: Я ни в коем случае не заявляю, что на С++ драйвера писать нельзя )). Я лишь хочу сказать, что в данной узкой области С код имеет не меньшее право иметь место

Здравствуйте, TarasCo, Вы писали:


TC>>>blah-blah-blah

Ладно, это уже holy-war. Это уже во флейм переростает.

Я тоже считаю, что написание драйверов на C имеет право на существование.

Что же касается смешанного C/C++ кода, то я так пишу. И ничего пока что, ни на какие грабли не напарываюсь!