Note that case-insensitive compare is extremely complex in Unicode, so if
it is required you have to obey the PASSIVE_LEVEL constraint.
Otherwise, if bitwise equality suffices, a bitwise compare will do just fine.
joe
I think the Unicode tables are pageable, and thus this limitation.
You can compare the strings bytewise (case-sensitive) at any IRQL
using memcmp() or such.–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com“James Harper” wrote in message
> news:xxxxx@ntdev…
> The documentation for RtlXxxString and friends in most cases says IRQL
> must be PASSIVE_LEVEL. Is this a hard and fast rule that the
> verifier/PREfast/checked build is going to trip me up on, or is some
> flexibility allowed?
>
> If I can guarantee that the buffers for my UNICODE_STRING are
> NonPagedPool, can I get away with calling RtlCompareUnicodeString? Or is
> it more that the RtlCompareUnicodeString routine itself might be paged
> out?
>
> My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary
> length, so they need to be managed separately to the DeviceIdentification.
> The names reflect the name of a network resource that in turn has an
> arbitrary length (there probably is an actual limit, but it’s probably
> longer than I want to allocate “just in case”).
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>