Re: 64-bit - the desaster continues ...
- From: "Peter Sleuth" <psleuth@xxxxxxxxxxxxxxxx>
- Date: Mon, 18 Jul 2005 05:37:01 +0200
"a" <blwatters@xxxxxxx> wrote
> First, depite that fact we are half-way through 2005, even in North
> America, most corporations have not standardized on pure XP and 2003
> Server operating systems. Win98 and NT 4 still exist on some places.
new server deployments at our clients sites are almost exclusively Windows
Server 2003 nowadays. New client deployments in trading rooms will see a
good part of win64 over the next two years.
> Corporations have long since gotten off the latest and greatest treadmill.
> Even if they wish to upgrade their high-end servers to Longhorn, they
> won't be in any hurry until 2006 and I don't see any company moving
> 10,000 workstations to 64-bit anytime this decade.
Upgrade on workstations will be slow, but new server deployment is where the
action will take place.
And don´t forget that we are talking about Borland bringing us DCC64 in the
end of 2007 at earliest, if ever.
> Second, unlike 16-to-32-bit, I don't see anyone rushing to replace
> desktop applications with 64-bit. 16-bit apps were unstable, slower,
> and had lots of limitations. 32-bit fixed most of this. Going 64-bit
> won't have dramatic effects to cost justify the tens or hundreds of
Agreed. But there are certain areas, where 64-bit makes a big difference.
Every application that requires as much memory as it can get, e.g. windows
server 2003 serving hundreds of terminal services clients, exchange server
that hosts ten thousands of mailboxes, server apps using large
in-memory-databases, every desktop app that prints documents in very high
professional resolutions, every media app that tries to handle DVD-movies,
> Third, most folks will be running 32-bit apps under Win64 for a long,
> long, time. Most corporations will have a lot of in-house 32-bit
> applications which they can't live without for a long time. Reporting
> tools, desktop database, small applications, scheduling software,
> accounting programs, PDF software, etc. They will be accepting
> 32-bit apps for some time.
Yep, but we are not talking about the 32-bit apps they will continue to
accep, but the 64-bit apps they will soon use. Just try to write some
inprocess addins for those 64-bit apps, oops.
> Forth, I don't see any competitors rushing out to implement 64-bit
> anything, nor do I see a massive desktop advantage even if they
Do you really think that over the timeperiod until Borland might release a
DCC64 (end of 2007 at earliest), none of your competitors will release a
64-bit edition of his product? Do you think they all are asleep for the next
> a) They'd have to be using C++. If they are using VB, C#, or any
> other system, they'd have to rewrite their entire product anyway.
> That puts them in the same boat also.
All of our main competitors already use C++.
> b) They get to write the application with few 64-bit libraries and
> tools. i.e. no Active-Xs. They also get all the head-aches of
> native MS C++ coding -- library incompatibilities, unsafe code,
> for example.
Thats true, but they seem to be used to the pain.
> c) They get to discover all the bugs of a new compiler, OS, and
> development environment/compiler. Longhorn will have native
Yep. But most of the compiler bugs in VC++/64-bit might already have been
discovered and fixed by Microsoft. Don´t forget that Microsoft already
shipped two 64-bit operating systems compiled with this compiler, and is
about to launch 64-bit editions of SQL-Server 2005 in a few months, also
done with this compiler.
> d) They need to work around all the problems with having a
> 64-bit app and not having access to 32-bit apps. It will be a long
> time before folks have 64-bit apps and libraries, so they'll need
> to find ways to connect to 32-bit libraries and apps.
Yep. Similar to us.
> e) They now have to maintain two copies of their code. It is highly
> unlikely that they'll be able to convince folks to upgrade thousands
> of machines to Longhorn just to run an app. They'll need two
> applications for years. And they'll have a lot of work keeping
> both versions dumbed down to the lowest-common-denominator.
Having a single-source codebase in C++ works fine (well, let´s say for 98%
of the codebase). No reason for having two different copies of the code. Of
course they have to follow to the lowest-common-denominator, that is true.
> f) Any such native application isn't .NET. It won't be able to
> utilize all the .NET advantages -- from marketting, safe code,
> single-exe compile, use of 3rd-party components, etc.
> g) It doesn't help with web applications. ASP.NET apps
> should run fine in 64-bit windows, so there are much cheaper
> ways to get to a 64-bit application.
Not relevant for us. We don´t do web apps (well, at least they are not our
> There are certainly advantages to writing drivers, utilties, and
> other tools in native 64-bit. However, that isn't what Delphi
> is optimized for. Folk doing such things are likely C++ to start
We don´t write drivers etc.
> I would personally hope that a competitor would go 64-bit
> today. The drain on resources, managing code-bases, and trying
> to sell such a beast would be fun to watch.
Wait until a customer tells you he has heard that your product is not
state-of-the-art because you don´t support 64-bit, but your competitor does.
Wait til your competition crushes on you.
> If Delphi 2008 includes a 64-bit .NET path, great. By this time
> the 32-bit .NET world should be stable, 64-bit .NET should be
> out and working, and one would have the advantage of all the
> .NET features and only need to maintain one code base.
> BTW. ISAPI is old technology. Folks don't consider it safe in
> the 32-bit and they certainly aren't likely to buy it in the 64-bit
Thanks for your opinion,
- Prev by Date: Re: Going back to Delphi 7 -> Borland, what went wrong in 2001 ?
- Next by Date: Re: 64-bit - the desaster continues ...
- Previous by thread: Re: 64-bit - the desaster continues ...
- Next by thread: Re: 64-bit - the desaster continues ...