It would certainly be possible to support Unicode in the VCL for Win32. The only real question is how. Oddly, most of the frequent requests for Unicode support never attempt to answer this, and it seems to me that if we want Borland to add this feature then we, as VCL users, should be giving them guidance as to our needs.
The Boat Anchor
One of the first questions we must answer concerns Win 9x support. Apps running on 9x can’t actually use Unicode, but it is possible — but somewhat more involved — to make an app which supports 9x whilst offering Unicode on modern operating systems. Borland’s Danny Thorpe has indicated, however, that doing Unicode support properly in the VCL would be such a significant change that ensuring it worked correctly on both NT-based OSs and DOS-based OSs would make the project so large as to "essentially double the development effort." I don’t want to go into too much detail on this — there are a lot of different ways the project could be undertaken, and they all have there ups and downs — because the point is that supporting 9x makes things a lot harder, and every year that goes by makes it less important.
Personally, dropping 9x wouldn’t bother me in the slightest. My company doesn’t support 95, and we won’t support 98 by the time such a VCL could be released. Microsoft won’t, either. We’ve never supported ME. But I do remember the fracas when Borland released a version of Delphi variants which wouldn’t work on original, unpatched Windows 95 a few years back. At the time original Win95 was further back in history than Win98 SE and ME are today.
So I don’t think you can really ask for a Unicode VCL without also stating that you are OK with Borland ending support for the 9x "boat anchor." For most of us this won’t be a problem. But it’s important to get this idea out to the Delphi community so that people who do have an issue with it can have a chance to express their dissent.
How Much Unicode Do You Need?
Another significant question is where to draw the Unicode line. Do you want full Unicode as in the VCL for .NET where the string reserved word changes to Unicode, or something less? Borland could choose to do something as minimal as a parallel set of components (which would be kind of pointless as such a component set is already available for free) or draw the line anwhere between that and "full" Unicode support.
I personally feel that anything less than full Unicode in the VCL (meaning the string reserved word changing to Unicode) will solve only part of the problem and put off and prolong the pain of the rest of the transition. I have watched the pain developers experience when they realize that their strings won’t work with a certain language or combination of languages for as long as I’ve been programming. How much longer do you want to fight this war? Unicode is intended to be a final solution to the problem of representing written language. It’s time to put it to rest.
However, it’s important to remember that Delphi developers are rightly sensitive to any change in string types. Here are a couple of episodes from recent history which are instructive:
- In D4->D5 (IIRC) strings were changed so that they could be safely read from a single thread in a multithreaded application, causing a (IIRC) 20-30 across-the-board performance penalty. The original bug was embarassingly bad, and nobody came up with a much better solution, but there was outrage at the change.
- In VCL for .NET, string is System.String (Unicode). It’s also an immutable type, which means you have to use a separate type, StringBuilder, to do stuff you can easily do with AnsiString in performance-sensitive code. Even though Delphi users gain a significant new feature they’ve been asking for for years (Unicode) and it is still possible to write good-performing code, nobody likes having to rewrite working code.
Vote Early, Vote Often
In summary, it’s not enough to ask for Unicode. This is a significant change and we must be specific about what we want and how we want it done. If this issue is important to you, speak out and be detailed!
{ 23 } Comments
Delphi already has unicode
http://www.tntware.com/delphicontrols/unicode/
Nikola, the link you give was already in my post!
I see now. I’m mostly using keyboard, so I missed it by not "hovering it" with mouse.
I’ve been using tnt controls for some time, because my native language uses 2 codepages equally (in win: 1250 and 1251), and I find it a great solution just as it is. Additional set of components.
In my opinion anno 2005 EVERYTHING should be unicode. My wife is Chinese so i know the problems which are raised when the OS (Win XP) and many applications still don’t know how to handle multiple users with different locale settings. Yes this is true, in Win XP Pro it’s not possible for two different users to have completely different locale settings. The codepage is a systemwide setting. The world is so international that unicode should really be the only way to store text. If this implies dropping that piece of sh*t os Win 9x, thank god there’s now a valid reason.
I think it would be ok to drop Win95/98/ME as long as its announced well in advance.
My vote goes for going all the way and changing "string" to be unicode also. For backward compability I guess it must be possible to make a compiler directive like $H. When its possible with two different type three shouldn’t be a problem or…? Standard packages could then be supplied in two versions.
The compiler directive would also solve the Win95 issue (sort of :-))
There are the tnt components for forms but what is used for reporting? Is there a Delphi unicode report tool?
Crystal Reports should work. There are probably other choices, but I don’t know what they are off the top of my head.
I think there would be thre options with regard to Win9x
- not support Win 9x at all any more (I don’t advoate this)
- provide full Unicode support for both Win9x and Nt> (Danny suggests the costs and issues are prohibitive)
- Provide full Unicode support for NT>, but the existing level of support for 9x.
I take it the third of these is what you are advocating?
Lauchlan Mackinnon
Unicode-Report generator: take a look at http://www.combit.com
They have a product called List & Label, i checked it together with D5 (not D2005!) pro and it gave me perfect unicode prints.
The new dbgrid from TMSSoftware can show (and print? - i did not test it) unicode as well.
My feeling is that Borland are actually waiting for Win32 to die, and not Win95/98/ME. It’ll be a long wait.
Michael, I honestly don’t think Borland is that clueless. After all, they have enhanced Delphi for Win32, in contrast with what Microsoft did with VB for Win32.
As of today, I see no point in support for building all-in-one applications, which provide Unicode on NT, and in the same time still nicely degrade to non-Unicode version of the same application on win9x.
IF it is possible without too much extra work for Borland, and without too much penalties for application writers, a possibility to build two different executables from the same source code (via a compiler directive) - one for NT, and another one for win9x - would still be nice. IMHO. But the importance for this fades away.
Delphi is disappointing at not supporting Unicode to a satisfying extent and, by the way, PDA/mobile phones programming. For the former, the problem doesn’t lie on creating new applications, as we have TNTWare and the other similar tools. The problem is how we can convert "legacy" Delphi applications written with InfoPower, ReportBuilder, etc. to make them Unicode compatible.
I think that the benefits of supporting Unicode would out-weight the disadvantages of dropping support for obsolete Win9X platforms.
I don’t have a need for Unicode myself, but dropping Win9X would simply not be a problem for me. If people are still using these old operating systems then they should upgrade.
In the past though I have used a string as a simple way to temporarily store binary data. I hope that supporting Unicode would not break this? Although I don’t think I currently have an app which still does this.
Pete, the TAnsiString type would still be available, so you’d still be able to use it to store binary data. But I would *strongly* recommend that anyone who does this use TAnsiString explicitly (or, better still, a PChar) and not depend on the string reserved word to mean TAnsiString. In Delphi for .NET it doesn’t!
LMD ElPack provide set of controls that support of unicode on both 9x and NT+
Unicode makes sense on Delphi 64 and OS with 64 bit because of effort. Then we can drop the 32 bit VCL and Win95.
Surely Borland could support Unicode on Win9x via the Microsoft Win9x Unicode Support Layer, the same way everything else that want to use Unicode in 9x manages to support it?
David, the Unicode layer for 9x doesn’t actually provide Unicode on 9x; it just allows you to write a Unicode app for NT/2000/XP/2003 which will still run (albeit without Unicode) on 9x. This is discussed in my article.
Nikola, the TNT compounds don’t solve the Unicode problem for the scientific application because the compounds don’t contain a Unicode version of TeeeChart.
The scientific applications often use English GUI and message anywhere in the World, including Asia. And they need to display English, Greek and Nordic characters like lambda, mu, angstrom, …
As you (Craig Stuntz) wrote,
" as a parallel set of components (which would be kind of pointless as such a component set is already available for free) "
I think this is what most people have wanted for years, and we developers don’t want to have to go to TNT to get the components; we feel more comfortable (a) if Borland internally has the source code to the TNT components (or the equivalent source code written by Borland) , and (b) that Borland is maintaining it. In other words,
(1) If the developers at TNT could do it, why couldn’t Borland?
(2) If Borland was low on manpower, why not negotiate a fee and buy rights from TNT? I doubt that the TNT components are 100% bug free, and somebody needs to be maintaining it.
(3) Why should we trust TNT? For example, its components’ icons have BOMBS on them, which seems juvenile and a coded message that they may have hidden malicious intentions. Would you trust a component that has the skull-and-crossbones picture on it, or a hazardous-materials-sign? That same bomb icon was used for the Apple Macintosh to indicate the system had died. Please read the "moral" section of Ken Thompson’s Turing Award reception speech on "Reflections on Trusting Trust" (http://www.acm.org/classics/sep95/). I trust Borland to some extent because it is a public company listed on the NASDAQ, with a street address and a financial incentive to act responsibly towards its customers . Why should I trust TNT? What motivates TNT to provide bug-free non-malicious code?
(4) Microsoft will stop providing security patches for Windows 98 in July of this year (2006) (http://www.microsoft.com/windows/support/endofsupport.mspx): "July 11, 2006 will bring a close to Extended Support for Windows 98, Windows 98 Second Edition, and Windows Me as part of the Microsoft Lifecycle Policy. Microsoft will retire public and technical support, including security updates, by this date." Therefore any arguments about Borland having to support those versions of Windows evaporate; Borland can say, "Since Microsoft doesn’t support these version, Borland is also discontinuing its support."
Unfortunately the problem of the debate has been the ambiguous meaning of "VCL", as you have pointed out; most developers just wanted the UNICODE compatible components, and spoke of "Unicode VCL" as a shorthand for that subset of the issue. Another problem is the desire within Borland for a one-size-fits-all-solution or a Grand-Unified-Solution (overhauling the VCL); personally I think this was a mistaken policy.
Now that Borland is looking to sell its IDE division to concentrate on blah-blah-lifecycle-blah-management-blah, I’m trapped in indecision whether to continue with the Borland product line, or bite the bullet and embrace .Net. I REALLY do not want to.
By the way, I’m still using C++Builder, not Delphi.
(I’d appreciate, Stuntz, if you could please indicate whether you have read my post, since this blog article is almost a year old; dunno if your blog notifies you when somebody contributes a comment. Thanks)
Well, "User," I read your comment, but I don’t agree with it. You don’t have to trust TNT if you don’t want to, but forward compatibility is one of Delphi’s biggest advantages over its competitors right now. To answer your specific questions:
1) The question is not "could Borland do it" — of course they could — but *should* they? My argument — indeed, the whole point of this post — is no. Your opinion may differ, of course.
2) See (1)
3) You don’t have to trust TNT if you don’t want to, but I don’t believe Borland will ever expend resources on a solution which is of limited use to anyone with a big legacy code base, so by arguing for that solution you’re in effect limiting yourself to smaller vendors.
4) I fully agree. Dropping support for the boat anchor can’t come soon enough.
I would like to see the whole VCL go Unicode and support for Win98 dropped.
> If the developers at TNT could do it…
Make that "developer"… there’s only one: me.
> For example, its components’ icons have BOMBS on them, which seems juvenile and a coded message that they may have hidden malicious intentions.
Wow, that’s a bit paranoid! :^) The bomp icon is simply a clever way to symbolize "TNT". The components are distributed in SOURCE FORM ONLY, and many developers can and have looked at the source code. If there were malicious intents, they would have been discovered a long time ago! The icons were graciously volunteered to me by another developer a long time ago.
> What motivates TNT to provide bug-free code?
I (the developer of these components) wrote these controls for use in my own application. I made them available for free so that I could improve their quality (and thus the quality of my applications) by the feedback I’d get from other developers. I’m an application developer first, and a component developer second.
I can understand your apprehensions about not wanting to use a component set developed my an individual person. But do keep in mind that they are distributed in source form only, and that many other application developers have chosen to use them:
http://www.tntware.com/delphicontrols/unicode/where_used.htm
Post a Comment