Date: Sun, 31 Jul 94 12:19:30 -0400
From: dj AT ctron DOT com (DJ Delorie)
To: eliz AT is DOT elta DOT co DOT il
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: GO32 DPMI problem? 


> > (see the manual).  I recommend using memset(&regs, 0, sizeof(regs))

> Now, this seems to be unfair.  The docs (libcref.info) only says, that
> *if* SS and SP are zero, a small stack will be provided.  It doesn't

Yup, you're right.  I've been telling people this so long I forgot
that it's not documented.  I'll fix that right away.

> say what happens if they're non-zero; for all I knew this could be handled
> by the library routine.  It certainly does not say to zero-out the

If SS:SP is not NULL, they are used AS IS.  That's why the program crashes.

> On a related issue, I have problem with allocating DOS memory for INT 21h
> functions.  The docs says there is no automatic deallocation upon program
> termination for lower memory, so the only reliable technique seems to be

Since go32 is a dos program, any DOS memory it allocates (on your
behalf) is freed under the rules governing all dos programs.  If dos
automatically frees allocated memory on exit, that will cover your
program as well.

Note that normal dos programs do NOT normally get their interrupt
vectors restored for them, but go32 does this for you anyway.

> Also, I saw a ``transfer buffer'' being mentioned.  Does this mean there is
> a scratch space in the lower memory ready to be used for such cases?  If it
> does, will this be supported in v2.0?  And what are the ``proper'' ways to
> use this transfer buffer without risking an ``anti-social'' behavior as far
> as other ``clients'' of the buffer are concerned?

The transfer buffer is set up specifically for the application to
transfer data from virtual to real memory.  It's size and location are
defined in _go32_info_block in <go32.h>.  It is used by such calls as
write, printf, findfirst, open, etc.  It is not used by any of the
DPMI functions, nor is it affected by paging.