Ready... set... Reboot Redux

by Michael S. Kaplan, published on 2005/12/12 05:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/12/12/502463.aspx


It was way back in February of 2005 in the Ready... set... Reboot! post that I first started talking about the issues surrounding rebooting the OS upon a change of the default system locale.

After Rob Mensching's In Defense of Windows Vista's Restart Manager this last weekend, I thought it might make sense to talk about it a bit more.

Rob's post (and the Restart Manager) center on the replacament of in-use executable files and the resumption of whatever processes those executable files were doing.

Now certainly that is something that could affect NLS functionality in hot fixes or in service packs -- for our code in kernel32.dll or our *.nls data files, if any are updated.

But the reboots that happen for the default system locale happen for basically two reasons:

  1. To facillitate the update to the CP_ACP and CP_OEMCP values for all non-Unicode conversions, operations, and applications on the machine.
  2. To allow the GDI font linking cache to be updated based on the rules of the chosen language

In the case of #1, it does affect in-use, memory mapped data files, and shared memory (in Vista this is shared memory across the whole machine; in prior versions it was shared only across WindowStations).

For #2 on the other hand, this is a WindowStation-specific cache that is built upon the creation of a WindowStation (this is why people found that if you changed the default system locale but did not reboot that new Terminal Services  sessions (which run in new WindowStations) would pick up some of the updated font linking characteristics.

Now the GDI font cache (where font linking happens, not font fallback, as I described here), is not completely in a consistent state in this situation of no change in code page but rebuild of the font cache, due to the fact that the console (.FON) fonts are code page based, and therefore kind of depend on the code page update to completely do the font cache update. But if we limit the conversation to the truetype font cache stuff (which is all the good Unicode applications have to worry about), then the font linking will be updated properly (for the most part) even in this non-rebooting case.

There are some additional wrinkles, however.

Now take the post I did about East Asian Font Names.... for example. I talked about the work that was done in Windows 2000 to support loading the different names of fonts -- something that is especially important for the East Asian font names like GulimChe versus 굴림체.

However, the font cache has to deal with more than just the font name -- it must also deal with aditional words like the word "Bold" in the Tahoma Bold font -- which will show up as Tahoma Gras on a machine with a French default system locale. And apparently that support was not done as fully (probably due to not being backed up by the font name resource holding the localized name?).

It turns out that there are many situations that require not just one reboot but TWO reboots in order to completely give the expected results for such cases, due to the complex in way in which the font cache is built up (and even how GDI decides if or when it needs to build up that cache).

Hard to have a goal of eliminating a reboot if you have to worry about needing two reboots, isn't it? :-)

If there was ever a good reason to change the font weight rather than using the font name to pick up the bold/italic/bold-italic variant of the font, then this is it! You may not have heard it here first, but it is very good advice either way.

Somehow, I am doubting that the Windows Vista Restart Manager is going to untangle all of these issues, since there is likely a whole bunch of code that needs to be updated in GDI before the Restart Manager could hope to help out here.

In Rob's post, jws commented about the continuum of inconvenience:

Let's not talk about 'reboots' as such. Whenever possible we should not interrupt the user. There is a continuum of inconvenience that goes-

1. no visable effect
2. close and re-open application
3. log off/log on
4. shutdown/restart

I guess to that we have to add 5. shutdown/restart twice to the list, huh? :-(

And that is not even talking about all of the interesting issues with the code pages that I will blog about another day....

 

This post brought to you by "" (U+32a9, a.k.a. CIRCLED IDEOGRAPH MEDICINE)


# Gabe on 12 Dec 2005 5:52 AM:

Kinda makes you wonder why there isn't just some "Update GDI Font cache" operation, huh? It seems a bit ridiculous to have to reboot the whole machine just to be able to update some font information.

# Michael S. Kaplan on 12 Dec 2005 8:42 AM:

Hey Gabe --

It is hard to do it inplace since the cache would almost certainly be in use. Though perhaps the way has been shown that it could move to a "level 3" inconvenience if we can figure out the rest of the issues....

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.

referenced by

2012/01/26 If font linking doesn't fit the text to a T (or ț!), a Romanian letter may be right but not quite look it

2010/03/30 A modest proposal

2008/10/28 Ready... set... Reboot Redux, part Deux!

2006/09/19 Ready... set... Don't Reboot!

2006/03/14 GDI Font Linking in GDI+

2006/02/13 Getting all of the localized names of a font

2006/01/22 Questions about font linking, etc.

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