Yes, Virginia, there is a Delphi MacOSX and Linux project...

Posted by on in Blogs

I guess the proverbial cat is now out of the bag. As was shown in the Delphi/C++Builder roadmap at Delphi Live!, Project X has been under way for a while now. So now you know some of the reason why things have been rather quiet here since I could not really talk about what I'm working on. The good news is that we now have a returning top-shelf engineer working on the compiler. This person was heavily involved with the original Delphi on Linux project, so there is a lot of institutional knowledge that he's able to bring to the table. Things are going to be done

Another noteworthy item is that the information in the roadmap was more about future technology rather than specific releases. In fact, for the first time in nearly as long as I can remember, we literally have several parallel efforts going on. Unlike the previous Delphi on Linux era where the teams were bounced back and forth between the Windows and Linux projects, we're keeping a smaller, more focused team engaged on "future" work with minimal distractions. Of course the "next" product release will always engage the majority of the team, but having several "background threads" of development adds a truly exciting dynamic to the team.

So if you're at all interested in some tidbits of information about the technology behind Project X and some interesting insight into a lot of the really low-level bit-twiddley aspects of the Delphi compiler and how it integrates with a new platform (and even an "old" platform like Linux) you really must check out Eli Boling's new blog. In fact, he's already starting posting some pretty gnarly stuff about some of the more goofy aspects of the Mac OS. Oh, and if you know the definitive answer to this question on Stack Overflow, please post it there.

So strap in, hang on, it's going to be an interesting ride :-).

Tags: CodeGear
About
Gold User, Rank: 84, Points: 11

