Borland's Kylix: turbocharging Linux development

By: Scott Courtney
Monday, April 9, 2001 08:30:07 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reviews/3207/1/

Not Your Father's TurboPascal

"Yep," said Grandpa, "I remember back when floppies were over five inches wide! You could get the whole operating system on just one, but it was a squeeze, yessiree. There was this little company called Borland, and they put a whole compiler on one of those floppies. Called it, um, TurboPascal. It was a screamer, too. You could get twenty-thousand lines a minute compiled, and that was on an XT. Not like them whippersnapper gigahertz Athlon things like you youngsters are running these days. Nosiree. Back then, when rocks were soft, we had to run our programs one at a time. But that TurboPascal, yessir, that was something else."

Okay, I'll admit it. I'm old enough to remember (fondly, I might add) the original TurboPascal that came on a floppy disk for $39.95. It was a little sobering to realize, as I did when starting this review, that there are thousands of coders today who were in grade school when TurboPascal 1.0 shipped in November of 1983. Heck, there are programmers who weren't born yet. So, for those too young to recall, TurboPascal made a big splash because it fit on a single floppy (when its major competitor needed half a dozen), ran lightning fast even on an XT (I clocked it at over 20,000 lines per minute compiling on a 4.77 MHz 8088), and was the closest thing to free (beer) around (selling for $39.95, if I recall). TurboPascal was from this really hip company called Borland International, run by a sax-playing barbarian named Kahn. The code itself was written by Anders Hejlsberg in Denmark, but Philippe Kahn's audacious personality caught the imagination of young programmers, myself included.

Was TurboPascal any good? Let me put it this way: Using version 3.0, I once wrote a real-time monitoring system for the HVAC (environmental control) system of a machine shop. The thing talked at 9600 baud over a serial port to an Allen- Bradley programmable logic controller (PLC), using the weirdest serial protocol you ever heard of. It showed (on a Hercules monochrome graphics card -- remember those?) a drawing of the shop with temperature and humidity readings from numerous data points. It communicated with the PLC and updated the screen in realtime, using a multithreading mini-scheduler that I hacked together myself from scratch, because the underlying operating system was DOS. There were even interrupt handlers for the serial port and keyboard. Everything -- and I mean everything -- was written in TurboPascal, with inline assembly language used only for the CLI and STI instructions to manage the 8088's interrupt enable flag and a little stack management. All of this ran on a 4.77 megahertz 8088 with 640K of RAM. So, Bill Gates was right, and 640K was enough. And TurboPascal was as good as it gets.

I stayed with TurboPascal until about verion 5.5, then abandoned it in favor of Watcom C and later REXX, Java, PHP, and others. TurboPascal didn't go away, though -- it just changed its name to Delphi and went after the Windows crowd with a serious rapid application development (RAD) environment. I've heard about Delphi for years, and even received mailings from time to time from Borland -- excuse me, Inprise -- about how great it was. Every one of these went into the trash, usually followed by a snarky comment like, "I don't want your Windows crap -- come back when you port this thing to a real operating system!"

Apparently, an anomoly in the space-time continuum caused my snarling to be piped directly to the brains of Inprise management, because they did exactly that. Maybe they even read my thoughts, because in January they announced that they were dumping the Inprise name, which I never liked, to go back to their Borland roots. Well, maybe they thought of it on their own. Anyway, it came to pass that LinuxWorld Expo in NYC saw the announcement of Kylix, which will eventually have both a C++ and a Pascal version but which today is basically Delphi for Linux.

A lot of the reviews and commentary on Kylix seemed to be written from the viewpoint of an experienced Delphi user: "Hey, look, now we Delphi gurus can move our code to Linux." I wanted to take a look at Kylix as a new user, someone who has never even seen Delphi before, and who is used to coding without a RAD. Hence this review, which I hope you will find informative and interesting. First, You Have To Install It

