August 1, 2013
I'm spending some time focusing on migration of applications written with old versions of Delphi. First step, the technical issues making things difficult.
I'm spending some time focusing on migration of applications written with old versions of Delphi. First step I want to focus on in this blog post are the technical issues making things difficult. Later on, I'll move to potential solutions. For now, let's keep the reason why one wants to move (or prefers to stay with his current, old version of Delphi) at a side.
There are several issues our customers are facing when migrating the code of their old VCL applications to a recent version of Delphi (still building Win32 VCL applications). In most cases, if you reopen an existing Delphi 7 application in Delphi XE4 and try to recompile it you’ll receive a lot of errors.
Here are some technical issues preventing an application to re-compile directly (I might be missing others):
1. Existing compiled code (DCU, BPL) Delphi developers built or received (in case of third party components) cannot be used in newer versions of the product. All code needs to be recompiled from the original sources
2. Delphi developers on versions before 2009 have to upgrade their string management source code to embrace Unicode (this is the single most relevant change to Delphi causing incompatibility). Unicode support also implies mapping to a different set of Windows API functions (Wide vs. Ansi)
3. Depending on their original version, developers have to fix some minor issues related with functions and classes moved to different units, signature changes, features deprecated over time, etc. Nothing major if you know what to look for...
4. Many applications stuck on old versions of Delphi are still based on the BDE (or other old database engines, not fully supported any more).
5. Applications might use third party components available only in compiled format and not available any more (see issue 1 above)
6. Applications might use third party components not available any more, and with source code that doesn’t compile (due to the issues 2, 3, 4). At times, a new version of the component is available but hard to find (for example, now part of a different library)
7. Applications might use third party components still available today, but with many incompatible changes, causing them a hard time to migrate their code to the new version of such components (understandably, many components added features or changed their interfaces over such a long time frame)
Did you see any other technical reason blocking the migration of existing Delphi source code on older versions of the product? In there any specific detail about one of the points above you want to add? Again, let's keep solutions and success stories (I know there are many) for a later blog post...
(PS: Please don't get into "you did Unicode migration wrong" kind of comments, as I find tham pointless by now, and would likely delete them!)
posted by
marcocantu @ 10:09AM | 21 Comments
[0 Pending]
21 Comments
Migrating Delphi Code Technical Challenges
In adittion, be carefull if you plan to compile for 64
bits and use old third party librarys with assembler
code. Probably it don't work, but it's not a Delphi
fault, is that 64 bits is different. So, you must
consider this question in your projects (compile for 64
it's one of the big features of XE*).
My personal experiencie: I have all the problems with
old third party components: Don't exists anymore or cost
a lot of $$ upgrade again :(
Comment by Diego
[http://www.cocosistemas.com]
on August 1, 10:47
Migrating Delphi Code Technical Challenges
I think you've got the main challenges spot on Marco.
I blogged about our experience quite heavily
(http://delphidisciple.blogspot.co.uk/2013/03/migratio
n-to-xe3-almost-there.html), and certainly our
biggest hurdle was one particular third-party
component (ODBCExpress) that died before Delphi 2009,
and so there was no Unicode version. Despite having
the source code, I had neither the knowledge nor the
inclination to convert it. So we manually migrated to
dbGo (ADO), safe in the knowledge that this is
supplied out-of-the-box and has been supported from
Delphi 5 right through to XE4.
The main lesson for me? Don't just find a cheap or
free component to do a job. Find a reputable
component vendor. We have now only 3 third-party
component sets that we use and all are well
established, well known and well supported.
Comment by Jason Sweby
[http://delphidisciple.blogspot.co.uk/]
on August 1, 12:48
Migrating Delphi Code Technical Challenges
See QC#797921, "Importing a project from a previous
release doesn't fix references to object repository
items".
Also there is an issue when .dcp contains the Delphi
version inside the file name. Moving a project to a
new release requires to fix the .dcp names when you
use run-time packages. Because too many developers
don't want to use package options to set the .bpl
suffix, it would be nice if the IDE could handle this
somehow.
Comment by on August 1, 13:19
Migrating Delphi Code Technical Challenges
These migration problems are indeed one of the major
obstacles when developers evaluate a possible upgrade to
the newest version of their development tool. I think that
Embarcadero could earn much more profit if they would
decide to address this problem.
Embarcadoro could provide a tool or a set of tools to
alleviate this problem:
1. A tool which clearly lists all third party source code
and components needed by a specific project or project
group which are not available in the search path of the
desired target IDE. It shouldn't be too difficult to
compute the difference between the projects needed subset
of the source search paths to the projects needed subset of
the target search paths.
2. An included extensive database of third party source-
code and components, where the difference list from the
above point is a list of links pointing to:
a) local source paths needed to add to the search paths of
the target IDE, where a button click then adds the missing
search paths to the target IDE;
b) the remaining difference list then pointing to the
websites where the missing components can be downloaded.
If Embarcadero puts 2 programmers inside a room, this
should be a job of not more than a week. And we all would
be happy.
Comment by Peter on August 1, 14:12
Migrating Delphi Code Technical Challenges
I'd recommend compiling with XE3/XE4 and 64-bit to
identify the "worst case". We ended up with some 3rd
party components that were only available as 32bit
COM, but many of the other applications "just worked".
(We were starting with D2010)
Here's a few more problems:
1) 32bit allowing mixing asm & Delphi, 64-bit doesn't
2) D2010 allows cascading from one constructor to another
3) compiler strictness, E.g. pointer math or
{$IF CompilerVersion >= 23}
function HookCallWndProc(nCode: Integer; wParam:
NativeUInt; lParam: NativeInt): NativeInt; stdcall;
{$ELSE}
function HookCallWndProc(nCode: Integer; wParam,
lParam: Longint): Longint; stdcall;
{$IFEND}
Comment by Tan on August 1, 15:17
Migrating Delphi Code Technical Challenges
The most dangerous thing is, that there is no
migration path from VCL to FMX. Many programmer are
not able to bring their huge VCL apps to
OSX/Linux. FMX is completely incompatible and a great
mess. Whereas Lazarus did the right thing: One
framework for all platforms.
Comment by Peter on August 1, 15:53
Migrating Delphi Code Technical Challenges
8. Applications might use some removed component which
was part of Delphi official release, but not available
any more, like Bold (which was not a third-party
component).
9. Hard to prepare the migration to the NextGen
compiler.
10. Applications using a deprecated Microsoft
technology like DDE or DCOM.
11. Lack of high-level documentation of the old
Application architecture.
12. Lack of unit tests and/or regression tests.
13. Some minor breaking changes at compiler level
(like "record case" alignment rules change in XE3, or
"object" instability).
Comment by Arnaud Bouchez
[http://synopse.info]
on August 1, 16:28
Migrating Delphi Code Technical Challenges
Something to the list: Routines including some kind of
pointer arithmetic, low-level memory manipulation
and/or inline assembly usually cannot be recompiled
out of the box.
One side note: “recompiling” is not “migrating”. I
have seen Delphi 5 apps recompiled with Delphi XE3 and
still the app is non-Unicode, 32 bits (as opposed to
64bits), same old legacy data access technology, more
bugs than the original D5 version: this is not
“migrating”, it’s just “recompiling”. These things
have to be taken into careful consideration:
recompiling won’t take away the fact that the
application is legacy or it won’t necessarily make
your application better. This is a risky, time
consuming, error prone undertaking and the bottom line
is that sometimes is not worthy.
I rather prefer the term “rewriting” as opposed to
“recompiling” or “migrating”.
Comment by Yanniel
[http://www.yanniel.info/p/delphi-programming.html]
on August 1, 17:23
Migrating Delphi Code Technical Challenges
Well, I for one feel stuck on D2007 forever. I have a
popular large program that I cannot seem to migrate. I
purchased 2009,10,XE3 but have not been successful. So
now I have stopped buying upgrades.
Maybe if there was a way to globally keep using ansi
strings I could migrate up. IMHO if you all think it is
so simple to migrate from ansi to unicode you should
have upgraded my code automatically.
Comment by Mike W on August 1, 18:49
The Mountain and Why I Didn't Surmount It
Marco,
The question I asked myself with every new edition
of Delphi was, "Is there anything in there that
benefits me?" And the answer was usually a vague
maybe, but not a "it's worth the cost to upgrade"
feeling. I had my third-party editor that did a lot of
what the IDE editor improvements were all about. I
even had a unicode library on the one project I wrote
that had the possibility it might be needed. But I
knew I was never, ever going to need unicode again. At
each step along the way, I only saw expenses and not
much, if any, income-production from giving up my
Delphi 7.
The Delphi DCU incombatabilities from one version to
the next were a sop to third-party developers. But the
expense in updating them, along with Delphi itself,
has killed the brand. Sure, big multi-programmer shops
undoubtedly had the source code, but I know a LOT of
little one-man efforts like myself, watched the
pennies and didn't always buy the source code. And
even if I had, the changes in the Wide/Ansi string
issues were enough in one case I encountered with
Delphi 2010, that I gave up quickly trying to update
source code I DID buy. (I had bought the 2010 version
because I was emailed a threat that IF I didn't
update, I would be treated as a new customer if I
decided to update to a future version of Delphi. I
have written exactly one app in 2010.)
I kept trying. I'd skulk around CodeRage and even
download the sessions I couldn't watch in real time.
All I wanted was a reason to make the jump. I thought
it might come with some new database technology. I saw
what I thought was an automated tool to do all the
work of ridding my MILLIONS of lines of code from
their BDE dependency. But I was mistaken. Nope, I was
always going to be looking at a time sink to switch
out, given hundreds of forms, ten times that number in
database connections and all kinds of procedures I had
written to shorthand use of BDE stuff having to be
re-written. The failure to create a standalone tool or
Delphi add-ons to automate, as much as possible, the
process of switching over to the then current accepted
database darling, was the biggest issue beyond pure
cost. Oh, there was also the licensing issues with the
new database layers, but that was a page two thing
when the decision had been made after reading the
first page of issues.
I've stopped signing up for CodeRage and even
downloading sessions after the fact. I am not the
customer Embarcadero is aiming at anymore (if I ever
was). It's not Embarcadero's fault. The product is
being used in more countries requiring unicode than
not, these days. Programmers are looking for ways to
code quickly and efficiently for apps rather than
applications. I'm just chugging along towards
retirement fulfilling my duties in programming stuff
for local companies that use my software to run their
businesses. Point of sale software, Order tracking,
full systems software. It's what I write for the small
(Sub 100 Million dollars) companies I've worked with
for years now. I'm useful and economical with what I
do. And have done. Thanks to Delphi and the various
owners that created it for me (plus ALL those
third-party providers that let me fake capability all
these years). But however you massage your list,
Marco, the economics and the time to upgrade have
gotten prohibitive to guys like me.
Too bad.
Comment by Gary Mugford on August 1, 20:16
Migrating Delphi Code Technical Challenges
Old programming styles with many
Var a absolute b;
Mem[] := XY;
Move()'s on changes generic var types
Inline ASM
INLINE($XY)
Frank
Comment by Frank Lauter
[http://www.infobaseweb.de]
on August 1, 20:37
Migrating Delphi Code Technical Challenges
8. DevExpress doesn't support FMX.
Comment by Markus Ja on August 2, 04:43
Migrating Delphi Code Technical Challenges
I am stuck on D7 because of Bold.
Comment by Sam on August 2, 06:03
Migrating Delphi Code Technical Challenges
Jumped to XE4 from D2007 last week.
(also have D2009 but never used it in production)
Currently I'm troubleshooting a problem with Named
Pipes between D2007 and XE4 apps.
string data received from D2007 app is not correct in
my freshly compiled XE4 app.
given that Named Pipes data is handled internally in
unicode by Windows I expected no problem here.
No conclusion/solution at the moment. I've just
started working on this issue.
Comment by Damien Demars
[http://idea43.com]
on August 2, 08:27
Migrating Delphi Code Technical Challenges
I'm still forced to use D7 as this is the closest one to
kylix so that I can check the code under windows and
then compil it with kyliix
So, I will have to wait ...
..
Comment by sebastien on August 3, 23:42
Migrating Delphi Code Technical Challenges
I'm migrating from D7 to XE4, mainly to code to iOS
devices. I was pleased to be able to port a lot of
code much faster then I anticipated (with little change).
Things I dislike:
1) String indexes starting on [0] instead of [1] for
iOS. This created most unpleasant bugs. Pos()
function, which I used a lot, does not work. Had to
revise all code involving parsing.
2) Automatic garbage collection. I used the following
construction many times, to create local memory
databases of objects:
aObj:=TMyObj.Create;
aObj.SomeProperty := foo;
fMyList.Add(aObj); //add aObj to some TList
With automatic garbage collection, aObj gets wasted
some time after this code exits.
I prefer to control the release of my objects, so I
used aObj.__ObjAddRef (iOS only) to disable reference
count. I did the same years ago for COM objects (also
reference counted)
Omar
Comment by Omar Reis
[http://www.tecepe.com.br/nav/]
on August 6, 14:37
Migrating Delphi Code Technical Challenges
A big issue that seems to be under-appreciated is that the IDE
design-time interfaces change between most every release. It's easy
to lump this into issues regarding 3rd-party components, but it
affects anything designed to hook into the IDE, including property
editors supplied with 3rd-party components.
Some of this is due to enhancements in RTTI functions and services,
while other aspects are because the design-time API changes.
Delphi itself has never offered particularly useful or innovative
property editors, leaving them for 3rd-parties to develop.
A lot of component libs broke between D6 and D7 because of this,
never to be ported forward. Some vendors took this opportunity to
completely rewrite their libs.
I've seen examples where a comp lib couldn't be ported to a new
version -- not because anything in the run-time part broke, but
because of incompatibilities in the design-time part; they were
complex enough that nobody bothered. (mostly open source stuff)
I have lots of older comp libs that need lots of work in the design-
time part to make them work with newer versions of Delphi, but
nobody has (and I'm not going to bother, either).
Comment by David S on August 7, 01:27
Migrating Delphi Code Technical Challenges
We have not had many problems migrating from 7 to 2010
to XE2. The main issue was components, as many have
mentioned. The strategy we used was to change to new
components in the old delphi version first, then
migrate up versions. For example we had a Toolbar
component that was not going to be moving forward, so
we dropped it in Delphi 7, and replcaed it with a
commercial one (with source - just in case, and the
company had been around some time, and fortunately i
still around). That way we only broke 1 thing at a time.
The ansistring/unicode string problem was never
serious for us, and in fact was a benefit. The only
issue we had was when we read directly from disk - and
simple char=>ansichr was the only required changes.
We don't do database so maybe that is where others are
having issues. For no-database apps I think it is
trival changes.
The most serious problem we have had is getting x64 to
work. We use a component called KOL to do threaded
GUI work (yes it is possible in Delphi). Works
fantastic in x386, but needed major (weeks) of
rewrite/testing for x64. Also there is the problem
with ASM and incldued obj files that need to be
removed/updated.
One important lesson we learn't is: go with companies
that seem to continually develop there components. If
you haven't seen a release in 9-12 months a warning
light should flash, as no component is perfect.
Comment by B Hunter on September 17, 02:31
Migrating Delphi Code Technical Challenges
What does the it mean "Error in module : Contains
clause is incorrect" while opening the source code of
a D7 package file in XE3??
I was trying to migrate from D7 to XE3.Usually all of
my .DPK files compiles successfully while some
components like Raize etc giving me above mentioned
errors.
Comment by Shiju MS on November 23, 09:57
Migrating Delphi Code Technical Challenges
Hello Marco,
What is your recommendation for placing files that are
required by the application (application path on
deployment) during development?
An example is a project migrated from an old Delphi
version (Delphi 2010) that used Rave reports with the
Rave (.rav) file in the Delphi project folder which
was the same for all build configurations.
Newer Delphi versions have different build folders for
Debug and Release making it a challenge to use for
example ExtractFilePath(Application.ExeName) to load
the file at run-time, during development as there is
no common path.
Comment by Martin on June 3, 17:07
Delphi Parser Migration Wizard & SDK
Hi All,
All this any many more issues regarding migration of legacy
Delphi & C++ Builder code to support the latest RAD Studio 10.1
Berlin can be easily & automatically be solved using the Delphi
Parser.
Since 2016, the Delphi Parser is a recommended tool by
Embarcadero & working closely together to provide better tools
for maintaining & optimizing the Delphi code.
http://www.delphiparser.com
Comment by Oren Aviram
[http://www.delphiparser.com]
on September 8, 08:55
Post Your Comment
Click
here for posting
your feedback to this blog.
There are currently 0 pending (unapproved) messages.
