Xref: news2.mv.net comp.os.msdos.djgpp:3466
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: dxegen questions
Date: Sun, 05 May 1996 10:03:24 CDT
Organization: Rice University, Houston, Texas
Lines: 21
Message-ID: <318cc33c.sandmann@clio.rice.edu>
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>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

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