Kylix comes in a thick box which, unlike a lot of software these days, isn't just full of air to consume retail shelf space and make life hard on shoplifters. Inside the box are the two CDs (one for Kylix itself, one for "companion tools" which are not part of this review), along with three softbound manuals. There is a little "Quick Start Guide" which is really a programming tutorial and which, surprisingly, contains no installation instructions whatsoever. The "Object Pascal Language Guide" does for the Borland's Pascal dialect what the original K&R book does for C. I found it to be well-organized and very readable. The third book, a rather thick tome, is the "Kylix Developer's Guide." This manual is extremely comprehensive and covers the philosophical and practical aspects of Kylix programming, focusing on specific tasks in many cases but also explaining the concepts behind the examples. The examples are real, meaningful code that illustrate some rather tricky concepts, such as rubberbanding graphic selection and multithreading. To say that I was impressed with this book would be an understatement, though I should mention that it does not contain a "dictionary" style reference to the Kylix standard object classes. Rounding out the package is a poster-sized class tree for all the built-in objects, of which there are many.

The installation instructions are on the main CD, and the README file is quite insistent about the need to have very recent versions of system libraries. Kylix is extremely fussy about its environment, and I spent half a day updating my system (which I had previously thought was pretty close to current) as each library upgrade led to a dependency of something else. I ended up with glibc 2.2.1 and libjpeg 6.2.0. To their credit, the folks at Borland provide a pre- test script that examines your machine to see what you need to update before Kylix will install. The script is on the distribution media or can be freely downloaded from the company's web site (see References at the end of this review). My advice is to get your system accepted by the pre-tester before you buy Kylix. I didn't mind bringing my system up to date, but I must admit a little puzzlement at why so many other applications were running just fine on the libraries that I had previously while Kylix wouldn't even install. Kylix is more finicky than either Apache or MySQL, neither of which are exactly trivial programs.

Getting Started, Learning to Fly (And to Fall Down)

Kylix is a screen space pig, as are all the other integrated development environments I've ever seen. It starts up with a main menu/tool bar that contains all the usual features: file and project operations, clipboard control, tool and environment settings, compile and debug functions, and so forth. There is also an object properties dialog, a graphical form editor (for GUI layouts) and a source code browser that is linked to the object class tree. There is a lot of information presented, and it is very well organized, so I'm not really criticizing Borland for taking up a lot of real estate on the monitor -- but you should be aware that this is not a tool you'll want to use on a display smaller than 1024x768.

The menus and toolbars are extremely customizable, and many of the window sub- panes can be docked together or floated independently. I intentionally avoided changing many of the default settings so that the screenshots with this review would be more typical, but rest assured there are a lot of virtual knobs to twiddle and levers to pull in the Kylix user interface. The widgets, both in Kylix itself and in the runtime application environment, are mature and solid, working as expected without the anomolies and annoyances that I have sometimes seen under older X11 environments. Kylix is a very polished tool, and except for the errrors mentioned previously the GUI development environment worked quite well for me.

Kylix is geared toward a "project" mentality, as are most IDEs, but the project management dialogs stay mostly out of the way during the coding process. I was pleased to see that my coding efforts were integrated smoothly into Kylix's own project repositories; for example, one UI form that I created became available for re-use without any action on my part. To make objects globally reusable requires a few clicks on a menu, but is not at all difficult. The only negative comment I have for the project management functions was that it was unclear, at least to me, how the visible IDE popups related to the underlying source code and resource files. When I clicked on "File...Save" from the IDE menu, I was not always sure which file I was saving, and where. There is a "File...SaveAll" function which is sometimes enabled and sometimes not, and again I could not fathom what determined this option's status. Likewise, the "File...Reopen" list includes both individual files and entire projects, and it was not clear to me the implication of re-opening a previous code file from within a different project. Probably this is all documented somewhere, but it was not intuitively obvious.

A new project is started with one empty form onto which you can drop various visible and non-visible GUI components. These automatically become declared objects within the form itself, and the main form is in turn an instance of the TForm object class. With a modern IDE, it is generally possible to create a displayable but non-functional (stubbed) prototype of the application's user interface without writing any code, and Kylix is no exception. The GUI control widget set is quite extensive, and Kylix goes beyond simple widgets to include entire pre-defined dialogs. These components are numerous and include things like password entry as well as dual-lists, in which items can be moved by the user from a pool of options (on the left) to and from a list of selected items (on the right). You can add your own commonly-needed dialogs and forms to the Kylix repository as well.

Learning to Fly (And To Fall Down)

Borland provides a tutorial guidebook that guides new users through the entire process of creating a working text editor application in Kylix. Naturally enough, and like any true geek, I totally ignored the tutorial and dove into writing some code in a project I called MyApplication. With the amazing speed that comes only from a sophisticated rapid development environment, I was soon flying along at Mach 3. Unfortunately, I was also in a tailspin headed directly for the nearest mountain range. The good news was that I got to see what Kylix does when your application generates a segfault (something that is supposed to be impossible in Pascal). Kylix handled it gracefully, showing a detailed hex dump which I didn't bother to analyze, and I instead fixed the bad object reference in my code. In about an hour I realized that this ad-hoc coding approach was getting me nothing but frustration. With a sigh of resignation, I opened the tutorial.

The tutorial spends about a dozen pages explaining the various aspects of Kylix's own user interface. It's painful to wade through all this when you really want to be crunching out Pascal code, but they are right to force the issue. Kylix is a very deep and mature IDE, with a lot of subtle features that are not obvious at first glance. For example, just about anything in your code is really a hyperlink to the online manuals. You simply hold down the Control key while clicking with the left mouse button to bring up the relevant section of the reference manuals for the class libraries or Pascal language. The links are only visible when the Control key is pressed, though, so without the tutorial I never would have known about this useful feature. The online help also contains code examples, though these seem mostly to be trivial code fragments.

Users of other IDEs, such as IBM's VisualAge for Java, will have no trouble using the GUI designer. Widgets such as pushbuttons, text fields (Borland calls them "Memo" fields), scrollbars, dropdown lists, and so forth are provided on the main Kylix menu, under a series of tabbed sections. Most of these are intuitively clear, but it was not obvious to me the difference between "Standard", "Additional", and "Common Controls." After a little time in Kylix, though, I had memorized a few of these and I think the rest would fall into place with a little more practice.

The process of placing and editing widgets is very intuitive, especially if you have used another IDE before. The Object Properties dialog is continuously visible (to the left of the screen) and allows one to set the static properties of the widgets. These include things like the caption (label), alignment, height and width (which can also be done graphically), cursor override, and so forth. Wherever a static property of one object needed to contain a reference to another (previously defined) object, the properties dialog offers a helpful drop-down selection list of all objects that are suitable in type. For those that are text or integer constants, the change can be made directly in the properties table.

Finally! Some Actual Code!

Less intuitive, at first, was the creation of a main menu and a toolbar. Kylix has abstracted the concept of an Action List, which contains all of the user-driven action events that can be handled by the form. Instead of defining the menus and toolbars, and then filling in their behaviors (the actions) later, Kylix makes you define the comprehensive list of actions first and then attach them to toolbars or menus. This was counter-intuitive to me, but once I realized what Kylix expected I had no difficulty completing the task. Likewise, the little button images (mini-icons) used for the dropdown menus and toolbars are drawn from an Image List which is created before the menus and toolbars that use it. In this process, I found a Kylix bug: You are supposed to be able to re-order the images by dragging them around in the Image List, but I was totally unable to get this feature to work except for moving one image, one time. I am not sure why it worked once, but I was unable to make it work again. This was upsetting to my sense of order that wanted the images to be inside the Image List in the same order they appeared on the menus of my application. Practically speaking, though, it had no effect because each Action List item has an integer index into the Image List, and these can be in any arbitrary order.

Once you have defined the Action List and (if desired) the Image List, creation of the application's main menu is extremely easy, and consists only of selecting the blank spaces on the menu and using the context popup menu to add a new item, then editing its properties to point to the appropriate action. Creating a toolbar is equally easy and involves much the same process.

Finally! Some Actual Code!

Once I had the GUI defined, it was time to attach real code to the event handlers. Kylix uses an object-oriented event model in which the very act of calling a particular function on a particular object instance implies which object receives the event and which event type is being received. This is similar to the event model in Java 1.1 and later, although the notion of an event as an object in and of itself is downplayed. In any event (pun intended), the model used in Kylix and Java alike is much more elegant than the old "case statement from hell" approach used in the days of Windows 3.x.

Some of the trickiest operations needed by the text editor application are also pre-built for you. Kylix includes a selection of common actions such as cut, copy, delete, and paste, and these can be attached easily to menu items. Additional code required for clipboard functions: zero.

For the rest of the functions, most notably the File... menu, the code was simple and straightforward, and typical of what is used in just about any GUI environment. At various points in the coding, a little code-completion menu will pop up and offer a fairly intelligent listing of the possible completions of the current syntactic token. For example, after you have typed the name of an object instance, the popup will show the method (function) names that apply to that object. As you type the first few letters, the choices narrow further and further. At any time, you can use the keyboard or the mouse to select the one you want. Parameter help is also included.

