64-bit on the horizon? (Was Re: Vista Requirement Already)

In article <45bfdf82$1@xxxxxxxxxxxxxxxxxxxxxx>, Nick Hodges (CodeGear)
says...

Objects in Mirror are closer than they appear.

Could we dare hope that that applies to D2008 - specifically 64-bit
support?

I am being asked to provide a way forward to transition an extensive and
complex code base to 64-bits - an exercise that will necessitate
significant re-architecting of the codebase itself (not just to address
32/64-bit issues, but generally to improve the codebase)

This work will likely be starting in earnest in the next 12-months.

At the moment I cannot recommend staying with Delphi as 64-bit Delph
doesn't (yet) exist, and the language used when discussing a timeframe
for it's expected (is that too strong a word?) arrival seems vague, to
say the least ("sometime in 2008" is the firmest I've heard iirc).

Currently I am in the position of having to recommend a move to .net
(2.0) as a way of getting to 64-bits - existing .net skills are C#
based, so a move to Delphi.net is unlikely to say the least. More
probable is that Chrome would be used to leverage source code re-use
where possible (limited) since this would be supportable within a common
IDE (i.e. Visual Studio) with which the existing .net teams are
familiar.

This is a significant factor - the existing teams with MS VS and .net
experience are obviously able to provide assistance with to the team(s)
coming to MS VS from Delphi.

Setting aside fundamental concerns with the .net credentials of Delphi
(e.g. but not predominantly - just by way of illustration - the
different component models for VCL.NET vs WinForms), BDS would be wholly
new to everyone. Therefore no in-house support and mentoring, and given
the dramatic differences between BDS and the D5 environment the majority
of the team is familiar with, there would probably be a significant
adverse impact on productivity, at least initially.

No doubt you will argue that BDS would ultimately prove more productive,
but early humps can be difficult to get over, and with an easier option
available, the path of least resistance is clearly also the most
attractive to the decision makers (who aren't necessarily practioners).

Bear in mind however that work may well start sooner rather than later.

D2007 and .net 2.0 support may well be due before D2008 and 64-bit
support, but at the moment, in terms of "reach out and touch them"ness,
they are both the same - i.e. neither are tangible products and waiting
for either/both represents a gamble, compared to embracing a known,
tangible quantity even if notionally inferior).


I would much rather be able to stick with Delphi, but cannot in good
faith say that it is the best option right now (and my job is to
identify the best option for the software, not for me personally).

Help!?



Aside (and a rant - sorry): In common I am sure with very many other who
have been waiting impatiently for 64-bit Delphi, 64-bit capability is
FAR more important than generics or partial classes, for example.

Why?

Easy.

If it don't do 64-bit, it don't it. Period. There are no ways around
the fact that 32-bit Delphi doesn't produce 64-bit native executables.

Generics, partial classes etc - these are all "nice to haves" (for some
- I personally have yet to be convinced that they are even "nice to
have". They absolutely aren't "necessary").

It is particularly frustrating to know (ok, "to have to suppose") that
these language "toys" ("not essential" = "toy" in my book) have received
higher priority than a fundamental and basic functional gap - i.e. 64-
bit support.

It's all the more annoying when, in looking around for alternatives, we
find that the space for 64-bit development tools is bereft of practical,
sensible options.

There is a HUGE gap in the market here, which Borland/CodeGear have
allowed to appear whilst seeming to me at least playing "me-too" catch
up with "competitors" that they cannot hope to actually "compete" with.

</rant>

--
Jolyon Smith
Say, do any of you guys know how to Madison?
.

Relevant Pages

  • My thoughts about Delphi and its future
    ... I only mention the Pascal part of Delphi because ... Cross-platform support. ... VCL framework is in my opinion the single most ... UI controls haven't changed since the beginning. ...
    (borland.public.delphi.non-technical)
  • Re: TChart questions
    ... For some Delphi versions there's an editor help available, ... Steema Support Central ... We wouldn't have even looked at TChart without it. ... If I'm doing a bar graph, side by side, two series, I get the chart ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: How would you steer Delphi if you were Nick?
    ... realistic - .NET applications are going to be developed using Visual Studio ... which is why I think Delphi will become ever more niche. ... and I'd push forward with Win64 support. ... If DevCo wants to support another platform, I would support the Mac. ...
    (borland.public.delphi.non-technical)
  • Re: Wild speculations about the "other" factors
    ... There was only ONE .NET "focused" release, Delphi 8. ... Delphi 9 had Win32 support. ... Do you think that providing as many new features of D9 ... to the Delphi/Win32 personality came without cost? ...
    (borland.public.delphi.non-technical)
  • Re: DONT USE PIXEL TRANSLATIONS IN DELPHI
    ... Bait-and-switch is when a company deliberately advertises one ... that they don't officially support ... If you honestly wanted an assurance that it would work under Delphi, ...
    (borland.public.delphi.thirdpartytools.general)