When you have the leisure, it is much easier; I once spent a year converting a Win16 app
to Win32, so when we finally bit the bullet to go to Win32, it took two more days of
detailed debugging (mostly fixing compiler-detected errors, some of which were due to
stricter compiler syntax checking) and we were there.
For the Unicode conversions, for code I haven't written I rarely have the leisure; in
fact, the assignment is often "Can you convert this to Unicode as quickly as possible?"
usually followed by a request to have the Korean, Japanese or Chinese version deliverable
in less than a month. I tell them that getting the resources translated is their problem,
but I'll give them an app that can be converted. I haven't taken longer than a week to do
a conversion (but that was all I did for that week).
Note that I point out that other localization issues (such as number formatting, date
formatting, time formatting, etc.) are beyond the scope of that estimate and will cost
extra; they usually go for that, which usually adds another couple days. And yes, on a
rush job there are often a couple remaining glitches (bugs) that show up in final
acceptance testing, but most of these are trivial. One that was not took several days of
editing and a LOT of consulting back and forth as to what the "right" decision was. It
was not an easy change in that case.
Fortunately, I have not had to deal with legacy data (such as an email system), but often
deal with "mixed mode" (ANSI and Unicode) apps, where the 8-bit characters are often going
from/to some embedded system. In one case, we did UTF-8 encoding to the target system,
with its ensuing pain (the system accepted 20-byte text fields, which meant that the worst
case was 5 characters of localized text; but this would have required massive changes in
their embedded code; the average was about 7 characters of localized text, encoded as
UTF-8. but of course if the customer used 7-bit-realizable characters, they could get the
whole 20 in. European customers got unhappy because accented characters now too two
bytes, and therefore they had compatibility problems, but the customer had decided to live
with this).
Mostly, it's a lot of tedious editing and a lot of really careful reading of the code. But
it pays well, which is why I do it. Haven't done one in about two years.
joe
Post by David WebberFrom: Joseph M. Newcomer
Post by Joseph M. NewcomerTake David's advice: convert to Unicode. Seriously. I've converted 100K lines from ANSI
to Unicode in about three days of intense editing,...<
It took me about a year to do something similar (ending with a day of
intense editing <g>) BUT ...
I made the decision that my (then) next version would not have to run on
Windows 98, and I did it in a leisurely fashion, just converting stuff when
I came across it. All my char's became TCHAR or WCHAR (=wchar_t) or were
left as char as appropriate. The ones left as char, I replaced by CHAR
(upper case) as a signal that I had considered it, and decided it really was
a 1-byte object. [Then on D-day, I changed the project settings to
Unicode, and then came the picking up of the (relatively few) things I had
missed.]
Anything to be saved in a file became WCHAR as it was important to me that
the file format would be the same if I did a Unicode and a non-Unicode
build. (In the event I have never needed a non-Unicode build and I doubt
now that I ever shall.)
Most of the instances of CHAR were just where I wanted to have a 1-byte
integer, but there are also one or two places where single byte characters
For some reason ::GetProcAddress() takes an old fashioned const char *
string argument for the function name. (I guess function names in Arabic
script are not a good idea <g>.)
And I explicitly use the ASCII version ::GetGlyphOutlineA(), because the
character number it takes is different for symbol fonts than that of the
wide character version ::GetGlyphOutlineW(), which needs Unicode code point
in the user symbols range. Had I just used GetGlyphOutline(), it would have
involved a different argument for a Unicode and non-Unicode build.
But these exceptions are pretty few and far between. (Most folk never have
to use GetProcAddress, and GetGlyphOutline is definitely one of those
routines you save for Sunday best <g>.) Mostly it's just a case of making
sure you use TCHAR almost everywhere, and WCHAR or CHAR where you need them,
and checking that anything which takes a string argument is compatible
(strlen, vs _tcslen, vs wcslen etc ), and (as Joe points out) that any
sizeof operations are done correctly.
After that you need to make sure you have Unicode settings defined in the
project, and that your rc file is a Unicode text file with the proper
Japanese text in it.
Dave
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm