Thanks for the clarification, Jerry.

It's amazing how inaccurate software reviews actually are. I should have known to question the WINE issue due to other "questionable" comments the guy was making in other areas.

>I don't think that is correct.
>
>Borland uses its "Borland Componant Library for Cross Platform, CLX (tm)" and most versions of Kylix will come with the CLX source code and, as such, does not need the Windows API or emulation. IF Delphi 6+ programmers use the CLX(tm) components they will have full cross-platform capability. Kylix will compile CLX compliant Delphi 6+ apps without problems, and visa-versa. On Linux deployed apps will include *.SO files (Linux shared libraries), not WINE.
>
>There will be three Editions; Enterprise, Desktop and Open. The Open Editon will be a free download and can be used only to write GPL code. (page 6 of eval_guide.pdf, found at http://www.borland.com/kylix/papers/eval_guide.pdf ) Open Edition Kylix itself will not be GPL, though, because it's source is propriatary. Also, page 20 says NO run-time interpreters (WINE) are necessary.
>
>http://www.borland.com/kylix/linux/features.html
>
>Apps compiled to 'native code' in Linux don't need a support layer like WINE. To use apps that need WINE you must first load WINE, then the app that calls it. This is usually done by calling a script acting as a shell. Corel had to do some MAJOR tweeking of WINE to get it to work, and while the GPL required them to return their efforts to the community, it has not improved WINE that much in the subsequent milestone compiles. Before WINE ever gets to the point that it reliably supports all Win95 and Win98 apps, tools like KDevelop, Glade, Kylix or QtDesigner, and the flood of apps they encourage, will make WINE a mute and useless tool. KDE apps under development are approaching 3,500+ the last time I saw a count, which doesn't count the several hundred that are already available. Nor does it count the Open Source Star Office, or KDE Office, etc..
>
>Kylix is a better approach than WINE supported tools -- a complete native Linux GUI RAD. What is also obvious is the Borland has been studying VFP!
>
>That's not to say that Kylix will or won't be successful. Personally, I don't believe Kylix will be successful, but as an old Pascal programmer I hope they are wildly successful! Consider though, that I loved Turbo Pascal with a passion and was a Delphi user for a couple of years, but migrated to VB because I was more productive with it and VB had a larger following - read 'more clients' would accept its use. To be sure, Delphi has improved considerably since I left it, but the move was made and turning back usually doesn't happen. KDevelop (KDE) and Glade (GNOME) are already on the ground floor of Linux, and they are GPL with source, too. This is to say nothing of QtDesigner and a dozen other tools of lesser strength but very capable of putting up GUI apps. I will try the Open Edition of Kylix, though, if not the Desktop Edition.
>If Kylix demonstrates that it was rushed to market (lots of bugs, etc...) it will die a quick death or slide into obscurity like Corel WPO2K did.
>
>The biggest hurdle to VB and VFP programmers will be that Pascal is a stongly typed and structured language, and it is objects with a vengence. The concepts of component inheritance (not VB's 'cut&paste' but more like VFP's controls),UNITs, forward declarations, structures, Object Pascal, etc..., will represent a steep learning curve to those with only scripting experience. About the same type of learning curve that would be experienced if they moved from VB or VFP to C#. C and C++ coders will probably have little trouble moving to Kylix, but it begs the question: why? Especially if they have KDevelop. I can NOT see the value in moving from one propriatary tool (VFP) to another (Kylix) when I could use a tool for which I had the complete source and for which I did not have to use increasingly scarce dept funds to purchase per-seat licenses and/or upgrades, nor face the problems of file formats that lose support.