The File...Open dialog is trivial, because it simply invokes a standard dialog operation (modal) and then reads the result to see if the user actually chose a file. I did find a bug in this function: If you add an option of "all files" (for file type) and have a mask of "*", it fails to match anything. Apparently Borland has introduced a DOS-ism here in that they assume every file will match "*.*" and not "*" by itself. Hopefully this will be fixed in the next release, but for now it is an annoyance.

The Help...About dialog is also trivial to implement, if you don't want anything fancy. I was pleasantly surprised to note that a fixed- text label that exceeds one line automatically wraps, something that some IDEs do not handle gracefully.

At this stage, I had a working text editor! All the basic clipboard and text selection features worked as expected. Help...About did what it was supposed to do, and behaved modally as is typical. Except for the filename masking bug previously mentioned, File...Open also worked as intended and text files (.txt extension) opened perfectly. It was interesting to note that there were, by default, no scroll bars in the text editing area, but the PgUp, PgDn, and arrow keys allowed navigation. I am sure that adding the scrollbars is simply a detail I overlooked, perhaps only a matter of setting the right properties on the text area itself.

Non-GUI elements and a usability acid test.

Graphical Interface Items Aren't Always Graphical

Real-world programs, unlike sales demos, need to deal with objects and events which have very little to do with the graphical interface and which, in many cases, have absolutely no visible representation. Kylix, as do most other IDEs that I have used, insists on forcing objects such as TCP/IP sockets, action lists, periodic timers, and database connections into little icons that one drops onto the form as if they were GUI components. The upsides of this are that it is very intuitive for a GUI-oriented programmer, and that doing so makes sense when these same objects are also dropped seamlessly into the event model of the GUI (as they are in Kylix). In my personal opinion, however, this makes less sense than having a separate domain for these abstract objects. I would like to see a screen-domain and an event-domain, one defined by space and the other by time, but Kylix does not work that way. In this design choice, I must admit Kylix follows the precedent of other IDEs, so I concede that I am probably in the minority with my opinion. If the pseudo-GUI-ness is a forced relationship, at least it is well implemented and the non-GUI objects behave much as one would expect.

Kylix provides an amazing variety of non-graphical components, especially with regard to Internet connectivity. There are clients for FTP, Gopher, Telnet, HTTP, NTP, DNS, and other protocols. For most of these, believe it or not, there are corresponding server objects. You can even do low-level TCP or UDP socket communication. I haven't had a chance to play with most of these yet, but I did browse the library and was impressed with the breadth and depth of what I found. The version of Kylix that I have is the Server Developer, so some of these objects may not be available in the smaller versions. I probably wouldn't use Kylix to replace Apache in a production web site, but I can easily imagine using it to prototype (at a high level) an embedded device with TCP/IP servers on board, or to build a test harness for a specialized TCP/IP client program.

There are also objects for database connections, supporting such popular choices as DB2, Oracle, and MySQL. I have a very recent build of MySQL (3.23.33) installed and tried to use the Kylix objects to connect to it. Unfortunately, Kylix complained that I did not have libmysqlclient.so.6.0.0 installed. In fact, I have libmysqlclient.so.10.0.0 installed. It seems odd that a product which insisted on a glibc no earlier than 2.2 would want such an old MySQL library and refuse to work with a newer one. Perhaps this is resolvable; I tried the usual symlinks and ldconfig, as well as searching the Kylix media for the 6.0.0 version, but all to no avail. With no more time to spare before deadline, I surrendered, but I still hope to make this work soon.

By the way, Kylix does support multi-threaded programming, though many of the built-in objects are not guaranteed to be thread safe. There is a simple semaphore mechanism provided by a globally-declared object which serializes access to any of the GUI objects. In this regard, Kylix and Object Pascal fall short of what I have come to expect from Java, but the business-type applications for which Kylix is intended probably do not require robust thread management. As with anything else, it is up to the programmer to decide what tool is right for the job at hand.

The Acid Test: Putting the Manual Away

As a final test before writing this review article, I wanted to push myself to the limit, to see just how usable Kylix could be after a modest (two days, roughly) learning period.

