Mail Archives: djgpp/1996/05/10/14:21:10
> I think most people think (as I did) that DXE's are the "official" DLL's for
> djgpp, that's why no DLL loader writers have come forward yet.
No such endorsement - DXEs were written with the 80/20 rule - 80% of the need
with 20% of the work. They work for what was needed to get V2 released
(EMU387 and potentially graphics drivers). My interest in DOS is essentially
gone, so I have stopped doing DOS type development, or I would have written
something just to prevent from answering questions about DXEs :-)
> You mention in the DXE source that you fixed a few bugs in DJ's DLL code, so
> I'm assuming you mean the '94 code. Were the bugs the subtle kind that takes
> days to find, or would it be worthwhile for me to spend a couple of hours
> debugging that code, so we can have (sortof) full DLL capability in DJGPP 2?
> (BTW, I have a copy of the o'Reilly COFF book, so you can be as technical as
> you like if you want to explain some aspect of the code in detail).
DXEs were based 50% on a graphics device driver prototype which DJ distributed
to a very limited group back in the V2 alpha days, and 50% on the '94 DLL
code. I could never get EMU387 to work with the '94 DLL code, but when I
sat down and put new code together from the new projects, and tried to
fix it, it didn't take much more than a couple of hours.
I have an unreleased DLL code sent to me for review last summer (right in
the middle of fixing my flood destroyed house) and if the author says it's
OK, that would be the basis to start on DLLs (it's 90% done).
My vision was to write the code, define the entry points into the library,
run a processor which created a ?.DLL and a ?.A - and then you would just
link to the ?.A which transparently did this all for you.
> About the global variable problem, is it enough to pass the DXE init routine
> (the one whose address is returned by _dxe_load()) go32_info_block (and then
> set it up as a global inside the DXE), or must I look at the source code for
> each function I may want to call inside the DXE for info on the globals I
> need to pass?
You need to look at the source. Then you would need to set up a return
structure of routines (not just a single routine) so you could call multiple
entries for init, etc.
> Also, why does printf() crash when used in DXE's? it is because of the global
> var problem, or is it yet another subtlety of MS-DOS?
Well, printf does I/O (problem #1) and does a malloc (problem #2).
> Sorry for the barrage, but I think DLL's are a rather good idea (having come
> from an Amiga background :) and I think that they'd be a great addition to
> DJGPP.
They have a place, yes. But putting the entire libc in one and "sharing"
it does have some minor problems...
Our current libc is around 0.5Mb in size. With shared libraries, that
means "hello world" would need an extra 0.5Mb at run time (and yet another
file) to execute over the current setup. Even if we made the shared
library work across nested processes (make/gcc/cc1) you still would not
usually break even on memory.
So, disk space usage would be less, it would be easier to apply libc bug
fixes, but memory usage would go up. The complications have made this
a low priority for me to look at, and nothing gets written in DJGPP
without a champion for the idea with the time, skills and resources to
make it happen.
There is nothing technically difficult about supporting shared libraries
and/or ELF (or any reason not to do so) - it's just someone needs to
volunteer a few weeks of time to make either happen.
- Raw text -