Диспозиция такая. Поставил Windows 2000 DDK (дистрибутив win2kddk.exe, 68905688 байт). Далее прописываю в msdev-е (Enterprise 6.0 SP3) include path к inc-директории DDK и ставлю его на первое место. После чего подключаю

#include <ddk/ntddk.h>

и получаю кучу сообщений вида:

E:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\NTDDK\INC\ntdef.h(602) : error C2011: '_FLOAT128' : 'struct' type redefinition
E:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\NTDDK\INC\ntdef.h(649) : error C2011: '_LARGE_INTEGER' : 'union' type redefinition
E:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\NTDDK\INC\ntdef.h(668) : error C2011: '_ULARGE_INTEGER' : 'union' type redefinition

Спрашивается, и какого #$$# он хочет?..

Поставил потом DDK XP (там и поддержка Win2000 тоже есть). Ситуация точно такая же! Перепробовал всевозможные варианты с путями подключений (в том числе ставил их вперед и назад, вводил новые и т.д.) Еще общались по асе с FaileR-ом, безрезультатно.

В этой связи — большая просьба: кто пользуется DDK под Win2000 в Visual Studio (а не из командной строки компилирует), приведите тут свои настройки (особенно интересуют пути поиска h-файлов, а также начала всех программ, где включается ntddk.h с сотоварищами).

Дмитрий Котеров
Из книги Справочник по базовым функциям API Windows NT/2000 Неббет Гэри (Gary Nebbett).

... Базовые функции API, определенные в файле заголовка ntddk.h, могут быть вызваны программой для Win32, но сам файл ntddk.h не может быть включен в блок компиляции непосредственно, как winnt.h (который косвенно подключает файл windows.h). Это связано с тем, что некоторые структуры данных определены в обоих файлах. При компиляции простой программы ... возникает большое количество предупреждений о попытках переопределения типов данных и макросов, а также об ошибках компиляции ...

Файлы winnt.h и ntddk.h содержат множество определений полезных функций и структур. Вместо того, чтобы копировать их из одного файла в другой или редактировать, удаляя совпадающие определения, примеры этой книги используют возможность языка C++ размещать определения (Win32 и базовые) в различных пространствах имен:
[code]
#include <windows.h>
namespace NT {
extern "C" {
#pragma warning(disable:4005) // переопределение макроса
#include <ntddk.h>
#pragma warning(default:4005)
}
}
using NT::NTSTATUS;
int main()
{
return 0;
}
[/code]

Компилятор Microsoft языка C++ версии 11 (поставляемый в комплекте с Visual C++ версии 5) компилирует этот код безо всяких предупреждений об ошибках, но компилятор версии 12 (входящий в состав Visual C++ версии 6) выдает много "примечаний". Эти примечания содержат информацию, сообщающую о переопределении макросов. В отличие от предупреждений устранить такие сообщения нельзя.

Как следствие применения пространства имен, все применяемые определения типов из файла ntddk.h следует предварять указанием пространства имен "NT:: ". Исключение сделано лишь для NTSTATUS (применяемого с помощью оператора using), чтобы макрокоманда NT_SUCCESS осталась работоспособной.

Для удобства, все примеры этой книги используют единый подключаемый файл ntdll.h, содержащий как windows.h, ntddk.h, так и все определения базовых системных служб ...

Но что это, простите, за фигня такая? Неужели все-все, кто пользуются DDK, выделывают такой трюк?

Тем более, что этот совет относится к случаю, когда одновременно включают и windows.h, и ntddk.h. У меня же ситуация иная.

Для примера я создал простой проект с ЕДИНТВЕННЫМ файлом, в котором написана только одна строчка:

#include <ntddk.h>

Больше нигде ничего нет - ни в проекте, ни в файле. Пути поиска h-файлов я поставил такие:

E:\PROGRA~1\MICROS~2\WINDDK\inc\w2k
E:\PROGRA~1\MICROS~2\WINDDK\inc
E:\PROGRA~1\MICROS~2\WINDDK\inc\ddk\w2k

1. Остальные пути ОТКЛЮЧИЛ. Выдается:
e:\progra~1\micros~2\winddk\inc\ddk\w2k\ntddk.h(24) : fatal error C1083: Cannot open include file: 'excpt.h': No such file or directory

2. Добавил основные пути. Теперь выдается:
e:\progra~1\micros~2\winddk\inc\ddk\w2k\ntddk.h(7916) : error C2146: syntax error : missing ';' before identifier 'InterruptTime'

Может быть, нужно какие-то дополнительные макросы определить в настройках компилятора? У меня сейчас определены: WIN32,_DEBUG,_WINDOWS,_MBCS

Попробовал пример, который приводится выше. Действительно, он работает, но выдает кучу Note. Неужели у всех так?.. Ведь примеры как-то компилируются без этих ошибок (только вот как, понять невозможно, там какая-то хитрая схема через программу build, которая использует непонятно что).

[ Дмитрий Котеров
: Но что это, простите, за фигня такая? Неужели все-все, кто пользуются DDK, выделывают такой трюк? ]

Похоже, что все. И у Неббета написано почему.
Создаешь обычный пустой консольный проект.

/// xxx.cpp

#include "ntdll.h"
#pragma comment(linker,"/ENTRY:main /FILEALIGN:0x200 /MERGE:.data=.text /MERGE:.rdata=.text /SECTION:.text,EWR /IGNORE:4078")

int main()
{
return 0;
}


/// ntdll.h

#pragma once

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

