We recently ported over legacy code to now use Visual Studio 2005 and unicode.
What are the key areas that are affected by switching to the unicode character set?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We recently ported over legacy code to now use Visual Studio 2005 and unicode.
What are the key areas that are affected by switching to the unicode character set?
My biggest nightmare of all while starting to support unicode (I don’t like the word ‘converting to unicode’) is 3rd-party libraries which accept char* for filenames, and then forward these to legacy windows APIs like CreateFileA.
It is very hard to make these support unicode if you don’t have the library source code, and also, this practice is perfectly good on Linux where UTF-8 is universally supported.
What my team had to do is getting 8.3 filename for every file before feeding it into these APIs. It relies on registry setting (ON by default) that prevents windows from using non-ascii chars in 8.3 filenames, and in keeping 8.3 filenames in the first place.
This does not work if the broken library creates a file, because the 8.3 filename is not known before creation. We had to trick this by creating a wrapper which would create the file, allocate the 8.3 filename and then feed it to the library.