The win32 API has for example two methods StrFormatByteSize and StrFormatByteSizeEx. Even though both the methods symantically do the same thing and the Ex counter part only offers a new parameter to slightly change the behavior then couldn't they have two overloads of the same function?
Is it a limitation of c/c++ or what is the possible reason for such an awkward convention?
The Win32 API is a C (not C++) API. The C language doesn't support overloaded functions.
Complete aside: The Win32 API uses __stdcall-decorated functions, which include the number of bytes of parameters as part of the function name. __stdcall is not part of the C language, but Windows linkers have to know about it.
Microsoft could have used this to implement some kind of overloading, but (since a lot of languages don't understand overloading) that would limit the number of languages that could be used to program Windows.
Is it a limitation of c/c++ or what is the possible reason for such an awkward convention?
Yes, and the reason that C doesn't support overloading functions is because, name mangling(conversion of function names to be used by the linker) used for standard C doesn't account for its function parameters.
I.e. void func(int) in C gets mangled to _func
so you cannot have func(int) and func(bool) together, as both will be converted to _func.
Whereas in C++, the mangled name for a function accounts for all its function parameters, but as name mangling in C++ was not standardized, the name mangling is compiler dependent.
One more thing to keep in mind is C++ doesn't consider the return parameter of the function in the mangled name. Hence, one cannot have overloaded functions as void func(int) and bool func(int) together.
--Samrat Patil
Microsoft never bothered.
Sure, a few people here say that C doesn't support overloading. That's irrelevant. The API already uses overloading, C-style. For instance, the StrFormatByteSize function you mentioned really has two overloads: LPSTR StrFormatByteSizeA(DWORD dw, LPSTR pszBuf, UINT cchBuf) and LPWSTR StrFormatByteSizeW( LONGLONG qdw, LPWSTR pszBuf, UINT cchBuf);. The problem with this mechanism is of course that it generalizes poorly to the various _Ex suffixes.
Microsoft could have added a header which provides StrFormatByteSize as two inlined C++ functions, instead of C macros. Had they done so, it would have been easy to add the third overload for the _Ex suffix. There's no such C++ header, though, and therefore no C++ overloads at all.