> Это для Вас они пишут-ся -- сами собой. =))) А кто-то их пишет. С использованием DDK (+IFS Kit), которое стало WDK, а не этого модно-молодёжного фреймворка.._.
KMDF - это фреимворк для написания драйверов уровня ядра (в линуксе почти все такие). Эти драйверы всегда пишутся на С.
UMDF - это фреимворк для написания драйверов пространства пользователя. То есть не драйверов, на самом деле, а тех самых DLL-ок которые цепляются к какому-то специфическому API, которое ядро выставляет в юзерспейс. Исторически их можно было писать на C++, потому что они работали через шину COM. А потом случилась 8-ка. В 8.1+ наступил UMDFv2 и теперь надо писать как в KMDF на С.
Это обёртки над WDM, которые существуют со времен Vista. Это слишком молодежно? А что надо VxD вспоминать? Или может быть писать на голом WDM? Так его уже тоже не рекомендуют для новых драйверов. Опять же, WDM это тоже С.
Меня так умиляет ваше желание обойти стороной самое главное, что было сказано в моем комментарии выше про поведении студии. Повторю еще раз громко и отчетливо:
Если в "Visual C++" проекте встречается файлы *.c, то они компилируются по стандарту языка С89 + куски С99. KMDF/UMDF и сама WDM - это С. С++ раньше было можно использовать для юзерспейса и то, это померло вместе с 7-кой.
> Об этом говорят IRP, которыми объекты обмениваются. Но про эти сообщения говорить явно рановато. ;)
> Ну да, приложение в юзерспейсе получает хендл объекта и с ним оперирует. А в ядре хендл транслируется в указатель на объект. Это называется "сокрытие реализации". ;))
И какое отношение это имеет к изначальному утверждению, что ООП не используется для драйверов уровня ядра, они на С?
Вы точно понимаете эту фразу правильно? Речь идёт не об академической методологии "всё есть объект". Речь именно о полнофункциональных ООП-языках у которых есть инкапсуляция, полиморфизм, наследование и абстракция, позволяющая определить поведенческие модели для объектов и, как следствие, обязывающая компилировать программу в промежуточное представление, куда транслируется весь этот ООП-шный синтаксический сахар.
А если Вы, любезный, вдруг помыслили что "сокрытие реализации" ↔ "инкапсуляция" и наличие этого сокрытия порождает ООП, то вы ошибаетесь, ведь "инкапсуляция" ∈ "сокрытие реализации". ООП-шная концепция инкапсуляции - это один из методов сокрытия, который, среди прочего, подразумевает еще включение методов в объект-класс.
Во-первых, пальцем ткните где это внутри WDM, да так чтобы на C++ классом, а не объявление указателей на функции в поле структуры.
Во-вторых, наличие инкапсуляции является необходимым, НО НЕ ДОСТАТОЧНЫМ условием для появления объектно ориентированной модели, а то и С и Rust станут объектно-ориентированными языками.
События, опять же, тоже не являются частью ООП. Они могут быть реализованы не только при помощи ООП, но и при помощи той же ECS или так как это делают в системном программировании, конечными автоматами,.. по-разному. И то что драйверы обмениваются друг с другом IRP-структурами (СТРУКТУРАМИ КАРЛ!) говорит о наличии шины данных. И что? Если я пропихну структуру с указателями на функции, контексты и прочее через пайп, то это у меня уже ООП появилось?! Ну тогда ядро Linux тоже на ООП (доказательство: наличие unix pipes, structs, function pointers)... тьфу.
> Читайте для начала Рихтера, или кого там принято рекомендовать по такому поводу. Только потом Уолтера Они.
Меня терзают смутные сомнения... А вы сами-то читали или просто "рекомендуете"? Покажите пальцем, где у того же Уолтера Они код на С++. А если рекомендовать, то может актуальную доку, а не учебник по написанию драйверов для 98/Me/2k/XP.
