Subject | RE: [IBO] Delphi Live - Where is Delphi going? |
---|---|
Author | Calin Pirtea |
Post date | 2009-05-18T07:02:05Z |
Brilliant!
Thanks, Th.
Calin.
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On
Behalf Of m. Th.
Sent: Monday, 18 May 2009 2:02 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Delphi Live - Where is Delphi going?
Calin Pirtea wrote:
.NET solution, works _already_ on Mac/Linux via MONO. What was
officially announced (and demonstrated) at Delphi Live is a
cross-platform compiler for native code. If you'll have a look at photos
from Robert Love's blog you'll see in one or two a Hello World Delphi
application running on Mac.
A few words about this strategy: (for more, google for Nick Hodges's
article "The future of Delphi Compiler" on EDN)
The compiler will have a back-end - front-end architecture which means
that will support more languages (ie. different front-ends) - Delphi &
C++, of course (perhaps in the future will be added other ones, I don't
know), and it will support different code generators (different
back-ends): for Win32 (obvious), for Linux and for Mac. They will target
especially on the Mac the desktop side and on Linux the server side (as
expected, of course). The 'Project X' (as is code-named) probably will
be released in 2010, with a preview for a closed audience this year and
it features simultaneous multi-target compilation (IOW, with a button
you can generate 3 (three) executables: for Win, Mac & Linux). A special
case here is Win64 codegen which as you see from the 'unofficial'
roadmap is rolled out in a separate release code named Commodore. I
don't know the reasoning, but most probably is about VCL.
The VCL is a very important thing in this strategy. Nick stated very
clearly that the new compiler (written (almost) from scratch) will
compile (almost) all the old code. (See his article in EDN). But because
VCL is just a thin layer around Win32 API, making VCL cross-platform
isn't practically possible. So, they spoke about a new cross-platform
library which will have a "limited compatibility" with VCL. Nowadays,
for them the compatibility/ease of transition and quality are top
priorities (thing which is very good) so they will try to do all the
best in order to mimic the VCL's behavior but anyone who knows at least
a little what's under the hood knows that this isn't always possible.
But continuing to support VCL on 32bit and expanding it to support the
Win64bit platform is a thing which is quite feasible (imho) so, that's
why (I think) they will provide a separate release for Win64.
In our case, since we know that by far the VCL's hardest part to make
cross-platform is the part which deals with GUI, it seems obvious that
the in the IBO package must exists two sub-packages the Comm Layer and
the UI Layer. Of course the UI Layer will have dependencies in the Comm
Layer, but the Comm Layer must *not* have dependencies in the UI layer
(I'm thinking now at Design-time Editors) in order to be ported easily
to the Project X.
HTH,
m. Th.
[Non-text portions of this message have been removed]
Thanks, Th.
Calin.
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On
Behalf Of m. Th.
Sent: Monday, 18 May 2009 2:02 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Delphi Live - Where is Delphi going?
Calin Pirtea wrote:
> Hi Jason,<snip>
>
>
>
> I think the cross platform things is .NET (MONO) only.
>
>
>
> I'm excited to be able to reach the MAC platform!Nope. CodeGear Delphi Prism (aka RemObjects's Oxygene) - which is EMBT's
>
> Jason Wharton
>
>
.NET solution, works _already_ on Mac/Linux via MONO. What was
officially announced (and demonstrated) at Delphi Live is a
cross-platform compiler for native code. If you'll have a look at photos
from Robert Love's blog you'll see in one or two a Hello World Delphi
application running on Mac.
A few words about this strategy: (for more, google for Nick Hodges's
article "The future of Delphi Compiler" on EDN)
The compiler will have a back-end - front-end architecture which means
that will support more languages (ie. different front-ends) - Delphi &
C++, of course (perhaps in the future will be added other ones, I don't
know), and it will support different code generators (different
back-ends): for Win32 (obvious), for Linux and for Mac. They will target
especially on the Mac the desktop side and on Linux the server side (as
expected, of course). The 'Project X' (as is code-named) probably will
be released in 2010, with a preview for a closed audience this year and
it features simultaneous multi-target compilation (IOW, with a button
you can generate 3 (three) executables: for Win, Mac & Linux). A special
case here is Win64 codegen which as you see from the 'unofficial'
roadmap is rolled out in a separate release code named Commodore. I
don't know the reasoning, but most probably is about VCL.
The VCL is a very important thing in this strategy. Nick stated very
clearly that the new compiler (written (almost) from scratch) will
compile (almost) all the old code. (See his article in EDN). But because
VCL is just a thin layer around Win32 API, making VCL cross-platform
isn't practically possible. So, they spoke about a new cross-platform
library which will have a "limited compatibility" with VCL. Nowadays,
for them the compatibility/ease of transition and quality are top
priorities (thing which is very good) so they will try to do all the
best in order to mimic the VCL's behavior but anyone who knows at least
a little what's under the hood knows that this isn't always possible.
But continuing to support VCL on 32bit and expanding it to support the
Win64bit platform is a thing which is quite feasible (imho) so, that's
why (I think) they will provide a separate release for Win64.
In our case, since we know that by far the VCL's hardest part to make
cross-platform is the part which deals with GUI, it seems obvious that
the in the IBO package must exists two sub-packages the Comm Layer and
the UI Layer. Of course the UI Layer will have dependencies in the Comm
Layer, but the Comm Layer must *not* have dependencies in the UI layer
(I'm thinking now at Design-time Editors) in order to be ported easily
to the Project X.
HTH,
m. Th.
[Non-text portions of this message have been removed]