Once you invent a new flag you can start using it to fix errors of the past without breaking backwards compatibility.
One of the errors of the past was that property sheet page dimensions were taken relative to the “MS Sans Serif” font, even if the page used some other font.
DLG_SAMPLE DIALOGEX 32, 32, 212, 188 CAPTION "Caption" FONT "Lucida Sans Unicode" ...
This sample dialog template says that it is 212dlu wide and 188dlu tall. If the dialog template were used for a standalone dialog, those DLU values would be calculated relative to the font on the dialog, namely Lucida Sans Unicode.
However, if the dialog template were used for a property sheet page, earlier versions of Windows would interpret the values 212 and 188 relative to the font of the property sheet frame (usually MS Sans Serif), not relative to the font associated with the page itself. Many people worked around this problem by giving their pages pre-adjusted sizes, so that when Windows measured the dialog against MS Sans Serif, the adjustments cancelled out.
In other words, suppose that Lucida Sans Unicode is 25% wider
than MS Sans Serif. (I’m just making up numbers.)
Then to get a 212dlu-wide dialog relative to Lucida Sans Unicode,
the dialog template would specify a width of
Since people were now relying on this behavior, it couldn’t be changed. If you went in and “fixed” it, all those pre-adjusted dialogs would come out at the wrong size.
Ah, but now there is a new flag,
Starting in Windows 2000, if you specify the
DS_SHELLFONT dialog style for your
dialog template, then the dialog dimensions are taken relative to
the font you specified in your template
(which is probably what you wanted)
rather than relative to the property sheet frame font.
If you leave off the flag (as older programs will), then the
property sheet measurement code remains bug-for-bug compatible
with previous versions.