[DUG] iOS 64bit - Delphi vs Java

[Jolyon Smith]

@David, I'm not sure how evolutionary change is relevant to concerns
relating to technology having been superceded and abandoned.

The BDE didn't evolve.  It was replaced and abandoned and applications
relying on it then experienced difficulties arising from changes in the
operating environment.

It may not be possible to avoid this entirely.  But you can hope to reduce
the risk by ensuring that your applications employ technology that is an
integral part of your operating environment, rather than relying on
proprietary components that may be abandoned.

Particularly if the developer of the proprietary tech has an established
record of adopting a "replacement" over "evolution" approach to change in
these areas.

On 30 January 2015 at 10:38, David Brennan <dugdavid at dbsolutions.co.nz>
wrote:

> I’m not sure the change in technologies over time is particularly relevant
> – if there is a language where technologies such as this haven’t evolved in
> the last 15 years then that language is probably dead or dying. As you
> mention .NET has plenty of such examples which have been hung out to die
> slow deaths.
>
>
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Friday, 30 January 2015 8:46 a.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java
>
>
>
>
> There is also the use of proprietary technologies that the tool vendor has
> a habit of changing from time to time.  Did you replace the BDE yet ?  Did
> you replace it with DBExpress ?  Using 3rd party drivers ?  Are they still
> supported ?  When might you be planning to replace DBExpress with FireDAC
> ?  What comes after FireDAC ?  Did you ever migrate to CLX ? (and then
> what?)  Have you migrated from VCL to FMX yet ?
>
> It is hard to avoid the fact that Borland/CodeGear/Embarcadero have "form"
> in this area.
>
> (Which isn't to say that .net is itself entirely immune from such issues)
>
>
>
>
>
> On 29 January 2015 at 18:32, John Bird <johnkbird at paradise.net.nz> wrote:
>
> Old yes, well C is older, C++ is about as old,  Java is about as old (1996
> for V1).  So there is a rational debate to be had about age.
>
> Security risk ?
>
> I would have thought off the top of my head that Delphi does not carry too
> many obvious security risks:
> - Relatively few DLL problems as it generally packages everything in the
> EXE
> - Relatively immune to buffer overflows if not allocating memory manually
> or
> using C-type strings (PChar).
> - Can one really make a case that Delphi is less secure than  Java?
>
> There are occasional bugs to watch out for eg
>
>
> http://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow
>
> Maybe the corporates mean security risk of an ageing programmer suddenly
> feeling the need to retire from whatever cause.
>
>
> -----Original Message-----
> From: Paul Hectors
> Sent: Thursday, January 29, 2015 4:38 PM
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] iOS 64bit
>
> +1
>
> My recent experience is that corporates do not like it when you inform them
> that your application is written in Delphi, it is perceived as old and a
> security risk. It would be nice if there was a white paper or some material
> to reassure them.
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150130/680d4846/attachment.html