The casing table case (.NET)

by Michael S. Kaplan, published on 2005/09/22 03:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/09/22/472596.aspx


When I was in elementary school, I read a book entitled The Violin Case Case. To be honest, I remember very little about it other than the title, as well as an hour long conversation we had about the title (which now that I think about it may have been my introduction to things linguistic).

The title of this post is a somewhat lame attempt at an allusion. Just FYI....

Anyway, an anonymous person going by the handle CN asked in the Suggestion Box:

http://blogs.msdn.com/greggm/archive/2005/09/21/472453.aspx

This post, and others, state that the new .NET features for ignoring case in comparisons matches the behavior of the OS. Is that really true? I was under the impression that the casing tables were defined on each partition, for NTFS. (and that you've blogged about this tiny difference before)

I thought it would be nice to explain what was going on here....

Now if you are a regular reader you will know how I have talked about OrdinalIgnoreCase and how it does thing that are not found in nature (unleww you consider the NT filename/object space to be natural, of course!).

Anyway, in Windows Vista we are doing the casing table update I was hoping we would do. And the folks in the .NET Framework were very concerned that their efforts to provide the OrdinalIgnoreCase comparison type would have been in naught since the OS might have a different idea of what ignoring case means for ordinal comparisons.

The solution? Well, make sure that OrdinalIgnoreCase uses the OS casing table's rules, so you can get the expected behavior when comparing against filenames, named pipes, mutexes, environment variables, and so on.

Of course that does not expose the casing results to developers using the .NET Framework, at least not without a pinvoke....

Which brought on the extra part of the solution to take care of this small discontinuity -- the casing results when you use the InvariantCulture will also match the OS results, so that you can duplicate what the .NET Framework is doing here if you need to.

Now the casing results for all other cultures will return the ones that the .NET Framework provides -- the change only affects InvariantCulture-type casing operations, and OrdinalIgnoreCase (a new option in Whidbey).

So CN, I hope this makes the issue clearer -- in summary the changes were to:

  1. Support the OS style comparisons via OrdinalIgnoreCase
  2. Allow developers to mimic the results with Invariant casing plus the Ordinal style comparison

 

This post brought to you by "" (U+fffc, a.k.a. OBJECT REPLACEMENT CHARACTER)

 

 


no comments

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day