Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

The dialog manager, part 2: Creating the frame window

The Old New Thing — Wed, 30 Mar 2005 15:57:00 GMT

Walk the template header and do what it says.

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

jbn — Wed, 09 Feb 2005 22:09:00 GMT

I think gnu emacs does that too, with is why there's a silly limit on the size of editable files having to fit on 26 bits or something (you could find the exact number by looking at the source code).

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Steve P — Tue, 08 Feb 2005 21:06:00 GMT

Sounds reasonable to me.

If you're supposedly supporting an older operating system, then you should be making sure your code actually works on said operating system.

The older OS has no idea how important those random bits might be, so all it can (and should) do is throw an error.

Think of it like a function that is only available in later versions. Should the older OS simply ignore it because it isn't available? :)

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Jonathan — Tue, 08 Feb 2005 17:00:00 GMT

>Cooney: I'd probably require that any undefined bits be zero. After seeing Raymond's experience with the sloppy version and seeing the intel manuals that demand a zero in all reserved fields, I can't really see doing it any other way.

But then you've lost the ability to cleanly handle future flags.
The reason Kristoffer Henriksson suggested that the OS ignore unknown flags was so that programs written for later OSs (say Win2K) could set those flags without it affecting their ability to run on an older OS (say NT4) which didn't handle the flag.

If we follow your suggestion to require unused flags be set to zero, we are back to not being able to pass flags to NT4 that might be valid on Win2k, but not valid on NT4. I assume that would require the API to return an error if it saw a non-zero value for a flag it didn't support, since if the API didn't enforce the requirement, we are back to the problem Raymond listed with Apps passing random flags because they aren't forced to do otherwise.

If the OS threw an error on an unknown flag it would require all apps to choose to:
1) never select flags older OSs didn't support,
2) select new flags knowing it would prevent the program from running on older OSs,
3) add code to detect which OS you were on in order to choose which flags to throw.

Handling forward and backward compatibility is just a tricky thing to do...

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Larry Osterman — Tue, 08 Feb 2005 14:18:00 GMT

Jonathan: IIRC, the reason the pointer to the malloc was removed was because it wasn't possible to set it. Originally, there was a CoSetMalloc to go along with CoGetMalloc - the idea was that you could change the allocator used by COM to suit the needs of your application.

Unfortunately, there were a bunch of apps/shell extensions that relied on the fact that the shell used LocalAlloc() for it's implementation of IMalloc and they called LocalFree on the memory (instead of calling CoGetMalloc and using that value).

And when someone tried to replace the default allocator, blam!

So the parameter was pulled to ensure that apps couldn't misbehave in that way.

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Norman Diamond — Tue, 08 Feb 2005 09:06:00 GMT

> We learned this lesson the hard way - many
> apps passed uninitialzed garbage as flags
> and got away with it because the flags were
> ignored. Along comes the next version of
> Windows that *gives the flag meaning*, and
> now the app crashes.

That is true. That also explains why Windows XP checks some supposedly ignored structure members and returns errors if those members are not zero -- later versions of Windows might use them for something. Now if MSDN would say that those members should be zero instead of saying that those members are ignored, programmers would understand faster why they were getting error returns.

Sorry I don't remember which APIs I was getting hit by because it was about two years ago. Though I have a feeling that it would be productive to search for the word "ignore[d]" in the Windows API section of MSDN.

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Anonymous Coward — Tue, 08 Feb 2005 05:26:00 GMT

Apple had some fun when earlier 68k chips ignored upper bits in addresses since they couldn't address that much memory. Various developers used to use the upper bits as a type field, such as specifying if the remaining bits were a point or an integer. Then along came a new chip that could address the memory and paid attention to the upper bits and all sorts of programs crashed so they had to introduce various compatibility hacks. (Somewhere inside Apple is Raymond's counterpart :-)

This kind of "trick" is very common for Lisp environments. Nowadays you can pull the same trick but using the lower bits instead. For example you know memory allocations are going to be 4 byte aligned so you can use the lower 2 bits to indicate the type of whatever is pointed to. Remember to set the bits to zero when doing the memory access.

Sort Order....

Jim — Mon, 07 Feb 2005 23:39:00 GMT

http://support.microsoft.com/default.aspx?scid=kb;en-us;319827

Sort order...

Jonathan Allen — Mon, 07 Feb 2005 19:36:00 GMT

0.1-...
0.2-...
0.15-...

Looks fine to me. Of course, I'm used to seeing things like "Section 0, Paragragh 15" or "verion 0, subverion 15" being written as 0.15. I don't I've ever used decimal numbers in a filename.

re: Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT?

Cooney — Mon, 07 Feb 2005 19:27:00 GMT

> Why wasn't the rule from the beginning that unknown flag bits being set were silently ignored? If you were designing the API from scratch today, would you do it that way -- is it just something that was not thought of at the time -- or is there a reason for making undefined bits being set an error?

I'd probably require that any undefined bits be zero. After seeing Raymond's experience with the sloppy version and seeing the intel manuals that demand a zero in all reserved fields, I can't really see doing it any other way.