The evolution of dialog templates - 32-bit Classic Templates

re: The evolution of dialog templates - 32-bit Classic Templates

Frederik Slijkerman — Mon, 21 Jun 2004 15:31:00 GMT

What's the reason to pad fields in structures like this to DWORD boundaries? This is always a lot more work to program for -- and test the special cases that require padding. It's especially irritating with DIB scan lines.

The only reason I can think of is that it is marginally faster. Sounds like a good example of premature optimization, or am I mistaken?

re: The evolution of dialog templates - 32-bit Classic Templates

Raymond Chen — Mon, 21 Jun 2004 15:38:00 GMT

It's not an optimization. It's a necessity.

The overwhelming dominance of the x86 architecture in the world of Win32 makes people think that the way the x86 does things is normal, when in reality the x86 is the weirdo.

PPC, MIPS, Alpha AXP, ia64 all crash if you access unaligned data. x86 is the weirdo: It permits unaligned data access.

re: The evolution of dialog templates - 32-bit Classic Templates

Cooney — Mon, 21 Jun 2004 15:39:00 GMT

It could be a remnant of the Alpha/MIPS NT effort - accessing unaligned data caused a segfault instead of simply being slow. Alternate theory: the structs used to hold this data are compiled with dword alignment and loaded directly from a file, so unaligned data is misinterpreted.

re: The evolution of dialog templates - 32-bit Classic Templates

JamKnight — Mon, 21 Jun 2004 19:07:00 GMT

I don't understand why you would even want to have unaligned data access. In my opinion it only makes things more complicated.

Can anyone point to a case where it is better/cleaner than using aligned?

re: The evolution of dialog templates - 32-bit Classic Templates

Cooney — Mon, 21 Jun 2004 20:32:00 GMT

If space is really tight, as it was way back when, then every byte counts. Otherwise, go right a head and align your data - I do.

re: The evolution of dialog templates - 32-bit Classic Templates

asdf — Mon, 21 Jun 2004 21:21:00 GMT

It makes your code cleaner if you don't have to worry about unaligned stuff. For the most part this is transparent to you but there are some areas where it isn't. You pay for unaligned memory access in higher cycle counts, not having atomic operations, and segfaults in non x86 processors. Win64 supports bad code with SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT) or the __unaligned qualifier (how thoughtful of them).

re: The evolution of dialog templates - 32-bit Classic Templates

Simon Cooke [exMSFT] — Mon, 21 Jun 2004 22:47:00 GMT

JamKnight:

Unaligned is better than aligned when you're dealing with different CPUs that have different alignment requirements from the get go.

(eg. a CPU that required 16bit alignment vs. one that requires 64bit alignment... but you design everything before the 64bit one is on the horizon).

But yeah, it's a real edge case.

The evolution of dialog templates - 32-bit Classic Templates (from: Raymond Chen)

Test .Text Blog — Tue, 22 Jun 2004 03:35:00 GMT

re: The evolution of dialog templates - 32-bit Classic Templates

doynax — Tue, 22 Jun 2004 01:26:00 GMT

> (eg. a CPU that required 16bit alignment vs. one that requires 64bit alignment... but you design everything before the 64bit one is on the horizon).
This doesn't have to be a problem, just align everything according to the largest datatype.

re: The evolution of dialog templates - 32-bit Classic Templates

Waleri — Tue, 22 Jun 2004 05:35:00 GMT

Unfortunatly, one cannot use control's text ordinal to display text - it works for icon and bitmaps only. pity

re: The evolution of dialog templates - 32-bit Classic Templates

asdf — Tue, 22 Jun 2004 06:57:00 GMT

Raymond: the x, y, cx, cy fields should be signed and there is no 0xFF 0x00 to specify ordinals, it's all 0xFFFF.

re: The evolution of dialog templates - 32-bit Classic Templates

Holger Dors — Tue, 22 Jun 2004 07:22:00 GMT

