Marco Tech Blog

June 13, 2009

Delphi Cross-Platform Dream, by Tim Anderson (on the Register)

I found a very nice article, with an interview to Embarcadero CEO Wayne Williams, written by Tim Anderson and published in The Register

posted by marcocantu @ 8:33AM | 21 Comments [0 Pending]

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

> underlines cross-platform has higher priority than
64 bit support

That's disappointing, IMHO.

Comment by Moritz Beutel [] on June 13, 11:32

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

> underlines cross-platform has 
> higher priority than 64 bit support.

That's also very stupid, IMHO, first because porting 
Delphi and the VCL to 64 bit is simpler than 
developing a cross-platform compiler and library, and 
also because they're very late to deliver a Windows 
64 bit compiler. 64 bit deployment are growing 
stronger - if nothing to break the 4GB barrier. It 
makes very little sense to buy a machine with 8GB or 
more and don't take advantage of them.
It is true that most 32-bit applications can run on 
64 bit systems, but there are technical and marketing 
reasons to deploy full 64 bit applications - and the 
transition is much easier than starting writing 
applications for MacOS or Linux.
Company names may change, but they always take the 
wrong road.

Comment by Luigi D. Sandon on June 13, 14:43

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

A Nice Article. It's good to see that Wayne is clearly 
passionate about his strategies and truly believes in 
them. Mentioning the 64bit priority was his only 
mistake. 

Lets hope that the actual product is as exciting as they 
hope.

