Why are some GDI functions named ExtXxx instead of XxxEx?


By convention, an enhanced version of a function Xxx is called XxxEx, but there are many GDI functions that don't follow this conventions, most notably ExtTextOut, which should have been named TextOutEx under the XxxEx convention. Why don't the GDI functions follow that convention?

Because they were named before the XxxEx convention was established.

Nothing nefarious, just an artifact of history.

Comments (21)
  1. Florian says:

    And besides, ExtTextOut just sounds cute.

  2. waleri says:

    If this API be extended further, it will be named ExtTextOutEx? :)

    No, seriously, is there any Ex API extended even more?

  3. Somebody who doesn't actually care says:

    "they were named before the XxxEx convention was established"

    So why establish a convention contrary to existing practice? It’s like, you know, reading the contract from the other side, or something.

  4. bob says:

    "So why establish a convention contrary to existing practice?"

    Because there were multiple existing practices and its better to choose the "correct" convention to standardize on rather than pick something just because it exists?

  5. AC says:

    No, seriously, is there any Ex API extended even more?

    A recent example is the addition of IInternetSecurityManagerEx in WinXP SP2 and then IInternetSecurityManagerEx2 in IE7.

  6. SRS says:

    I say bring back ‘Presto’ as a standard convention.

  7. Leo Davidson says:

    "So why establish a convention contrary to existing practice?"

    Adding the -Ex suffix is much better than adding the Ext- prefix because it keeps closely related functions together in alphabetically sorted indices (or "indexes" if you prefer).

    My guess is that the problem with Ext- prefixes quickly became apparent as the Windows API documentation grew and became more organised, although I wasn’t there and may be wrong.

    (Of course, MSDN could use a special sorting algorithm on its index but why go to that trouble just to preserve a convention that hasn’t been used much and is of little other consequence?)

  8. Anonymous says:

    No, seriously, is there any Ex API extended even more?

    EnumCalendarInfoExEx and EnumDateFormatsExEx in Vista. Basically, they just add a "context" parameter to their callback functions.

  9. JohnW says:

    EnumCalendarInfoExEx and EnumDateFormatsExEx in Vista.

    Ugh.  Should just have done EnumCalendarInfoEx2. Otherwise, we’ll be looking at EnumCalendarInfoExExExExExEx one day.

    Maybe the assumption is that it’ll be entirely deprecated before that insanity kicks in.

  10. tcliu says:

    The DirectX team has the best solution, in my opinion: IDirect3D, IDirect3D2, …, IDirect3Dx with x being the interface version.

    Simple, understandable, and avoids the -Ex suffix which only works once and must then be turned into ExX with X being the version anyway.

  11. Niels says:

    IIRC many of the -Ex functions instead of a regular parameter list takes a pointer to a struct with parameters, and often the first field of that struct is a "size of struct" one. This essentially makes it possible to use the size field as a "version" field and upgrade the struct without changing the function, and let newer implementations of the function accept several versions of the struct.

    Although I’m not sure what an older implementation of the function should do if it receives an unknown version of the struct.

  12. Bruno says:

    "Although I’m not sure what an older implementation of the function should do if it receives an unknown version of the struct."

    Fail with the appropriate error code. I don’t know offhand what the appropriate Win32 error code is though.

  13. なんで、GDI 関数は XxxEx じゃなくて ExtXxx なん?

  14. Narr says:

    let newer implementations of the function accept several versions of the struct.

    Good luck with that. I think Raymond has covered many cases where that can’t be done because some big names didn’t understand the size field.

  15. Yuhong Bao says:

    BTW, which version of Windows added ExtTextOut?

  16. waleri says:

    I think newer implementations *do* accept several versions of the struct. Otherwise, applications written with an older SDK will fail to run ot newer OS versions.

  17. Igor Levicki says:

    I think the real reason is that too many GDI function names ended with letter "s" ;)

  18. Yuhong Bao says:

    I think the real reason is that too many GDI function names ended with letter "s" ;)

    But not ExtTextOut, so…

  19. James says:

    Narr: That works fine provided the very first implementation (and subsequent ones, of course) enforce the size value. Then, any code which passes an incorrect size value will never have worked anyway, neatly avoiding the need to compensate for author incompetence there.

  20. Jolyon Smith says:

    Q: "So why establish a convention contrary to existing practice?"

    A: "Because there were multiple existing practices and its better to choose the "correct" convention to standardize on rather than pick something just because it exists?"

    Except of course that there was no standardization, only the establishment of a convention to be applied in the future.

    The existing inconsistencies remain(ed).

Comments are closed.