You write "strings got changed from ANSI to Unicode": what kind of encoding is used for Unicode? Is it UCS-2 or UTF-16?

I never have been able to find the answer on this...

re: The evolution of dialog templates - 32-bit Classic Templates

Frederik Slijkerman — Tue, 22 Jun 2004 09:05:00 GMT

For example, with 24-bit DIBs it is a pain in the behind because you can't write

lpPixel = lpData + 3 * (x + y * width);

but the tedious:

byteWidth = (width * 3 + 3) & 0xFFFFFFFC;
lpPixel = lpData + 3 * x + y * byteWidth;

re: The evolution of dialog templates - 32-bit Classic Templates

Raymond Chen — Tue, 22 Jun 2004 14:24:00 GMT

Holger: What's the difference between UCS-2 and UTF-16? As far as I can tell they both use surrogate pairs.

re: The evolution of dialog templates - 32-bit Classic Templates

Holger Dors — Tue, 22 Jun 2004 14:49:00 GMT

@Raymond: no, UCS-2 cannot use surrogate pairs and is limit to codepoints up tp $FFFF. AFAIK that was the reason why UTF-16 was created in the first place.

re: The evolution of dialog templates - 32-bit Classic Templates

Raymond Chen — Tue, 22 Jun 2004 14:58:00 GMT

I have no idea. But instead of just saying "Gosh I will never know", I decided to search on google for "site:msdn.microsoft.com surrogate pairs" and it found this page
http://msdn.microsoft.com/library/en-us/intl/unicode_192r.asp . Please, people, don't be lazy. Do some searching yourself before asking questions. I have better things to do with my time.

re: The evolution of dialog templates - 32-bit Classic Templates

Holger Dors — Tue, 22 Jun 2004 15:19:00 GMT

I'm sorry to have wasted your time, Raymond, but I really did search earlier for an answer to this. It just never occured to me to search for "surrogate pairs".

But finally, thanks to you, I have an answer: starting with W2K UTF-16 (and therefore surrogate pairs) are supported, up until then it was UCS-2.

Many thanks for your help!

re: The evolution of dialog templates - 32-bit Classic Templates

Marcdlg — Wed, 23 Jun 2004 00:51:00 GMT

> PPC, MIPS, Alpha AXP, ia64 all crash if you access unaligned data. x86 is the weirdo: It permits unaligned data access.

Raymond,

I cannot resist the pedantic urge to correct this.

-AFAIK there are no PPC CPUs which do not support unaligned integer data access in hardware.

-MIPS generate a precise exception that allows the kernel to emulate in software the unaligned access. (Granted this is dead slow. And a more than sufficient reason to avoid unaligned data at all cost. (e.g. for a packed struct a MIPS compiler will generate 4 load byte instructions to access a dword)

-Alpha probably does software emulation too, since it is frequently impossible to statically determine if an access is aligned or not.

And having worked on optimizing network stack code for MIPS, x86 is a smart "weirdo".

re: The evolution of dialog templates - 32-bit Classic Templates

Ben Hutchings — Wed, 23 Jun 2004 17:41:00 GMT

Marcdlg: Support for misaligned access is an optional feature of the PowerPC architecture, at least in little-endian mode (which is what Windows uses). The early PowerPCs (601, 603, 604) raise an exception for it.

re: The evolution of dialog templates - 32-bit Classic Templates

Raymond Chen — Fri, 16 Jul 2004 18:58:00 GMT

asdf: 0xFF 0xFF and 0xFF 0x00 are both valid and mean different things! I was not sufficient clear.

0xFF 0xFF means "What comes next is a special class ordinal (0x80 = button, etc.)".

0xFF 0x00 means "What comes next is a class ordinal (atom)."

The evolution of dialog templates - Summary

The Old New Thing — Sat, 23 Jul 2005 04:13:30 GMT

Trying to capture the changes in a table.