Hi Team,
I was just pondering the current directions of PC hardware, OSs and software in general.
PC hardware is really more than capable of, if not designed for, 64+bit.
I see it inevitable that Micro$oft will one day say 'No More' to 32 bit and only offer 64 bit.  Not tomorrow but not too far away either.  Effectively Apple has already done this.
Further, I see more and more software suppliers moving towards 64bit and to Unicode.  Yes I know they are not tied together.
I see 3rd Party Libraries for Delphi will go all Unicode to simplify their support demands.  e.g. Indy is going that way.  I expect others to follow.
This means that the lower orders, non-Unicode versions, of Delphi will be left in the cold.  As with other trends, this is inevitable.
So, to the reason really for this post/discussion - I have always stuck with non-unicode (ANSI) development.  It has caused me headaches in some cases but they haven't been insurmountable.
With an eye to the future - What needs to be done to move a non-unicode App & EDB Database to Unicode?
Perhaps this post would have been better in the ElevateDB General area but I figured there will be a lot of discussion about the subject rather than the question.

Over to you...
Ian

Ian


Remembering the discussions at the time on the Embarcadero newsgroups we were constantly told there was virtually nothing to do. If you had followed the correct approach for development that was fairly correct.

One of the biggest issues (so my memory says) was use of strings as storage rather than using a TBytes or some such construct. You mentioned Indy, a lot of the comms software relied on char = byte and had to be altered. In many cases this simply meant changing : string to something more appropriate.

There were blogs about the conversion - I'll see if I have any of them stored somewhere.

You'll have to convert your tables from ANSI to Unicode. I seem to recall that export / import was the best way forward for that. As far as the application is concerned try compiling as 64 bit unicode and fix errors and test

Roy Lambert

Ian Branch wrote:

> Is Unicode inevitable?

Sounds more like you are asking if you should upgrade your Delphi beyond 2007? If so, I'd say yes if you are actively using Delphi for new code. (Not using Delphi at all is a separate conversation!).

In general, moving to the newer version has been simple for me. Only in things like encrypting strings was it an issue where I'd have to change "string" to "AnsiString" to get the correct bytes. One application I haven't updated because it uses strings as a transfer buffer, and they can get up to 2GB long. I can't copy it at any point due to size, and accidentally making it two-bytes-per-char would take it beyond the 2GB memory limit of 32-bit processes. I should really rework it, but I've moved to C# really, so don't want to...

--

Matthew Jones

Hi Matthew,
   Using D10.3.3 att but sticking mainly with ANSI att.
Ian

On 2/9/2020 5:02 PM, Ian Branch wrote:
> With an eye to the future - What needs to be done to move a non-unicode App & EDB Database to Unicode?

My $0.02

I'm going to assume you want to move to Delphi/Windows Unicode which is
UTF-16 (UTF-8 is most popular unicode encoding these days on web and
mobile but that you have to manage yourself if you wish to use internally).

For delphi unicode migration it depends on what your app does with
strings (or if using strings as byte arrays) but in general I'd agree
with others that migration itself is mostly straightforward.

Assuming you currently use "string" type and mostly use delphi string
manipulation (string,copy, iteration etc) most of it should work as is.

If you use lot of C style api calls (i.e. memcpy, move etc) it's bit
more work to go thru all of that.

Embarcadero white papers are actually pretty good starting point :

https://www.embarcadero.com/rad-in-action/migration-upgrade-center

EDB side is simpler - in fact there is a native edb migrator included
with edb to migrate from ansi<->unicode etc

Few other considerations are things like loading files (i.e. need to
consider file encoding) and sorting and searching but usually not big
deal and just do some testing

64-bit like you said is not related to unicode directly but again unless
you load external DLLs is mostly taken care of (you do need components
that are compatible and if you load any external DLLs then those you
need 64bit versions also).


Raul

Ian Branch wrote:

> Hi Matthew,
>    Using D10.3.3 att but sticking mainly with ANSI att.
> Ian

So you are just asking if you should switch to using Unicode database storage. I'd say yes, far more flexible string storage, and no conversions to mess things up.

--

Matthew Jones