What’s the deal with the DS_SHELLFONT flag?

Date:February 4, 2005 / year-entry #31
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20050204-00/?p=36523
Comments:    34
Summary:It indicates that you want the Windows 2000 default shell font. But that doesn't mean that you're going to get it. In order to indicate that you would like the "Windows 2000" look for your dialog, you have to do three things and hope for a fourth: Use a DIALOGEX template instead of a DIALOG template. Set...

It indicates that you want the Windows 2000 default shell font. But that doesn't mean that you're going to get it.

In order to indicate that you would like the "Windows 2000" look for your dialog, you have to do three things and hope for a fourth:

  1. Use a DIALOGEX template instead of a DIALOG template.
  2. Set the DS_SHELLFONT flag in your dialog styles.
  3. Set the dialog font to "MS Shell Dlg".
  4. Hope that you're running on Windows 2000 or later on a system that has the new Windows 2000 dialog font enabled.

If all four conditions are satisfied, then your dialog gets the "Windows 2000" look.

If any condition fails, then you get the "classic" dialog font. Note that the fourth condition is not within your program's control. Consequently, you have to make sure your dialog looks good in both the "classic" dialog font and the new one.

For property sheet pages, things are more complicated.

It would be visually jarring for there to be a mix of fonts on a property sheet. You wouldn't want the "Advanced" button to be in MS Sans Serif but the "Apply" button in Tahoma. To avoid this problem, the property sheet manager looks at all the pages in the property sheet. If they are all using the "Windows 2000" look, then the property sheet uses the "Windows 2000" look also. But if there is even a single page that does not use the "Windows 2000" look, then the property sheet reverts to the "classic" look and also converts all the "Windows 2000"-look pages to "classic" look.

This way, all the pages in the property sheet have the "classic" look instead of having a mishmash of some pages with the classic look and some with the Windows 2000 look.

That's why you will occasionally find that a shell property sheet has reverted to the "classic" look. Some shell extension infected the property sheet with a page that does not have the "Windows 2000" look, and for the sake of visual consistency, the property sheet manager set all the pages on the property sheet to "classic" look.

This is another reason it is important that you test your property sheet pages both with the "Windows 2000" look and the "classic" look. If your property sheet page ends up sharing a property sheet with a non-"Windows 2000"-look page, your page is going to be reverted to "classic" look.

