Задачка вроде простая
Работает драйвер в режиме ядра.
У него есть строка в памяти (и готовый указатель, конечно).

Нужно эту строку перевести в Upper Case
Другой вариант — найти в этой строке заданную подстроку, невзирая на регистр букв.

После безуспешных попыток прилинковать winuser.h, в котором объявлена функция CharUpper, возникло ощущение, что эта функция работает только в user mode. Да и в MSDN сказано, что она использует драйвер национальной привязки
...
To make the conversion, the function uses the language driver for the current language selected by the user at setup or by using the Control Panel.
...
Посему вопрос: братья, как проще выкрутиться? Чтоб найти подстроку в заданной строчке или перевестивсе в верхний регистр?
(Уровень IRQL может быть как PASSIVE, так и DISPATCH)

Вопрос, наверное, глупый, но я еще мало пишу на DDK. Sorry.

toupper() из <ctype.h>
должна работать но только с латиницей, видимо

А>После безуспешных попыток прилинковать winuser.h, в котором объявлена функция
>CharUpper, возникло ощущение, что эта функция работает только в user mode. Да и в MSDN

Конечно. Принципиально невозможно звать Win32 функции в ядре. В ядре — свой особый мир.

По теме — RtlUpcaseUnicodeString пробовал?

Здравствуйте, Maxim S. Shatskih, Вы писали:

А>>После безуспешных попыток прилинковать winuser.h, в котором объявлена функция
>>CharUpper, возникло ощущение, что эта функция работает только в user mode. Да и в MSDN

MSS>Конечно. Принципиально невозможно звать Win32 функции в ядре. В ядре — свой особый мир.

MSS>По теме — RtlUpcaseUnicodeString пробовал?

Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные готовить или свою написать )

А насчет поиска.. если включительно с DISPATCH — незнаю другого варианта как написать самому или лучший вариант это отложить всю работу пока не понизится IRQL.

И смотреть в сторону Rtl..UnicodePrefix.

Здравствуйте, Злость, Вы писали:
MSS>>По теме — RtlUpcaseUnicodeString пробовал?

З>Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные готовить или свою написать )
есть RtlUpcaseUnicodeChar
соотв она + цикл даст то что нужно

хотя про нее тоже написано что она только для Passive, в моих проектах я ее не только на PASSIVE использую и пока вроде бы проблем не было. Комментарии специалистов?

Здравствуйте, Valerio, Вы писали:

V>Здравствуйте, Злость, Вы писали:
MSS>>>По теме — RtlUpcaseUnicodeString пробовал?

З>>Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные готовить или свою написать )
V>есть RtlUpcaseUnicodeChar
V>соотв она + цикл даст то что нужно

V>хотя про нее тоже написано что она только для Passive, в моих проектах я ее не только на PASSIVE использую и пока вроде бы проблем не было. Комментарии специалистов?

Да все функции можно вызывать хоть на DISPATCH_LEVEL — если все в NonPool, но тогда под verifier.exe жить не будет если проверку на IRQL включить

Здравствуйте, Злость, Вы писали:

З>Здравствуйте, Valerio, Вы писали:

V>>Здравствуйте, Злость, Вы писали:
MSS>>>>По теме — RtlUpcaseUnicodeString пробовал?

З>>>Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные готовить или свою написать )
V>>есть RtlUpcaseUnicodeChar
V>>соотв она + цикл даст то что нужно

V>>хотя про нее тоже написано что она только для Passive, в моих проектах я ее не только на PASSIVE использую и пока вроде бы проблем не было. Комментарии специалистов?

З>Да все функции можно вызывать хоть на DISPATCH_LEVEL — если все в NonPool, но тогда под verifier.exe жить не будет если проверку на IRQL включить

Да все будет нормально и под верифаером. Просто MS "подстилают солому". Все их юникодовские строки виделены на свопируемой памяти. Соответственно, попытка работать с ними на DISPATCH_LEVEL вызовет page fault (как всем известно ). Когда происходит падение под верифаером при вкл. IRQL — значит был доступ к свопабельной памяти (проверка IRQL заключается только в том, что вся свопабельная память принудительно свопируется (как достало это слово ) ). Поэтому если есть уверенность, что обе строки в несвопируемой памяти — можно пользоваться ф. Rtl... (или если кому нравиться ANSI C — стандартными — реализация то одна ) на любом IRQL. В частности, RtlUpcaseUnicodeString можно использовать только при собственноручном выделении строк (т.е тр. парам = FALSE)

Здравствуйте, TarasCo, Вы писали:


З>>Да все функции можно вызывать хоть на DISPATCH_LEVEL — если все в NonPool, но тогда под verifier.exe жить не будет если проверку на IRQL включить

TC>Да все будет нормально и под верифаером. Просто MS "подстилают солому". Все их юникодовские строки виделены на свопируемой памяти. Соответственно, попытка работать с ними на DISPATCH_LEVEL вызовет page fault (как всем известно ). Когда происходит падение под верифаером при вкл. IRQL — значит был доступ к свопабельной памяти (проверка IRQL заключается только в том, что вся свопабельная память принудительно свопируется (как достало это слово ) ). Поэтому если есть уверенность, что обе строки в несвопируемой памяти — можно пользоваться ф. Rtl... (или если кому нравиться ANSI C — стандартными — реализация то одна ) на любом IRQL. В частности, RtlUpcaseUnicodeString можно использовать только при собственноручном выделении строк (т.е тр. парам = FALSE)

