<div dir="ltr">@John,<br><br>I am surprised that you dismiss the ASLR problem so lightly. You cannot surely regard this as merely an installation "nuisance" ?<br><br><div><br></div><div>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.<br><br>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 !<br><br>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.<br><br>The BDE absolutely does not work under those conditions.</div><div><br><br><div>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).<br><br>But if you do get unlucky. Tough luck. (until you reboot).</div><div><br></div><div><br>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.<br><br><br>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.<br><br>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.<br><br><div>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.<br><br><br>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.<br><br><br></div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 January 2015 at 12:26, John Bird <span dir="ltr"><<a href="mailto:johnkbird@paradise.net.nz" target="_blank">johnkbird@paradise.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div style="FONT-SIZE:12pt;FONT-FAMILY:'Calibri';COLOR:#000000">
<div>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</div>
<div> </div>
<div>1 – No work to do other than figure out installing it on Windows 7
etc</div>
<div>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.</div>
<div>3 – That it still works after 15 years where other technologies have come
and gone is neat.</div>
<div style="FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibri";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline">
<div style="FONT:10pt tahoma">
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">I found an interesting user survey on Delphi vs
C#.</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><a title="http://vschart.com/compare/delphi-programming-language/vs/c-sharp" href="http://vschart.com/compare/delphi-programming-language/vs/c-sharp" target="_blank">http://vschart.com/compare/delphi-programming-language/vs/c-sharp</a></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">C# scored more real good things (eg free versions
for commercial use, documentation, HTML, Community, Jobs)</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">But the most interesting ones to me
were:</font></div>
<div><font size="3" face="Calibri">Preference – Delphi scored 59% to C#
41%,</font></div>
<div><font size="3" face="Calibri">Delphi works out of the box 65% to C#
35%</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">Surprises or dubious areas are – C# rated well
for iOS/Android development (is this so??) and better for performance than
Delphi (really?)</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">C# rated poorly for JVM support.
Surprise surprise!</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div style="BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title="jsmith@deltics.co.nz" href="mailto:jsmith@deltics.co.nz" target="_blank">Jolyon Smith</a> </div>
<div></div>
<div style="FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibri";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline"></div></div><span class="">
<div>
<div style="FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibri";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline">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.<br><br>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
</div></div></span></div></div></div></div></div>
<br>_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br></blockquote></div><br></div>