Re: Questions about MSDN for some DDK functions


"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message news:S6tze.1451$yL4.339@xxxxxxxxxxx
"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:uxBBwK6gFHA.3608@xxxxxxxxxxxxxxxxxxxxxxx 
1.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k109_81806669-d742-4cb9-b4dd-d7e40fef171a.xml.asp
says:
Return Value
RtlUpcaseUnicodeChar returns the uppercase version of the specified Unicode character.

MSDN gives no exceptions. Even if the uppercase version of the specified Unicode character requires two Unicode characters to express, RtlUpcaseUnicodeChar returns it in one WCHAR. May I express some doubts about this definition?

You are confusing things here, all UNICODE characters are 16 bits, this is not a multibyte model where some things are lead characters.

I am not confusing anything. In a character set which Microsoft commonly uses for German and other languages, there is a lowercase letter which is a single character but which uppercases to two characters SS. In the ANSI encoding which Microsoft commonly uses for that character set, one single byte lowercase letter properly uppercases to two single byte uppercase letters. In Unicode one 16-bit lowercase letter properly uppercases to two 16-bit uppercase letters. I still doubt that RtlUpcaseUnicodeChar performs the way MSDN documents it.

2.
[...]
There is not a direct call to do this, multibyte character stuff has limited support in the kernel, the expectation is you go with UNICODE where everything is the same size, therefore faster and safer to use.

Fine, we agree that Microsoft's ANSI functions are incapable of uppercasing the German letter referred to above. But here you say the expectation is to go with Unicode, where it still looks like Microsoft's Unicode functions don't deal with it the way MSDN says.

Meanwhile as originally mentioned, some of Microsoft's code still uses ANSI (for example, in the country where I live, boot.ini is both read and displayed in ANSI code page 932 = OEM code page 932). This kind of thing doesn't get solved by setting an expectation for me to go with Unicode.

3.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k109_c1a13e9a-f863-4bcd-ae89-daee0c3d3a4b.xml.asp
says (for RtlUpperString):
The number of bytes copied from SourceString is either the Length of SourceString or the MaximumLength of DestinationString, whichever is smaller.

So even if the MaximumLength of DestinationString is longer than the Length of SourceString and is also long enough to hold the entire uppercase conversion of SourceString, RtlUpperString will still truncate the result at the Length of SourceString, will waste the remaining available space, and will lose some of the characters that should have been converted. Why?

Without checking the source, so this is from memory. RtlUpperString will use the RtlUpperChar type conversion model if this is upper case able and not part of multi-character string it is uppered, otherwise not.

That looks like an answer to 0% of what I asked in question 3. Did I misunderstand your answer?

4.
A little bird told me why RtlIsValidOemCharacter isn't documented. Probably the thing takes a single byte parameter and returns a single byte result and is thoroughly incapable of distinguishing valid OEM characters from garbage. But why is the thing exported? Are there really some callers that call it? If so, aren't the callers guaranteed to fail? Wouldn't it be better to delete the function RtlIsValidOemCharacter entirely?

It is documents in the IFS kit.

Yikes. From that I infer that there really are some callers that call it, and that is why it is exported. But surely the thing is thoroughly incapable of distinguishing valid OEM characters from garbage? I messed up in guessing that it probably returns a single byte result because obviously it returns some representation of a Boolean, but what is the type of its argument? It sounds like you have the IFS kit and its documentation, so please kindly look it up. Does it really take a parameter of type pointer to multibyte character (i.e. char* or something equivalent to that or pointer to an unsigned or signed version) and does it really parse all chars of the character to check for validity? 

.

Relevant Pages

  • Re: VB - Ascii to Unicode and then Unicode to UTF-8 conversion (Very desperate!!)
    ... Latin together) then you have to use a Unicode column type. ... AscW returns the real Unicode character ... for Chinese characters, ... then the next thing to worry about is your CSV file. ...
    (microsoft.public.vb.general.discussion)
  • Re: Unicode Support
    ... if two Unicode strings are the same? ... UTF-16 is basically telling everyone "ok we all got to start ... character, and will likely support *both* endians. ... UTF-8 encodings are also easy to learn to ...
    (alt.lang.asm)
  • Re: KANJD212
    ... >>Who decides the factors and what are their criteria, Unicode? ... But once a character is defined/get a codepoint in Unicode it ... standard modifies the codepoint of the kanji to a totally new ... I can use a code like JIS X0208 along with a font ...
    (sci.lang.japan)
  • Re: Questions about MSDN for some DDK functions
    ... Since all the comments talk about single character UNICODE, ... Even if the uppercase version of the ... > uses for German and other languages, there is a lowercase letter which is ...
    (microsoft.public.development.device.drivers)
  • Re: Determining if a string is Unicode
    ... there's nothing magic about Unicode. ... where each character occupies 2 bytes, as opposed to a Single-Byte Character ... You could load up a string with rubbish, ... > INF file like so: ...
    (microsoft.public.vb.general.discussion)