by Michael S. Kaplan, published on 2011/03/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/03/17/10142495.aspx
So a question came up the other day.
Someone was wondering why The following two functions:
both list an IRQL level in the docs of PASSIVE_LEVEL.
Now I've randomly talked about IRQL from time to time in blogs like A difference that makes no difference, makes no difference (aka IRQL <= APC_LEVEL vs IRQL < DISPATCH_LEVEL) but these days I don't have much that I need to do down there so I don't talk about it much.
Now you could think of these functions as the Rtl* versions of _itow and _wtoi. Since that's all they really are.
And in fact that is kind of tied up in why they cannot run at DISPATCH_LEVEL. Because at one time (back when those CRT functions were first done), they both moved stuff in and out of their non-Unicode counterpart functions. RtlIntegerToUnicodeString and RtlUnicodeStringToInteger simply inherited this implementation (which may no longer be there in the CRT now?), and they depend on RtlAnsiStringToUnicodeString and RtlUnicodeStringToAnsiString, neither of which can be run at DISPATCH_LEVEL since either the code or the tables the code uses may not be paged in at the time.
The other, related functions that do the same conversions to IntPtr and such have the same issue.
Now strictly speaking, this could be fixed.
Neither RtlIntegerToUnicodeString nor RtlUnicodeStringToInteger are doing anything all that complicated such that implementing them straight in Unicode would be a terrible speed or size burden.
Though since drivers often have to target multiple versions and it would be weird to have IRQL info documented as being different in different versions, no one is really clamoring to fix the issue in the more conventional way (create new functions).
To be honest I would put both in a header file under a special define so the fix would optionally be available in any version of Windows. And just fix it for once and all.
But again that lack of clamor would hardly make people want to run out and do a bunch of work here.
Maybe in the scheme of things, these small "corruptions" in the model don't really matter.
Perhaps kernel level and device driver level engineers don't think of functions that only run at PASSIVE_LEVEL as being flawed, even if (in cases like this one) they could be, if they were only designed to do so. Designed better.
Maybe they wouldn't even judge this in terms of better or not better (though the purely Unicode function would be both safer and faster, which makes it likely that all things being equal they would pick the purely Unicode function if they had the choice).
The impact with all these kinds of examples (and many others like them!) is little pockets of non-Unicode that will forever hold us back from being fully Unicode, even if you the third party developer moves completely to Unicode....