Заявляю что все выделялось в NonPool и когда использовалась стандартная Rtl... функция под verifer с включенным обязательная проверка IRQL все валится. Написал свою функцию и все ... работает.

А насчет реализации

Здравствуйте, unintruder, Вы писали:

U>toupper() из <ctype.h>
U>должна работать но только с латиницей, видимо

Да, так и придется делать. Ибо все Rtl...String функции рассчитаны преимущественно на PASSIVE уровень, что у меня встречается значительно реже, чем DISPATCH.

Спасибо всем принявшим участие в обсуждении.

MSS>>По теме — RtlUpcaseUnicodeString пробовал?
З>Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные
>готовить или свою написать )

Естественно. NLS таблицы сидят в pageable memory, и потому такого рода функции работают только на PASSIVE.

Придется отложить транслитерацию до PASSIVE. Я бы так вообще на юзер моду эту задачу возложил по возможности.

V>хотя про нее тоже написано что она только для Passive, в моих проектах я ее не только
>на PASSIVE использую и пока вроде бы проблем не было. Комментарии специалистов?

NLS таблицы сидят в pageable memory. Дальше продолжать?

Даже KdPrint(("%wZ")) не работает на DISPATCH.

TC>Да все будет нормально и под верифаером. Просто MS "подстилают солому". Все их
>юникодовские строки виделены на свопируемой памяти.

В третий раз пишу. В свопируемой памяти не строки, а таблицы перекодировки. И все операции, где нужны эти таблицы — работают только на PASSIVE.

З>Заявляю что все выделялось в NonPool и когда использовалась стандартная Rtl... функция
>под verifer с включенным обязательная проверка IRQL все валится. Написал свою функцию и
>все ... работает.

По-моему, вывод достаточно понятет. Будет все валится, будет. Раз в несколько часов, например. или под нагрузкой

Верифаер не зря придуман.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>По теме — RtlUpcaseUnicodeString пробовал?
З>>Жаль что эта функция только на PASSIVE_LEVEL работает (нужно или зарание данные
>>готовить или свою написать )

MSS>Естественно. NLS таблицы сидят в pageable memory, и потому такого рода функции работают только на PASSIVE.

MSS>Придется отложить транслитерацию до PASSIVE. Я бы так вообще на юзер моду эту задачу возложил по возможности.


Небольшое уточнение — PASSIVE_LEVEL и APC_LEVEL(но очень аккуратно, это как правило paging io, насколько я помню, Валерий именно в таких частях кода употреблял соотв. функцию).

Документация DDK в некоторых местах вместо <DISPATCH_LEVEL неточно ставит PASSIVE_LEVEL как требование.

На самом деле требование OS эквивалентно макросу PAGED_CODE()

V>Документация DDK в некоторых местах вместо <DISPATCH_LEVEL неточно ставит
>PASSIVE_LEVEL как требование.

Это факт.

Крайне мало где нужен именно PASSIVE, и не годится APC. Во всех Zwxxx функциях ввода вывода, например. Дело в том, что APC_LEVEL блокирует IopCompleteRequest, и потому никто не просигналит Irp->UserEvent. Ждать будем потому — до морковкина заговения.

Здравствуйте, Maxim S. Shatskih, Вы писали:

V>>Документация DDK в некоторых местах вместо <DISPATCH_LEVEL неточно ставит
>>PASSIVE_LEVEL как требование.

MSS>Это факт.

MSS>Крайне мало где нужен именно PASSIVE, и не годится APC. Во всех Zwxxx функциях ввода вывода, например. Дело в том, что APC_LEVEL блокирует IopCompleteRequest, и потому никто не просигналит Irp->UserEvent. Ждать будем потому — до морковкина заговения.



Совершенно верно, и видимо изначально документация DDK писалась в основном для разработчиков драйверов периферийных устройств (для кого APC редко интересен), и некоторые статьи не вполне еще обновлены, хотя прогресс большой.

--(для кого APC редко интересен)--

(кроме storage stack)

Здравствуйте, vstrogov, Вы писали:

V>Небольшое уточнение — PASSIVE_LEVEL и APC_LEVEL(но очень аккуратно, это как правило paging io, насколько я помню, Валерий именно в таких частях кода употреблял соотв. функцию).
так точно

только собрался уточнить, что у меня это использовалось в случаях, когда Paging IO возможен (APC_LEVEL) и поэтому нестрашно, а уже уточнение озвучено, спасибо Владимир

Здравствуйте, Maxim S. Shatskih, Вы писали:

З>>Заявляю что все выделялось в NonPool и когда использовалась стандартная Rtl... функция
>>под verifer с включенным обязательная проверка IRQL все валится. Написал свою функцию и
>>все ... работает.

MSS>По-моему, вывод достаточно понятет. Будет все валится, будет. Раз в несколько часов, например. или под нагрузкой

MSS>Верифаер не зря придуман.

Ясно спасибо. Я не подумал ... действительно если NLS таблици перевода находятся в свопируемой памяти.

Мой вариант не упадет ... так как я тогда просто ограничил функциональность

#define upcase(C) (WCHAR )(((C) >= 'a' && (C) <= 'z' ? (C) - ('a' - 'A') : (C)))

И теперь все ... спасибо за разьяснения.