Re: 64-bit - the desaster continues ...

"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
> millions.

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,
HDTV-broadcasts etc.

> 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
> succeed.

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
2-3 years?

> 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
> bugs.

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
concern here)

> 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
> with.

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
> world.

Partially agreed.

Thanks for your opinion,

-Peter


.

Relevant Pages

  • Re: D8: first impression and uneasy feeling... (long)
    ... pack server apps and gui apps. ... I think people that defends .net here is people doing mostly server ... Borland has an incredible potential here, but it has to realize there ... with a .NET server and a win32 client. ...
    (borland.public.delphi.non-technical)
  • Re: Permissions Chart ?? or web site ??
    ... The environments I deal in tend to have tens of thousands of file shares and thousands of local site admins, 99% of whom don't really understand in the slightest bit how Windows works so the most secure way of doing things is the most simple to understand easily automated way. ... In fact, in most environments I have to work on file share stuff for, I redirect them from ad hoc shares to three types of shares per server and the local site admins don't even have to understand what a share is let alone properly configure it. ... One single share per server for apps run from the servers. ...
    (microsoft.public.windows.server.active_directory)
  • Re: adding a terminal server
    ... you will need the applications residing on the terminal server. ... I'm assuming the apps ... be a backstep to run apps and all local users and remote users. ...
    (microsoft.public.windows.terminal_services)
  • Re: How do I fix OMA on SBS2003?
    ... Some of the earlier WM5 devices through Verizon & Sprint required you to run a special utility on the phone to install your self-signed cert successfully ... As far as OMA is concerned - I would double check to make sure it is using the same ASP.NET version as the other apps in whatever IIS Application Pool it is using. ... "Activesync encountered a problem on the server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Advanced Forth app techniques
    ... competed with the other apps from their time. ... Have you made use of 2D arrays? ... different one somewhere the compiler will issue a warning. ... You're talking about data structures, here, aren't you? ...
    (comp.lang.forth)