namespace NT
{
extern "C"
{
#pragma warning(disable:4005)
#include <ntdef.h>
typedef __int32 LONG_PTR, *PLONG_PTR;
typedef unsigned __int32 ULONG_PTR, *PULONG_PTR;
#include <ntddk.h>
#include <ntstatus.h>
#pragma warning(default:4005)
}
}

using NT::NTSTATUS;


В Tools->Options->Directories у мя прописаны пути

для инклуд файлов:
e:\ntddk\inc
e:\ntddk\inc\ddk

для либов:
e:\ntddk\libfre
e:\ntddk\libfre\i386

Больше я ничего не менял. И все компилится. Только куча предупреждений выдается, как у Неббета и написано.

Понятно... Что ж, очень жаль.

Новая заморочка. Теперь MmMapIoSpace и MmUnmapIoSpace не находятся линкером. Пишет:

error LNK2001: unresolved external symbol __imp__MmUnmapIoSpace
error LNK2001: unresolved external symbol __imp__MmMapIoSpace

Просмотр ntoskrnl.lib (который, естественно, подключается — ведь ZwCreateFile работает) показал, что там они называются __imp__MmMapIoSpace@16, т.е. с собакой на конце.

Вообще, такое впечатление, что этот DDK делали люди, которые потом его ни разу не тестировали. Как вообще могут появляться такие ляпы?..

[ Дмитрий Котеров: Новая заморочка. Теперь MmMapIoSpace и MmUnmapIoSpace не находятся линкером.

Пишет:
error LNK2001: unresolved external symbol __imp__MmUnmapIoSpace
error LNK2001: unresolved external symbol __imp__MmMapIoSpace ]

Йо...! Так ты дровину пишешь? Тогда забудь, что я сказал. Это относится к native-приложениям, тем, которые только из ntdll.dll API зовут.


[ Дмитрий Котеров: Просмотр ntoskrnl.lib (который, естественно, подключается — ведь ZwCreateFile работает) показал, что там они называются __imp__MmMapIoSpace@16, т.е. с собакой на конце. ]

ZwCreateFile работает, потому, что точно такая же функция экспортируется из ntdll.dll. Вот линкер ее оттуда и тянет. А MmMapIoSpace только в ntoskrnl, а он у тя не подключен. А собака на конце это так называемое декорирование имен. Тут все правильно.

Короче! Если ты дрова пишешь, то должен вызывать только функции ядра (теоретически).
Если нативное приложение, то функции ядра звать не можешь (даже теоретически).


[ Дмитрий Котеров: Вообще, такое впечатление, что этот DDK делали люди, которые потом его ни разу не тестировали. Как вообще могут появляться такие ляпы?.. ]

Очень обманчивое впечатление.

[quote]
А MmMapIoSpace только в ntoskrnl, а он у тя не подключен. А собака на конце это так называемое декорирование имен. Тут все правильно.
[/quote]
Все подключено. Я ж тоже не ля-ля тут, сиу уже третий день: в настройках линкера стоит «No Default lib» и подключены ntoskrnl.lib, hal.lib. При этом, если указать ntoskrnl.lib1 (единичка в конце), ругается на отсутствие файла (следовательно, без единички включается, раз не ругается).

Так что дело может быть только в рассинхронизации версий h-файлов и lib-файлов. В либах некоторые имена (MmMapIoSpace) идут без собак тогда как по h-файлу должны быть с собакой (PASCAL и все такое).

Ни о какой ntdll.dll и речи, естественно, не идет — она запускается значительно ПОЗЖЕ, чем мой драйвер. Можно пользоваться только hal и ntoskrnl.

Поставил VS.NET. Никаких изменений по сравнению с 6.0 не заметил (разве что система очень понравилась - хорошо мужики постарались). Ну и убрались проклятые note-сы.

Попробую еще снести нафиг XPDDK (который, видимо, просто нерабочий; есть у меня еще маленькое подозрение, что дело может быть в predefines, но оно рассеивается потихоньку, уж больно глупо) и поставить 2000 DDK.

В общем, пришел я к неутишительному выводу, что в реальности никто тут драйверов такого низкого уровня на VS не писал, что бы ни говорили. А жаль :-(

Ларчик просто открывался: надо было поставить Calling convertions в __stdcall по умолчанию (в настройках проекта).

Теперь еще глюк в линкере обаружился: не хочет он линковать с базовым адресом /base:0x80010000 (а такой адрес обязателен), пишет чушь вроде

fatal error LNK1249: image exceeds maximum extent with base address FFFFFFFF80010000 and size 0xE00

Кто его просил рассматривать это как число со знаком совершенно непонятно.

Самое смешное, что в 6.0 этой проблемы не было вовсе.

Можно ли прикрутить старый линкер к VS.NET?..

Не, стоп, я гоню. Он просто теперь /driver не понимает в #pragma comment-ах (интересно, что их сподвигло так сделать), ему ее надо явно указывать в настройках проекта. Как только указал, все заработало.

[ Дмитрий Котеров: ...в реальности никто тут драйверов такого низкого уровня на VS не писал, что бы ни говорили.]

Ну дык это ж асмовая борда, вроде ;-)

Ну а какая разница... Человек, разобравшийся с ASM-ом, разберется и с Visual-ом, благо что на нем можно делать все, что и на ASM-е, да плюс еще ООП. (-;

Тему можно закрывать. Все компилируется и даже (о ужас!) работает (временами, когда погода хорошая). Всем спасибо.