by Michael S. Kaplan, published on 2008/07/07 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/07/8699735.aspx
Previous blogs in this series:
This next part of the series is about a phenomenon that I hope most people are unfamiliar with, whether in their personal or professional lives.
In one's professional life, it is usually less than ideal to be in a pure do you want fries with that? kind of situation where there is really nothing beyond where you are being used and for how long. Thus even feeling the question is appropriate to ask is a sign that one might be in the wrong job.
And in one's personal life, it is always a net negative kind of a sign if one is being used, only made slightly less negative if one is aware of it (since one can then change the situation). But the ultimate low point would likely be feeling the title question bubble up.
I won't talk about the few times (very few times) this has come up in my personal life in this blog. Maybe some other day in this Blog. Though holding one's breath waiting might be a poor bet....
Ditto on the professional side of this atomic wedgie inducing fence.
But I'll talk about an aspect of the question that one wants one's code to be able to ask any time one wants to remove or replace a component.
I run across this issue quite a bit with keyboard layouts, and it is even harder to handle when one is dealing with fonts.
The latter is the subject of today's blog (the former might be the subject of some future blog).
So about asking a font whether anyone is still using it....
Ironically, the font is no better off than the two situations I hinted at in the beginning of this blog -- there is really no way to ask the question. There is, quite simply, no way to find out if the font is in use by the system. At all.
The files may not be locked (the various components that use fonts tend to open the file, cache some information like metrics of the font and glyphs, keep weak pointers to other information for easy lookup later, and then closes the file. This all happens very quick, so the odds of the file being in use at the time are not very good; your only real hope if it is in use is that it will not be asking for any glyphs or other information not already cached -- which includes new sizes or other attributes of the same font.
This causes two different somewhat intractable problems:
1) Obviously if one is removing a font that is in use one will have GDI or whomever pointing to something that isn't there. This is really quite unlikely to crash or blue screen because of years of hardening, but it is quite capable of causing strange problems with processes that assume the font is still valid.
2) If you try to install a font and an earlier version of the font has been determined to exist (see Part 1 for more on the version stuff), there is no way to know if the font is currently in use. If it is then there is no way to know the impact of replacing the font file due to orphaning all of those references to information in the font.
Paul Linnerud relayed in a document an anecdote that helps underscore the consequences of these problems here:
...were to replace the font file with an updated file, Windows would not be aware of this change and would still assume the cached pointers were valid. If an application attempts to access the font for more glyphs than are cached or withes to change size unexpected results will occur and they may not occur for some period of time. The first time I saw this, the font Tahoma was replaced and was in use by Microsoft Mail. About ½ hour after the font was updated, suddenly all the lower case characters using that font would not display.
There are even worse scenarios you could imagine here, I'm sure. I am quite bullish about the safety aspects here -- the code has been quite throughly hardened here to keep terrible results from happening. But I am not so bullish about potential appearance problems; in fact I am really quite bearish. And the problems are (ironically given the word usage) quite unbearable in many situations.
You may have noticed the interesting consequences of the problems hinted at here occasionally in the past without really attributing a specific cause. A reboot will obviously fix it so I suppose you could just attribute it to @#%&*! Microsoft software and/or operating systems and call it a day. :-)
But the deeper issue remains -- if you remove or replace an installed font file you have no real way to know the potential impact on anything that may have been using or may still be using (or even may plan to use) the font.
Again I will talk about some partial mitigations for all of this in a future blog in this series, as well as some "apparent" solutions that can actually be much worse.
At the core of it all is that any time one can reasonably desire to ask the question Are you done using me yet?, one is in a potentially bad and possibly weird situation until and unless one gets the opportunity to reboot....
This blog brought to you by Ƒ (U+0191, aka LATIN CAPITAL LETTER F WITH HOOK)
Andrew West on 7 Jul 2008 10:52 AM:
Surely the font installer does not need to know who exactly may or may not be using the font; it just broadcasts the WM_FONTCHANGE message and well-behaved applications will handle it and update their font information accordingly.
Michael S. Kaplan on 7 Jul 2008 11:51 AM:
This will come up under partial mitigations (coming soon!). It is "the way" but there are significant problems with it, enough that I would hesitate to place too much stock in the message.... :-)
John Cowan on 8 Jul 2008 1:34 AM:
The obvious tactic would be to shut down, boot up using a Linux live CD or DVD, and remove or change things on the disk (including the Windows registry) to your heart's content. Make sure to back up whatever you have changed, of course.
Michael S. Kaplan on 8 Jul 2008 2:27 AM:
Changing the filesystem and registry from another OS is "obvious"?
In what dictionary can that definition be found? :-)
go to newer or older post, or back to index or month or day