Comments (34)
  1. Jonathan says:

    Now if only we could get all property sheets to use visual styles… The all-too-frequent mixing of themed and non-themed backgrounds is definitely a visually jarring experience.

  2. fckgw says:

    What’s the difference between ‘MS Sans Serif’ and ‘Microsoft Sans Serif’?

  3. Waleri says:

    And which font will be used in a dialog, if shell font is NOT granted?

  4. Raymond Chen says:

    Whatever font you would have gotten if you hadn’t said DS_SHELLFONT.

  5. Waleri says:

    What is the purpose of DS_SHELLFONT then?

    I mean, using "MS Shell Dlg" tell the system to map the font using current locale and other settings, so font is substituted anyway. Acording to MSDN, DS_SHELLFONT allows chaging font’s size/weight, but same can be done via DS_SETFONT. Isn’t this like using two flags for same thing, or DS_SHELLFONT does something extra?

  6. Raymond Chen says:

    Please read the first sentence of the article.

  7. DrPizza says:

    I have no idea what this is all about. I wish there were some pictures to show what you’re talking about.

  8. Waleri says:

    Yes, I did read it. What I try to figure is why both DS_SHELLFONT and "MS Shell Dlg" should be used to indicate shell font. DS_SHELLFONT simple affects font mapper behave. I simply try to figure why it is impossible to use shell font OR user-defined font, or in other words, why DS_SHELLFONT works ONLY with "MS Shell Dlg".

  9. Raymond Chen says:

    "Why both DS_SHELLFONT and ‘MS Shell Dlg’ should be used to indicate shell font."

    Feel free to propose an alternative algorithm that remains backwards compatible with NT 4.

  10. Tom says:

    Hm interesting article, that saves me changing the fonts with WM_SETFONT for my controls to Tahoma if the font is present.

    Is there a way to determine the default shell font in Win 2000/XP?

  11. David Candy says:

    Why is it always 8 pt (2.82 mm). I have to edit the dlg template resource in programs like Character Map and Calculator to be able to see it. At 12 pt I can see the characters in character map but the status bar is off screen.

  12. Jonathan says:

    I went back and was fixing a shell extension of mine to use this, and came across what seems like an additional requirement: DS_3DLOOK. Without it, I was getting MS Sans Serif; with it, I got Tahoma.

  13. Tom says:

    Jonathan: actually it works without explicitly specifying DS_3DLOOK. Are you sure you’re using DIALOGEX?

  14. Jerry Pisk says:

    Now if only Visual Studio (version 6) actually allowed you to specify "MS Shell Dlg" as the dialog font. It always replaces it with whatever its own dialog font is (MS Sans Serif).

  15. Chris says:

    How is "MS Shell Dlg 2" related to this?

  16. Raymond Chen says:

    "MS Shell Dlg 2" is another name for the "Windows 2000 look".

  17. Jonathan says:

    Tom: Yes, I’m using DIALOGEX. But I guess I was wrong after all–I just tried it again (without DS_3DLOOK) and it worked correctly. Could’ve sworn it wasn’t working last night ;-)

  18. Alex Blekhman says:

    Tom wrote:

    "Is there a way to determine the default shell font in Win 2000/XP?"

    1. GetStockObject(SYSTEM_FONT)

    2. GetObject()

  19. A says:
    1. GetStockObject(SYSTEM_FONT)

      That won’t work. As the name implies, SYSTEM_FONT returns the "System" font. (Don’t believe what the SDK docs say.)

      Your best bet is probably to query the font of an existing DS_SHELLFONT dialog, otherwise I believe your only option is to query the "MS Shell Dlg 2" value in this registry key:

      HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionFontSubstitutes

  20. Jack Mathews says:

    GetStockObject( DEFAULT_GUI_FONT ) ?

  21. A says:

    GetStockObject( DEFAULT_GUI_FONT ) ?

    …returns Sans Serif.

  22. J. Edward Sanchez says:

    I’ve always used GetStockObject(DEFAULT_GUI_FONT) without any problem.

    I just ran the following quick test on Windows XP SP2:

    1. Call GetStockObject(DEFAULT_GUI_FONT).

    2. Select the returned font handle into a display context.

    3. Call GetTextFace() on the display context to retrieve the name of the selected font.

    According to GetTextFace(), GetStockObject(DEFAULT_GUI_FONT) returns "MS Shell Dlg", which sounds right to me.

    My FontSubstitutes table maps "MS Shell Dlg" to "Myriad Condensed Web Italic", and the actual font used is indeed Myriad Condensed Web Italic. On an uncustomized Windows XP system, it would map to "Tahoma" instead.

  23. J. Edward Sanchez says:

    Correction: On an uncustomized Windows XP system, "MS Shell Dlg" maps to "Microsoft Sans Serif" (a TrueType rendition of the venerable MS Sans Serif). "MS Shell Dlg 2" maps to "Tahoma".

    Going back to Tom’s original question (how to determine the default shell font in Windows 2000/XP): Alex’s answer is correct in the sense that MS Shell Dlg can be called the default shell font. Note that the name "MS Shell Dlg" can actually be used directly in most contexts; Windows will silently do the mapping for you.

    If you’re interested in the "Windows 2000"-look GUI font, you can similarly use the name "MS Shell Dlg 2" directly, and not worry about what font is actually being used behind the scenes.

    However, if you’re looking to determine what actual font "MS Shell Dlg" (or "MS Shell Dlg 2") maps to, I have no better answer than A’s suggestion that you dig into the FontSubstitutes table in the registry. (Querying an existing DS_SHELLFONT dialog would probably just spit back the "MS Shell Dlg" or "MS Shell Dlg 2" name.) However, going into the registry for this is not something I would recommend.

    I hope there’s a clean way to do it.

  24. Raymond Chen says:

    When would a problem need to know what "MS Shell Dlg" maps to? If it wants to use the default shell font then use ‘MS Shell Dlg’ and let the font mapper do its job.

  25. Norman Diamond says:

    2/4/2005 1:52 PM David Candy

    > Why is it always 8 pt (2.82 mm).

    It isn’t.

    2/6/2005 3:56 PM Raymond Chen

    > When would a problem need to know what

    > "MS Shell Dlg" maps to?

    Aha. OK, it might be that no application needs to know what font it gets mapped to, but sometimes applications need to know what size of font gets mapped to. If they assume 8 then you know what happens. (By the way despite recent examples, fortunately this happens a lot less often now than in the past.)

  26. Raymond Chen says:

    There’s a suggestion box – please use it. If you ask here I will probably forget.

  27. Alex Blekhman says:

    J. Edward Sanchez wrote:

    "However, if you’re looking to determine what actual font "MS Shell Dlg" (or "MS Shell Dlg 2") maps to, I have no better answer than A’s suggestion that you dig into the FontSubstitutes table in the registry."

    I tried

    SystemParametersInfo(SPI_GETICONTITLELOGFONT, …) and it seems that this function does perform font mapping. However, I can’t imagine for now why do I want to know that.

  28. Rookie says:

    Can you use, say, FONT 8, "MS Shell Dlg" *without* using DS_SHELLFONT?

    If so what’s the difference between this and declaring it with DS_SHELLFONT?

    If not then that answers Waleri’s question too.

  29. muro says:

    now I modified an existing dialog with the described changes (DIALOGEX, style flags, font). I noticed, CCheckListBox items don’t draw the right edge of the checkbox correctly – is this a known problem? I temporary added a space at the beginning of each string :-(.

    Note: this only happens with some characters at beginning – e.g. ‘a’, it doesn’t happen with ‘1’.

    Any ideas?

  30. J. Edward Sanchez says:

    Rookie: If you don’t use DS_SHELLFONT, you get plain old "MS Shell Dlg", which by default maps to "Microsoft Sans Serif" on Windows XP. If you use DS_SHELLFONT, you get "MS Shell Dlg 2" (the "Windows 2000"-look font), which maps to "Tahoma" by default on Windows XP.

    You might ask: Why not just use "MS Shell Dlg 2" directly? Because older versions of Windows don’t support it. Using "MS Shell Dlg" with a supplementary flag allows for graceful degradation on older versions of Windows.

    For more information, see:


  31. Mark Kramer says:

    This link:


    Says: "specify DS_SHELLFONT with MS Shell Dlg 2 to map to Tahoma."

    Wait, I thought Raymond just said to use DS_SHELLFONT with "MS Shell Dlg" (not 2)?

  32. Raymond Chen says:

    If you say "MS Shell Dlg 2" then you don’t need to say DS_SHELLFONT.

  33. I have talked in this blog about a lot of different kind of font mapping features in various Microsoft…

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index