Hacker News Reader

Comment by pavlov | Hacker News Reader

There's something about Win32's C style that just makes my eyes bleed:

  static LRESULT WINAPI MCIWndProc16(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
  {
    switch (msg)
    {
    case MCIWNDM_SENDSTRINGA:
        lparam = (ULONG_PTR)MapSL(lparam);
        break;

    case MCIWNDM_SETTIMEFORMATA:
        lparam = (ULONG_PTR)MapSL(lparam);
  ...

All caps for typedefs in C is just evil. And this example doesn't even have Hungarian notation.

View on HN

That's not even the full Win32/16 style. That first line should be:

    static LRESULT WINAPI MCIWndProc16(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

And even then MS couldn't decide whether to use message (MSG struct), Msg (SendMessage), uMsg (WindowProc) for the second variable name. Sometimes they would use hwnd as well. I remember it all being very, very confusing when I was learning to program because it was inconsistent in so many ways.

In a semi-related note, Raymond Chen's blog (1) is great for diving into the history of the Windows API and its many quirks and gotchas.

[1] https://blogs.msdn.microsoft.com/oldnewthing/

Oh my god, I had the same experience growing up. Whenever I moved into the Windows API territory as a kid, I got pushed away, and now in hindsight I know why. The data types used to communicate with the Windows API was ambiguous, sometimes interchangable and often were simply typedefs that I didn't know about. Terribly confusing to a child but now I understand the concept of backwards compatibility and why one would avoid breaking support.

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.)

Yeah, 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.

Interestingly 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.

Could you link the GEM sources? I used GEM a long time ago and would love to have a look.

The DR GEM sources are here:

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/

Although types in _t are supposed to be reserved for future POSIX / compiler use.

It's doubly sad when you think that most people will see this first. I understand that's a complex and real product so to hell with idealism, but when you see code like:

http://piumarta.com/software/maru/

it makes C much more loveable.

ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

> ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

See also: https://news.ycombinator.com/item?id=11005003 -- It's not only C, but there are some C codebases on there.

Thanks, lots of good things there :)

> ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

This is not my area of expertise, but Lua, LuaJIT, and Redis are quite nice imo.

I've heard that too. let's have a list :)

Really? Have you ever done any professional C work? :)

This is, like, #99 on the list of problems. #99... out of 50!

Upper case names like MCIWNDM_SETTIMEFORMATA are constants. Once you work with it a little it makes complete sense.

Upper case names are used for both; HWND, UINT, WPARAM, LPARAM, ULONG_PTR in that example are typedefs.

Reply on news.ycombinator.com