Message-ID: <20030420175150.25182.qmail@web41015.mail.yahoo.com> Date: Sun, 20 Apr 2003 10:51:50 -0700 (PDT) From: Daniel Borca Subject: Re: dxe review To: Andrew Cottrell , Charles Sandmann Cc: dborca AT yahoo DOT com, djgpp-workers AT delorie DOT com In-Reply-To: <002d01c306f6$484d41d0$0100a8c0@acp42g> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Hi guys! You are mixing two different things here! Or are there three? PRIMO: Yes, Andrew, you are right: "the DXE code must not call code in LIBC which is linked with the app". And here's why: let's take the simpler example. `statsimp.exe' is linked against LIBC and uses "strlen"; that means the `strlen' code is being injected into the DXE. By default, the generator will make the "strlen" symbol visible *FROM* DXE (unless you filter it with -E or -X). When you link your application, the "strlen" entry from LIBC is discarded and replaced with the one in the import library. The import library does not contain actual code (only DXE does!), but wrappers (initially pointing to `dlopen()'). Now, suppose your application fires and hits "strlen"; this will invoke `dlopen()' to load that DXE where "strlen" has moved. But `dlopen()' needs the *REAL* "strlen", so calling it will again get to `dlopen()'. It's a deadly embrace situation. Special note: "strlen" is just an example here. It might be "open" or "memset" as well! Bottom line, symbols required by the `dlopen()' code must be hidden inside DXE, so the linker won't get confused. So, your problem does not have anything to do with what Charles suggested. But yes, basically, you'll need to run dxe3res. Which moves us to the second point. SECUNDO: I doubt turning Allegro into a DXE will be of any usefulness. Because Allegro gives public variables, such as `mouse_x', `mouse_b' and so on. I mailed mr. Hargreaves about a month ago, regarding this issue. He never replied. Having that said, you need to manually write some little functions: `get_mouse_x()' etc. because the documentation clearly states: VARIABLES cannot be accessed directly when using IMPORT LIBRARIES. The only way to do this is via `dlsym()' -- which somehow contradicts the import library concept. The problem lies with the COFF. Ohwell, I'm tired of this COFF subject... nobody listens, yet everybody needs "super-cool" dynamic modules. For your information, I managed to turn Allegro into a DXE directly from the static lib. And was able to use it also :) And now the grand finale... TERTIO: the `dlopen()' strength resides in its tradition. OTOH, the import libraries are important where you want to use DXEs, YET YOU DON'T WANT TO CHANGE A LINE OF CODE. All you have to do is pay a little more attention to how the linking is done, and provide the symbol table. Unfortunately, the DXE needs to know where the symbols from the main image are located. Two or more DXEs can resolve each other (in a non-cyclical fashion). But when it comes to LIBC, things get complicated. Charles' plans to build LIBC.DXE would solve all the aforementioned problems. There is a workaround... very shallow, though. Make the import library "touch" the symbols it needs. This way, the linker will be forced to trigger them (symbols) from all static libs it requires. Determining the address will be very simple, then. The drawback? This method cannot be applied to `dlopen()' which knows nuts about import libraries. Again, LIBC.DXE could be the solution... Ciao Ciao! PS: Tim was right about the `const'. Excellent explanation! ===== Regards, Borca Daniel http://www.geocities.com/dborca/ __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com