If anyone ever looked at the Win32 API and tried to claim that the functions were implemented consistently, then odds are they are clinically insane. If you know what I mean.

So thats not what I am thinking about.

I am thinking about the little consistencies that one can find in families of APIs, such as

  • Most of the NLS APIs take an LCID, all of which use the behavior of ConvertDefaultLocale on the LCID you pass in
  • The registry APIs returning the error value so that 0 means success whereas it would mean failure for most other APIs.
  • The "Ex" versions of keyboarding APIs take an HKL parameter, and their non-Ex counterparts use the current default
  • The NLS APIs can take a buffer size for the in buffer or you can pass -1 to indicate it is null terminated
  • Most of the GDI APIs return a BOOL
  • Flags and the way they are named seem consistent within families in USER, GDI, KERNEL, NLS, etc., even though wildly different when compared between these families
  • Buffer semantics are again generally consistent within families

This is something that I always personally found to be comforting -- like there were teams that had the institutional memory of the APIs they have and that when they add them they try to keep these little consistencies so that people who use them could have intelligent guesses as to behavior so if they understood some APIs they could end up understanding a lot of the rest.

But the other day I was talking to some colleagues who said that they never really grouped API behaviors this way, and they minimized the actual benefit to trying to maintain such a consistency.

So what do you think? Is there a benefit to the little consistencies? Do you believe they are even present? Or is that just me assuming patterns where there are none of any importance?

Also, a random note to answer a question posed by Jonathan Wilson in the "suggest a topic" post -- the LoadKeyboardLayoutEx API sort of follows the above pattern with "ex" versions of keyboard APIs but it also involves other stuff like windowstations. Its not documented because it does not really provide any usable functionality outside of the USER subsystem that one cannot get with existing APIs like LoadKeyboardLayout. But the USER subsystem does have to care about things like separate windowstations....

This post brought to you by "વ" (U+0ab5, a.k.a. GUJARATI LETTER VA)