Board index » delphi » Suicide is imminent!!!!

Suicide is imminent!!!!

In article <>,

>When I use the DLL in another app (be it a C++/Delphi app), and only
>call Init and CleanUp, everything is fine. That is, until I run the
>program a second time and BANG! GPFs in any number of different DLLS,
>including the Kernel, ILD01.DLL, COMMDLG.DLL etc.

>The WIERD thing is that I can run a Delphi app that uses the DLL from
>inside the Delphi IDE as many times as I like, it *never* crashes!?
>The same app runs once off the desktop and then explodes the
>second time.
>Does *anyone* have any idea what I could be doing wrong?

I had a similar problem.  It was caused by the fact that I renamed my DLL.
Windows then refused to unload it properly, and wierd behavior was abound.

This may not be related.  But it never hurts.

Kirk Out
Kirk Wolak                                   It's not whether you win or lose                          It's how you place the blame!
// Views expressed are my own and not those of the company I work for!


Re:Suicide is imminent!!!!

In article: <>  Chris Isbell <> writes:


> You could take a look at pages 466-471 of Steve T's book "Delphi
> Developer's Guide". To quote: "The VCL's session variable, which
> is based on the BDE, is not initialized per task, but rather per
> module.... This means that the BDE services cannot be provided
> through a DLL to multiple application tasks....Borland recommends
> preventing multiple attempts to use BDE by providing the user with
> initialization and verification routines."

Hmmm. I will get this book, but in the meantime I think I am doing that.
The above quote seems to imply that exposing the BDE interface is bad news,
although it may mean the DB components as well. My DLL only creates one
TDatabase and one TTable object no matter how many apps are using it (hence
the Init and Cleanup procedures).

This problem occurs when only one app is using the DLL.

I have had a reply from someone that has run the example code without any
problems on a Win3.1 machine.

  "Walk in shadow, walk in dread. Loosefish walk as like one dead."
  ** The CARDIACS ** Buy one of their CDs NOW and join the family.
Marc Palmer is NOT a bona-fide representative of The Alphabet Business
Concern or The Cardiacs, and his opinions, while of value to some,
are not indicative of those held by the aforementioned parties.

Re:Suicide is imminent!!!!

Jump, jump, jump, jump...

Err, sorry 'bout that. What I meant to say was this...

You can't write reentrant DLLs that use the BDE. Even the Borland
documentation states this fact. Sorry.

Luke Webber

* Note: The opinions expressed by Luke Webber are in no way supported *
*       by his employers, Luke Webber Consulting Services             *

Re:Suicide is imminent!!!!

In article: <41o8d0$> (Luke Webber)


> Jump, jump, jump, jump...

> Err, sorry 'bout that. What I meant to say was this...

> You can't write reentrant DLLs that use the BDE. Even the Borland
> documentation states this fact. Sorry.

Hey - maybe I'm being dumb but where's mu re-entrancy? I only acquire one
TDatabase, one TTable, one set of fields etc. Besides, my test program
is only one app....there shoul dbe no reentrancy.

I am confused! I have a very straightforward DLL with a simple interface.
No matter how many apps use the DLL, it will ALWAYS only have ONE TDatabase
object and one TTable. The DLL simply provides an interface to a single

Maybe they're trying to stop me writing SuperParadox? Actually I'd be quite
happy to be able to read my *own* database file from my *own* applications!!!

I'm not convince it's a re-entrancy issue. I've spoken to Borland/Digital
Support in Holland and faxed them a report. I'm yet to hear from them.

It seems pretty stupid to duplicate hundreds of KBytes in various Delphi EXEs
when the database access code is identical. That old static/dynamic link argument

Other Threads