Есть сишная либа, которую мы писали для ring-3 и есть уже некоторый объем ring-3 кода, который юзает эту либу. Сейчас понадобилось использовать либу в ring-0, в драйвере. И принято решение делать код "кроссплатформенным". С самим кодом, в общем сложностей никаких, компиляберность под wdk достигли быстро. Но уперлись в интерфейс. Часть функции в интерфейсе либы юзает wchar_t * (строки путей к файлам), для ring-3 это вполне приемлемо. А вот для ring-0 конечно же удобнее было бы использовать UNICODE_STRING.
И вот тут начинается конфликт между ring-0 и ring-3 пользователями либы. Нужно делать интерфейс, так чтобы он был удобен для всех. А варианты, которые я вижу:
1) заставить ring-3 пользователей страдать: использовать везде UNICODE_STRING
2) заставить страдать ring-0 пользователей: оставить в интерфейсе wchar_t * и заставить их формировать терминированную нулем строку из UNICODE_STRING. Т.е. перевыделять буфер строки UNICODE_STRING.Buffer, копировать оригинальный буфер + L'\0'. А потом очищать выделенную память.
3) как компромисс, сделать два аргумента: первый — строка, второй — размер буфера строки. DoSomething(wchar_t * str, int str size); Сформировать такие два аргумента из UNICODE_STRING.Buffer + UNICODE_STRING.Length легко. А вот для ring-3 аргумент размера буфера строки все равно обуза.
4) делать два разных интерфейса. Для ring-3 набор функций, например, DoSomething(wchar_t *); а для ring-0 — DoSomethingNative(UNICODE_STRING *); Но это тоже не нравится из-за дублирования.

Как вообще кроссплатфоменный принято в таких случаях оформлять?

p.s. Самое интересное, что в ring-0 в итоге строка из либы попадет в NtCreateFile(), т.е. если оставить wchar_t * в интерфейсе, то в ring-0 получается нелепая конверсия: UNICODE_STRING -> wchar_t * -> UNICODE_STRING