Date:	Fri, 1 Jan 93 14:19:16 EST
From:	peprbv AT cfa0 DOT harvard DOT edu (Bob Babcock)
To:	alane AT wozzle DOT linet DOT org
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Packing go32 into an .exe

>1. What DOS interrupts do you need?

According to my notes, the DOS interrupts which were not supported (at patch
level 3) were int 21, functions 0d, 10, 11, 16, 17, 19 and 36 (all hex).
Several of these are FCB functions, needed for dealing with volume labels.  It
turns out that there is no single way of creating or changing a volume label
which will work under the OS/2, Windows 3.1 and Ergo DPM-16 DPMI environments,
so I ended up writing a real mode DLL for these functions.  (Can I do the same
thing with djgpp?)  I also recall that the bdos() function didn't work (I
think it checked the carry flag even for functions which don't return status
in the carry flag), but that was easily fixable.  Looking at my gcc-specific
code module, I see that my critical error handler was dummied out.  I don't
remember whether that was laziness on my part, or whether I couldn't get a
handler to work.

>[crash when swap disk full]
>2. Yes that is still true, but frankly, all DOS extenders that I know
>of that support VM have that property -- what would you have it do?

Windows 3.1 and OS/2 give me virtual memory.  If I try to malloc too much,
malloc returns NULL.  I can then save work-in-progress, and maybe shell out
and free up some disk space.  It's also nice to be able to tell how much
(virtual) memory is left so that you can save your work before you hit a
crisis.  Otherwise, you may find that you can't do a save because opening a
file takes some memory for buffers.  I agree that you are in trouble if it
gets to the point of having no swap space when a page fault occurs, but I
would think that this need not happen if the memory allocation routines can
get information about the swap space.

- Raw text -