Shift in .NET handling of culture data

There’s been a shift of handling culture data in .NET 4. This may have influences of attempts in fixing Persian culture.

The shift is simple, while prior to version 4, CLR insisted on using privately stored culture data in a “culture.nlp” binary resource, version 4 gave up and uses windows API to get data from operating system. This is why some complained about missing CultureTableRecord while using PersianCalendar.

Culture Data Prior to .NET 4

The following sequence shows how culture data are handled in prior to version 4:

1. CultureInfo constructor calls CultureTableRecord.GetCultureTableRecord:

   

2. CultureTableRecord constructor uses CultureTable.Default.GetDataItemFromCultureName:
3. The Default property returns m_defaultInstance field which is initialized in class initializer:
4. Finally InitializeBaseInfoTablePointers loads “culture.nlp” from assembly resources:
5. where “culture.nlp” can be found in mscorlib resources:

There’s also a CalendarTable class with virtually the same approach:

CultureData in .NET 4

The above approach has been totally deprecated in .NET 4. Now CLR prefers to use Windows API to retrieve culture data. For instance, the following excerpt is from disassembly of CalandarData code where CLR attempts to enumerate optional calendars by calling EnumCalendarInfoExEx:

Conclusion

There’s been a shift in handling culture data in .NET 4: Now CLR prefers to use Windows API to get culture data This will have influences in fixing Persian culture as I will describe in later posts.

CodeProject