Re: Did Borland doing well in Q4? Listen to the Earning CC

In article <47cc4615$1@xxxxxxxxxxxxxxxxxxxxxx>, markus.humm@xxxxxxxxxx
says...
Hello,

do you have any other proposal how they should make the transition? It
_will_ occur someday.

Yes, I've gone into at length before, and it's really quite simple.

Extend String RTTI to include encoding information.

Currently we have length and reference count, to that I suggested we add
Encoding.

Encoding would be UTF8, UTF16, UTF32 or an ANSI codepage #.

"String" declarations would map onto a project specific default
encoding, with the existing (and some new) string types providing
"macros" for declaring strings of certain encodings:


s: String; // Determined by project options
sA: ANSIString;
s8: UTF8String;
s16: UTF16String;
s32: UTF32String;


For an old project opened for the first time, the new "String Encoding"
project option would of course default to ANSI, using the "system"
codepage.

The RTL would be extended to support transcoding of strings as required:

s8 := s16; // Converts s16 to UTF8 in s8
s := s8; // Converts s8 (UTF8) to ANSI - codepage
// determined from RTTI of s

For conversion to/from specific codepages, RTL routines would be
provided:

s := UTF8ToANSI(s8, cp1251);


NOTE: It would not be possible - with one exception - to change the base
encoding of a string, i.e. from UTF8 to UTF16 or UTF?? to ANSI or vice
versa.

The exception to this rule might be for ANSI strings, where it would be
possible, via RTL support, to change the code page, if required:

SetCodePage(s, cp1250); // Compilation error if "s" is not ANSIString

And of course interrogate the codepage:

cp := GetCodePage(s); // Compilation error if "s" is not ANSIString


Or alternatively codepage might also be immutable in which place
conversion could not be perfoemd "in place", i.e. :

s1250 := ChangeCodePage(s, cp1250); // Compilation error if "s" is
// not ANSIString



The real beauty I see in this approach is that if you are supplied a DCU
(e.g. the VCL) which was compiled with "String" mapping to ANSIString,
and you are compiling an application with "String" mapping to (e.g)
"UTF8String", it doesn't matter.

i.e. you get to choose the encoding most appropriate to your needs.


For an existing application it would of course be the other way around:
the VCL could be UTF16 and your existing ANSI application and all your
code would continue to use ANSIStrings.

You could use existing components/libraries consistently (one caveat
being if you changed your project string encoding to something other
than ANSI, at which point you would need to have ensured Unicode
"friendliness" of any 3rd party code you are using that uses "String"
types.

BUT

That would be a choice you make and a positive decision that you take,
which - key point - you could easily reverse if needed.


And: your example with the BDE isn't really fitting here as the BDE is
shipping till today which gave you a multi year migration period.

It may be shipping, but it aint working in many cases.

There is a multi-year migration period for Tiburon too. Just keep using
D2007 until you've changed tools/languages completely or simply have no
choice but to do the Unicode Boogie Tiburon Stylee.


That is backwards compatibility!

No, it's mothballing. As long as the BDE continues to work, great. But
if you have problems you will not get any help from Borland since it has
been an officially deprecated product for years.

And none of the DB vendors supported by SQL Links are under any
obligation to continue to support the client stacks that the BDE relies
on, and aiui in the case of SQL Server, that support will come to a
grinding halt in SQL Server 2008.

Even SQL Server 2005... iirc it supports connections from DBLIB, but
doesn't come *with* DBLIB. So if you are upgrading from a SQL Server
2000 client, the BDE will be fine. But if you are installing an
entirely fresh SQL Server 2005 client you will need to have a SQL Server
2000 client installer handy too.

At least that's my understanding.

In any event that backwards compatability that makes all this work is
nothing to do with Borland/Inprise/CodeGear, and everything to do with
the DB vendors.

So if you want to hallelujah backwards compatability, sing the praises
of Oracle and Microsoft etc etc.


(ok dbExpress is completely different but
imho needed to be to provide more possibilities)

Greetings

Markus

.

Relevant Pages

  • RE: Bug in My.Computer.FileSystem.WriteAllText
    ... ByVal file As String, _ ... The first one is using System.Text.Encoding.UTF8 as the default encoding. ... for BOM) is provided. ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • urwid with multi-byte encoded and bidirectional text?
    ... I would like to support whatever encoding the user likes. ... *new* line translation format would have to support characters that are ... N bytes in the string and M columns wide when displayed, ...
    (comp.lang.python)
  • Re: text datatype support
    ... Unicode or in the default character encoding of the database. ... True means that string parameters are sent to SQL Server in ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Is there support for the ANS LIST Statement in SQL Server?
    ... We are considering moving our application to MS SQL Server from another ... When I have looked at the documentation I do not see any support ... for the ANS LIST statement. ... string containing a list of items matching the WHERE clause separated by the ...
    (microsoft.public.sqlserver.server)
  • Re: Web app security
    ... to make the.NET AES encryption to work together with the AES encryption ... BTW, in your code, you first use Unicode Encoding to convert string to ... Microsoft MSDN Online Support Lead ...
    (microsoft.public.dotnet.framework.aspnet)