About the Fonts folder in Windows, Part 1 (aka What are we talking about?)
by Michael S. Kaplan, published on 2006/06/25 13:32 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/25/646701.aspx
When I first mentioned yesterday that I was going to be blathering about the Fonts folder for a bit, regular reader Rosyna commented:
It'll be interesting. I know virtually nothing about the Windows fonts folder. Many people hate the Mac OS X's multiple fonts folders (System, "Local", Network, User, and Classic). It becomes hard to deal with everything has having multiple duplicate fonts is very possible and almost the case on every single Mac OS X box.
The good thing though is that any font dragged into a Mac OS X font folder is available to all applications immediately.
I suddenly realized I wanted to start things a bit differently than what I was originally going to do.
(For those of you who hate the "Add Font..." dialog, wait for the next post -- I'll be getting to that shortly!)
So, we'll start with simple question: What the hell is the Fonts folder?
The simple answer? It is a Shell namespace extension that causes any display of %WINDIR%\Fonts in the Windows Explorer to have a special view where typical filesystems actions in Explorer such as copy, move, and delete have special handlers.
It is by no means the only way to get fonts ontop Windows, though.
If you look at the Platfrom SDK documentation for the AddFontResource function:
The AddFontResource function adds the font resource from the specified file to the system font table. The font can subsequently be used for text output by any application.
So all you have to do to get a font available to everyone is call this function!
Of course there are things to keep in mind in the remarks section:
Any application that adds or removes fonts from the system font table should notify other windows of the change by sending a WM_FONTCHANGE message to all top-level windows in the operating system. The application should send this message by calling the SendMessage function and setting the hwnd parameter to HWND_BROADCAST.
When an application no longer needs a font resource that it loaded by calling the AddFontResource function, it must remove that resource by calling the RemoveFontResource function.
This function installs the font only for the current session. When the system restarts, the font will not be present. To have the font installed even after restarting the system, the font must be listed in the registry.
Wow, those three paragraphs are like three strong drinks, aren't they? They tell you:
- you ought to tell everyone else if you added a font via the WM_FONTCHANGE message (seems a bit like this issue with SetLocaleInfo, doesn't it?)
- Clean up after yourself when you are done via a RemoveFontResource call (just like mom said -- clean it up when you are done with it!)
- Don't expect it to survive a reboot if you don't do some more work (though it does not tell you precisely what that work is!)
That work in the third bullet point is to add the font's name and filename to the registry in the following subkey:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
And although most of the files listed there will have no path (in which case %WINDIR%\Fonts is assumed), this is not a requirement.
All that our Shell Extension Fonts folder does (well, it does more than this, but bear with me for a bit) is wrap all this up. In fact, it is GDI that makes an AddFontResource call on every font in that registry key when it does its own initialization, and it is the folder's handling code that adds and removes fonts from the list in the registry.
But all of the hints are here -- anyone who hates the Shell Fonts folder interface to these things can build their own code. They can even make it a Shell Extension wherever they like, and put in all the same kind of handling code, or better.
Now the Shell code does a bit more here -- for example you can install a font programatically by opening the Fonts folder in Explorer and simply copying the font file to the folder (more on why this is not the best way to do it later!). It also gives some unique views of fonts that are in the folder (more on these later, too), and it completely hides hidden files even if you have the "Hide protected operating system files" setting unchecked (which you would do as well if you saw what was in there!). And lots of other little things like that.
But clearly the widespread belief that fonts need to be in the Fonts folder (which requires admin privileges to write to) is a myth. The only action that truly requires admin-style privileges is writing to that registry key (since it is under HKLM), but just about everything else is a bit more open to people.
The myth is a tribute to What it means to be in the default install, and how hard it is to get noticed as a feature if the feature is not available in some default, built-in fashion.
Imagine for example if the Fonts folder was actually further virtualized into supporting both the current folder in %WINDIR%\Fonts and some kind of per-user folder like under %USERPROFILE%\Fonts or something -- so that anyone could install fonts and you would either have the "just me" or "all users" choice, or if you lacked permissions it would be a "just me" install automatically.
For now one will have to keep imagining (there is no such feature in Vista, for example).
But I will be talking more about the Fonts folder in future posts, specifically to cover:
- The Add Fonts dialog
- Various views of fonts located in the folder
- More on that registry key GDI uses
- Changes to the Fonts folder in Vista
- and more!
So stay tuned, there will be much more for font users, typographers, people who find my posts witty, Microsoft bashers, basically just about everyone....
This post brought to you by F (U+0046, a.k.a. LATIN CAPITAL LETTER F)
# Ben Cooke on 25 Jun 2006 2:54 PM:
Hmm. That answers my question quite nicely.
However, it is a bit vague on one point: the documentation you've quoted refers to "The current session" but then goes on to say "when the system restarts". My idea of "the current session" is the period between someone logging on and someone logging off, but from the mention of restarting I guess this really means that this setting lasts until the machine is shut down.
This then leads me to wonder whether a non-admin user is able to write/run an app that calls AddFontResource and have that font available to all users until the system is rebooted. In particular, can I register a font called Tahoma which has stupid/offensive glyphs and have apps use that instead? Or does Windows protect existing named fonts from being masked by new registrations?
(I notice that AddFontResourceEx can do what I would have expected AddFontResource to do -- it can register a font privately for use only by that application. Strangely, it also seems to have an option to bar all apps from "enumerating" the font, which I guess means it won't show up in the font list? I'm not seeing anywhere an option to register a font only for the current login session.
Of course, I could try this stuff for myself. When I get a moment, I may write a little utility which can just add/remove arbitrary font files from disk, and which can be added to the list of actions on *.ttf files for quick, temporary installation of fonts.
# Michael S. Kaplan on 25 Jun 2006 4:16 PM:
Hi Ben --
Actually, that "restart" text is from an older time when a restart was how the session was reset.
In Vista, it is always the logon/logoff; in prior versions, it is just a new WindowStation, which means for example a TS logon will get the latest list rather than the one already there.
AddFontResource cannot be used for provate fonts -- you have to use AddFontResourceEx.... :-)
Other questions you raised including consequences of that last point!) will be covered in future posts.
# Rosyna on 25 Jun 2006 4:22 PM:
Very informative.
It's interesting that AddFontResoure/AddFontResourceEx doesn't automatically notify clients that the font list has changed. After all, by default, people are extremely lazy and when it comes to doing something, most people take the easiest way out. If you look at ATSActivateFontFromFileSpecification (
http://developer.apple.com/documentation/Carbon/Reference/ATS/Reference/reference.html#//apple_ref/doc/c_ref/ATSFontActivateFromFileSpecification) it has the option for a flag, kATSOptionFlagsDoNotNotify, which will supress the notification. I use this when I just need to get a string rendered in an image since I immediately deactivate the font after rendering. It is kind of weird that I have to use the same flags and everything when using RemoveFontResourceEx.
What's really odd is this comment: "To add a font whose information comes from several resource files, point lpszFileName to a string with the file names separated by a | --for example, abcxxxxx.pfm | abcxxxxx.pfb."
I'm not sure how I feel about shell folders personally. I think they can be useful but also make the operation significantly less "consistent" with the rest of the file browser UI.
Hmm, I wonder which group I'm under.
# Anonymous on 25 Jun 2006 6:19 PM:
"for example you can install a font programatically by opening the Fonts folder in Explorer and simply copying the font file to the folder"
That 'programatically' (sic) should be 'manually', right? :)
# Michael S. Kaplan on 25 Jun 2006 7:49 PM:
I actually meant programatically -- manually copying would be just like drag&drop in Explorer, but I was talking about how the folder, when opened, would have knowledge of things you did outisde of the Shell, such as programmatic copies....
Centaur on 26 Jun 2006 10:24 AM:
> and it completely hides hidden files even if you have the "Hide
> protected operating system files" setting unchecked (which you
> would do as well if you saw what was in there!)
No I wouldn’t. The user has requested that hidden files be visible to him, and his/her orders are not to be questioned. After all, none of these files are too special — there are the files representing bitmap fonts Fixedsys, Terminal, System, Courier, MS Serif, MS Sans Serif, Small Fonts, and Symbol; the Marlett truetype font; and the desktop.ini file which is responsible for all this “magic”. An experienced user deserves to see them.
# Michael S. Kaplan on 26 Jun 2006 2:24 PM:
Cenatur,
The list there is a conceptual list of fonts -- thus even if there are separate files for the various code page and size varieties of the bitmap fonts or marlett, showing them in the Fonts folder would not actually help anyone (since the other versions are not USED in any way.
What precisely is the functionalitgy you believe is missing?
# Mike on 26 Jun 2006 2:42 PM:
"session" has a specific meaning in Windowsese. Nevertheless it's a bit hard to pin down. Its mostly refers to a logged-in user. So if both Alice and Bob are logged in they are in different sessions. If Alice calls AddFontResource she will see the new font but Bob won't. The whole concept gets a bit hazy because logging out and back in again does not necessarily create a new session on XP. For Vista you always get a fresh session though.
To be overly pedantic and start moving into the realm of irrelevent implementation details GDI does not read the info in the Fonts key in the registry. USER does that and (essentially) calls AddFontResource on your behalf at session startup. So to return to Alice & Bob, if Alice registers the font in the registry Bob still won't see it, but once he relogs it'll appear (assuming his session got recreated). Interestingly, this happens even if Alice does *not* call AddFontResource. This seperation between registering font and actually telling GDI to start using it can be confusing at times...
# Adam on 27 Jun 2006 11:55 AM:
I don't know about "deserves", but as an experienced user who's checked the "Show all hidden files" box, if I browse to a directory in my file manager, I want to see the files in that directory.
A file manager that does not do that one simple thing - the only thing it is meant to do - is broken.
Look, if I really want to, I can just go to a command prompt, 'cd' to the correct directory and 'dir' it. But it's a pain in the behind, and the point of a GUI is to make things like browsing your filesystem *simpler*. Now you're just making it harder.
Why do I want to look there? Maybe I'm just curious. Maybe it's because I want to figure out how Windows does things. Maybe I want to see the last-modified timestamp on a font file because some hypothetical virus can exploit a hypothetical recently-found buffer overrun in the font-rendering hinting parser (?) and hides itself in a .ttf file.
It doesn't matter *why*. On my PC, that's *my* concern. But if I've checked the "show me all hidden files" box, then that's because *I want it to show me all the hidden files*.
# Michael S. Kaplan on 27 Jun 2006 12:46 PM:
Hi Adam,
Well, that's just it -- a Shell extension is not just a file list. It is a virtualized view of the folder -- note how you do not get file names or extensions, either?
Explorer is a file manager that supports virtualized views, and in many cases uses virtualized folders. Have you looked at "Temporary Internet Files" lately? :-)
In any case, this particular folder has been around with the very functionality you are against for the last 10+ years and the last 10 versions of Windows. Has it truly made you want to uninstall the OS? I hope not!
# Adam on 28 Jun 2006 4:26 AM:
Michael: Sorry to disappoint you, but I'm a Debian user these days :-0
And when I use Windows, I generally turn off all the shell extensions that I can. I hate them.
Look, if I go to the Control Panel and select "fonts", then, sure, I expect to see a list of logical fonts installed on the system. Probably some toolbar/menu items for "install fonts", "remove fonts", etc... (if I have authorisation to do those actions). I don't care about the files used, or even if Explorer is used to display the list of fonts. But if navigate to a particular directory in a file manager, that's because I want to know what files are in it!
(Sorry, this is starting to get really OT now, but I can't stop.... :)
Same with temp internet files. If there's an IE button "show cache" then fine - show me whatever you think is appropriate. If I browse to the relevant directory in the filesystem with a file manager, show me what's on the filesystem.
Ditto Recycle Bin. If I hit the "recycle bin" button on my desktop, launch whatever application is appropriate (including Explorer with some extenstion to give me "undelete" options or whatever). If I browse the filesystem to get there, *I want to know what's on the filesystem.*
I just want Windows to stop thinking it knows better than me what I actually want to do, because it keeps getting it wrong! If it can't "Do What I Mean" (DWIM) there should just be a button to make it "Do What I Tell You, No Matter How Crazy It Sounds" (priveliges permitting).
# Michael S. Kaplan on 28 Jun 2006 7:25 AM:
Michael: Sorry to disappoint you, but I'm a Debian user these days :-0
Ah, then the command line should be something familiar....
(Sorry, couldn't resist!)
# Adam on 28 Jun 2006 6:23 PM:
:-)
# John Elliott on 3 Jul 2006 8:57 AM:
@Adam: In the good old days, if you suspected Explorer was lying to you then you could look at the same directory with Winfile. But for some reason Winfile doesn't get distributed with Windows these days.
Centaur on 3 Jul 2006 10:43 AM:
> What precisely is the functionalitgy you believe is missing?
I believe there should be separate views for Control Panel | Fonts and C:\WINDOWS\Fonts (and the same goes for Temporary Internet Files, Recycle Bin and other magical places). Alternatively, there could be a “Show files” link, like in the views for Windows and Program Files directories.
I believe that a file manager must show the file system “as is”, with clear indications when something is not what it seems to be — like ftp servers and archive files. I believe that the decision to hide file extensions by default in Windows 95 was a grave mistake which brought about millions of users who don’t know when it’s safe to open a file that came from an untrusted source. I believe users should strive to understand their computers better, and introducing magic makes it harder.
This is one of the reasons I use an alternative file manager and only turn to Explorer for very specific needs.
# Ricardo Cancho (Spain) on 21 Jan 2008 1:24 PM:
Hi.
My experience: RemoveFontResource() works only for font files instaled by the same program that performed AddFontResource(), and in the same session. If you'll try to use RemoveFontResource to go away an arbitrary font manually installed in C:\Windows\Fonts or installed with your own program, but after a rebooot, RemoveFontResource fails (the .ttf file is locked). So you can't write a full "Font Manager", as I tried myself.
The only way I found was: a) open C:\Windows\Font through with the explorer, b) use SendKeys to locate the font face plus style in the list c) use SendKeys {DEL} to delete (& unregister) the file, and d) use SendKeys %{F4} to close the explorer's window.
Believe me, the result isn't a commercial piece of software at all.
Yours.
Ricardo Cancho.
kiers on 24 Nov 2008 11:51 PM:
hmm...interesting. I understand what u said about "shell namespace extension" and how for THIS particular folder there are special handlers for copy cut paste etc.
My problem: can I "move" via a junction poiint (parse point under NTFS) the c:\windows\fonts folder to D:\fonts for space saving reasons?
I copied all fonts under teh c: folder and pasted them to D: folder. however I noted the C; folder had 231 fonts inside, however right clicking on the c: fonts folder itself showed "363 files" !! at 436MB.
whereas the pasted fonts folder in D: drive ONLY shows 231 "files" at 312MB!!!
question: what's missing in the d: folder that the c: fonts folder has??? i don't want to empty the c: folder and apply the parsepoint till I am reconciled between c: and d: !!!
any suggestions? am I kosher?
Michael S. Kaplan on 25 Nov 2008 9:56 PM:
Many of the font files are marked system and hidden, it looks like you did not move those?
ldandmbbrown on 23 Feb 2010 9:15 PM:
Michael, I read your blog About the Fonts folder in Windows, Part 1 (aka what are we talking about?), Your blog About the Fonts folder in Windows, Part 2 (aka Adding Fonts), the commentaries left about the posts. Followed the embedded links within your post and still have come away with the feeling that getting fonts into the Windows\Font folder is easy...Its getting them out that is somewhat hopeless by any other means than through the provided UI.
I manage around 1000 devices both MAC and PC's running Mac OS 10.x through Windows XP, Vista and now Windows 7. The problem that we fight on a daily basis is maintaining the bare minimum amount of fonts on each platform (~66 to be exact) hoping not to interfere with the fonts supplied to us by our customers (Which by the way I suspect are creeping into the Windows\Font folder somehow).
Three (3) to four (4) weeks ago, I set out on a mission to make maintaining our fonts a more efficient and less resource intensive endeavor. Here I am 3 - 4 weeks later posting a comment to an article you posted 4 years ago and still each avenue I have went down has brought me back to the same place (want to delete, use the UI...such a wonderful customer experience)....Only way to bust the fonts out of captivity once placed in the Windows\font folder is to manually rip them out. This seems very counter productive to me in an age when technology has exploded into the hands of almost everyone.
The ramifications of fonts just showing up and being able to be installed with the introduction of @Font-face command. This command used poorly by anyone wanting to use cute fonts in a webpage or document, coupled with an OS willingly accepting them with open arms is alarming (or should be). The ramification of the installation of fonts without anyone’s knowledge exposes companies to all sorts of ethical if not financial risk.
If the owners of the Windows\Font folder as you so brilliantly implied are not concerned with the introduction of unsolicited, unwanted files, why would they be so protective of not allowing authorized users of being able to just as easily remove them? I would be happy to expound upon this further if you have any interest, even if you want to take them into another discussion venue. Look forwards to hearing from you soon.
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
go to newer or older post, or back to index or month or day