Comments

  • Guest
    Marcelo Wednesday, 20 May 2009

    The link to Eli Boling's blog is wrong. The right one is...

    http://blogs.embarcadero.com/eboling/

  • Guest
    Márton Balassa Wednesday, 20 May 2009

    Allen, where can we read about this new road map and the new features? Unfortunately, I've missed the conference, but I'm very+ curious about the new stuff. And also, rock me, but we are still using D2007, and there is no comprehensive list of the new features and fixes of D2009, by which we could decide to port our projects or wait for the next release.

  • Guest
    Allen Bauer Wednesday, 20 May 2009

    xepol,

    Yes, traditional VCL is inextricably tied to the Windows platform. For that reason, we're looking at other options and solutions. I have nothing to announce right now, but we are painfully aware of the issues involved. Another thing to note is that this is **not** being planned as a one-shot project, so there may be some things that we won't get quite right out of the gate. That's what version 2 is for :-).

    Allen.

  • Guest
    Philipp S Wednesday, 20 May 2009

    Thanks for this post! Now that you've got to worry about 16-byte alignment, this of course also raises the question of whether it will finally become possible to make select variables 16-byte aligned in Delphi Win32, so as to ease the use of aligned SIMD instructions?

    Second related question is whether you could reveal what calling conventions Delphi for Win64 will use internally (and what x64 ASM functions would look like)?

  • Guest
    ahmoy Wednesday, 20 May 2009

    Delphi v2??? nope, my question is not on the rad ide version but on the Delphi language version...

  • Guest
    snorkel Wednesday, 20 May 2009

    "I still think Linux is a dead end"

    Linux is not a dead end.
    I have a PostgreSQL admin program created with Delphi(2009) and I have had tons and tons of requests for a native version that runs on Linux (and OS X).

    Any cross platform Delphi will absolutely have to have 3rd parties involved like DevExpress etc. I hope code gear is including major 3rd parties in the development.

    Linux users will buy software, but it can't be super expensive.

  • Guest
    Daniele Teti Wednesday, 20 May 2009

    Really a great news!
    I was at Delphi live and I'm waiting for a blog post like this!

  • Guest
    David B Wednesday, 20 May 2009

    I disagree with Xepol about VCL. Or rather I disagree with his conclusion, which appears to be that a competely new OSX-VCL will be more popular than making the existing VCL compilable into OSX.

    Very few people are going to rewrite their entire existing VCL application with a new OSX-VCL. I know we certainly won't. Whereas I imagine a lot of developers would be interested in taking their existing VCL application and with just a few changes produce common ifdefed source which can be compiled for Win32 OR OSX.

    I agree that the current VCL doesn't suit Mac OSX. I don't know if it is possible to evolve the current VCL in such a way that it would suite Mac OSX and still be backwardly compatible with existing VCL applications. I do know it is likely to be very, very hard, much harder than just creating a new non compatible OSX-VCL.

    But the fact is, that is the only way to get major buy into the OSX compatibility. Failure to achieve easy common sourcing of existing Win32 applications between Win32 and OSX means that the OSX functionality will only be for a small amount of new development and suffer accordingly.

    Note that this goes along with what Snorkel said. If DevExpress and other key third party component providers aren't willing to modify their libraries for OSX (which is only likely if they too can common source) then you are dead in the water in terms of converting any existing development companies using Delphi (which lets face it must be 95+% of the market for each new Delphi release).

    If someone can provide a compelling case otherwise then I'm interested to hear it. By compelling case I don't mean simply saying that doing what I suggest is hard - I know it is hard, my point is that it is the only way to achieve real success.

  • Guest
    Rich Wednesday, 20 May 2009

    My customers and I already use Linux/FreeBSD servers, but are staying with Windows on desktops.

    Being able to write GUI apps for Linux is much lower priority for many--so I hope that aspect doesn't cause a multi-year delay before we can write Linux server apps.

    Heck, give us the ability to compile ISAPI .so files we can deploy to Apache2/Linux--and take your time getting GUI really nice after that.

  • Guest
    David B Wednesday, 20 May 2009

    Clinton/Xepol: Yep, we use third party components like most people with any application of note.

    I think we actually agree in general.

    The current VCL will not port very well to OSX or Unix, it would need a major upgrade and this would be very hard to do while retaining a smooth upgrade path from VCL2009 and also allowing third party component providers to upgrade their code to the new version without a complete rewrite.

    So hard that it might be impossible with the resources CodeGear have.

    But if you are NOT going to do this then I don't see any point in building OSX support. If it means a new OSX-VCL which is not compatible with the current VCL and unlikely to ever be supported by the major third party component vendors then what have you got? Certainly not a tool which is of any real use to most current Delphi users who have large existing applications which they are not going to rewrite.

    As you say it didn't work for Kylix or VCL.NET so no reason to expect it would suddenly work for OSX.

    To that I would add UNLESS CodeGear somehow put the effort in to achieve relatively easy two way compatibility with the Win32 VCL for both developers and third party component writers.

    Of course it is possible that the OSX angle is aimed entirely at new developers and not at all at existing Delphi users. Is there a dearth of visual development tools for OSX? IFF so then maybe that make sense.

  • Guest
    Maxim Wednesday, 20 May 2009

    Cross-platform modern native compiler is great. Just between C++ and Java/NET.

    But the main problem would be like in Java - the difference in platform GUI toolkits, web stacks etc. For GUI in the Java world there are two distinct branches: Swing - no platform controls and everything is drawn by Java and SWT - proxies and wrappers for platform controls. By the way, Lazarus/LCL still plays the try-to-catch game in the SWT style and is still 0.9.x.

    Probably, Delphi, being native, should support one cross-platform (single-source) GUI library and one additional for each platform. Programmers always have a fork: either make a single-source generic cross-platform application or a heavily specialized for each one.

    Should Delphi support both cases? Definetly not in the nearest timeframe? If not, which should be first? What way (Swing or SWT/LCL) should it go? Isn't wine sufficent for Linux? Isn't (or won't be) Web2.0 (ExtJS, qooxdoo, ...) sufficient for single-source solution?

    I as a customer just do not have answers for all this questionsrigh now? I just hope that Delphi team has some questions as well and is ready to discuss them.

    So my first approach (for my own answers - pre-alpha version):
    - SOAP and JSON backend for single-source browser-based solution (with ExtPascal to avoid JS learning?). Some sort of DelphiPHP with native Delphi code instead of php but focued on AJAX only with no server-side html rendering at all.
    - VCL + wine for Linux. Belive me, almost each and every application I create with D2007 works in wine.
    - as for OSX - simply don't know

    Reasons:
    - I would like to run my applications to Linux/wine just because of financial reasons - in crysis time it's difficult to upgrade and maintain hundreds licenses for Windows. I just don't want to rewrite them - just run as is. Probably, I need a minor help from compiler to mark wine-incompatible calls with warnings. Do I want to compile to native Linux executable? Do I want it now? No, now I need a sofisticated wine configuration/deployment tool with automatic setup of midas.dll registration, DBX dlls's placement, etc.
    - I would like to make some applications available from outside of the office. And I don't know what platform the user will use. So Web-only. But still reach clients.

    {$TODO AFTER ALL OTHER DONE
    As for managed platforms: do you remember Delphi -> JavaVM demo years ago? If you've desided against ".NET is C#" why "JavaVM is Java" is still valid? Delphi/Object Pascal compiler plugin for Eclipse like Prism for VS?
    }

  • Guest
    Luigi D. Sandon Wednesday, 20 May 2009

    1) Please don't call it ProjectX - it recalls CBuilderX and that was not a great project...

    2) I am on the side of those who prefer a native framework than a cross-platform ones. The latters will always require compromises - and lead to poor or alien GUIs. When we are going to target MacOS, we will develop a MacOS application, and it shouldn't show it was developer with a cross-platform tool. I know it's a bigger effort than write once compile everywhere - if I needed it I would be using Java.

  • Guest
    Yogi Yang Wednesday, 20 May 2009

    I think CG needs to take some clue from KBasic. I know, I know it is basic but the way in which the developer has wrapped QT it is just fabulous.

    Do check it! who knows it may give you people some ideas for working out a VCL (without its current version dependence problem) replacement framework for non Windows OSs.

    HTH

  • Guest
    K.A. Wednesday, 20 May 2009

    Whoever wants the best native GUI application in a specified platform, must use the native SDK: on Windows, one must use Visual C++ and Win32 API; in MacOSX, Objective-C and Cocoa API, etc.

    The cross platform development appeal is to have the same code-base and being able to deliver that same application on multiple platforms. Libraries like QT and wxWidgets (Former painting and latter wrapping native controls) do a good job in delivering an acceptable - Native looking - GUI on multiple platforms (Code::Blocks and pgAdmin III by wxWidgets, many others with QT)

    Failing to realize this key concept will negate the whole point of cross-platform RAD development.

    Also, CG/Embarcadero can develop the Cross-Platform GUI, and leave the door open for third-parties to deliver the specific native ones for the market.

    It's worth noting that at the moment, Linux is more of a proven server technology than a desktop one, so delivering a solution to cross-compile server side 64bit application servers on Linux is IMHO of more importance.

  • Guest
    Daniel Luyo Wednesday, 20 May 2009

    Well, IMHO if it's native then go native.
    But there should some steps in the middle:

    Step 1. No GUI apps, great for server, and plugins. Ideal for Linux environment. Short term.

    Step 2. Plugable GUIs for multiplatform, want QT? use the QT-ONLY way, wants GTK use the GTK-ONLY way, for all the plataforms. This is not 100% native but more easily doable. Only for new applications. Mid term

    Step 3. Full Native, for each platform, the hardest but the finall correct solution, the same current code will compile for every platform, native tweaks will need ifdefs. Long Term

    We can always relay to class inhertance, BaseClass > WinClass, NixClass, OsXClass. More work but better user experience

  • Guest
    snorkel Thursday, 21 May 2009

    There are lots of people using desktop Linux, many more than you think. Are there a lot of Linux desktops in US corporations NO, but there are many,many many at home or on laptops etc.
    What Linux needs is a Visual Basic type of software explosion as seen when VB 3 came out all those years ago.

    The Desktops are there and very very nice. KDE 4.2.x is incredible as well as the latest Gnome versions.

    I think using QT 4.5 would be a good move as it supports Linux, windows and Mac. QT now has new licensing that would allow CodeGear to use it without having to purchase any kind of license etc.
    http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt

  • Guest
    snorkel Thursday, 21 May 2009

    Someone mentioned Kbasic, Gambas is also very well done.

  • Guest
    wpslider Friday, 22 May 2009

    five, six years ago would have been the right time for this project. As it is at the moment, I *already* run my D2007 dccil winforms project on osx via Mono.

    What I would recommend would be some sort of gcc backend to be written that allows delphi syntax to be written that targets multiple platforms/architectures. Think iPhone, Android.

  • Guest
    Luigi D. Sandon Sunday, 24 May 2009

    "Whoever wants the best native GUI application in a specified platform, must use the native SDK: on Windows, one must use Visual C++ and Win32 API; in MacOSX, Objective-C and Cocoa API, etc."

    Visual C++ *is not* the native SDK on Windows - it's just a compiler - what about Delphi application using the Windows API - aren't they native? Don't mess the compiler with the APIs.
    However when Delphi will start to deliver so-so "multiplatform" GUIs that looks so-so on every platform we will switch to other compilers able to exploit the native APIs

  • Guest
    SJG Monday, 25 May 2009

    Show Me The Money !! I'm not going to be interested in anything that falls by the wayside because CodeGear/Embarcadero can't make money out of it. And for CodeGear/Embarcadero to make money out of getting Delphi to produce applications for Linux and other platforms they have to come up with a toolset that is attractive to a significant number of the developers who will be building new applications for new devices based upon those platforms. Picture a 'cloud' with server farms hanging out of the back-end and everything from lounge room televisions and netbooks to Mercedes and Boeing Dreamliners hanging off the front-end. Marketeer's hyperbole? Perhaps. But that is what is currently being sold by the bucketful, and that is what is shaping end-user expectations. Every outfit that could potentially use Delphi licenses to develop and maintain application systems that are delivered through that cloud is an opportunity for CodeGear/Embarcadero. And those applications include everything from banking to porn, artists to zoos. Curiously enough, many end-users don't seem to give a hoot about all the techno-babble or what goes on under the bonnet - they just want something useful that is easy to use and affordable. Most end users couldn’t give a fig about choice or freedom or open: top of their consumer-oriented lexicon is convenient and intuitive and inexpensive. Witness the Asus eeePC: Linux had its shot, and now most of those gadgets ship with Windows XP because that interface is familiar to many end users, and because there are plenty of familiar Windows applications available. A Linux look-and-feel? Which one? You might as well paint a target on your forehead as far as commercial viability is concerned – and forgive me if I’m wrong, but the last time I checked in, CodeGear/Embarcadero was still a commercial for-profit enterprise. And the Apple thing? Opium for the addicts. Most of the commercial desktop software outfits who still bother are those who established niche markets for their product lines well before OSX fell out of the sky, and only Apple makes decent money out of i-Pod and i-Phone and other i-toys. So when it comes to making Delphi produce applications for multiple platforms I would suggest that tomorrow’s users are looking for the interfaces they see in Minority Report and Star Trek – not forms, typewriters (and a block of cheese) from I Love Lucy. Back in the days of its saxophone-chevy incarnation, what is now known as CodeGear was a leader and an innovator. Perhaps it’s back to the future time.

  • Please login first in order for you to submit comments