Xref:	news2.mv.net comp.os.msdos.djgpp:3563
From:	fnunez AT cs DOT uct DOT ac DOT za (Fabian Nunez)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: dxegen questions
Date:	7 May 1996 06:52:22 GMT
Organization:	University of Cape Town
Lines:	53
Message-ID:	<4mmrv6$e8h@groa.uct.ac.za>
References:	<199605031526 DOT LAA01425 AT mv DOT mv DOT com> <4mdcjg$dv5 AT rs18 DOT hrz DOT th-darmstadt DOT de> <4mhk1g$8c3 AT groa DOT uct DOT ac DOT za> <318cc33c DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host:	unagi.cs.uct.ac.za
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

In <318cc33c DOT sandmann AT clio DOT rice DOT edu> Charles Sandmann <sandmann AT clio DOT rice DOT edu> writes:

>> I tried to write a loadable VESA 2 module using a DXE and all I got was
>> segmentation violations.  The code worked fine if statically linked, so
>> my guess is that DXE's have problems talking to the __dpmi and _go32_dpmi
>> functions, same as with printf, etc. Any ideas for a workaround, or have I
>> found a bug? 

>Anything which references a global data variable which is expected to be 
>initialized will have problems.  Many of the __dpmi functions will work, but
>__dpmi_int won't since it does some complications with ds_alias.  You can 
>either avoid these routines (better) or initialize the variables to the
>appropriate values in a firsttime section of code.

>> (BTW, I looked at the old '94 version of DLL's for DJGPP V1,
>> and it allowed for sharing variables and functions with the main executable -
>> why was this removed from DXE's? it seems like a good idea to me)

>Footprint.  The DXE load code is only a couple hundred bytes.  This is important
>since it's included in EVERY V2 image (to load the emu387 if needed).  It was
>also simple, easy to write/debug, and met all the needs at the time.  It 
>was never intended to be a full DLL sort of package (I anticipated one would
>be generally available by now).  

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. 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).

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?

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?

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.

Thanks
fabian
--
Fabian Nunez, Bachelor of Computer Science, University of Cape Town
email:fnunez AT cs DOT uct DOT ac DOT za   web:http//www.cs.uct.ac.za/~fnunez
----------------------------------------------------------------             
"k3wl aRe th3 lAmErz, 4 thEy sh4ll RulE!" - from the ElitE Bible 

- Raw text -