3 ms·
I get why you say they're evil, but their existence meant that moving from Win16 to Win32 to Win64 with minimal code changes was actually feasible without major
by gecko 11y ago
I get why you say they're evil, but their existence meant that moving from Win16 to Win32 to Win64 with minimal code changes was actually feasible without major rewrites. If those had instead been e.g. "static pascal MCIWndProc16(unsigned, unsigned, unsigned, long)", then you'd have had issues with some of those transitions. (In fact, you kind of did going from 32 to 64 bit, which is why "long" in Win64 is still 32 bits.)
- pavlov 11y agoYeah, they were useful all right! I was just doing some petty complaining about why they chose that particular style. Everybody else uses either camelcase or snakecase for C types, so a type used to transmit information about zombie bites would be something like ZombieBiteDescriptorRef or zombie_bite_desc_t ... But on Windows, the type would be ZOMBIEBITEDESCRIPTOR. And typically a variable's name would be prefixed with the type, Hungarian notation style: ZOMBIEBITEDESCRIPTOR *pzbdFreshBite = WDGetLatestBiteEx(0, 0, NULL, NULL, 0); ... It just looks so bad when you're used to the other C styles.
- wmil 11y agoAlthough types in _t are supposed to be reserved for future POSIX / compiler use.
- cmrdporcupine 11y agoInterestingly I found that the (now GPL'd) GEM sources from Digital Research (windowing system from the 80s for x86 and 68k) also follows this capitalized-typedef convention. It's all WORD/LONG/UWORD. They even typedef void to VOID. It's excruciating on my eyes.
- mfincham 11y agoCould you link the GEM sources? I used GEM a long time ago and would love to have a look.
- cmrdporcupine 11y agoThe DR GEM sources are here: http://www.deltasoft.com/downloads-gemworld.htm http://www.deltasoft.com/downloads-gemworld.htm The actively developed fork of it for the Atari ST and emulators is here: http://emutos.sourceforge.net/en/ http://emutos.sourceforge.net/en/