Re: Indy and D5 to XE6 migration

Giganews Newsgroups
Subject: Re: Indy and D5 to XE6 migration
Posted by:  Remy Lebeau (re…
Date: Wed, 24 Sep 2014

jkomorowski wrote:

> The highest revision number present in that Indy source is "Rev 1.146"
> its highest revision number is also "Rev 1.146".

SVN does not store revision history inside the source files themselves.
You are looking at old history that was carried over from Indy's previous
VCS system, TeamCoherence.

> But the very first compilation attempt indicated that both versions are
> not identical

No, they are not.

> Then I've noticed other (numerous) differences.

Yes, there have been numerous changes to Indy over the past 4 years, to support
Embarcadero's migration to Unicode, and then its migration to mobile.  Some
of the more notable changes have been blogged about on Indy's website:

> 1. Should we migrate also to Indy version included in XE6?

Yes, or even the latest from Indy's SVN, which is newer than what shipped
with XE6 or even XE7.

> 2. Are there particular unicode-related "precautions" to take?

Since Embarcadero's migration to Unicode, Indy has become very Unicode-aware
internally.  Just about everything (with a few exceptions) is done in Unicode
now.  When using Indy in pre-Unicode versions of Delphi, Indy still uses
Unicode internally, but also performs Ansi<->Unicode conversions in many
interfaces, most of which provide extra optional parameters so you can have
more control over which Ansi charsets are used for the conversion.  Those
do not apply in Unicode versions of Delphi.

One notable gotcha I encountered alot when migrating Indy to Unicode is use
of TStringStream.  TStringStream is encoding-aware now.  Be careful when
using Indy to fill a TStringString, such as with TIdHTTP or TIdMessage.
In pre-Uicode versions, TStringSteam wrapped an AnsiString, and it would
read/write that AnsiString as-is, and its DataString property would simply
access that AnsiString directly.  Now TStringString wraps a byte array, and
its DataString property performs a data conversion based on the encoding
you specify (or don't) in TStringStream's *constructor*.  Which means you
have to know the correct byte encoding up front.  If the bytes you store
in the stream do not match the declared encoding, you will get data errors.
In some cases, you may need to switch to TMemoryStream and perform manual
conversions afterwards, such as with ReadStringFromStream().  That way, you
can detect/choose the correct encoding after storing the bytes in the stream.

Remy Lebeau (Indy Team)


In response to

Indy and D5 to XE6 migration posted by jkomorowski on Wed, 24 Sep 2014