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 :-).
The link to Eli Boling's blog is wrong. The right one is...
ReplyDeletehttp://blogs.embarcadero.com/eboling/
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.
ReplyDeletexepol,
ReplyDeleteYes, 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.
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?
ReplyDeleteSecond related question is whether you could reveal what calling conventions Delphi for Win64 will use internally (and what x64 ASM functions would look like)?
Delphi v2??? nope, my question is not on the rad ide version but on the Delphi language version...
ReplyDelete"I still think Linux is a dead end"
ReplyDeleteLinux 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.
Really a great news!
ReplyDeleteI was at Delphi live and I'm waiting for a blog post like this!
My customers and I already use Linux/FreeBSD servers, but are staying with Windows on desktops.
ReplyDeleteBeing 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.
Clinton/Xepol: Yep, we use third party components like most people with any application of note.
ReplyDeleteI 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.
Cross-platform modern native compiler is great. Just between C++ and Java/NET.
ReplyDeleteBut 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?
}
1) Please don't call it ProjectX - it recalls CBuilderX and that was not a great project...
ReplyDelete2) 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.
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.
ReplyDeleteDo 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
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.
ReplyDeleteThe 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.
Well, IMHO if it's native then go native.
ReplyDeleteBut 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
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.
ReplyDeleteWhat 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
Someone mentioned Kbasic, Gambas is also very well done.
ReplyDeletefive, 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.
ReplyDeleteWhat 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.
"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."
ReplyDeleteVisual 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
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.
ReplyDeleteHopefully it won't be taking resources away from Update 3, 64bit support, multi-threading support etc. and there will be some long term commitment behind the project (Kylix, CBuilderX... I'm looking at you, that ProjectX naming awfully sounds like yet another experimental project).
ReplyDeleteBy the time we were considering Kylix usable enough, it was getting obsoleted.
Also whatever support libraries you design, please, please, don't go the CLX (or C) route, don't involve conditional directives, whether just around "uses" section or scattered throughout the code. It's unnecessary and we're still cleaning up that mess from the Kylix era. Keep the mess in specific units or the compiler.
@SJG, It is cool that you mentioned Minority Report and Star Trek. VCL is going to natively support touch, multitouch and gestures. During the opening keynote on DelphiLive we have seen fragments from "Minority Report" (http://blogs.embarcadero.com/pawelglowacki/2009/05/20/38711) and "Quantum of Solace" and images of Star Trek. THIS IS WHERE Delphi is going with UI experience!
ReplyDeleteRe. Stack-alignment on OSX (in case it's not answered already on stackoverflow):
ReplyDeleteWalter Bright had to deal with the same issue when porting his D compiler to OSX.
http://dobbscodetalk.com/index.php?option=com_myblog&show=Porting-D-to-the-Mac-Pt.-3.html&Itemid=29
From a comment on his blog:
"The reason that OS X aligns reals, and every other kind of data, to 16 byte boundaries is that SSE requires 16 byte aligned data. Since OS X uses SSE in many places it requires that all data, including the stack, be 16-Byte aligned. "
Just a "hello world" console application on Mac? You must be kidding me! :lol:
ReplyDeleteYet another promise and waiting, what a shame for a big company like CodeGear is unable to create a true cross platform tool while many open source projects had done it since ages. Even FPC/Lazarus -as it uses same language: pascal- had done it very well if you eager to be honest to yourself. :P
Sorry, as long as CodeGear is unable to show me something that truly working, not just promises and buzzes all around, or "hello world demo, I don't believe it! :P
If RealBasic can create simultaneous applications for the MAC O/S and Windows and Linux, it is certainly feasible for Delphi. They also have 2 way code tools just like in Delphi - click the VCL component event procedure or write the code in the editor.
ReplyDeleteI was thinking about abandoning Delphi for Real Basic, but if you're going to develop a compiler in the near term, I will continue with Delphi. I started with Turbo Pascal 2.0 and wrote Windows programs starting with Delphi 1.0 and up.
I hope that there is a delphi native compiler planned for
ReplyDeletelinux - .net is not for me - the VCL has served me too well
This would be a real confidence booster for native delphi developers, whether they are going to use the linux platform or not.
64 bit can wait a bit
I don't really care about a single cross platform GUI framework, VCL or otherwise. As many have already said, if you want a true cross platform GUI framework, just use Java. I want rich UIs that take advatage of the native capabilities of each platform.
ReplyDeleteTherefore, if I want to write a true cross platform client application I would write the underlying business and data layers to be true cross platform and it would be great if Project X allows me to compile the same source to all three platforms.
I would then create seperate thin GUIs for each of those platforms, utilizing the best of the native UI functionality on each of those platforms and compile those UIs seperately for each platform and make those UIs utilize the same underlying layer mentioned above (but compiled for that platform).
In other words, three seperate and thin GUIs sharing the same underyling business and data layers.
Can't wait for Project X.
We now using a lot of O/S, actually Linux (Ubuntu) and Windows (XP).
ReplyDeleteFor our customer MS-Win remain the main o/s at the moment , but OSX is increasing everywhere.
Before this post we was on deciding if port our application to other languages... now we have decided to wait until 2010 and maintain our Delphi apps.
so the cross platform is a priority for us. Actually in some cases we use wine, but we can't contiune using it, for some problems that you can imagine.
bst rgds
Ivan Revelli
Yes Yes and Yes!
ReplyDeleteFinally! I have had a mac for so long, and so many programs just begs to be written for it -- but freepascal simply dont cut it (not much of a GUI there).
Cant wait for the mac version!
How long do we have to wait, and what will be the results? I was very enthusiastic for Kylix, only to see the vagaries of the then Borland strategy go astray. Once burned...
ReplyDeleteAlso, what about the pricing? Any pricing over 99€ (the original TP prices) is out of the question.
And guys, try to be compatible with the leader on unices and MacOS : FPC/Lazarus. You're years behind. When do we even get a 64 bit compiler?
Best regards,
Thierry
Since Lazarus / FPC exist, support Win,Linux, MacOSX, can compile in 64 bits and over platform like in WinCE/Arm and of course is unicode right before D2009, i think this Project X is useless.
ReplyDelete0.9.29 is really advanced.
"Since Lazarus / FPC exist, support Win,Linux, MacOSX, can compile in 64 bits and over platform like in WinCE/Arm and of course is unicode right before D2009, i think this Project X is useless.
ReplyDelete0.9.29 is really advanced."
Project X is not useless. The IDE of Lazarus is still a bit behind the Delphi IDE.
I would love to see the Delphi IDE support the Lazarus compiler and QT integration.
This will be enough for me. And it doesn't sounds so tough right?
stop bashing, please!
ReplyDeleteyes, we need delphi for mac osx/linux.
and yes, there's lazarus.
however, while lazarus is really nice it doesn't help me migrating my 10+ years old delphi applications that use a lot of third party components. there is a real need for delphi X, and i'd be the first to buy it.
lots of my clients are asking for osx versions - the pressure is getting higher every day. i really need a stable, supported, backwards-compatible version of delphi to create osx versions of my applications. it's good to know that embarcadero are working on it (even though they're really really late...). i just hope they get project x to market in 2010. otherwise i might have to take the bitter pill to rewrite my most importan app from scratch.
embarcadero, please shed some light on what's going to come? will the VCL be there for OSX/linux? or do we have to replace the entire frontend of our apps? please give us some hints!
and keep up the good work! i'm really looking forward to cross-compilation! i love delphi, that's why i'm still hoping for another solution that "porting-away". but i can't wait forever...
all the best
chris
Wine Perfectly works with delphi apps, I think just creating a linux header is enough , then embedding the needed wine stuffs inside the apps (As Wine is free and open source)so vcl will work perfectly in Linux without rewrite
ReplyDeleteGreat article....
ReplyDelete