Short answer:
UChar is a 16 bit integer so I guess that unicodestring stores the string in utf16. Actually utf16 is the native format of windows (not true for win9x versions) so you should just use this string with windows with the 'W' (utf16) versions of the winapi functions (I guess you don't know what im talking about so continue reading).
Long answer:
For backward compatiblity reasons every windows functions that work with strings have 2 versions. An ansi version for backward compatiblity, and an utf16 (widechar) version that is actually the native for the OS. Example DrawTextA() and DrawTextW(). One of them expects you to pass in a const char*, the other expects a const wchar_t*. I guess you are wondering what is that DrawTextA() and DrawTextW(), since you know only a DrawText() function and msdn docs are also using just DrawText()! Actually DrawText is just a macro that is defined to either DrawTextA or DrawTextW depending on your visual studio project settings - more accurately the character set setting. The same is true to the string parameter of drawtext that is LPCTSTR - this LPCTSTR is defined to either const char* or const wchar_t* finally. You should read this article to get the grasp what I'm talking about:
What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)?[
^]
After reading that short article do this: Set the character set setting of your project to unicode. Use the windows functions directly with sSrc.getTerminatedBuffer() - the utf16 string. If you are using special (non ascii) characters then always use uncode, and not some codepaged legacy stuff that might work on some machines where the language and codepage settings are the same as on your machine. If you are writing crossplatform program then its wise to store utf8 everywhere and on windows converting the parameters to utf16 for the time of function calls and the converting back the result to utf8 for your prog if it the call returns some strings.
EDIT: Forgot to mention something: Its very important to switch your "character set" project setting to unicode because it makes sure that DrawText is actually defined to DrawTextW and not DrawTextA - same is true for every other winapi functions that work with strings. I'm writing this because once I left my character set project setting on Unset (ANSI) and then used some 'W' function calls directly without useing the macros that were actually defined to ansi function calls. This worked for me but one day I found myself in front of a very strange bug that took me a whole day to find: My window creation code and my message loop contained some ANSI stuff becase they used the macro versions of the functions and this bizarre mixture of ansi/unciode stuffs cause very strange bugs! Even some window messages and window message related structs are Ansi/Widechar dependent! So its 2012, forget about ansi and go ahead with unicode.