Comment by jamie [http://jamiei.com] on June 13, 14:50

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

 Is not clear if cross-platform is mono based. I think
the only acceptable solution must be native one. 
OTOH, implementing a VCL compatible with mac and linux
is not enough. That is already and is called LCL by
lazarus+fpc.

The hard part is convince thirdy party libraries
providers to put the needed effot in cross-platform
components... That is exactly the need with lazarus
and fpc, rigth now. Is only suitable for servers IMHO.

Comment by Donald Shimoda [http://donaldshimoda.blogspot.com] on June 13, 19:05

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

Crossplatform and 64bit are two separate projects 
running in parallel. 64bit is moving fast but will 
take longer to get to market than xplat. 64bit has 
many implications on the existing customer Delphi and 
VCL Windows codebase. xplat is certainly a lot work 
(new compilers and VCL framework) but has a different 
type of of impact and expectation on existing code 
bases. ie we're more free to make breaking changes 
when going cross platform than 64bit. 

Comment by Michael Swindell [http://embarcadero.com] on June 13, 21:30

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

What about 64 bit support for xplat compilers? The reg
article says linux & mac version will be released next
year, will it be i386 only?

Comment by silver [http://premiumpaidsurveys.net/] on June 14, 19:37

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

We are *already* writing and deploying our Linux 
applications on *64 bit* Linux (of course using gcc). 
Thereby for us a *32* bit Linux cross-compiler is 
utterly useless.
Our next upgrade, if ever, will be for a 64 bit 
Delphi/C++ Builder.

Comment by Luigi D. Sandon [http://www.sandon.it] on June 14, 22:17

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

Delphi needs to reach x-platforms, its a must, and its
URGENT since Borland days (it was before the Kylix
days in fact). This late was a big harm to Delphi, but
it still time to make the move and be successful:
Delphi has enough potential to kick asses out there.
Native code rules, and thanks God Embarcadero knows that.

Comment by Javier Santo Domingo on June 14, 23:47

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

@Michael Swindell,

This surprises me.  The transition from 32-bit to 64-
bit should be easier than the switch from 16-bit to 
32-bit.

With the 16/32 bit transition, integers changed size, 
where-as with 32/64 bit it is only pointer sizes that 
change.

That's at the hardware level of course.  I don't know 
about the WinAPI itself.

But even so, I can't imagine that patching an existing 
framework should take longer than creating TWO 
entirely new frameworks from scratch, even allowing 
for the advantages of "greenfield" development vs the 
"existing code" problem.

I for one am extremely disappointed at this news.

Where I work there has been a renewed interest in 
Delphi and native code on the strength of the promised 
64-bit support and the apparent revitalisation of the 
product in the hands of Embarcadero.

64-bit support has always been a bigger issue for us 
and our customers even than Unicode was, and here it 
is being pushed further and further down the priority 
list!

This news of the downgrading in importance of 64-bit 
support couldn't have come at a worse time!

Comment by Jolyon Smith [http://www.deltics.co.nz/blog] on June 15, 06:47

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

I find it extremely worrying, for the same reasons
Jolyon, Luigi & Donald explicited.

Comment by Eric [http://delphitools.info/] on June 15, 11:08

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

Just to add my voice to the main thrust of comments...

Yes, 64 bit is the crunch issue for us and has been 
for all the YEARS it has been promised and then 
delayed. 

I think I'm right in saying that is was Wayne 
Williams himself who said at the time of the CodeGear 
aquisition that the team should and would deliver on 
the EXISTING roadmap before changing directions. 
Well, you can spin it any way you like, but that 
clearly hasn't happened. 

When a company makes such "promises" (putting aside 
the niceties of safe habour statements etc..) then I 
expect them to be delivered. You cry wolf once too 
often...

So where are we then? Taking into account all that 
I've heard and read up until this interview, I was 
still expecting a "preview" 64 bit compiler in the 
middle of 2009 (it's 15th June 2009 today), and in 
the first half of 2010 I was expecting a full 64bit 
Delphi. Are we getting a preview 64 bit shipped with 
Weaver (I'm putting aside "Weaver" coming 
before "Commodore" of course). Are we in fact going 
to see even the 64 bit preview slip and be included 
in some cross platform product coming out some time 
in the 2nd quarter of 2010? The full 64bit then maybe 
shipping before the end of 2010? 

The Register interview and Micheal's comments here 
feel like opening salvos, softening us up the to news 
that,yet again, 64 bit is getting pushed back. 

It's well past time that some dates were pinned to 
the current very loose roadmap. As a company we've 
already taken 18 months worth of customer flak for 
not having 64bit capability. Please do not make liers 
out of us yet again.

Comment by Paul on June 15, 11:48

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

 Excellent discussion on the future of Delphi, both
projects are essential, but I do not think that should
be in parallel, creating applications 64Bits IMHO is
more important because the technology is already here,
I do not know the sale of shares of 64 bits OS but not
take a long time to grow this market and all of our
applications should be able to use the huge resources
available through these operating systems.

otherwise non-Windows platforms and are currently at
64 bits, it EMBARCADERO stuck in 32-bit Linux?

Comment by Efrain on June 15, 17:40

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

I am very disappointed about postponing the 64-bit
compiler. It's been promised since years and we have
already been forced to port certain parts of our
source code to MSVC to provide 64-bit compatibility.

Repeatedly not shipping what was promised before
severly damages the trust we have in Delphi. With a
hundred thousands lines of Delphi source code, we are
practically locked into the Delphi platform, so it's a
very delicate relationship that must be handled with
extreme care.

There is more to Win64 than breaking out from the
2/3Gb max. memory use. Even with WOW64 the DLL/COM
in-proc is a technical limitation that affects us and
other developers. As Luigi mentioned, marketing is
just as important, quite often our customers ask why
we still have not yet shipped a native 64-bit version
and we've been telling them since years that it's
"coming soon, but oh, you wouldn't win that much with
64-bit anyway".

I don't mind a PHP, Ruby, Modula-2, Eiffel or
Smalltalk IDE, a MacOS or a BSD compiler as long as
the good old Delphi for Windows folks get what they
were promised.

Comment by Peter on June 16, 10:29

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

@ Javier: "Delphi needs to reach x-platforms, its a must"

Why? 

Assume Apple ported an Apple Object Pascal syntax
compiler to Windows. 

Who would buy it?

Only those Apple developers that prefer to stick to
the language syntax they feel comfortable in, and how
many would that be?

"Delphi has enough potential to kick asses out there."

If this new VCL provides a layer to ensure all Delphi
Pascal code is multi-OS compatible, it will be thick
and slow. May as well use Prism .NET/mono variant.
Also, the programmer will be protected from OS
specific features because otherwise the code becomes
OS dependent.

But if this new VCL is a "thin" layer, then the
programmer will have to get to know the quirks of each
OS, and if this is the case, you may as well just use
one of the more mature tools for that platform.
Learning a new syntax is no big deal. Learning the
quirks of each OS IS a big deal.

Add to that the fact that it will take a few versions
before each Delphi platform VCL is stable.

"Native code rules, and thanks God Embarcadero knows
that."

I think you may just have hit on something there! 

Embarcadero owns CodeGear now, and I suspect
Embarcadero needs xplat for its own business reasons.

Comment by Ken Knopfli on June 16, 15:13

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

 I Really do no understand Embarcadero

They can ask about Cross platform and what it worth 
from the clients that paid for Kylix (all four of 
them)

IMHO  when Win-7 will be out there and Win 2008 R2 
that mostly will be 64 bit .... 

if Embarcadero will not be there there will be no 
happy future for delphi....

Comment by Yaron Nahum on June 16, 17:13

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

@Yaron Nahum:

Make that 5 clients. 

I bought the expensive Enterprise(?) version of Kylix
two weeks before they dropped the price! And since I
am a good boy, I paid cash - and was told that,
because of that, there was nothing they could do to
help :(

Comment by Ken Knopfli on June 16, 19:49

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

 Crossplatform first is the natural path to 64bits
It woul be much easier to port the compilers to 64 
bits after the Crossplatform chalenge is done. 

Comment by Ring Lord on June 18, 03:13

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

I've got it figured out. Remember the debate over the 
super-secret numbers Nick Hodges claimed to have that 
showed that there was a phantom army of Delphi 
for .Net users? Apparently they're all using it on 32-
bit OSes. :-)

Ok, that started as a joke, but now that I recall, 
that was actually a refrain from certain folks in 
positions of power such as Mr. Hodges: that they 
could code 64-bit in Delphi RIGHT NOW by using .Net, 
hence there was no need for Delphi to rush in to 64-
bit. Maybe that's still the internal consensus? 

Comment by Joseph G. Mitzen on June 19, 05:03

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

It is not true that xplatform is a "natural path" to 
64 bit. It is true they have to update the compiler 
to a new architecture and multitarget-enable the IDE -
 but the fisrt outcome of it could have been a 32/64 
bit compiler. Then they would have to upgrade only 
one "VCL" - the Windows one.
If they go xplatform first they'll have to deliver 
the libraries also - and that's a far more broad task 
than upgrading the Windows VCL - and then upgrade of 
all them when going 64 bit (unless they want to 
deliver a lame mix of 32/64 bit compilers) - even if 
the 32 bit were coded with an eye upon 64 bits.
I agree with Knopfli that the real driver could be 
internal, and not external customers.
It's a very risky approach, IMHO, because a real, 
working xplatform devtool is very complex to build, 
even if the IDE is not ported, and I do not know how 
many more failures Delphi can endure, and how much 
can lag behind the leading Windows development tools 
before becoming a total no-go.

Comment by Luigi D. Sandon [http://www.sandon.it] on June 19, 16:56

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

I also see this the same way...

I and several ISV friends of me need 64bit.
A 32bit application is limited and running in a wow 
emulation layer where it is separated from the native 
windows things and tricked/redirected into backward 
compability things.

It isn't nice for marketing or development to roll 
out yet another old emulated 32bit software, now that 
Windows 7 is comming and every new machine customers 
buy is x64.

To have a valuable selling product out there, you 
need a customer base that actually pays, and you need 
to invest a long time into knowing the platform and 
stuff.

How nice... yet another bunch of strange components 
that force an app into a behavior and does strange 
things, just to enable osx (like kylix done... i 
never liked kylix code).
And yet another uncertain time and yet new 
considerations... should we lock our next version 
into delphi that is maybe a dead end of slowness, 
uncertainity and strange decisions, or begin our next 
projects (or port old ones) to other languages or use 
lazarus instead.

You think you can juggle around your dev customers 
every year and pump your resources in many adventures 
instead of concentrating on one.

Do you know what peoples say about you?
"Philippe Kahn of Borland fritted the resources of 
his company in to much featureless projects and 
ignored his real customers for too long, while he 
tried to fight on too many fronts and to do too many 
things and to follow every hype."

Yes its true, and it didn't change now...
Why not assign all developers on the next delphi 
architecture, clean old hurried up things up and do 
real clean options for unicode/64bit and stuff.

And as i said before... give out clear routes that 
you really follow till release...

Your customers are companys that have also customers 
and long projects and they simply can't stand 
uncertain futures and jumpy behavior...

Your company was and is always like "oh lets ignore 
the customers and the needs and do our own stuff and 
to not get bored, lets start half hearted adventures".

More and more companys can't stand this and will 
reconsider this in the next business talk. "is it 
more secure and profitable to move away?"

I've also heard from big players "we don't start any 
new projects in delphi cause of this. our code is 
locked on it, but new code will be done in other 
languages/ides and we slowly redo the old ones"

Why not drop .NET requirement from the IDE, redo the 
bad things in delphi and move also to new 
technologies...
Bad things you ask? there are many... for example, 
the bad way of installing packages, the bad package 
folder management, the inability to copy packages and 
options to other pc's quickly (notebook etc).
Also make components delphi version independent and 
make delphi able to consume c++  obj/lib files and 
assign devs on porting over microsoft sdk's when they 
come out...

Many features where just quick hacks, like unicode, 
the lock statements and so on.

Why do you throw out your resources and money into 
uncertain things and abadon your real market?

Why not really push your gem Delphi with full force 
forward?

The best and most stable ide, recent sdk's, recent 
technologies, cleaning up quick hacked in features 
and old bad things and do it the real good way?

I bet you will get millions out of it and a big 
market.

But no, you abadon and push back the market, start 
new adventures of which nobody knows if he gets money 
and how long it takes to get a stable ide and to know 
the quirks of the platforms...

You can't simply put together two buttons and sell a 
mac product.

You do so many things the bad way... but its your 
company and your ide...

Im bound to delphi, cause i like the language synthax 
and dislike c++ and big .NET installs, but i and most 
others will move along someday.

Either to a solution like Lazarus or take the hit in 
getting used to c++ somehow.

A dev can't find a delphi job in his neighbourhood 
and a ISV may run into a dead end when using delphi.
All uncertain cause the delphi guys run through the 
world with the hands in front of their eyes.

I bet there are some really bright minds in your 
company, but they can't really take a stand and move 
the ill horse 360° around to make it strong and shiny 
again.

You may fear microsoft and want to flee to other oses 
or get internally pushed by embarcadero database devs 
to move the other way, but it isn't good... neither 
for you, nor for your customers.

Well... im here, and im staying for some time, like 
many... just to see which hits we need to take next.

Maybe a clumbsy bad VCL and mindless warnings and 
hacks so it is compatible with other platforms?

Quick 64bit hacks with 32bit code but 64bit PE 
headers?

Huge 2MB empty exes?

Emulated 32bit exes while most customers run on 64bit 
while our apps are moved into "Programs (x86)" 
folders and emulated and separated from the rest of 
the system, for 4 years till delphi moves?

Well... time will tell.

Sad but true.

Comment by Peter Meier on June 22, 17:29

Delphi Cross-Platform Dream, by Tim Anderson on the Register 

Kylix 4.0 I guess (in Quality and Backing, not 
realistically "Kylix").

Comment by Nate. on June 28, 08:19