X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: RFC - Dynamic loading
Date: Thu, 20 Dec 2001 18:56:41 +0100
Message-ID: <000001c1897f$b30362c0$c27d76d5@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <10112200510.AA19496@clio.rice.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> As promised some time back, I've started to look at dynamic linking.
> I first looked at the two DLL type packages on Simtel.  Both of them
> have nice features, but are a little heavy for what I am looking for.
> I also looked at what DXE does and my 1995 notes, and see the plans
> for expansion still look feasible and backward compatible.
> 
> The first thing I'm looking at is making DXEGEN be able to support
> exports and imports.  I can even have it automatically create an
> export template for all symbols if one doesn't exist.  If you want
> to export variable/memory locations you would need to edit the
> template (default would be assuming all exports are routines).
> Imports would automatically be handled at load time.

You'd also need to provide for C++ support; a standard DXE cannot
survive an exception being thrown in it (because the stack unwinding
info doesn't get registered at load time).
My local version of the now defunct DLX package added support for this,
which worked fine for gcc 2.95.x, but needs reworking for gcc3.  I've
just started looking into it again, and have gotten tentative approval
from NanoSoft, Inc. (who wrote DLX) to fork off my own version of the
library for further development.
I'll certainly agree that as it stands, it's a bit heavy for libc use
though.