[DUG] iOS 64bit - Delphi vs Java

[Jolyon Smith]

@John,

I am surprised that you dismiss the ASLR problem so lightly.  You cannot
surely regard this as merely an installation "nuisance" ?


Every time you boot a Windows Vista (or later) system, the OS randomizes
the location of some DLL's in memory for each process.  There is a specific
address range reserved for this "shuffling" and DLL's that are not flagged
as compatible with the mechanism are excluded from the process.

The problem is that the BDE relies on a piece of shared memory, used by
every BDE application.  rather inconveniently, the default location for
this shared memory is in the address range reserved for this DLL
randomization !

Every time you boot the system, a DLL may be plonked at that address and
when you try to start your first BDE application it will fail to load since
it cannot reserve the required piece of shared memory at that location.

The BDE absolutely does not work under those conditions.


The problem is often dismissed as "a random issue" because it seems to be
fixed by a reboot (or two).  The ASLR shuffling caused by a new boot is
more likely than not to come out with a "BDE compatible" result, so if you
get unlucky once you are unlikely to be unlucky a second time (in
succession).

But if you do get unlucky.  Tough luck.  (until you reboot).


To resolve this properly you need to identify a "safe" area outside of the
ASLR address range using some form of VM address space inspector, such as
the SysInternals VM Map utility, and change your BDE configuration to use
this alternative location.


The problem is that there is no "guaranteed safe" location that you can use
for ALL systems.  The available safe addresses will vary from system to
system according to what device drivers, system components and applications
are installed and in use.

The only way to identify a safe area is to start every application on a
system that a user might use and identify an unused address common to ALL
those applications.

Then all you can do is hope that a subsequent device driver, system
component or application update/install will not render your chosen "safe"
address unsafe again.


This would be a trivial issue to resolve in the BDE itself by making the
shared memory allocation more resilient.  But of course, the BDE is no
longer supported and afaik hasn't had a fix in more than a decade and never
will again.





On 30 January 2015 at 12:26, John Bird <johnkbird at paradise.net.nz> wrote:

>   I have been involved in migrating a BDE application from Delphi 5 to
> XE5, and it still uses the BDE.  No problem.   Not abandoned – so what is
> your point?  The reasons they still use the BDE are
>
> 1 – No work to do other than figure out installing it on Windows 7 etc
> 2 – The BDE despite being a nuisance to install on workstations actually
> offers some real nice functionality – the update queries with GUI
> selectable fields that are candidates for being updated with ApplyUpdates
> is very nice to use.  Alternatives meant enough recoding that they decided
> not to bother.
> 3 – That it still works after 15 years where other technologies have come
> and gone is neat.
>
> I found an interesting user survey on Delphi vs C#.
>
> http://vschart.com/compare/delphi-programming-language/vs/c-sharp
>
>
> C# scored more real good things (eg free versions for commercial use,
> documentation, HTML, Community, Jobs)
>
> But the most interesting ones to me were:
> Preference – Delphi scored 59% to C# 41%,
> Delphi works out of the box 65% to  C# 35%
>
> Surprises or dubious areas are – C# rated well for iOS/Android
> development  (is this so??) and better for performance than Delphi (really?)
>
> C# rated poorly for JVM support.   Surprise surprise!
>
>  *From:* Jolyon Smith <jsmith at deltics.co.nz>
>   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
>
> _______________________________________________
> 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/6bb39039/attachment-0001.html