Board index » kylix » Actual Cross-Platform Development
Actual Cross-Platform Development
2005-08-01 04:56:35 AM
I've seen quite a bit of general discussion here about what the best
cross-platform development tool to use is, but little about actual
cross-platform development (e.g., case studies). I've tried out a number
of cross-platform tools over the years and would like to relate my
experiences with some of them and how well they meet my goals of
preserving my huge investment in legacy Delphi code:
(1) Java - requires complete rewrite of all Delphi code.
(2) Kylix - let's face, Kylix is dead, and even if it weren't, it's not
truly cross-platform since there's no support for the most popular Unix
platform in use today, Mac OS X.
(3) Chrome - I have not been able to get even the simplest Chrome or
VB.NET Windows.Forms application to run under Mono on the Mac. I'm tired
of crossing my fingers waiting for things to get fixed (see 2 above).
Chrome is also different enough from Delphi in some fundamental ways that
it's difficult to move much legacy code from Delphi to Chrome. Example:
Chrome strings are 0-based, Delphi strings are 1-based. Any use of System
unit routines like Pos, Delete, Insert or Copy or indexing of string
chararacters (string[ ]) will have to be rewritten. In one of my projects,
I had over 500 uses of just these four routines alone. Hacking the code at
this level is a good way of introducing bugs into perfectly stable code.
(4) Free Pascal / Lazarus - this is the closest thing to the holy grail
that I've found yet. I was able to convert a modest-sized GUI app (approx.
6,000 lines of code) to Lazarus without much trouble and only a bit more
work to get it to compile and run on a Mac. I now have a single set of
source files that can be compiled with Delphi 7 or Lazarus on Win32 or
with Lazarus on Mac OS X and Linux.
I was also able to compile and test approx 50,000 lines of non-GUI code
with FPC on both Win32 and OS X with only minimal changes.
Ideally, cross-platform development should be planned for in the initial
program design and not added later to an existing code base, but even if
this wasn't planned for, it's not impossible to add it with Lazarus,
assuming the app was structured properly in the first place. That is, that
non-GUI number-crunching and database management code is in separate units
from GUI code and that Win32 API references have been isolated from the
rest of the code as well.
One advantage of Lazarus/FPC is that it has almost complete cross-platform
support for Delphi-compatible units such System, SysUtils, DateUtils,
StrUtils, Classes, Variants, Math, IniFiles, and Registry. It also has
incomplete cross-platform support for Windows and Messages units in the
form of its own LclIntf and LMessages units. The FPC compiler is also
highly compatible with Delphi code, requiring only a couple of minor
tweaks with var parameters where FPC is more restrictive than Delphi.
I've reported a few minor bugs to both the Free Pascal and Lazarus teams
within the last couple weeks and some of these have already been fixed in
the latest snapshots (www.ca.freepascal.org/Lazarus/). This may be
"beta" software in some sense, but it feels stable and alive.
My modest-sized app above exercised a number of things:
- VCL-type form and controls.
- Windows version resource (on the Mac, I just substituted an .ini file
containing the [Version Info Keys] entries from my project's .dof file
since this type of resource is specific to Window; I then loaded the file
with a TIniFile).
- Registry (on the Mac an .xml file can be used - your code stays the same
whether manipulating the Windows registry or an .xml file).
- dBASE file manipulation (on the Mac, a few conditionaly-compiled tweaks
to reverse the order of bytes in the binary values of a dBASE file's
header is all it tool to support this unit of mine on the Mac's
"big-endian" PowerPC processor).
This is not to say the FPC/Lazarus can be substituted in all cases for
Delphi. A couple of things that aren't currently supported could create
- No cross-platform help solution yet.
- No support for TRichEdit in the Laz ComCtrls unit.
Deployment of compiled GUI apps on Unix systems requires the GIMP Toolkit
(GTK) files to be installed. On Mac, the optional OS X X11 app also needs
to be installed as well. Currently, Laz apps on Mac use the GTK-based
controls, which may not be acceptable to some Mac users who don't want to
see the X11 menu and window on their desktop when running your app. But
for developers who would rather have a Mac-based app, X11 and GTK and all,
rather than no Mac app at all, this is an acceptable solution.
"Carbon"-based native Mac controls are planned, but little work has been
done on this to date.
--- posted by geoForum on delphi.newswhat.com