>The Total Commander comboboxes for the left and right drive list
>are Unicode. However, Total Commander calls
>SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
>to add items as ANSI text. This seems to work, but it's adding some
>extra text at the end.

If I understand correctly, Total Commander is calling SendMessage, which in
this case is translated to SendMessageW (as the comboboxes are Unicode).

So TC is calling SendMessageW to append an ANSI string to a Combobox.
Let's give a look to SendMessageW  implementation thanks to Doxygen:
http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88d98.html#a18e5b961d742150a18d3039b5dd88d98

02161   Result = NtUserMessageCall( Wnd,
02162                               KMMsg.message, 
02163                               KMMsg.wParam,
02164                               KMMsg.lParam,
02165                              (ULONG_PTR)&Result,
02166                               FNID_SENDMESSAGE,
02167                               FALSE);

Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall.

But in this case the BOOL ANSI should be TRUE as the string is really ANSI.
So since this moment we are treating TC call ( SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); )
in the same way as we would be treating SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext);
This seems a bug for me.

Feel free to correct me, but seems that SendMessageW is able to set both kind
of strings ANSI and UNICODE in Windows, while we are forcing to our
SendMessageW implementation to treat them as UNICODE always.
Am I wrong? 
This could be a big potential issue as this could affect to all the SendmessageW calls. 

This is all just a guess, so please feed me with your knowledge.
Thanks a lot!