Mega Code Archive

 
Categories / Delphi / Ide Indy
 

Porting Delphi Applications to Kylix

Title: Porting Delphi Applications to Kylix Question: Covers the seven most common problems in the porting process and shows ways to solve them. Answer: Porting GUI-based applications from Windows to Linux has never been easier. Since Kylix's CLX library is so similar to the VCL in some cases migration is done a few minutes. Most programs however will need some substantial work. This article covers the most common issues and shows how to resolve them: 1. File Names The first problem you will be running in are Linux file names. It makes a difference whether it's MyUnit, myunit or Myunit and with Kylix you have to write the unit name correctly in the unit and in the uses directive. Chances are that you have to rename your Pascal files on the file server as well, if you don't want to live with carelessly spelled file names forever. For the Netware server 4.11 we are using in the office, this is a problem. It will not allow to name a file Test but always renames it to TEST internally. So we had to write a little tool that runs on Linux and renames the files via the Samba server. 2. File Names, Again If your program works with files (and which one doesn't?), you have to check for all backslashs used as path delimiters, upper and lowercase in file names and extensions and for drive specifications. There are SysUtils functions like ExtractFileName that work correctly on both platforms but not everybody uses them. Other helpers will be available with Delphi 6 such as IsPathDelimiter and IncludeTrailingPathDelimiter. Also, comparing two file names using CompareText might not be such a good idea on Linux systems. 3. Units Part of the CLX units have names with are preceded by a Q. Q stands for Qt which is the Troll Tech library for visual controls used for VisualCLX. CLX forms are found in QForms, Controls becomes QControls and so on. We use the LINUX define to compile against the correct libraries like that: uses {$ifdef LINUX} QForms, QControls, QStdCtrls, {$else} Forms, Controls, StdCtrls, {$endif} System, SysUtils; It is important to have at least one common unit after the endif. If you put the semicolon behind StdCtrls and QStdCtrls the IDE sometimes feels it must append other units within the ifdef. 4. Forms Yes, you can reuse Delphi forms with Kylix. No, it's not a good idea to do it. If you save your form with Delphi 5 in binary mode (put "Text DFM" off in the local menu of the form designer) you will be able to open it with Kylix. But you probably won't like the layout of your controls under Kylix because it seems to work somehow different. This means you have to change it. Furthermore, CLX controls are missing some of the properties VCL controls have, there are different enumeration values, different font names, additional properties. There are not so many differences but the few suffice to make you want to save your Kylix form in a different file. Our preferred procedure is like that: - Save the form in a binary file under Delphi 5. - Copy the *dfm to a *xfm for use in Kylix. - Change {$R *.dfm} to {$ifdef LINUX}{$R *.xfm}{$else}{$R *.dfm}{$endif} in the form's source code unit. - Open the unit and the form with Kylix and adjust the layout to Linux. This way you can reuse your existing forms but you have to maintain two copies. In my opinion it's the best you can do at present. 5. Windows API Functions There is only one thing to say to Windows API Functions: Good-bye. Even if the Kylix IDE uses Wine to run on Linux, Kylix applications don't. This is what you will have to do: - Replace Windows API functions by Delphi functions or components wherever possible. You can do this for most of the file management routines for example. - Write a wrapper function to switch between Windows and Linux version using the LINUX define. That is what we have done e.g. for Sleep and LockFile. Linux system functions are to be found in the Libc unit. 6. VCL Components The good news is that there is a CLX version of most of the commonly used controls and components like TEdit, TStringGrid, TListView, TTimer. But almost all is not all and you will not find e.g. a one-to-one replacement for the TRichEdit control, because it is based on a Dll delivered with Windows. There are two new components called TTextViewer and TTextBrowser that you can use instead but they are quite limited in terms of functionality. There is not much what you can do if a control you need isn't available. Either you manage to get along without, or you wait until a third-party manufacturer offers it or you develop it by yourself. 7. Database Components Since Borland has given up the BDE you will miss the TTable, TQuery, TDatabase and TSession components on your Kylix palette. If your application uses them, you have three alternatives to think about: - Switch to MyBase. MyBase is a kind of database surrogate based on XML files that can be accessed via a TClientDataSet component. Because MyBase has neither index files nor does it support multi-user access, it is a solution only for single-user projects with very small database tables. - Switch to dbExpress and use a database server. dbExpress is the new and slim Borland database access layer. Kylix is delivered with dbExpress drivers for MySQL and Interbase (Desktop Developer) and Oracle and DB2 (Server Developer). Drawback: Your application architecture becomes much more complex, your customer will need to have a database server installed and maintained, great parts or your source code have to be changed. - Switch to a BDE-compatible replacement. There are some BDE replacement database engines available under Windows and there is already one for both platforms at the time of this writing. With TurboDB Components you have to convert your BDE table files but you can stay with your application architecture, you have only minimal source code changes and your customers won't even know about your application using a database (http://www.turbodb.de). There are still some more topics like online-help and assembler statements. But I believe the ones listed above are the most common problems so this article gives you a good insight in what will await you when starting to port your Delphi applications to Kylix.