From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304200456.AA22077@clio.rice.edu>
Subject: Re: dxe review
To: acottrel AT ihug DOT com DOT au (Andrew Cottrell)
Date: Sat, 19 Apr 2003 23:56:49 -0500 (CDT)
Cc: dborca AT yahoo DOT com, djgpp-workers AT delorie DOT com
In-Reply-To: <002d01c306f6$484d41d0$0100a8c0@acp42g> from "Andrew Cottrell" at Apr 20, 2003 02:35:32 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> Finally had a play with the DXE test programs and they worked fine.
> 
> I tried two real world test with Allgro and Grep and unfortunatly both
> failed as indicated below. Am I correct in my interpretation of the docs in
> that the DXE code must not call code in LIBC which is linked with the app?
> If I am wrong then any ideas on the problems below?

For any module which uses symbols in the main image, you must tell it where
to find them.  This is ugly.  Use dxe3res to create a wrapper which does
it automatically.  After reading the documentation, I am convinced that
this advice should be moved to the top as it's the "most powerful" and
"requires minimal interaction from the user".  The other methods require
writing non-standard code which no one will want to maintain.

The where to find "printf" type problem really hinders the dlopen() 
usefulness for compatibility purposes - and will continue to do so 
unless the location of all routines is stored in the image always.
(I have a plan to make libc dynamic which automatically would provide
all this info - but time is too short to finish it in the next few
weeks).

Thanks for the tests - I'll do a new pass at the documentation...
Try dxe3res and let us know if that works.