delorie.com/archives/browse.cgi | search |
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 |
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 |
> 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |