Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Linux Business Software IT Linux

Borland/Codegear Doesn't Plan to Revive Kylix 89

An anonymous reader writes "Borland's tools spinoff, CodeGear, is laying plans to revive the classic developer products — but Kylix is staying dead, the CEO says. "I hear lots of discussions about Kylix, but I didn't see lots of revenue in my reports about Kylix," he told CRN."
This discussion has been archived. No new comments can be posted.

Borland/Codegear Doesn't Plan to Revive Kylix

Comments Filter:
  • Delphi(till version 6) and Kylix were great tools, despite all the bugs and the damned impossible price.
    • by RingDev ( 879105 )
      For those of us who haven't used Kylix before, what IS Kylix?

      -Rick
      • Re: (Score:2, Informative)

        by twms2h ( 473383 )
        Kylix is (was) Delphi and C++ Builder for Linux/i386. There were three versions and I only ever used Kylix 3 with the Delphi personality. That one was fine. Stable, useful, and the price also was right: It only cost me 19 Euros. I can't comment on the C++ personality or Kylix 1 and 2. I guess they must have been pretty awful for Kylix getting such a bad reputation.
        • I can't comment on the C++ personality or Kylix 1 and 2. I guess they must have been pretty awful for Kylix getting such a bad reputation.

          I bought the Kylix 1 version when first announced. Cost USD $1000. I would like to say I did great things with it or at least that it crashed so much I couldn't, but I didn't get to it, so it's still boxed up.

          There was the announcement of a Delphi / Kylix compatible version (apparently Kylix 3) which I called Borland about. The
      • by ceeam ( 39911 ) on Thursday December 28, 2006 @11:50AM (#17388650)
        Kylix was a hacked WINE'd (IIRC) Delphi IDE and compiler that had a brutally hacked Delphi's VCL (component library) named CLX (which was backported to Windows to allow advertising it as a cross-platform thing). It produced binaries for 32-bit x86 CPUs for specific versions of runtimes (libc included) and used QT (not KDE integrated of course) to handle application GUI. It had IMHO an overall crippled Windows version feel.
        • and used QT (not KDE integrated of course) to handle application GUI.
           
          How did they manage that, in view of the fact that Trolltech's license requires a fee for anything not GPL that is developed to use QT?
           
          What I mean is, did everything developed using Kylix have to be GPL or did a separate fee have to be paid to Trolltech, or did Borland have some special arrangement with them?
          • Re: (Score:1, Interesting)

            by Anonymous Coward
            Borland had some special arrangement with them. Borland also had a percentage of Trolltech shares.
    • Eighty bucks is an impossible price for a compiler now? Or, did you forget that Kylix was free for non-commercial projects?
    • Delphi's demise was quite predictable with simple datamining techniques.

      http://www.realmeme.com/Main/miner/technology/delp hiDejanews.png [realmeme.com]

      I was the subject of a great deal of hostility from the Delphi community when I posted this prediction back in 1999. I loved Delphi, it was the best tool I've ever used but you'd think that "rational engineers" could distinguish between personal feelings and market forces.

      There was clearly demand for a cross-platform version but Borland waited too long and java ate the wi
  • From the article:

    "I think that the Delphi community has shrunk past the point of sustainability, at least in the U.S. When I got my current position, maintenance of a group of legacy Delphi apps, I immediately went looking for the remnants of the old Delphi user group in the Dallas area. I was unable to find any of the members that still used Delphi at all."

    Interestingly, the TIOBE index still has Delphi at a pretty high position [tiobe.com]. We get about 40-50 people for our local Ruby user's group [novarug.org] meetings; I'm surp

    • by ceeam ( 39911 )
      There's Europe and especially eastern Europe where it's historically big.

      BTW - if you'd need to develop a native Windows GUI distributable app what would you use?
      • > BTW - if you'd need to develop a native Windows
        > GUI distributable app what would you use?

        C#, probably. C++ in a pinch. Or Ruby (via RubyScript2Exe [erikveen.dds.nl]) if at all possible!
        • Re: (Score:3, Interesting)

          by ceeam ( 39911 )
          C# is not "native Windows app", it's .NET app.
          Ruby - what library gives you native windows UI (like, with XP themes, advanced Windows controls etc, for example?).
          C++ - of course :) What library? MFC?
          • Re: (Score:3, Interesting)

            by Knara ( 9377 )
            Fairly certain that from MS's point of view, .Net apps are considered a "native Windows apps". You and I know this isn't necessarily the case in the wild, but I feel like quibbling this morning ;)
          • > C# is not "native Windows app", it's .NET app.

            True. But most Windows boxes have the .net runtime installed... I think it's a viable option. And you can always dip into unmanaged code if need be.

            > Ruby - what library gives you native windows UI

            I'd probably try WxWindows and see how that worked out. If not, maybe QT; there seem to be pretty good Ruby bindings for that.

            > C++ - of course :) What library? MFC?

            WxWindows or QT, probably. My few brushes with MFC have been unpleasant...
            • Re: (Score:3, Insightful)

              by blincoln ( 592401 )
              But most Windows boxes have the .net runtime installed...

              You might be surprised. Especially if you're compiling for .NET 2.0, which you should be, since the 2005 IDE is light-years beyond 2003, and the new features of the language are well worth it IMO.

              Obviously as time progresses, more and more people will have it, but a lot of them still don't. I put a note in my readmes and on the download pages for the apps I've released publicly, and I still get people asking me why they get an error along the lines of
              • > I still get people asking me why they get an error along the
                > lines of "you must have the .NET Framework v2.0 or higher
                > installed" when they run them.

                Yup, I hear you. Still, being able to use C# seems like it'd be worth the runtime hassles...
              • That is a good question - what can one use for developing a native Win32 app?

                I know a fellow doing C++/MFC, but that seems like an exercise in masochism, even for C++ programming. The official Microsoft Way was that mere mortals program in VB and that real guru types produced the ActiveX controls that were assembled in applications by VB, and you can do the same thing using Matlab or even Python (assembling apps in a scripting environment using ActiveX controls implemented in C++ using MFC or ATL).

                But

      • delphi :-b

        it is the best one for developing win32 apps. much faster and much more comfortable than even c#/winforms
  • Not a surprise (Score:5, Interesting)

    by El Lobo ( 994537 ) on Thursday December 28, 2006 @10:36AM (#17387658)
    As a many years user of Borland Tools since the old Turbo Pascal days, it doesn't surprise me that Borland will not support Kylix anymore.

    When Borland was investigating if Kylix was a viable product they did a poll betweenBorlands users. The poll gave an incredible 94 (or something similar) percents of the votes with people entusiasthically screaming: "Yes, we will get Kylix" "Cool, now I can code for Linuzzz". When the product was done and out there, only some miserable number of copies were sold. That was one of the problems: the Linuzzz crowd has a natural dislike for non-free products.

    Borland (maybe Inprise back then) made then a move: made it free, but only if the code produced with Kylix would be GPL. Then the user base rised kind of, but many Windows coders realised that linuzz is not Windows and the dependence nightmare began. Borland was obligated to support only 2 distros (IIRC) because they could not guarantee that the rest of the distros would have the needed dependences.

    Add to this that the IDE crashed badly, and here we have. A big flop.

    Another problem was that VCL applications were no more, and you must use CLX which was somekind of a bastard for a Delphi user....Oh well....

    There is actually a very interesting project that allowed programming in Windows with Delphi but deploying in Linux in a semiautomatical way... Forgot the name of the project but it was kind of officially supported by Borland.

    • Re: (Score:2, Interesting)

      by jackharrer ( 972403 )
      First and the biggest problem with Delphi / Kylix - they are well too overpriced. I used to code in Delphi and as a language is very nice. Fast and robust. But Borland killed it. Instead giving it to schools / unis and so for free they still wanted to make cash on it. Too greedy, IMHO.
    • by Netino ( 1021745 )

      (...) That was one of the problems: the Linuzzz crowd has a natural dislike for non-free products. (...)

      This is not a Linux phenomenon, this is an generalized computers users phenomenon.
    • by jma05 ( 897351 )
      > Borland (maybe Inprise back then) made then a move: made it free, but only if the code produced with Kylix would be GPL. Then the user base rised kind of, but many Windows coders realised that linuzz is not Windows and the dependence nightmare began.

      Actually Borland did not make Kylix free for GPL. They had an "Open Edition" that was quite devoid of features and had a timed "SPLASH SCREEN" with every executable advertising that Kylix open edition was used. That is hardly a free product, more like a tri
      • Instead of framing the question if Linux was ready for Kylix/Delphi, I ask if the Delphi crowd was ready for Linux.

        The sort of person developing on Linux probably came from a university Unix background and was comfortable with vi, emacs, make, makefiles, and the whole Unix style of software development. It is not clear that IDE's are of interest to the people already on Linux, let alone the stories on this thread about cost and bugs with Kylix. If the Linux world is to be sold on IDE's, it may come from

    • Maybe the problem was that it was a piece of crap (you cite IDE defects and abandonment of VCL in your post), rather than "Linuzzz" (is that like Micro$oft?) users not being willing to pay for anything.
    • by rasjani ( 97395 )
      Linuzz people had natural dislike for poor products. First version of Kylix was epitaph of "How not to do applications for linux" - Only crowd it had any effect in my eyes was windows programmers who didnt know anything about linux programming and wanted kylix to lower the learning curve. And it did poor job in that.

      Shitty product. FPC project and their gui ide is shitloads better product even thou it might even still be beta/alpha quality..

      • ...and wanted kylix to lower the learning curve.

        or eliminate the learning curve. I think the Borland (Inprise) $1000 price was based on "distribute your Windows app to Linux".

        I am glad to see in this thread that Delphi 5 and its apps run under WINE. I think that basically was the intent of Kylix, so WINE has come to the point of doing it much cleaner directly with Delphi.

        And I have a $1000 paperweight, or from the size of the box, boat anchor
  • by stg ( 43177 )
    Does that surprise anyone? I love Delphi, I've used it since the beta of version 1 (without upgrading from Delphi 5 till Delphi 2006 though) - but the moment they announced Kylix it seemed obvious to me that it was a bad idea and doomed to fail...

    The high price (for the "usable" version) when they released didn't help. A pricy tool for developers used to free tools, with its greatest strength being the GUI system and components on a system most used server-side...

    I understand it was a bit buggy, too, though
    • Re: (Score:3, Informative)

      by Micah ( 278 )
      Well I'll admit to thinking it was a great idea when it got started. Back in the late 90s, there were polls about which applications people wanted for Linux. Two consistently topped the list: Quicken/Quickbooks and Delphi.

      When they first announced its availability, at a price of a whopping $999 for the non-enterprise version, I immediately realized they didn't have a clue. No wonder almost no one bought it. When they announced that the price had dropped to $200, I ordered a copy immediately. It was ni
  • Straight from the nobody-gives-a-shit department.
  • Stupid bad timing. (Score:4, Insightful)

    by GallaherMike ( 987682 ) on Thursday December 28, 2006 @11:43AM (#17388544)
    At the time of the release it was not like there was much potential of a big revenue stream from the nix crowd to begin with. Who was the target audience? Lone developers that would have used it to build "free" apps. couldn't afford it, and corporate dev. shops that were using nix were only using it on the back end. So at best you are building middle tier or web services, both of which were already well supported by other languages/platforms for nix.

    There were functional problems as well. Making Delphi/CBuilder developers not use the controls and code base for win32 but requiring the use of CLX and custom libs for Kylix portability. An unstable initial IDE release. To name a few. Developers that work in Delphi or CBuilder all the time think in those languages, and know all the details (hidden features/bugs) of the controls they use. The compiler/linker should have taken care of the different platforms. Like compiler options that determine if you are compiling against win32 or nix. Making the developers try and remember all the differences is the same as making them learn a new language. Thats just dumb, and if there is one thing developers tend not to be it's dumb.

    Now if you come forward to today where Desktop nix is starting to make headway. What would be really interesting is if there were a stable version of Kylix that let you use your Delphi or CBuilder code, (not CLX and custom libraries for nix.) and the compiler/linker took care of the platform specifics. Price it around the same as the Turbos. You have a good viable product. ["Of course if wishes were horses we would all be eating steak"]

    I don't think Borland/CodeGear has the courage to do this. Because while the website says "Where developers matter" what it really means is "Where developers pocketbooks matter". Just look at the sad state of the BDS products. Borland hopped on the .NET train because that was where the money "is/was" but now instead of innovating, they play catch up for the privilege of being dependent on someone else's technology.

    I could rail all day on mistakes Borland made, but as they say hindsight is 20/20. Let's not focus on the past but look forward to the future and all the mistakes they have yet to make.

  • by scottsk ( 781208 ) on Thursday December 28, 2006 @11:48AM (#17388622) Homepage

    Funny this story breaks after I spend all morning getting Delphi 5 to run under WINE, to support a legacy app that was written back when Delphi 1 was an exciting new thing.

    Watching Delphi die horribly was sad. Delphi originally did one thing very, very, VERY well - it was a rapid development platform to make GUI apps in Windows very fast, that you could distribute as standalone applications that ran very fast. No VBXes or vbrun.dll. I knew Delphi was doomed when Borland changed the defaults to NOT create a standalone app. "They just don't get it." Then version after version took Delphi away from its mission. Delphi was not going to work as an enterprise database tool, an Active X control construction tool, a .NET language, etc. That wasn't why Delphi faithful liked it. Borland just didn't get what made Delphi great. Plus the price became outrageous with all this "enterprise" nonsense.

    So ...

    Why not open source Kylix/Delphi? Linux has no real rapid GUI development tool. Let real developers fix whatever is wrong with it. See if anyone uses it. After all, Turbo Pascal is as dead as dead can get.

  • by linuxtelephony ( 141049 ) on Thursday December 28, 2006 @12:01PM (#17388788) Homepage
    Kylix had lots of problems. I was one of the many excited when it was offered and became available -- that is until I downloaded and installed it. The out-of-date library requirements (almost from time of release) for installation, the unstable environment that was not responsive or would crash from time-to-time, the wine requirement. Couple that with an extremely expensive price tag.

    Borland/Inprise got greedy, plain and simple. They tried to charge a premium price for products on Linux. Had they done any amount of "real" research they would have understand that was not going to fly. I'm not saying there wasn't a market for non-free tools -- I think they could have made some great inroads had the priced and marketed Kylix properly. I remember being highly surprised at the high price of the "enterprise" version. Of course, they also charged a hefty premium for Delphi enterprise as well. I don't recall if Delphi and Kylix were the same price, it seems as though Kylix was noticeably more.

    Couple Borland's history of quality software, and an expectation of excellence from their loyal customers, with the quality of Kylix, the looming disaster was obvious. I tried Kylix 1 and Kylix 3. I don't know anything about 2. Kylix 1 always felt like it was more of an alpha or beta release when I used it, not a finished released product. You are not going to win any friends charging a premium price for something like that.

    The sad thing is, I have a gut feeling (pure opinion, not backed by hard facts) that the back end of Kylix was probably pretty decent. It was as though they were spending so much time getting the back end compiler part working perfectly that they ran out of time for the IDE and had to take shortcuts to get it out. Kylix may have been a technical marvel on one-hand, but the part that people actually saw and used on a day-to-day basis left a bad impression. Especially for the price.

    Instead of learning their lesson and adapting to the market, they blame the Linux market for being unwilling to buy non-free tools or make other excuses. When, in reality, had the product they offered lived up to the expected quality of Borland's products, and been sold at a reasonable price, my guess is they would have been much more successful.

    • The original intention, as I understand it, was that Kylix's cross-platform emphasis was, as Delphi typically was, intended for being able to port your custom, proprietary software in the business sector to Linux. They were hoping that Linux would take a larger role in the business desktop and server market for proprietary applications, and they happened to be wrong.

      That's why the price was so high at first-- it wasn't for open source developers, it wasn't for free software developers, it wasn't intende

  • by mhenley ( 542737 ) on Thursday December 28, 2006 @12:27PM (#17389080)
    I wrote some software in Delphi and was excited when Borland (Inprise) announced Kylix. In the end I purchased all the versions of Kylix that they released and none were up to production quality standards. They all had longstanding, known bugs that were never addressed. Eventually, I found the Lazarus project ( http://lazarus.freepascal.org/ [freepascal.org] ). While the debugging is not up to what I had with delphi, I am able to code in Linux on a project that other developers are developing in Windows. While we have found bugs and limitations, the developers are quick to fix problems that we find and/or suggest better ways to do things. Matt Henley
    • Re: (Score:1, Insightful)

      by Anonymous Coward
      One negative Delphi supporters like to point out is that Lazarus isn't quite ready yet, you know lots of bugs ... well neither is Kylix, so it follows that the most sensible thing is to go with an open source development tool.

      At one time Borland said they were committed to Kylix in the long term, so I guess I know how good their promises are.

  • CLX was kack. So I guess QT on windows was kack.

    If only they used the wxWidgets wrappers, they would have platform native widgets underneath.

    Lazarus is to me what Delphi used to be.

    Sam
  • Linux needs this (Score:3, Insightful)

    by MobyDisk ( 75490 ) on Thursday December 28, 2006 @07:48PM (#17394012) Homepage
    Linux needs a modern, stable, bytecode-based, object-oriented, cross-platform language and runtime. For Windows this is .NET. )Since this is Slashdot, 1000 people will poo-poo .NET by the time they make it to this sentence) The corporate reality is that C# .NET is replacing C++ as the standard language for enterprise development and GUI application development. As a language, C++ hasn't kept-up fast enough, and to turn C++ into a platform you need a whole variety of 3rd-party libraries. .NET is a one-stop solution and it is a joy to program in.

    Now while everyone is talking about this being the year of the Linux desktop, I see companies moving away from standards and toward .NET. And Linux doesn't have a viable alternative. The current options I see are:

    Java
    Mono
    Kylix?

    Each has limitations. Mono has/may have dangerous patent problems, and the Novell/Microsoft deal seems to confirm it. I'm not sure what Java's limitations are today, since I abandoned it a decade ago. Kylix was supposed to be the solution. It had the ease of VB, the cross-platform power Qt, and the power and elegance of C++. But today the VB IDE is considered anemic, Windows Forms is better integrated into the IDE than Qt, C# has integrated most of the good features of C++, and bytecode compilers are 70% of native speed which is good enough.
    • The biggest obstacles of using Java are the runtime support it offers. This might sound strange, since Java has been developed with runtime capabilities from the start. But since the focus on the enterprise edition, not too much has been done to address this issue:

      - finicly way to handle memory allocation - defining a maximum heap size to give hints to the garbage collector never seems like a good idea to me, unless you are an application server
      - command line support; you can use the Apache libs to create a
    • Concerning .NET I have a different opinion (To be more polite than 99% of the slashdotters concerning .NET ;-) ). A Virtual Machine ,like .NET only makes sense, if it is REALLY Platform independent. Any other way the advantages cannot make the disadvantages be forgotten. 70% sounds good, but it is still too slow, if you think about how much speed you can gain by code optimization. Just an example: I take one algorithm (NO SOURCE CODE IN LANGUAGE X, ONLY THE ALGORITHM!!!!) and optimize it, so that it runs, l
      • by MobyDisk ( 75490 )

        A Virtual Machine ,like .NET only makes sense, if it is REALLY Platform independent.

        I largely agree, but I doubt that Microsoft made .NET a byte-code language because they wanted to port apps to Linux. They wanted all the little side-benefits that go with bytecode languages that C++ programmers don't realize until they use it. The debuggers are better (fewer machine-level interrupt-level machinations) and they tend to be less crash-prone, they are less crash-prone, and have easier memory management. Dynamic linking is easier. Dynamic dispatch is easier. It is like when you first lear

        • With 10% I was referring to a possible Factor. To Increase the speed from, lets say exponential to polynomial you would usually have to reconstruct the whole algorithm. If you optimize it without rewriting it you can usually only improve the Factor, e.g. from 2*e^x to e^x.

          Byte-Code itself is a nice idea, because it leads programming languages back to the idea, write once, let it run everywhere, what was exactly the purpose why high level languages were developed. But if you lock them in again on one grou
    • by nurb432 ( 527695 )
      Sounds like you want Python.
    • Linux needs a modern, stable, bytecode-based, object-oriented, cross-platform language and runtime. Kylix was supposed to be the solution.

      But Kylix was not bytecoded and so does not meet that important role. It is Delphi - a language with pointers that compiles to machine code. You can leak resources by forgetting to free, and you can cause access violations by referring to objects that you have already freed. Like C++.

      Now Delphi.net is a different story, and also a less interesting one - if you're going to
  • by Anonymous Coward
    They have been hived off by Borland since there were no buyers.
    Borland have already sacked 120 staff in the last month since they are losing millions.
    Expect to see them shut down within 18 months.
  • Dropping Kylix is a pretty good decision, Linux has no future anyway [Ducks and covers!]

    It's a shame a lot of developers are leaving Delphi, its's still a fine language (probably the best for Windows RAD) and well supported, and as long as there is a Windows API it can still produce a single executable that will run fine on anything from Windows 95 to Vista. I personaly have no plans to move but (unfortunately for Codegear) nor do I have any to upgrade.

    Boz

    BozNZ - Simple solutions to complex problem
  • I agree that Linux needs a modern, stable, bytecode-based, object-oriented, cross-platform language and runtime. For Windows this is .NET. The corporate reality is that C# .NET is replacing C++ as the standard language for enterprise development and GUI application development. If I knew this in advance, I would save my time by investing more on C#. As a language, C++ hasn't kept-up fast enough, and to turn C++ into a platform you need a whole variety of 3rd-party libraries. .NET is a one-stop solution and
    • by GigsVT ( 208848 )
      What advantage is there to compiling to bytecode again?

      Java has failed to deliver on the "write once run anywhere" line of BS, and .NET was never intended to do that.

      We already have machines, they work just fine and AMD and Intel put a lot of effort into making them fast. Why do we want to add a pointless layer of machine abstraction on top of that?
  • Lazarus [freepascal.org] is the new Kylix!

    Why even use Delphi any more? All Lazarus needs is proper documentation and some tutorials to be written, and then everyone who used Kylix can port to Lazarus and avoid Delphi.
  • So they are renaming it "Killix"?
     
  • Funny, but the Hungarian Kylix [kylix.hu] site is hacked for more than one year. The page is full of text "Hacked By Milli-islam.OrG". Nobody cares at Borland.

Trying to be happy is like trying to build a machine for which the only specification is that it should run noiselessly.

Working...