To:	dj AT ctron DOT com (DJ Delorie)
Cc:	eliz AT is DOT elta DOT co DOT il, djgpp AT sun DOT soe DOT clarkson DOT edu, eliz AT is DOT elta DOT co DOT il
Subject:	Re: GO32 DPMI problem?
Date:	Sun, 31 Jul 94 13:48:53 +0300
From:	eliz AT is DOT elta DOT co DOT il

> You MUST completely initialize the _go32_dpmi_registers structure

Thanks.  That's what I've missed.

> (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
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
structure completely (unless there's some other piece of docs that I've
overlooked--and I did also look in dpmi.doc, dpmi.h, and internal.doc).
The docs should really be more explicit on this.

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
to keep allocating on entry to a function and deallocating before exit.
This seems to be quite a waste, not to mention possible problems in DOS
memory management caused by repetitive allocations.  But I see no way to
allocate once, then reuse it, because I can't ensure I get to deallocate
it: atexit() can't help, because a program can avoid it by calling abort(),
or by Ctrl-C, or whatever.  Is there any reliable way to only allocate once?

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?

Thanks in advance,
		Eli Zaretskii

- Raw text -