As an exercise, I decided to try to modify the Text Editor application from the tutorial to also be a primitive web client. I hardwired the URL for a page on LinuxToday into a couple of string constants and then I put down the manual, vowing to admit defeat or savor victory without opening it or the online help. The goal was to have the text editor support a web download button that would fetch the raw HTML (without rendering) from LinuxToday and paste it into the text buffer.

Getting the HTTP connection object into the code was trivial -- it appears on one of the IDE menus, and I simply added it to the main form. It took some dithering around before I remembered that I needed an Action List item before I could create a menu entry that caused the HTTP object to do something. From that point on, though, the process was very simple as far as the GUI was concerned. Within about fifteen minutes I had a menu item and a toolbar button that were intended to activate the web download.

Adding the actual event handler was a little trickier. I could use the IDE to get to the right spot in the Pascal code, where execution control would transfer when the button was pressed by the user, but I didn't know the name of the method (function) to invoke on the HTTP object to make it actually do something. I kept looking in the properties dialog for a "URL" but all I found was the host name. Finally, I guessed that the HTTP method might begin with the word "Get" so I created a reference to the HTTP object and then let the online syntax completion tool list all the "Get" methods for me. Bingo! The method is called, simply enough, "Get()" and its parameter is the rest of the URL not including the host name. Five minutes later, I clicked on the download button and saw LinuxToday's HTML code in my text buffer. Success!

Some might argue, with considerable merit, that this was not a realistic test. Real programmers don't arbitrarily abjure themselves against using the manuals, and two days is hardly enough time to learn a complex development tool like Kylix. Granted, on both points. My intention with this exercise was to simulate a harder problem, but approached after more training with the Kylix environment, and this seemed a reasonable approximation. Likewise, although real programmers don't arbitrarily constrain themselves from the manuals, there are times when one is working from a laptop at a remote location and the manual may be five hundred kilometers away. Even if the manual is at hand, one doesn't want to have to open it every two minutes, either.

So, take this test with the skepticism that is its due. It does seem to indicate that Kylix is a learnable environment, and by that I mean, "learnable within a reasonable length of time."

The Long Learning Curve, But Worth It

I am always somewhat amused by the product reviews that talk about a "steep" learning curve, when they mean that something is difficult to learn. Since time is usually the horizontal axis on a learning curve, steep curves actually mean a rapid increase in knowledge. To be perfectly clear, I will say that Kylix probably has a long, rather than steep, learning curve for users who don't already know Delphi. The GUI equivalent of "Hello, World" can be created in a couple of minutes with almost no coding, but there are a lot of steps needed in creating a useful application. Anyone who claims otherwise has been sniffing too much advertising ink.

This isn't meant as a criticism of Kylix, but rather as a reality check for project managers who think that you can just hand a RAD tool like this to a programmer and get instant productivity. Kylix is a serious tool, and learning to use it well involves patience and practice. Pascal was designed as a learner's language to teach structured programming. It provides a forgiving, simple syntax while avoiding the brain rot that comes from using BASIC. As such, it is a quick language for programmers to learn, but it is still different from what most Linux programmers know today. Little syntax quirks, like using ":=" for assignment and "=" for comparison, require some mental gymnastics for programmers who are used to C-like syntax in such languages as Java and PHP.

To this one must add the sheer volume of classes in the Kylix environment. No matter what you need to do, there is probably a class that implements at least a portion of the functionality -- in this way, Kylix is very much like Java, in that both have very rich standard class libraries. Also similar to Java is the way in which the Kylix developers have given careful thought to the abstract concepts such as collections and exceptions. There is an elegance to the class tree that will make it more adaptable to future developments such as new GUI components or new Internet protocols. Yet this flexibility bears a price tag in the form of increased learning effort.

Kylix is not difficult to learn, but neither is it intuitively simple. Nor is it suitable for a true novice programmer, in my opinion. This reality, though, does not diminish its value as a serious tool for a professional developer. If you are moving to Linux from a Windows environment, using either Delphi or Visual BASIC, then buying Kylix should be a no-brainer. For programmers who need to develop sophisticated, high-performance code where the user interface is only a small part of the project, Kylix may not be the right way to go. On the other hand, for a corporate developer writing vertical applications -- especially for in-house use in an environment where many such applications are needed in a short time -- Kylix is a splendid choice.