Mail Archives: djgpp/1996/03/27/04:38:36
> > 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
- Raw text -