He talks about the (four) steps that were taken to get everything unicode compliant, which resulted in :
1. A new compiler with new inherent UnicodeString type
2. A new RTL using new string type routines (i.e. many new compiler helper functions in System.pas).
3. An updated VCL using the new RTL that allows the string type to easily "float" to the UnicodeString type
4. A fully functional IDE compiling with the new Unicode Compiler, RTL, and VCL.
Looks like it is going to be a smooth shift...
Anyway one of the first things coming out for the new release and an interesting read!
5 comments:
They certainly want you to think that, but then they would, wouldn't they?
But anyone that thinks that supporting Unicode (in an existing ANSI application) is just a simple question of changing string types has simply never seriously looked at what is involved in supporting Unicode.
Any approach that seeks to portray it as this simple is similarly not properly thought through.
The approach in Tiburon will make it easy to write NEW Unicode applications.
But it simply will not fly as far as maintaining existing ANSI applications *AS* ANSI applications is concerned (in a commercial environment).
You might get away with (or at least be prepared to live with) the uncertainties if you are a hobbyist or knocking out small time desktop apps not on the critical path for your business, or your customers business.
But if that's where we want to see Delphi headed, then all good I guess.
We have just finished porting a rather massive Win32 app from ANSI to Unicode, using Delphi 7 and TNT components. Indeed, the conversion is not simple for existing apps (particularly 3rd party components and string manipulation code). But we have been clamouring for native Unicode support in Delphi for long enough that we should not complain.
It's Tiburon btw not TiburIon ;-)
@jolyon:
For a simple, "idealistic" application you won't even need to change types - you would just need to recompile to make it Unicode compliant, as they integrated the new Unicode type in a very consistent way into the compiler and RTL (imo). I.e. type string IS Unicode.
For a more or less complex application you will have to be more cautious though. Esp. sets of char and where you explicitly assume that an element of a string (a char that is) has exactly one byte might need re-thought.
@olaf:
This is unfortunately exactly the naive thinking that CG are encouraging by their approach.
Enabling Unicode and SUPPORTING Unicode are two very different things.
Post a Comment