On installing and removing fonts, Part 3: I'll love you forever, or at least for this session.

by Michael S. Kaplan, published on 2008/07/08 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/08/8706789.aspx

Dedicated to an Easter Egg poem, and its author...

Previous blogs in this series:

• 0: A long journey begins with the zeroeth step
• 1: Do I know you, or some version of you at least?
• 2: Are you done using me yet?

This blog in the series is a slight detour....

And I am going to go slightly out of order now.

The off-course jaunt started in my mind last time in a response to Part 2, regular reader Andrew West commented:

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.

Now Andrew is quite right -- WM_FONTCHANGE is just the message that a responsible installer/uninstaller would send here.

Unfortunately there are many problems with the architecture -- some the fault of installers/uninstallers that are indirectly the fault of the difficulty of the task, and others the fault of the complex process that nevertheless has failed to keep up with some of the complexities of the underlying platform:

• Lots of installers out there tend to be about as responsible as Nathan Scott's mom when she's bombed;
• Even more uninstallers out there tend to be worse;
• Since install and uninstall have detectable consequences, forcing this extra step is a little unfair;
• Starting in Vista, the work to mitigate shatter attacks keeps a process from communicating with elevated processes -- meaning the more important an application is, the less likely it is to get the message;
• The message does not go outside the session, meaning any other session remains unaware of the change -- woe to those who make these changes on a Terminal Server or the world of Fast User Switching!

You get the idea.

The design here is quite sensible for a bygone era, but to be honest something better might really be considered.

But I digress.

The point is that even a "well-behaved application" that sends the message and a "well-behaved application" that receive it might not ever be able to communicate well enough to be told that something is up.

Despite the fact that the contents of a directory and the contents of a registry key were altered.

So in the end, the rules (if you work within the framework above) end up being quite simple:

1. If the font is there and the new one is determined to be the same font but of a lower or equal version , then you do not have to do anything;
2. If the font was not there, then you can add it, add the registry information, and send the message; everything is as good as it can be, but other sessions and elevated processes might have to wait until next time;
3. If the font is there and the new one is determined to be the same font but of a greater version, then you have to do all of the install work but it is much safer to require the reboot and do the actual file replacement at boot time.

So pretty much the only time that you never have to do anything is when the font in question is already installed. when you didn't have to do anything.

Yeesh. Talk about over-engineered! :-)

In the next part of the series we'll talk about the mechanics of the install and uninstall that must happen....

And in a later blog I will talk about my opinion of regular reader John Cowan's suggested "solution", here. :-)

This blog brought to you by ƒ (U+0192, aka LATIN SMALL LETTER F WITH HOOK)

John Cowan on 8 Jul 2008 2:13 PM:

Michael S. Kaplan on 8 Jul 2008 4:28 PM:

referenced by

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