I thought that they were used for having a single plugin for both unicode and ansi OSes, as they were a wrapper for the real Windows API functions. But if foobar 0.9 only supports WinXP and 2k, and having into account that both OSes support unicode, what is the use of all those u* wrappers?

Thanks,
Jorge

PFC and company still use UTF-8 internally, so all of those functions which accept strings still need UTF-8 to UTF-16 conversion, and all those which return strings perform the reverse conversion.

But for example, if I use CreateWindowEx instead of uCreateWindowEx it shouldn't make any difference, right?

Thanks

I will try to explain it further:

If all the strings used in a plugin are in UTF16 (all are generated by Visual Studio, and no one come from foobar sdk), there is no problem in using CreateWindowEx (and the like) instead of the utf8 versions, right?

Don't forget about GetWindowText or SetWindowText. Unless you like translating the strings yourself, and in the case of GetWindowText, allocating buffers.

But it your program is configured as unicode, there is no problem in passing utf16 strings (to be exact, ucs-2) to win32 api functions like SetWindowText or GetWindowText, or I am wrong? If so, using uSetWindowText or uGetWindowText offers no advantage over standard api functions.

If you still don't understand the point of those functions being present, it should make no difference to you whether you use them or not.

Then, would you be so kind as to explain me the point of them?

It has already been explained in posts above.
The fact that something is in shared.dll does not mean that using it is mandatory; under 0.9, these functions are provided as helpers to avoid having to code UTF-8/string_base <=> TCHAR conversion again and again every time you work with window titles or whatever and your backend uses UTF-8 strings.

As English is not my native Language, I think I have misunderstood the previous posts. But it's all clear now, thanks!