class MyDriverClass
{
PDRIVER_OBJECT m_DriverObject;
public:
DRIVER_INITIALIZE mf_DriverEntry;
MyDriverClass();
};
MyDriverClass *g_DriverObject;
// The C linkage wrapper functionextern"C" DRIVER_INITIALIZE DriverEntry;
extern"C" NTSTATUS DriverEntry(__in PDRIVER_OBJECT DriverObject, __in PUNICODE_STRING RegistryPath)
{
// Create/Initialize class MyDriverClass with a pointer
// to it in g_DriverObject. g_DriverObject = new MyDriverClass();if (g_DriverObject == NULL)
{
//...
}
NTSTATUS st = g_DriverObject->mf_DriverEntry(DriverObject,RegistryPath);
//...
}
// Implement the DriverEntry member function
NTSTATUS MyDriverClass::mf_DriverEntry(__in PDRIVER_OBJECT DriverObject, __in PUNICODE_STRING RegistryPath)
{
m_DriverObject = DriverObject;
//...
}
Знающие люди, объясните как это понимать, оно вообще скомпилится? Если да, то как? Вроде как microsoft говорил всегда, что CPP в драйверах не поддерживает. Или я что-то упустил?
Здравствуйте, MTimur, Вы писали:
MT>Знающие люди, объясните как это понимать, оно вообще скомпилится? Если да, то как? Вроде как microsoft говорил всегда, что CPP в драйверах не поддерживает. Или я что-то упустил?
C++ в драйверах прекрасно работает с некоторыми ограничениями.
Здравствуйте, Cyberax, Вы писали:
MT>>Знающие люди, объясните как это понимать, оно вообще скомпилится? Если да, то как? Вроде как microsoft говорил всегда, что CPP в драйверах не поддерживает. Или я что-то упустил? C>C++ в драйверах прекрасно работает с некоторыми ограничениями.
Спасибо. Не подскажите где можно почитать подробнее об этом?
Простой тест
char * a = new char();
Результат:
error LNK2019: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) referenced in function _DriverEntry@8
Здравствуйте, MTimur,
C>>C++ в драйверах прекрасно работает с некоторыми ограничениями.
MT>Спасибо. Не подскажите где можно почитать подробнее об этом?
--
Можно начать отсюда C++ for Kernel Mode Drivers: Pros and Cons.
error LNK2019: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) referenced in function _DriverEntry@8
Ну так определи
Вообще, new() без параметров в ядерной разработке противопоказан. Я бы так и оставил его неопределённым и вместо него использовал бы параметрический new.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>Здравствуйте, MTimur,
C>>>C++ в драйверах прекрасно работает с некоторыми ограничениями.
MT>>Спасибо. Не подскажите где можно почитать подробнее об этом? ГМ>-- ГМ>Можно начать отсюда C++ for Kernel Mode Drivers: Pros and Cons.
ГМ>C уважением, ГМ>Геннадий Майко.
Мне особенно нравится эта фраза в заключении
"Several of the most insidious problems are extremely difficult to reproduce on demand while testing the driver, so a driver with an inherent unreliability might appear to run for extended periods with no problems and fail at random times. This reinforces the need for careful analysis."
Хотя вроде WDF написанна на С++. Так что наверное не все так плохо с С++.
Здравствуйте, Cyberax, Вы писали:
C>Я бы так и оставил его неопределённым и вместо него использовал бы параметрический new.
Отказаться от возможности написать
vector<int> v;
?
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
C>>Я бы так и оставил его неопределённым и вместо него использовал бы параметрический new. GN>Отказаться от возможности написать
Я и не понимаю — ради чего следует отказаться от возможность использовать дефолтный аллокотор и заставлять пользователя писать повсеместно дополнительный код?
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
В каком из случаев можно ответить на вопрос: "в каком пуле аллоцируется память?"
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
GN>В каком из случаев можно ответить на вопрос: "в каком пуле аллоцируется память?"
В том, который был передан в конструктор pool_allocator'а вместо ... второго варианта
Как много веселых ребят, и все делают велосипед...
GN>Я и не понимаю — ради чего следует отказаться от возможность использовать дефолтный аллокотор и заставлять пользователя писать повсеместно дополнительный код?
Удобнее контролировать. Случайно сложнее сделать аллокацию из неправильного пула из повышенного IRQL, например.
Здравствуйте, ononim,
GN>>В каком из случаев можно ответить на вопрос: "в каком пуле аллоцируется память?" O>В том, который был передан в конструктор pool_allocator'а
Боюсь, вопрос недопонят, в свете того, что 2 разных экземпляра одного типа должны быть эквивалентны.
Если есть мысли как сделать такой хитрый конструктор — с радостью послушаю
O>вместо ... второго варианта
Второй вариант — 2 разных не экземпляра, а типа аллокатора. Какие бенефиты даёт запрет неявного использования одного из типов?
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Если есть мысли как сделать такой хитрый конструктор — с радостью послушаю
Это в теории, на практике Dinkum STL прекрасно работает со stateful-аллокаторами.
Здравствуйте, Cyberax, Вы писали:
C>Удобнее контролировать. Случайно сложнее сделать аллокацию из неправильного пула из повышенного IRQL, например.
"Случайно" можно и другой пул написать
Про проверки IRQL, ксати, спасибо за намёк. Как я понял, идея делать их в мемберах аллокатора (это наверное и идеологически правильней — при доступе к памяти). Важно ли для реализации, дефолтный аллокатор или нет? По-моему — не важно.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
GN>Про проверки IRQL, ксати, спасибо за намёк. Как я понял, идея делать их в мемберах аллокатора (это наверное и идеологически правильней — при доступе к памяти). Важно ли для реализации, дефолтный аллокатор или нет? По-моему — не важно.
Дело не только в том на каком IRQL ты обращаешься к памяти. А еще в том в каком пуле обязан лежать тот или иной объект ядра, если для него выделена память. К примеру KeInitializeMutex требует non-paged pool для мутекса (впрочем это общее правило для объектов синхронизации). Кроме того просто тупо может быть ситуация когда память, выделенная на PSASSIVE_LEVEL будет использоваться на DISPATCH_LEVEL. Так что концепция "дефолтового" аллокатора в ядре неприменима.
Как много веселых ребят, и все делают велосипед...
остался без ответа.
C>А если серьёзно, то это баг в Стандарте.
Если так серьёзно, то что оно делает и в последнем драфте?
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
