А почему именно ХР? Судя по карте, железо позволяет обновиться до Win10 и использовать официальный тулчейн без проблем, не заморачиваясь с поддержкой легаси. Или проблема именно в специфике открытых драйверов?
ХР64 не поддерживается (не проверял, но, скорей всего, в ядре не хватит нужных экспортов, попробуйте), а про MinGW не подскажу, использую только MSVC. Если не секрет, что именно хотите реализовать и почему столь странный тулчейн и требование к 10 лет, как устаревшей, ОС?
К слову, такой же способ исполнения пользовательского кода в Ring0 используется и у меня: отключаем SMEP, сохраняем FPU-контекст и прыгаем на юзермодный код внутри __try..__except-блока (см. KbExecuteShellCode). А сейчас пишу обновление, чтобы напрямую работать с PTE-записями из юзермода (т.е., сможем открыть юзермоду всё ядерное пространство). С точки зрения секьюрности — полное ай-ай-ай! Но основная цель драйвера и заключается в том, чтобы максимально упростить выполнение необходимого кода в ядре и делать то, что нельзя.
Зависит от используемого функционала. Например, функции для работы с IO, MSR, чтение\запись памяти (в т.ч. ядерной) совершенно безопасны для продакшна и сделаны со всеми необходимыми проверками и ловушками исключительных ситуаций (например, с учётом, что приложение может попытаться освободить память или поменять её права доступа, пока мы с ней работаем). Но функции для, скажем, прямых манипуляций с Mdl небезопасны по самой своей сути: если приложение создало отображение и по каким-то причинам закрылось, не сделав анмаппинг — гарантированно получим BSOD при попытке отдать системе смапленные адреса. Такие функции я бы не рекомендовал использовать в юзермодном коде в реальных продуктах. Нужно смотреть, что именно требуется сделать и какие вообще пути для решения есть.
Что касается ядерной части, вполне можно использовать драйвер или API как готовый шаблон для написания своих ядерных компонентов в продакшн.
Если интересует надёжность каких-то конкретных частей драйвера — спрашивайте, обсудим.
Я сторонник использования новейшего стека технологий, и использование устаревшего стандарта было бы ударом по моим перфекционистическим чувствам) А вообще, коль скоро драйвера в подавляющем количестве пишут на C без плюсов, уже сам факт использования C++ в API может добавить неудобств тем, кто захочет перенести часть функций в уже существующий продукт. А если писать с нуля — тогда и смысла нет привязываться к старым стандартам, когда ничто не мешает сразу использовать всё самое новое.
Про клэнг ничего не могу сказать — не пробовал. Но, судя по постам на unknowncheats, им успешно собирают драйвера с поддержкой STL из коробки. А как разруливают исключения — не знаю. Но, раз клэнг используют в ядре, с сехами проблем быть не должно. С другой стороны, какие есть причины собирать им ядерные модули и не лучше ли использовать официальный тулчейн?
Мелочи, типа [[fallthrough]]. В ядерном коде с нововведениями не разойтись, но выставил сразу поддержку последнего черновика C++ (формально, уже C++20), чтобы при попытке обновить стандарт не возникло неприятных неожиданностей и варнингов. 99%, конечно же, C++11.
Что касается ядерной части, вполне можно использовать драйвер или API как готовый шаблон для написания своих ядерных компонентов в продакшн.
Если интересует надёжность каких-то конкретных частей драйвера — спрашивайте, обсудим.
Про клэнг ничего не могу сказать — не пробовал. Но, судя по постам на unknowncheats, им успешно собирают драйвера с поддержкой STL из коробки. А как разруливают исключения — не знаю. Но, раз клэнг используют в ядре, с сехами проблем быть не должно. С другой стороны, какие есть причины собирать им ядерные модули и не лучше ли использовать официальный тулчейн?