Re: D64, or Why Borland Ought to NOT Work on a 64-bit Version of DelphiRight Now

From: Thomas Miller (tmiller_at_bss-software.com)
Date: 02/01/05


Date: Tue, 01 Feb 2005 15:14:25 -0500

Bob Dawson wrote:

> "Dennis Landi" wrote
>
>>If your are using this as a reason not to build a 64-bit compiler
>>then its a red-herring.
>
>
> Actually I've explained before that software sales do not necessarily track
> hardware sales in a linear relationship. 64bit PC sales constitute a cap on
> the 64bit software market, nothing more. The market cap may be considerably
> higher than the actual market.

Agreed.

>
>
>>Borland just needs enough sales to justify
>>the cost of the compiler.
>
>
> Borland needs expectation of enough sales that would not otherwise occur to
> more than (profit) justify the cost of the compiler. That means the actual
> market demand for 64bit software that is not already satisfied by .NET's
> ability to jit as 64bit on demand. Simply talking machine numbers misses
> both of these issues.

Let's assume that there will be 1 billion x64 pc in the
world by 2010. This is pretty close to what the number bear
out in both of the reports.

Let's say that 2/3 actually want 64 bit software to run on
their 64 bit chip/OS. That leaves us with 667 million PC.
Let's say that the split between .Net and Native is split
50/50. The last market research I saw said that only about
15% of the business market place had bought into .Net. I am
conceding that over the next 5 years and before Longhorn is
really even being adopted, that is has risen from 15% to
50%. Gartner doesn't think it is going to raise that much.

That leaves ~334 million PC for .Net and ~334 million PC for
native. I don't think Borland would be wise to leave out
either.

>
>
>>We need to show that a the transition from 32-bit to 64-machines
>>is happening at a certain rate to prove that there will be a market
>>for a 64-bit compiler.
>
>
> Again, no one really doubts that this is going to happen.
>
>
>>We don't have to show that the "installed base" is
>>replaced, entirely; but that enough of the transition has occurred;
>
>
> What, in your view, constitutes 'enough'? In what approximate time frame
> will this critical mass occur, for which market segments, and how do those
> segments aligh with current or expected Delphi market penetration?

That is why I asked John Kaster to clue us in on the basic
reasons Borland has decided "no". Just the top three would
be sufficient for us to have a "real" discussion.

>
>
>>that's not all. It is also true that a significant portion, certainly
>>the overwhelming majority, *will* upgrade their Win32 compiler
>>to a Win64 compilation, given the opportunity to do so.
>
>
> That's possible, but nowhere near as certain as you seem to think. For
> example, would I as an individual developer and hobbyist like to upgrade to
> D64? Sure--new toy; why not? Do I think I have a business case for it that I
> can take to the CIO? No. Not even close to it.

That is your CIO. I am the CIO here and we would definitely
pay for the compiler. I also think if they add this, it
should be an Enterprise / Arch. SKU to help pay for the
initial cost. In a version or 2 they could bring it down to
the Pro SKU.

And again, I am not saying your CIO is wrong and I am right.
  I am trying to say we are both right. The question is
Borland going to abandon us native EXE folks just because MS
says to? That is the way most of us "native" programmers
view things.

I still think the right thing for Borland to do is release a
D2005a with .Net 2 support and then work on a 64bit open
beta 64 bit compiler, starting with non visual objects only.
The last thing we need is the visual stuff. Servers first,
client stuff second. If they do it, let's not make the same
mistakes they did with Kylix.

>
> bobD
>
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus


Relevant Pages

  • Delphi - does catastrophe loom ? (long)
    ... I've been buying and using Delphi since Turbo Pascal 5, and think that it is the ... However, I am beginning to think that Borland has made a major mistake going down the .NET path, and that Microsoft will be the beneficiary. ... however, when a 64-bit compiler was first mentioned at Borcon 2002 in Australia, it was targetted solely at Itanium. ... What Borland Marketing does not seem to comprehend is that while the market for an IA-64 compiler was probably several tens or even hundred of units, the market for an AMD64 compiler is in the range 10^4-10^5 units. ...
    (borland.public.delphi.non-technical)
  • Re: D64, or Why Borland Ought to NOT Work on a 64-bit Version of DelphiRight Now
    ... Actually I've explained before that software sales do not necessarily track ... the 64bit software market, nothing more. ... > the cost of the compiler. ... will this critical mass occur, for which market segments, and how do those ...
    (borland.public.delphi.non-technical)
  • Re: 64-Bit Compiler Would Help Sell More 32-Bit Compilers
    ... After we have the dominant market handled, ... > Borland to get started on a native 64-bit Delphi. ... > Borland is in danger of going out of business or even losing market ... compiler to handle kernel driver development-- but this /has/ existed ...
    (borland.public.delphi.non-technical)
  • Re: Borland Layoffs?
    ... > That's assuming that they could match the Intel compiler. ... So now Borland should not try simply because someone else has already ... Delphi 8 or any other .NET version of Delphi. ... that has yet to prove itself in the wider market. ...
    (borland.public.delphi.non-technical)
  • Re: Borland: Third party tools for Microsoft
    ... > MS has many partners including Borland, ... in to a library and IDE company. ... have is "we put any compiler developemnt in backburn and we do actively ... to the biggest market share and probably will be easier for them to ...
    (borland.public.delphi.non-technical)