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

From: Eric Grange (egrangeNO_at_SPAMglscene.org)
Date: 02/01/05 

Date: Tue, 01 Feb 2005 17:06:49 +0100

> I'm quite aware of market segmentation. What percent of Delphi applications,
> do you suppose, are designed to run exclusively via Terminal Services?

What percentage of Delphi applications can *not*?

Maybe you misunderstood, Terminal Services is MS's desktop remoting
layer, introduced with NT4 TSE, available out of the box on Win2k+.
You don't "design to run exclusively via Terminal Services", that would
be nonsense, it's not ASP, a program designed to work on a normal PC,
if it doesn't do weird things, will run on Terminal Services.

It's a way of efficiently replicating screen, display and other I/O
to a distant terminal, and a cheap way of upgrading hardware,
upgrading desktop PCs networks without upgrading client hardware,
it also makes administration, backup and setup a snap.
With a decent LAN and not graphically-intensive apps, they'll run
at good speed, often faster than they would on a standard client PC.

> Should Borland derail all other efforts to provide a solution to this
> segment of their market?

I can't think of *any* corporation of size that doesn't use TS those days,
if only for administration, sometimes for a few desktops, sometimes
for most of them.
For these corporations, switching to a 64 bit environment can basicly
happen overnight by upgrading about 1 server for a score of end users.
What it means is that by owning a single 64 bit server, *all* their
desktops become automagically 64 bit based (and there isn't even
a driver hell, you only have to setup 64 bit drivers on the server,
the clients can keep their old drivers, be cheapo linux boxes, etc.).

> But Borland has to decide how widespread that need really is,
> how common it might become, and if or when they should address
> it rather than other needs.

I've heard it often, but I've personnally come to the conclusion
that this explication is just an excuse to justify:
a) their unability to deliver any serious native compilation
    alternative anymore (doesn't seem to be much expertise on
    that front at Borland anymore, cf. the very low rate of
    native compilation enhancements, and all of these syntaxic
    sugar rather than support for modern CPUs)
b) not having anticipated it, or rather wasted millions
    on the architecture everyone (including Intel) was sure
    wouldn't win the desktop market, aka Itanium

Eric

Relevant Pages

  • Re: Stop TermService
    ... This is by design. ... 278657 - Terminal Services Cannot Be Manipulated ... MCSE, CCEA, Microsoft MVP - Terminal Server ...
    (microsoft.public.windows.terminal_services)
  • Re: Trying to stop the "Terminal Services" service
    ... MCSE, CCEA, Microsoft MVP - Terminal Server ... Is this by design of Microsoft? ... D:\home>sc query termservice ... I want to stop the "Terminal Services" service in the MMC, ...
    (microsoft.public.windows.terminal_services)
  • Re: Starting Terminal Services
    ... this service by hand, that's by design. ... 278657 - Terminal Services Cannot Be Manipulated ... If in Remote Admin mode, ... and see if that fixes the problem. ...
    (microsoft.public.win2000.termserv.apps)
  • Win2K Server in SBS2K3 Environment
    ... has a Win2000 Server for Terminal Services that WAS a DC.....I dcpromo'ed ... the 2K box out of the role prior to upgrading the SBS box.......problem ... The TS Licensing Service is now installed on the SBS2K3 box, ... that will allow a Win2K Server the ability to replicate and manage ALL the ...
    (microsoft.public.windows.server.sbs)
  • Re: ODBC Application
    ... Access is typically changed so much that upgrading it ... You are artificially limiting yourself and hurting yourself and customers by ... Microsoft MVP - Terminal Services ... Jeff Pitsch wrote: ...
    (microsoft.public.windows.terminal_services)