Unicode in Delphi/VCL (yet again)
Paras Kafley
VCL. Yes i know it is a major undertaking and everything that goes with
it, but not having unicode support in Delphi IMHO is fairly big
drawback. I know that there are good and free Unicode controls for
Delphi, but it sure would be nice to have unicode support in the core
product.
To me to be prefectly honest support for Unicode is far more important
than support for 64 bit native compiler and to hazard a guess I am not
the only one.
~Paras
Roby Della Pasqua
Just use UTF8 conversion routines and or widestring.
About controls unicode compliant check
http://www.tntware.com/delphicontrols/unicode/
"Paras Kafley" <paras.nospam.kafley_at_nospam.microbanker.org> wrote in
message news:42fd894a$1...@newsgroups.borland.com...
siegfriedn
> Does anyone know if Borland if ever plans to add Unicode support in
> VCL.
The VCL is derived from win32 controls which do not support UNICODE.
Your options are:
- 3rd party win32 Delphi components
- CLX
- VCL.Net
- Native .Net (Winforms)
siegs
Dennis Landi
message
> To me to be prefectly honest support for Unicode is far more important
> than support for 64 bit native compiler and to hazard a guess I am not
> the only one.
They are not mutually exclusive.
-- d
---------------------------------------------------
Need to see what's happening?
Check out the Delphi Community Blog Aggregator
http://delphi.flashblogger.com
Peter Morris [Droopy eyes software]
time for both.
Lee Grissom
> Does anyone know if Borland if ever plans to add Unicode support in
> VCL.
In the past, I have been told "no". This is the primary reason our enitre
R&D organization (hundreds) is moving to C#/VS.NET. We needed end-to-end
full unicode support, so no, you are not alone.
--
Lee
John Kaster (Borland)
> In the past, I have been told "no". This is the primary reason our
> enitre R&D organization (hundreds) is moving to C#/VS.NET. We needed
> end-to-end full unicode support, so no, you are not alone.
That sounds like a really bad, or perhaps just uninformed choice.
VCL.NET fully supports Unicode, so a far superior path to .NET is
moving your existing code to Delphi for .NET instead of rewriting it
all in C#.
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
If it's not here, it's not happening: http://ec.borland.com
Roddy Pratt
"John Kaster (Borland)" <jo...@borland.com> wrote in message
news:42feea38$1...@newsgroups.borland.com...
> That sounds like a really bad, or perhaps just uninformed choice.
>
> VCL.NET fully supports Unicode, so a far superior path to .NET is
> moving your existing code to Delphi for .NET instead of rewriting it
> all in C#.
>
bound to have a higher perceived 'risk level' than MS in terms of long-term
support and direction - look at the recent rumblings about Mr Coates's
suggestions. [Neither side gets it right always, but Kylix, CBuilderX and
(to a lesser extent) BCB have not exactly helped Borland's position]
Complex development tools have a lot of inertia associated - you need
*really* good reasons to invest the time in switching, [which is why we
still use BCB5...], and Delphi to Delphi.NET *is* perceived as a switch,
rather than a simple upgrade. This is why we added unicode support by using
the TNT components - we get unicode exactly where and when we want it,
without plaguing the entire application with it.
- Roddy
![Nick Hodges [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWsTjWTtYgQa_lIkPPY_9f1apuJLHGnOXqRfdvL-25iS-D7ruXW=s40-c)
Nick Hodges [TeamB]
> This is the primary reason our enitre R&D organization (hundreds) is
> moving to C#/VS.NET.
<head shaking> Another one of those confusing decisions. What do you
get from C# that you don't get from Delphi?
I simply don't understand these decisions.
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Bryce K. Nielsen
Yes, but 3rd party controls tend to be based on VCL not TnT, so they don't
support Unicode. I agree, Unicode would be a great boon to the VCL, and
wouldn't even mind a unicode "sister" set of controls, akin to CLX or TnT,
just something official from Borland...
-BKN
Andreas Hausladen
> What do you get from C# that you don't get from Delphi?
Lot's of work to spend on rewriting Delphi code :-)
--
Regards,
Andreas Hausladen
Lee Grissom
> VCL.NET fully supports Unicode, so a far superior path to .NET is
> moving your existing code to Delphi for .NET instead of rewriting it
> all in C#.
From a technology standpoint, I fully agree. However, the decision was made
at a higher level. There's a large array of factors in choosing a
development platform. We'd rather not have been forced to make a change to
begin with. If there were a full unicode solution in Win32 Delphi, I'm
fairly certain we'd have gone that route.
--
Lee
Lee Grissom
> <head shaking> Another one of those confusing decisions. What do you
> get from C# that you don't get from Delphi?
I do agree to some extent. From a tech standpoint, having used both long
enough, I'd saying they are even in benefit. From an employer standpoint, I
am aware of at least one point of view. True or false, HR has stated
difficultly in finding good Delphi developers to fill needed positions for
an agreeable compensation. The thought or fear was/is that the really good
developers that they want to hire refuse to work with Delphi and will only
work with the more trendy C language family. So we piloted into C#, and to
some degree that plan is showing some merit. A large group of us have been
taking .NET training courses over the past year, and the language and tool
used as part of the courses is based on C#/VS.NET. That's a factor for us
as well. It's a fascinating topic for certain.
--
Lee
Jason Smith
John Kaster (Borland)
> I doubt that VCL.NET "fully" supports Unicode. At least not in the
> current version of dbExpress .Net.
Additional unicode support is coming for dbExpress .NET. Even if you
DON'T move to VCL.NET, it still makes more sense to stick with Delphi
and re-use as much code as possible than totally rewrite it.
Kyle A. Miller
> "Nick Hodges [TeamB]" wrote
>> <head shaking> Another one of those confusing decisions. What do you
>> get from C# that you don't get from Delphi?
>
> I do agree to some extent. From a tech standpoint, having used both long
> enough, I'd saying they are even in benefit. From an employer standpoint, I
> am aware of at least one point of view. True or false, HR has stated
> difficultly in finding good Delphi developers to fill needed positions for
> an agreeable compensation.
Usually employers complain having trouble finding Delphi developers, and
Delphi developers have trouble finding Delphi jobs. Go figure. You did
qualify the statement with "an agreeable compensation". It's still
cheaper to pay a good Delphi and probably software engineer as bonus a
little more than hire and pay for the extra labor force required to
convert massive projects to a new language and framework. (We'll
temporarily suspend the argument about the time required to perform the
conversion, and the fact time is money. That's for development and
re-testing of code that is already working.)
> The thought or fear was/is that the really good
> developers that they want to hire refuse to work with Delphi and will only
> work with the more trendy C language family.
Tell them they'll be working with Java and see what they say. ;-)
> So we piloted into C#, and to
> some degree that plan is showing some merit. A large group of us have been
> taking .NET training courses over the past year, and the language and tool
> used as part of the courses is based on C#/VS.NET. That's a factor for us
All this effort to train, develop, and test comes at a cost savings when
compared to paying a good Delphi developer a little more? Hmm... I need
the Dilbert Principle for some personal therapy. ;-)
Nick Hodges [TeamB]
> True or false, HR has stated difficultly in finding good Delphi
> developers to fill needed positions for an agreeable compensation.
Okay, that is a reason I can at least understand. But saying "Delphi
doesn't give us Win32 Unicode, so we are switching to .Net and C#"
doesn't make /any/ sense.
Bob Dawson
> of at least one point of view. True or false, HR has stated
> difficultly in finding good Delphi developers to fill needed
> positions for an agreeable compensation.
Out of idle curiosity, does your HR department filter resumes before
forwarding them to the hiring manager? And what's an "agreeable
compensation"?
> The thought or fear was/is that the really good
> developers that they want to hire refuse to work with Delphi
Huh? Who's the 'they' here? If it's the HR folks I think I see the
problem...
bobD
Bernhard Geyer
I've made our application (1 Mio. Lines of Code) with only 699 € (LMD
ElPack) License-Cost and rewriting some code to change it from String ->
WideString Unicode-Enabled.
And contrary to C#/VS.NET this also work unter Win9x/ME.
.NET doesn't support Unicode unter Win9x/ME in the GUI. Delphi with
ElPack does.
Lee Grissom schrieb:
Roddy Pratt
news:430015d1$1...@newsgroups.borland.com...
> Okay, that is a reason I can at least understand. But saying "Delphi
> doesn't give us Win32 Unicode, so we are switching to .Net and C#"
> doesn't make /any/ sense.
>
Borland's stance on Unicode and VCL ("You can't have Unicode without .NET")
is self-destructive, because it forces developers to effectively choose a
new development environment. And whenever someone has to make that choice,
the majority will go MS - particularly if they feel that Borland has not
offered them a sensible way forwards.
- Roddy
Wayne Niddery [TeamB]
>
> Borland's stance on Unicode and VCL ("You can't have Unicode without
> .NET") is self-destructive, because it forces developers to
> effectively choose a new development environment. And whenever
> someone has to make that choice, the majority will go MS -
> particularly if they feel that Borland has not offered them a
> sensible way forwards.
I think you missed the point here. If one is going to pursue future
development in .Net (which is obvious if they plan to use C#) then the fact
that *Win32* VCL doesn't support unicode is a complete red-herring, there is
no relevance. I doubt it would be even remotely cost-effective to rewrite
perfectly good Win32 Delphi VCL apps in C++/MFC and I seriously doubt that
is their plan. But unless that *is* their plan, then the argument is
ridiculous.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"We've all heard that a million monkeys banging on a million
typewriters will eventually reproduce the entire works of Shakespeare.
Now, thanks to the Internet, we know this is not true." — Robert
Wilensky
Nick Hodges [TeamB]
>
> Borland's stance on Unicode and VCL ("You can't have Unicode without
> .NET") is self-destructive, because it forces developers to
> effectively choose a new development environment. And whenever
> someone has to make that choice, the majority will go MS -
> particularly if they feel that Borland has not offered them a
> sensible way forwards.
That's a good point.
Does any 32-bit framework do Unicode?
Dennis Landi
Roddy Pratt
news:4300a751$1...@newsgroups.borland.com...
> I think you missed the point here. If one is going to pursue future
> development in .Net (which is obvious if they plan to use C#) then the
> fact that *Win32* VCL doesn't support unicode is a complete red-herring,
> there is no relevance.
Well, I disagree... ;)
You and Nick are totally right that switching to C# and .NET as a 'solution'
to the lack of Win32 VCL unicode is daft.
But, my point is that the lack of a Win32 Unicode solution from Borland
forces a fresh choice of environment, and it's not surprising that some will
choose the MS route. Many won't want to switch to .NET, but Borland has told
them that's what they must do. So all bets are off.
If Borland actively promoted a win32 unicode solution (even TNT) then many
people would happily remain locked-in to Delphi.
- Roddy
Nick Hodges [TeamB]
> But, my point is that the lack of a Win32 Unicode solution from
> Borland forces a fresh choice of environment, and it's not surprising
> that some will choose the MS route. Many won't want to switch to
> .NET, but Borland has told them that's what they must do. So all bets
> are off.
I agree with that point -- a lack of Unicode support in Delphi Win32
may cause folks to re-evaluate their environment.
Given that, though, I still don't see the wisdom in leaving Delphi for
C# under that scenario.
Lee Grissom
> Out of idle curiosity, does your HR department filter resumes before
> forwarding them to the hiring manager? And what's an "agreeable
> compensation"?
That's the kicker. I hear everything second hand through my boss. Which is
why I preceded the sentence with "true or false". I could raise a fuss and
question the legitimacy of that claim, /particularly/ since I haven't seen
any new hires in our office for 2 years. Granted, we've hired dozens in St
Petersburg since then.
> Huh? Who's the 'they' here? If it's the HR folks I think I see the
> problem...
To be honest, I don't know. Everything gets filtered to me thru my boss.
In a corporate environment, there are so many variables, and so many
half-truths, and so many agendas.
--
Lee
Jason Smith
VCL means a lot to Delphi Win32 developers, especially in desktop
applications. People can be reluctant to go either .Net or Java just because
of the lack of support of Unicode. Switching to .Net or Java might cause
other implementation problems in other aspects, as .Net and Java might not
be seemed as proven solutions to desktop application yet.
A fix to Unicode support in Delphi win32 is more likely to retend Delphi
programmers' loyalty, and stop the critics of Unicode war in win32. In the
position of Borland, a fix to Unicode support in VCL win32 might cost less
than convincing people to switch to VCL .Net.
An immediate example: Look at devExpress, they are not keen on VCL .Net or
CLX development anymore but pure VCL win32 and .Net solutions at this moment
because the demand on VCL .Net or CLX is just not worth the effort.
I believe that Delphi programmers love Delphi, has greatly to do with Delphi
is so productive in win32 but not because the ability that Delphi can do
.Net or Delphi can do Linux.
It's great that Borland attempted to extend Delphi culture's to Linux and
.Net. But I believe if Borland was to make the same effort on VCL win32 as
they invested/are investing on CLX or VCL .Net, Borland's financial position
would be much improved.
Jason
Wayne Niddery [TeamB]
>
> You and Nick are totally right that switching to C# and .NET as a
> 'solution' to the lack of Win32 VCL unicode is daft.
That is the only point I was concurring with.
> But, my point is that the lack of a Win32 Unicode solution from
> Borland forces a fresh choice of environment, and it's not surprising
> that some will choose the MS route. Many won't want to switch to
> .NET, but Borland has told them that's what they must do. So all bets
> are off.
In the case where there is a genuine need for Win32 + Unicode, then you are
right. If .Net is a reasonable alternative to solve the issue, then there is
no reason to switch.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The two most abundant elements in the universe are hydrogen and
stupidity." - Harlan Ellison
Jason Smith
> are right.
With the increasing demand of international market (e.g. China), the need
for Unicode is arising.
The use of Unicode has been successful. There are many reasons to use
Unicode.
Deployment on Win32 has been successful.
Thus I believe the need for Win32 + Unicode is not far from genuineness.
> If .Net is a reasonable alternative to solve the issue, then there is no
> reason to switch.
Wayne, do u mean no reason NOT to switch?
Delphi Winform might be ok for Unicode. But Delphi VCL .Net still has issues
for Unicode, e.g. look at dbExpress .Net.
People here love the robustness of practical aspects of Delphi Win32. And
people might not have enough confidence in VCL .Net.
Win32 + Unicode might make robust Delphi Win32 more perfect.
Jason
Bob Dawson
> In a corporate environment, there are so many variables, and
> so many half-truths, and so many agendas.
My sincere condolences. When I left an environment like that and joined my
current company, my entire outlook on life improved.
bobD
Wayne Niddery [TeamB]
>
> The use of Unicode has been successful. There are many reasons to use
> Unicode.
> Deployment on Win32 has been successful.
> Thus I believe the need for Win32 + Unicode is not far from
> genuineness.
I'm talking about a genuine need on a project by project and/or company by
company basis. If the nature of the projects a company does requires this
than that is a legitimate issue. Otherwise not. The majority of applications
in Win32 *do not and will not require* unicode.
>> If .Net is a reasonable alternative to solve the issue, then there
>> is no reason to switch.
>
> Wayne, do u mean no reason NOT to switch?
No, I mean there is no reason to switch from Delphi in this case.
> Delphi Winform might be ok for Unicode. But Delphi VCL .Net still has
> issues for Unicode, e.g. look at dbExpress .Net.
Again that depends on the project that must employ Unicode. VCL.Net can be
used with ADO.Net. I also expect that dbExpress will be fixed for this.
> Win32 + Unicode might make robust Delphi Win32 more perfect.
No argument that it would be nice to have. But the number of cases where it
is really needed versus the cost of developing it *might* not make it
practical for Borland to do.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
Jason Smith
> unicode.
This might sound a hypothesis or intuition, yet to be proven. It would be ok
if you just use European languages. Many databases support Unicode. And most
Microsoft products (e.g. Microsoft Office) are unicode-enabled. Besides
project by project and/or company by company basis, Delphi has big market
share as a development tool for shareware markets. The support for Unicode
is just a standard item in modern software development. If Unicode was not
important, why would there a need to develop the standard for Unicode. And
if Unicode was not important, why did Microsoft reengineered their OS to
support Unicode today?
Day-to-day-use example of Win32 application -- chat messenger: I convince
people on my chat list to install MSN messenger for those who need to chat
in multiple languages (including Asian languages) as Yahoo messenger does
not have complete support for Unicode yet.
Enterprise-level example -- SAP: International companies might need
information of different langauges to exist together in a centralized
database. Since the ABAP 6.10 release, SAP was reengineered to accomodate
growth of the need of Unicode. SAP front-end built for Win32 might need
Unicode enability.
> No argument that it would be nice to have. But the number of cases where
> it is really needed versus the cost of developing it *might* not make it
> practical for Borland to do.
I guess the cost to develop VCL .Net + cost to convince people to switch to
VCL .Net from VCL win32 are even much higher. And yet, time will tell if it
is practical for Borland to do so.
> The majority of applications in Win32 *do not and will not require*
> unicode.
If you think majority of applications in Win32 *do not and will not require*
unicode, I would doubt how many majority of applications in Win32 *do and/or
will require* .Net.
In the earlier days, Borland said "If u need unicode supports then CLX";
Nowadays, Borland says "If you need unicode supports then .Net".
I might be biased, but it's interesting to see how this kind of strategies
will work.
I might be biased, but I would think VCL .Net will have the same fate as CLX
did.
Many people here are just not impressed by what VCL .Net can deliver.
Regards,
Jason
Lee Grissom
> Only because of Unicode?
I wrote "primary". In a corporate environment, things are generally not
black and white.
--
Lee
Lee Grissom
> My sincere condolences.
No need for that. :-) My job is fun, I love the people, and C# is a fine
language. It's the Delphi Team at Borland who has to bear the burden of
decisions that are out of their control. Delphi is the greatest IDE ever
made, but it's clear that Borland Corporate has their agendas as well. I
truly look forward to coming back to a full time Delphi job some day.
--
Lee
danny heijl
> The majority of applications
> in Win32 *do not and will not require* unicode.
I suppose you live in the US?
Windows codepage 1252 (or ISO-Latin1 or ISO-8859-1) has become largely
useless in Europe with the new memberstates. Only UTF-8 (for
storage/transport) and UCS-2 (for display) will do now.
Danny
---
Dave Nottage [TeamB]
> the lack of a Win32 Unicode solution from Borland forces a fresh
> choice of environment
You're talking about a pretty substantial change of environment,
including a change of platform, a change of language and possibly
rewriting substantial amounts of existing code, all to support *one*
aspect of the application.
That's still pretty "daft".
--
Dave Nottage [TeamB]
Roddy Pratt
message news:4301...@newsgroups.borland.com...
> You're talking about a pretty substantial change of environment,
> including a change of platform, a change of language and possibly
> rewriting substantial amounts of existing code, all to support *one*
> aspect of the application.
>
> That's still pretty "daft".
No disagreement there. But Borland's line that '.NET is the answer' involves
you doing all the above (minus the change of language) anyway to move from
VCL.WIN32 to VCL.NET...
[ disclaimer. I haven't had to do this on a delphi project, so I don't know
the EXACT pain level. But the number of IFDEF CLR lines I see in other's
code gives me some idea...]
- Roddy
Bryce K. Nielsen
> applications in Win32 *do not and will not require* unicode.
>
If that's not a biased opinion I don't know what is. You should say "The
majority of applications in Win32 *that I use* do not and will not require
unicode.". Oddly enough, the majority of the applications that I develop for
Win32 *do* use Unicode, and I would love it if Delphi VCL supported it
natively.
-BKN
Jason Smith
> involves you doing all the above (minus the change of language) anyway to
> move from VCL.WIN32 to VCL.NET...
.NET is the answer? I would say .NET is an uncertainty for desktop
application, at least for now.
> [ disclaimer. I haven't had to do this on a delphi project, so I don't
> know the EXACT pain level. But the number of IFDEF CLR lines I see in
> other's code gives me some idea...]
Pain levels not only for development but deployment as well.
Development: cost of code migration, unavailability of many 3rd party
components.
Deployment: overhead of .Net runtime
And what extra advantage do u gain? only for Incomplete Unicode support in
VCL .Net?
Jason
Jarle Stabell
>> The majority of applications in Win32 *do not and will not require*
>> unicode.
>
> This might sound a hypothesis or intuition, yet to be proven. It
> would be ok if you just use European languages.
Not even that. You ought to use Unicode if you are working with multiple
european languages.
> Many databases
> support Unicode. And most Microsoft products (e.g. Microsoft Office)
> are unicode-enabled. Besides project by project and/or company by
> company basis, Delphi has big market share as a development tool for
> shareware markets. The support for Unicode is just a standard item in
> modern software development.
> If Unicode was not important, why would
> there a need to develop the standard for Unicode. And if Unicode was
> not important, why did Microsoft reengineered their OS to support
> Unicode today?
Supporting it is an understatement, Unicode is the native string type of
both Win NT, Win2000 and XP. When not using Unicode on a modern MS OS, the
OS has to do conversions to and from Unicode. So MS has been using Unicode
as their native string type in their "real" OS'es since before Delphi 1.
I'm not alone in feeling that the limited Unicode support is the Achilles
heel of Win32 Delphi.
Cheers,
Jarle
Dave Nottage [TeamB]
> No disagreement there. But Borland's line that '.NET is the answer'
Out of the box? Sure, but it is not the only answer.
> involves you doing all the above (minus the change of language)
> anyway to move from VCL.WIN32 to VCL.NET...
Minus rewriting a lot of existing code.
--
Dave Nottage [TeamB]
Paras Kafley
>
> "Nick Hodges [TeamB]" <nickh...@gmail.com> wrote in
>
> > Does any 32-bit framework do Unicode?
>
>
> Qt.
>
> -- d
MFC if you can call MFC a framework <gd&r>
Paras
Paras Kafley
> The majority of applications in Win32 *do not and will not require*
> unicode.
Wayne, That's a fairly narrow view.
~Paras
Dave Nottage [TeamB]
> > The majority of applications in Win32 *do not and will not require*
> > unicode.
>
> Wayne, That's a fairly narrow view.
Are you saying the majority *will* require unicode? It can't be both
ways.
--
Dave Nottage [TeamB]
Jim Rowell
> Paras Kafley wrote:
>
> > > The majority of applications in Win32 *do not and will not require*
> > > unicode.
> >
> > Wayne, That's a fairly narrow view.
>
> Are you saying the majority *will* require unicode? It can't be both
> ways.
How about one half will require it, one half won't require it, and the other
half are undecided.
Dave Nottage [TeamB]
> > Are you saying the majority will require unicode? It can't be both
> > ways.
>
> How about one half will require it, one half won't require it, and
> the other half are undecided.
<g>
--
Dave Nottage [TeamB]
Jason Smith
> european languages.
Yes true. I just overlooked the European languages other than those included
in Windows codepage 1252.
> Supporting it is an understatement, Unicode is the native string type of
> both Win NT, Win2000 and XP. When not using Unicode on a modern MS OS, the
> OS has to do conversions to and from Unicode. So MS has been using Unicode
> as their native string type in their "real" OS'es since before Delphi 1.
Yes. And when I said re-engineered. It means Microsoft had to do another set
of UI controls in order to support Unicode. WideString native data type
alone was insufficient to have full unicode supports.
Cheers
Jason
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> Roddy Pratt wrote:
>
> > the lack of a Win32 Unicode solution from Borland forces a fresh
> > choice of environment
>
> You're talking about a pretty substantial change of environment,
> including a change of platform, a change of language and possibly
> rewriting substantial amounts of existing code, all to support one
> aspect of the application.
In Europe, having a local version of your software can be crucial (and
sometimes even a legal requirement). You won't be able to sell a lot of
English software in Germany of France, and I'm sure that in many other
countries, the same is true.
So that one aspect can be the difference between success and bankruptcy
for companies writing for that market.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"I'll moider da bum."
-- Heavyweight boxer Tony Galento, when asked what he thought of William
Shakespeare
Arthur Hoornweg
> Lot's of work to spend on rewriting Delphi code :-)
I wonder how many, if any, people actually migrate Delphi code from
Win32 to .NET? And if yes, for what reason?
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Arthur Hoornweg
>
> The VCL is derived from win32 controls which do not support UNICODE.
Most of them DO on Windows NT4 and higher...
Arthur Hoornweg
> But saying "Delphi
> doesn't give us Win32 Unicode, so we are switching to .Net and C#"
> doesn't make /any/ sense.
It does make some sense to me:
If Delphi doesn't give Win32 Unicode, one has 2 options to solve it:
- (a) Get some win32 components that DO give you Unicode
(such as Elpack or TNT)
- (b) Switch the platform to .NET.
This forces you to select a new development system. If you have
absolutely
nothing to migrate, you are fully free to select a new language.
I opted for option (a) because .net doesn't give me Unicode either (!!!)
if my application still has to support Windows 98 or ME.
Arthur Hoornweg
> I agree with that point -- a lack of Unicode support in Delphi Win32
> may cause folks to re-evaluate their environment.
>
> Given that, though, I still don't see the wisdom in leaving Delphi for
> C# under that scenario.
There are some points to consider:
- Do I actually need to port anything, or would I simply develop new
applications under .net?
- If there's nothing to port, I am obviously free to choose.
Will I stick with the language that I know so well? Am I prepared to
learn
something new? Would that look good on my resume, maybe even
improve my future career chances?
Arthur Hoornweg
> I agree with Nick.
>
> VCL means a lot to Delphi Win32 developers, especially in desktop
> applications. People can be reluctant to go either .Net or Java just because
> of the lack of support of Unicode.
Exactly. In my case, I switched to LMD Elpack for the Unicode support.
I use Delphi 7 pro.
Since then, the Borland VCL components in my component palette remain
unused because of the lack of Unicode support. All of the forms in my
current mega-application are completely stripped of Borland VCL
components !!!
It does not make sense to me to buy a new Delphi version if all the
brand new components it offers are going to remain unused as well!
Arthur Hoornweg
> Are you saying the majority *will* require unicode?
Since the majority of people on earth speaks either Chinese or Hindi,
I can confirm this with a loud YES.
Arthur Hoornweg
> The majority of applications in Win32 *do not and will not require* unicode.
Right. And everyone on Earth speaks English.
Larry Drews
@newsgroups.borland.com:
> Dave Nottage [TeamB] schreef:
>
>> Are you saying the majority *will* require unicode?
>
> Since the majority of people on earth speaks either Chinese or Hindi,
> I can confirm this with a loud YES.
>
It would seem to me that the number or percentage of people who buy or use
your software that speak either Chinese or Hindi would be the significant
figure. From what I read most of the Chinese and Hindi speakers are not
currently using computers for much of anything.
Arthur Hoornweg
> .NET doesn't support Unicode unter Win9x/ME in the GUI. Delphi with
> ElPack does.
... as long you're not trying to edit right-to-left ... But they're
working on that.
Angra Mainyu
> Arthur Hoornweg wrote
> @newsgroups.borland.com:
>
> > Dave Nottage [TeamB] schreef:
> >
> >> Are you saying the majority *will* require unicode?
> >
> > Since the majority of people on earth speaks either Chinese or Hindi,
> > I can confirm this with a loud YES.
> >
>
> It would seem to me that the number or percentage of people who buy or use
> your software that speak either Chinese or Hindi would be the significant
> figure. From what I read most of the Chinese and Hindi speakers are not
> currently using computers for much of anything.
Maybe you should take a moment and see what the rest of the world is actually
doing, you just could be in for the susprise of your life. You could start with
the book: "Three Billion New Capitalist".
ram...@bigpond.net.au
> > It would seem to me that the number or percentage of people who buy or use
> > your software that speak either Chinese or Hindi would be the significant
> > figure. From what I read most of the Chinese and Hindi speakers are not
> > currently using computers for much of anything.
>
> Maybe you should take a moment and see what the rest of the world is actually
> doing, you just could be in for the susprise of your life. You could start with
> the book: "Three Billion New Capitalist".
In this context it is interesting to note that the new Xbox 360 will
be manufactured in China...
Larry Drews
news:43032488$1...@newsgroups.borland.com:
>
> Maybe you should take a moment and see what the rest of the world is
> actually doing, you just could be in for the susprise of your life.
> You could start with the book: "Three Billion New Capitalist".
>
> http://tinyurl.com/dfnf8
>
What I would be interested in is the number of copies of software sold
world-wide and the number of copies sold to Chinese and Hindi speaking
people. Then we can see what % we are talking about.
Angra Mainyu
"Larry Drews" wrote
> "Angra Mainyu" wrote
> >
> > Maybe you should take a moment and see what the rest of the world is
> > actually doing, you just could be in for the susprise of your life.
> > You could start with the book: "Three Billion New Capitalist".
> >
> > http://tinyurl.com/dfnf8
> >
>
> What I would be interested in is the number of copies of software sold
> world-wide and the number of copies sold to Chinese and Hindi speaking
> people. Then we can see what % we are talking about.
What I'd be interested in is creditable validation of your statement, "From what
I read most of the Chinese and Hindi speakers are not currently using computers
for much of anything." That is what I responded to.
Dave Nottage [TeamB]
> > Are you saying the majority will require unicode?
>
> Since the majority of people on earth speaks either Chinese or Hindi,
> I can confirm this with a loud YES.
I'm talking about the number of applications, not people.
--
Dave Nottage [TeamB]
Nick Hodges [TeamB]
> - Do I actually need to port anything, or would I simply develop new
> applications under .net?
Even then, why not leverage your existing Delphi skills and code?
> Will I stick with the language that I know so well? Am I prepared to
> learn something new? Would that look good on my resume, maybe even
> improve my future career chances?
The latter would be a consideration for individuals, I suppose, but why
a business would make such a decision is a mystery.
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Larry Drews
Perhaps I am wrong, but my most recent understanding is that China is still
about 70%-80% agrarian, i.e., most of the Chinese population lives in a
farming environment, and that a majority of that farming environment is
still non-tech. From that I conclude that only a small % of the Chinese
population uses computers.
I don't know if the same % applies to India, but I do have the, perhaps
uniformed, impression that a lot of India is also still agrarian.
In contrast, only 3% or so of the U.S. population is agrarian, and that
population does make extensive use of computers.
I do not have any figures for other countries.
Please correct me if I am mistaken, with some actual facts.
Thanks.
Wayne Niddery [TeamB]
>
>> The majority of applications in Win32 *do not and will not require*
>> unicode.
>
> Right. And everyone on Earth speaks English.
Non-sequitur. While I understand that unicode makes internationalization
easier, people have been developing Delphi applications for years that work
in many different languages.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"Nurture your mind with great thoughts. To believe in the heroic makes
heroes." - Benjamin Disraeli
Ivan Rakyta
> in Win32 *do not and will not require* unicode.
Every application which can open file using open dialog requires Unicode
because the file system is Unicode.
So it makes about 99.99% of applications.
Craig Stuntz [TeamB]
> Arthur Hoornweg wrote:
> >
> > > The majority of applications in Win32 *do not and will not
> > > require* unicode.
> >
> > Right. And everyone on Earth speaks English.
>
> Non-sequitur. While I understand that unicode makes
> internationalization easier [...]
That's like saying that the VCL (or even WinForms) is "easier" than
the WinAPI. True, yes, but misleading as it understates significantly
the magnitude of "easier." The "English" bit is misleading, too, as
what's really hard is anything other than the system default charset.
Non-experts most likely *will* have problems when transliteration
begins.
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
Rudy Velthuis [TeamB]
> - Do I actually need to port anything, or would I simply develop new
> applications under .net?
>
> - If there's nothing to port, I am obviously free to choose.
Why would you choose something that required you to learn so much new
stuff (C# language, C# RTL, WinForms, etc.)? Do you have too much spare
time?
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Imagine if every Thursday your shoes exploded if you tied them the
usual way. This happens to us all the time with computers, and nobody
thinks of complaining." -- Jeff Raskin.
Rudy Velthuis [TeamB]
So are most cheap toys. That does not mean that all Chinese use or
purchase these toys. <g>
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"As God once said, and I think rightly..." -- Margaret Thatcher.
Rudy Velthuis [TeamB]
> Dave Nottage [TeamB] schreef:
>
> > Are you saying the majority will require unicode?
>
> Since the majority of people on earth speaks either Chinese or Hindi,
> I can confirm this with a loud YES.
Not the majority. A large part it probably is, indeed.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Never interrupt your enemy when he is making a mistake."
- Napoleon Bonaparte (1769-1821)
Arthur Hoornweg
> So are most cheap toys. That does not mean that all Chinese use or
> purchase these toys. <g>
Rudy, there's a new road restaurant at the German/Dutch border near
Enschede. You may know it. The last year I've noticed an exponential
increase in Chinese tourists visiting it. They really are the capitalists of
the near future.
Arthur Hoornweg
> Perhaps I am wrong, but my most recent understanding is that China is still
> about 70%-80% agrarian, i.e., most of the Chinese population lives in a
> farming environment, and that a majority of that farming environment is
> still non-tech. From that I conclude that only a small % of the Chinese
> population uses computers.
Even if only 10% of Chinese households has computers that adds up to more
than the entire USA!
Arthur Hoornweg
> Why would you choose something that required you to learn so much new
> stuff (C# language, C# RTL, WinForms, etc.)? Do you have too much spare
> time?
Don't mistake me, I'm not keen on moving away from Borland at all, I'd much
rather have a native Win32/Win64 Delphi with full Unicode support.
But if I'm ever forced to go the .NET way, I simply have nothing to port
because
everything I do is COM based.
If one switches from D7/win32 to D20057NET one has to learn the
concepts and
classes of the .NET framework anyway, plus the intricacies of the new
IDE, so
there's a lot of learning involved whatever option one chooses. And doesn't
D2005 include a C# identity anyway?
Dave Nottage [TeamB]
> Even if only 10% of Chinese households has computers that adds up to
> more than the entire USA!
Again, the question was about the software, not the people.
Yes, the people use the software, but how many Delphi apps are out
there where the users of them want to use it with a language that needs
to be represented using unicode? ie: is it the majority of Delphi
apps?, which was my original point.
It's a matter of curiosity only for me anyway: I was suspicious of the
claim that the "majority" need unicode.
--
Dave Nottage [TeamB]
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] schreef:
>
> > So are most cheap toys. That does not mean that all Chinese use or
> > purchase these toys. <g>
>
> Rudy, there's a new road restaurant at the German/Dutch border near
> Enschede. You may know it.
No, I don't. I usually travel through Ahaus to Enschede.
The last year I've noticed an exponential
> increase in Chinese tourists visiting it. They really are the
> capitalists of the near future.
No doubt. But it is still a long time. Currently, I'd guess most Chinese
don't have a computer, or even access to one.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"It's kind of fun to do the impossible."
- Walt Disney (1901-1966)
Jarle Stabell
> Arthur Hoornweg wrote:
>
>> Even if only 10% of Chinese households has computers that adds up to
>> more than the entire USA!
>
> Again, the question was about the software, not the people.
>
> Yes, the people use the software, but how many Delphi apps are out
> there where the users of them want to use it with a language that
> needs to be represented using unicode?
I don't know if there's any such language at all, at least it isn't used by
many.
But that is not the point, the main benefit of Unicode is that then you can
support *multiple* languages for "free", and today it is probably wise to
use Unicode instead of using some older technology to represent languages
like Japanese or any of the Chinese languages.
> ie: is it the majority of
> Delphi apps?, which was my original point.
> It's a matter of curiosity only for me anyway: I was suspicious of the
> claim that the "majority" need unicode.
I agree with you if one interprets 'need' in a strict sense.
But Unicode is the native string type of all modern MS OS'es, and it is the
native string type of both Java and .NET, isn't it rather obvious that
Unicode is what most of us will be using some time in the future, regardless
of whether we "need" it or not?
Non-Unicode strings will eventually become a thing of the past.
Cheers,
Jarle
Angra Mainyu
> "Angra Mainyu" wrote
> >> What I would be interested in is the number of copies of software
> >> sold world-wide and the number of copies sold to Chinese and Hindi
> >> speaking people. Then we can see what % we are talking about.
> >
> > What I'd be interested in is creditable validation of your statement,
> > "From what I read most of the Chinese and Hindi speakers are not
> > currently using computers for much of anything." That is what I
> > responded to.
>
> Perhaps I am wrong, but my most recent understanding is that China is still
> about 70%-80% agrarian, i.e., most of the Chinese population lives in a
> farming environment, and that a majority of that farming environment is
> still non-tech. From that I conclude that only a small % of the Chinese
> population uses computers.
>
Based an a few minutes Googling I come to the conclusion that presently there
are an estimated 90-100 million computers in China with that number doubling
every 24-30 months.
In July 2004 it was reported in China there are 87 million internet users which
had risen by 28% from the year before, so today at the same growth rate there
are 111 million internet users.
According to U S Commerce Service China: "In 2004, sales of all types of
software and software systems reached USD 25.4 billion, an increase of 28%.
Software and system integration sales revenue reached USD 19.7 billion" At the
same growth rate the total would currently be USD 32.5 billion
I guess it all boils down to "only a small % of the Chinese population uses
computers" but since the population is 1.3 billion the total is already an
impressive number and growing at a staggering rate and a USD 32.5 billion
software market is not to be sneezed at.
It's still not too late to start reading "Three Billion New Capitalist" ;-)
http://tinyurl.com/dfnf8
Larry Drews
>
> Based an a few minutes Googling I come to the conclusion that
> presently there are an estimated 90-100 million computers in China
> with that number doubling every 24-30 months.
>
> In July 2004 it was reported in China there are 87 million internet
> users which had risen by 28% from the year before, so today at the
> same growth rate there are 111 million internet users.
>
> According to U S Commerce Service China: "In 2004, sales of all types
> of software and software systems reached USD 25.4 billion, an increase
> of 28%. Software and system integration sales revenue reached USD 19.7
> billion" At the same growth rate the total would currently be USD 32.5
> billion
>
> I guess it all boils down to "only a small % of the Chinese population
> uses computers" but since the population is 1.3 billion the total is
> already an impressive number and growing at a staggering rate and a
> USD 32.5 billion software market is not to be sneezed at.
>
> It's still not too late to start reading "Three Billion New
> Capitalist" ;-) http://tinyurl.com/dfnf8
>
Thank you for the follow-up. I didn't realize that the Chinese computer
usage had reached those levels.
-Larry Drews
Angra Mainyu
>
> Thank you for the follow-up. I didn't realize that the Chinese computer
> usage had reached those levels.
You are most welcome. For a while when you kept insisted there wasn't much
Chinese computer usage, I thought maybe you were a CIA analyst. ;-))
Arthur Hoornweg
> Yes, the people use the software, but how many Delphi apps are out
> there where the users of them want to use it with a language that needs
> to be represented using unicode? ie: is it the majority of Delphi
> apps?, which was my original point.
Problem is, US-based software developers will probably never need Unicode.
Europe- or Asia-based software developers often can't do without it.
If Borland were located in, say Delhi, we would have had Unicode ten
years ago.
Dave Nottage [TeamB]
> Problem is, US-based software developers will probably never need
> Unicode. Europe- or Asia-based software developers often can't do
> without it.
>
> If Borland were located in, say Delhi, we would have had Unicode ten
> years ago.
I expect you're under-estimating the number of people there that can
use software with a language that doesn't require unicode.. but that is
a guess.
I also imagine that sales of Delphi in middle-Asia is pretty strong
compared to the US, despite the lack of unicode support for Win32 out
of the box.
--
Dave Nottage [TeamB]
Max
> Dave Nottage [TeamB] schreef:
>
>> Yes, the people use the software, but how many Delphi apps are out
>> there where the users of them want to use it with a language that needs
>> to be represented using unicode? ie: is it the majority of Delphi
>> apps?, which was my original point.
>
>
> Problem is, US-based software developers will probably never need Unicode.
> Europe- or Asia-based software developers often can't do without it.
>
> If Borland were located in, say Delhi, we would have had Unicode ten
> years ago.
BTW: The biggest software market outside the US is Germany (öäüÖÄÜ߀).
Yannis
> don't have a computer, or even access to one.
Considering this statement as a fact and the actuall population of the
Chinese I guess that I would make it my bussines to invest in this market
today because it will have the biggest expansion tomorow.
Regards
Yannis
Danny Thorpe
> Does anyone know if Borland if ever plans to add Unicode support in
> VCL. Yes i know it is a major undertaking and everything that goes
> with it, but not having unicode support in Delphi IMHO is fairly big
> drawback. I know that there are good and free Unicode controls for
> Delphi, but it sure would be nice to have unicode support in the core
> product.
> To me to be prefectly honest support for Unicode is far more important
> than support for 64 bit native compiler and to hazard a guess I am not
> the only one.
>
> ~Paras
Paras,
The main question is: How much compatibility are you willing to
sacrifice to get a Unicode VCL? Unicode VCL for Win32 will not be
fully compatible with many third party components out there. Unicode
VCL for Win32 will require new component designers in the IDE that will
not be compatible with Ansi VCL. Unicode VCL for Win32 will require
new design interfaces in the IDE which will not be compatible with the
existing design-time interfaces.
If we had the luxury of throwing a giant switch and making all strings
everywhere in VCL and the IDE Unicode, then these compatibility issues
might not be as severe (but there would still be breakages), but in
reality it will be necessary to keep the Ansi VCL going in parallel
with a new Unicode VCL. Unicode VCL and today's Ansi VCL controls are
very unlikely to be mixable in the same application (because one of
them would have to be the dominant model, and the other would be
penalized with string conversion performance bottlenecks and potential
data loss). Ansi and Unicode VCLs must coexist in the same IDE. That
means double the effort in the IDE, designers, components, data
support, and compiler, and double the effort for third party component
developers.
Yes, we intend to produce a Unicode VCL. We already have in VCL.NET,
and the only sane choice for 64 bit VCL is all-Unicode. The cost of
adding Unicode support is less when you are starting with a new
platform base which already has a compatibility barrier.
-Danny
--
Delphi Compiler Core: http://blogs.borland.com/dcc
Kevin Berry
> Yes, we intend to produce a Unicode VCL. We already have in VCL.NET,
> and the only sane choice for 64 bit VCL is all-Unicode. The cost of
> adding Unicode support is less when you are starting with a new
> platform base which already has a compatibility barrier.
Danny... good to see you getting involved here...
Just don't forget about the need to maintain 32-bit and 64-bit versions
of applications off the same code base... I think many 64-bit
development projects will need to produce EXEs for both platforms.
Cheers,
Kevin.
Bryce K. Nielsen
> and the only sane choice for 64 bit VCL is all-Unicode. The cost of
> adding Unicode support is less when you are starting with a new
> platform base which already has a compatibility barrier.
>
Does this mean that D64 is being worked on, and not just "use DotNet if you
want to run Win64 code"?
-BKN
Thomas Miller
>
> Yes, we intend to produce a Unicode VCL. We already have in VCL.NET,
> and the only sane choice for 64 bit VCL is all-Unicode. The cost of
> adding Unicode support is less when you are starting with a new
> platform base which already has a compatibility barrier.
>
> -Danny
>
Yes, break my code. Just make it easy to compile on a Unicode version
of Delphi and a ANSI version. If I had to use D7 or D2005 to compile
my code for ANSI, that would be fine.
I think D7 should be shipped from now on with all future Delphi SKUs.
Much like D1 was shipped for a long time with newer versions.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus
Dan Barclay
> Yes, break my code.
Ye know not until you've been there...
http://www.fawcette.com/vsm/interviews/storage.pdf
"After some discussion, I got up on my soapbox and suggested, "Drop backward
compatibility altogether. Do us a favor; haven't you guys learned the lesson
of DOS? Backward compatibility cost us so much money over the years. Break
my code. Force me into getting rid of my old code if I want to add VB7
features into my product."
And they did... We got VB.Net. Don't even *think* about going there. It's
far more ugly than has even crossed your mind.
http://vb.mvps.org/vfred/Trust.asp
Dan
"Thomas Miller" <tmi...@bss-software.com> wrote in message
news:430b...@newsgroups.borland.com...
Max
Nevertheless, I would appreciate a native UNICODE VCL with 64 bit.
--
-------------------------------------------------
Binary Packets with daily error corrections
http://www.de.freepascal.org/lazarus/
New: Free Pascal 2.1.1 / Lazarus 0.9.9
-------------------------------------------------
Create native 64-bit compiler/IDE
Vote http://qc.borland.com/wc/qcmain.aspx?d=7324
-------------------------------------------------
Parameterized Types (aka Generics) also for Win32
Vote http://qc.borland.com/wc/qcmain.aspx?d=11168
-------------------------------------------------
Help system needs major work
Vote http://qc.borland.com/wc/qcmain.aspx?d=13986
-------------------------------------------------
Dave Nottage [TeamB]
> Yes, break my code.
But don't break mine <g>
See also Dan's reply. I couldn't agree more.
--
Dave Nottage [TeamB]
Arthur Hoornweg
> Another thought: A UNICODE VCL does not run on Win95/98/Me anymore.
Not necessarily. Elpack runs fine. Just select a Unicode font.
As far a I'm concerned, it is sufficient if properties "caption" and "text"
are of type widestring and to have an implementation of tWidestringlist.
Tcanvas also needs a method TextoutW, and I desperately need a
tfield of type tWideMemoField. I don't necessarily need Unicode file
routines etc.
Thomas Miller
not, otherwise you wouldn't have a problem with this. The problem
is how does .AsString or .Text know when to handle it as an ANSI
and when to handle it as UNICODE? It can't. The only thing you
would have to do is update any literals stored in the DFM. That
could be done easily with an update program.
The break would be so minor, it shouldn't take more then a week
to convert several hundred units.
Dave Nottage [TeamB] wrote:
> Thomas Miller wrote:
>
>
>>Yes, break my code.
>
>
> But don't break mine <g>
>
> See also Dan's reply. I couldn't agree more.
>
--
Dan Barclay
The point is, neither you nor Borland has any of understanding the way it
would break *someone else's* code.
I honestly don't know the answer to these questions, but the effect has hit
hard before:
>The problem
> is how does .AsString or .Text know when to handle it as an ANSI
> and when to handle it as UNICODE?
Do developers use "string" for binary data? (note I didn't say "should").
> The break would be so minor, it shouldn't take more then a week
> to convert several hundred units.
Let me introduce you to a few million VB developers. Few of the breaks
introduced by MS seem significant by themselves. Together they are
impenetrable. You either have a stable language or you don't. There are
literally millions of VB developers with billions of lines of code that will
not be moving to VB.Net because of it.
That's not to say there isn't a good way to accomplish UNICODE in Delphi. I
will outright state that purposely breaking code shouldn't be on the list
though.
Dan
"Thomas Miller" <tmi...@bss-software.com> wrote in message
news:430c...@newsgroups.borland.com...
Danny Thorpe
> The only thing you
> would have to do is update any literals stored in the DFM. That
> could be done easily with an update program.
>
String literals in DFM files are already stored as UTF-8, a compressed
Unicode encoding. UTF-8 looks like ANSI/ASCII for chars < 128. No DFM
update utility is required.
> The break would be so minor, it shouldn't take more then a week
> to convert several hundred units.
>
The breaks I'm referring to run far deeper than DFMs. How much code do
you have that runs through a PChar array by incrementing a pointer by
one? In a Unicode world, PChar = PWideChar, which means each char is 2
bytes.
Similarly, any code that scans a string assuming that the first zero
byte is the null terminator will fail with Unicode strings, because
most Unicode chars (for English) have a zero high byte.
For most Win32 APIs involving string data, there are matching Ansi and
Unicode definitions. But not all. Which of the Win32 APIs that you
rely on today are not symmetric?
How much code do you have that is aware of multibyte character
encodings for Middle Eastern or Far Eastern languages? In a Unicode
world, most MBCS gymnastics are completely unnecessary and most are
benign, but a few MBCS code patterns actually fail on Unicode. See the
byte assumption above.
WideStrings are currently implemented by Delphi as OLEStr, aka BStrs,
allocated using the SysAllocString Win32 API. These are not reference
counted, and are rather promiscuous in copying themselves for every
reference. Clearly, the Delphi WideString implementation needs to be
changed to a reference counted WideString to save memory and
performance if WideString is to become the primary string data type.
But that means Delphi's WideString will have different allocation
semantics from OleStr. Reference counted WideStrings will have to be
converted to single-reference copies before being passed out of the
application to Win32 APIs expecting PWideChar buffers.
Breaking the WideString = OleStr type alias means that all the Win32
APIs that are now declared as taking WideString will need to be changed
to OleStr. We'll handle Windows.pas and the other Win32 API units we
provide, but you will have to do the equivalent work on any other DLL
API declarations your applications use. Until you find them all and
fix them, your app will compile fine but will crash mysteriously at
runtime. The compiler can't help you here because the compiler can't
tell if the DLL you're calling actually expects OleStr or if it's a
Delphi DLL that's actually expecting a Delphi reference counted
WideString. The compiler has to rely on you to get the declarations
right.
If your code and the components you use have been ported to Linux or
.NET in the past, then chances are these kinds of things have already
been found and modified to be char size agnostic.
Unicode VCL sounds like such a simple, little thread... until you start
pulling on it.
Danny Thorpe
> Another thought: A UNICODE VCL does not run on Win95/98/Me anymore.
> Nevertheless, I would appreciate a native UNICODE VCL with 64 bit.
Correct. Win95 and Win98 do not fully implement Unicode case
conversion or case insensitive string compares. By extension, that
means Unicode file names are not supported.
Kevin Berry
> Do you understand the way it would break your code? Obviously
> not, otherwise you wouldn't have a problem with this. The problem
> is how does .AsString or .Text know when to handle it as an ANSI
> and when to handle it as UNICODE? It can't. The only thing you
> would have to do is update any literals stored in the DFM. That
> could be done easily with an update program.
>
> The break would be so minor, it shouldn't take more then a week
> to convert several hundred units.
Not really...
What about the performance of WideString vs String? When I converted my
app to Unicode a while back the actual conversion was quick (I replaced
all "String" instances with "WideString" and replaced and wrote a number
of functions where they didn't deal with WideStrings properly or at
all). However, the part that did take a while was fixing performance
issues- WideStrings behave quite differently. I ended up writing my own
StringBuilder type class to deal with the cases where performance was an
issue. While this wasn't that involved it wasn't very simple either.
Especially when I ran into the WideString crashing issue with strings >
4K or so.
Also, as a precautionary measure I changed all of my properties that
were called things like AsString to AsWideString so that I knew exactly
where the changes occurred so I could verify that the code would work
alright. I also use a naming convention of sStringVar for strings and
wsStringVar for WideStrings. This made the conversion smoother too
because it forced changes throughout the code just to get it
recompiling- instead of finding problems at runtime.
Some of the gotchas regarding String and WideString also involve
automatic typecasting. Delphi does (or used to in Delphi 7) do some
strange things with type coercion for WideChars I believe (it treats
them like integers where char is automatically converted to a string).
It would be nice if Delphi treated WideChar like WideString rather in
these scenarios. Also, I found problems concatenating something like
this 'some ansi string' + WideStringVar. The end result was a String
instead of a WideString. This was a while back so some of these details
may be wrong. :-)
Cheers,
Kevin.
Nick Hodges [TeamB]
> Unicode VCL sounds like such a simple, little thread... until you
> start pulling on it.
... thus proving once again that nothing is as simple as the average
non-tech poster thinks. ;-)
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Mike Swaim
> What about the performance of WideString vs String? When I converted
> my app to Unicode a while back the actual conversion was quick (I
> replaced all "String" instances with "WideString" and replaced and
> wrote a number of functions where they didn't deal with WideStrings
> properly or at all).
Remember, WideStrings are COM objects, so they're
allocated/deallocated by the OS, leading to performance issues. Strings
in Unicode Delphi probably won't be WideStrings for performance reasons.
--
Mike Swaim sw...@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mps...@mdanderson.org or msw...@odin.mdacc.tmc.edu at work
ICBM: 29.763N 95.363W|Disclaimer: Yeah, like I speak for MD Anderson.
Roddy Pratt
news:xn0e6dfh...@newsgroups.borland.com...
> The breaks I'm referring to run far deeper than DFMs. How much code do
> you have that runs through a PChar array by incrementing a pointer by
> one? In a Unicode world, PChar = PWideChar, which means each char is 2
> bytes.
Just thinking about that makes me scared. The balance-sheet for this
approach makes no sense to me:-
Plus: "Your old applications will become unicode, simply by recompiling
them"
Minus: "Your applications will then break, losing you data, clients and
money"
The TNT model - (with a totally separate set of components), where char is
8-bit and widechar is 16-bit gives the developer complete control of how
much of an application is unicode. And many applications (particularly those
connecting to external systems) can never be 100% unicode. They will always
have a mix of unicode and non-unicode sections.
Also, TNT unicode is probably the most used unicode solution for win32
unicode developement on BCB and Delphi, so something that works with a
similar model will have advantages. In fact the only disadvantage of the TNT
components is that they aren't considered 'part' of Delphi, so 3rd party
component packs either reinvent the unicode wheel differently, or simply
don't bother.
I haven't thought this through in detail, but how about this approach?:-
Char/String : 8 bits
WideChar/WideString: 16 bits (but preferably faster than COM)
XChar/XString (8 or 16, depending on project options). with automatic
typecasts to and from the alternate representations.
Now any code written to use XChar/Xstring MUST be expected to be compatible
both ways. The VCL - and 3rd party libraries wanting unicode - can be
modified to use them pretty where appropriate, and just compiled both ways
to make libraries. I'm not sure of you need multiple sets of VCL components
(TLabel, TWLabel, TXLabel?) at design time. Possibly you may require
non-unicode VCL components even if your application is mostly unicode...?
Be gentle with me if it's totally implausible!
- Roddy