From: idr AT cs DOT pdx DOT edu (Ian D Romanick)
Message-Id: <199603270923.BAA28612@sirius.cs.pdx.edu>
Subject: Re: Where functions belong...
To: orly AT psylocke DOT eee DOT upd DOT edu DOT ph (Orlando A. Andico)
Date: Wed, 27 Mar 1996 01:23:45 -0800 (PST)
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.LNX.3.91.960327142009.109A-100000@psylocke.eee.upd.edu.ph> from "Orlando A. Andico" at Mar 27, 96 02:22:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> > I have a suggestion for the next release of DJGPP.  I think there's
> > quite a few functions that should be moved out of libc.a.  These
> > functions include all of the DPMI stubs and the dosmemget() types.  The
> > reason for this is that many people will probably want to use these
> > functions in DXEs, but you can't link libc.a into a DXE.  Or am I just
> > missing something?
> 
> I think that's a good idea too. Because isn't libc.a only supposed to 
> contain the POSIX C stuff? Unix doesn't have DPMI stubs. Actually, I have 
> no problem with the existing setup, except aesthetics, except it seems 
> that Ian now has found a good reason for separating the nonportable stuff 
> from the C library.

This is acutally compounded by the fact that a number of the DPMI stub
functions rely on data setup in crt0 (i.e., ___djgpp_ds_alias).  To this
end, I have conceded to write my own DPMI stubs.

However, the problem that I now have is that my stub for functino 0x0300
(simulate real mode interrupt) crashes when called from the DXE, but not
when called from a normal executable.  To make matters worse, I see no
way to debug a DXE as GDB won't even give a disassembly of the DXE
because it's not on the load module's text segment!  Ugh...talk about an
up-hill battle.

-- 
"Democracy is a poor system; the only       Other methods can be seen at
thing that can be said for it is it's       http://www.cs.pdx.edu/~idr
eight times as good as any other method."
    -- Stranger In A Strange Land