Включение заголовков C ++ в программы пользовательского режима, созданные с NT DDK
Итак … У меня есть компонент режима ядра и компонент пользовательского режима, который я собираю, используя готовую среду сборки NT DDK 7.1.0. Компонентом ядра являются все файлы .c / .h / .rc. Компонент пользовательского режима — это файлы .cpp / .c / .h / .rc.
Сначала это казалось самым простым в использовании строить для обоих, как я видел, вы могли бы изменить ./sources файл компонента пользовательского режима, чтобы сказать что-то вроде:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
UMTYPE = windows
UMENTRY = winmain
USE_MSVCRT = 1
Похоже, это не вызывало проблем, и я был доволен, пока не попытался #include <string> (или же <memory>или что-то еще) Не находит этот материал:
ошибка C1083: не удается открыть включаемый файл: ‘строка’: такого файла или каталога нет
Тем не менее, он компилирует часть пользовательского режима с семантикой языка C ++. Но как мне заставить работать стандартное включение?
Технически мне не нужно использовать DDK строить инструмент для пользовательского режима шт. Я мог бы сделать визуальное решение для студии. Я немного осторожен, поскольку столкнулся с другими неприятностями, такими как тот факт, что DDK использует __stdcall вместо __cdecl по умолчанию … и нет никакого прагмы или переключателя компилятора, чтобы переопределить это. Вы буквально должны войти в каждую декларацию, которая вас интересует, и изменить ее, предполагая, что у вас есть источник для этого. : — /
Я начинаю задаваться вопросом, является ли это просто фрактальным спуском в «То, что вы МОЖЕТЕ, не означает, что вы ДОЛЖНЫ создавать приложения пользовательского режима с помощью DDK. Здесь будут драконы». Так что мой вопрос не только об этом конкретном техническом препятствии, а скорее о том, стоит ли мне отказаться от идеи создания компонента пользовательского режима C ++ с помощью инструментов DDK … только потому, что компонент ядра является чистым C.
Решение
Чтобы создать программу пользовательского режима с WINDDK, вам нужно добавить некоторые переменные в ваш файл SOURCES:
386_STDCALL=0использоватьcdeclсоглашение о вызовах по умолчаниюUSE_STL=1использовать STLUSE_NATIVE_EH=1добавить поддержку обработки исключений
Все остальное у вас уже есть.
Я поставлю свой полный файл SOURCES для справки:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
TARGETPATH = obj
UMTYPE = console
UMENTRY = main
USE_MSVCRT = 1
USE_NATIVE_EH=1
USE_STL=1
386_STDCALL=0
SOURCES= main.cpp
И main.cpp:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "bla bla bla!";
cout << s;
return 0;
}
Повеселись!
Другие решения
Откажитесь от идеи создания компонентов пользовательского режима с помощью инструментов DDK. (хотя я нахожу концепцию захватывающей :-P)
Ваш компонент режима ядра должен быть собран отдельно от компонентов режима пользователя, что является хорошей практикой.
Вверху моей головы, и это действительно говорит об ограниченном опыте … есть много тонких различий, которые могут вспыхнуть, если вы попытаетесь смешать их вместе.
Используя свой собственный пример __cdecl vs __stdcall; У вас есть два разных соглашения о вызовах. _cdecl — это все ядро, и все методы C ++ обернуты в WINAPI (_stdcall) при прохождении соглашений и __stdcall выполнит очистку, выполнит автоматическую очистку стека и ожидает, что указатели фреймов будут вставлены повсюду. И если вы случайно используете параметры компилятора для вызова __fastcall, отладка будет проблематичной.
Вы определенно можете взломать что-нибудь вместе, но действительно ли вы хотите отслеживать это в своем пользовательском коде и среде сборки? Тьфу я говорю.
Если у вас нет особых технических причин для объединения этих двух сред (и отсутствие единого опыта сборки не является действительной причиной, поскольку вы можете получить это из пакетного файла с именем buildall.bat), я говорю использовать отдельные наборы инструментов.