To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: Packing go32 into an .exe
From:	alane AT wozzle DOT linet DOT org (J. Alan Eldridge)
Date:	Sat, 02 Jan 93 08:54:35 EST
Organization:	Disorganization

src4src!mcdhup!rutgers!wimsey.com!gerryt (Gerry Toon) writes:

> > 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? We're
> > in the middle of a faulting instruction, we have to page something in,
> > there are no code pages we can give up and re-read from the a.out, and
> > then we find out there's no room. Sounds pretty helpless to me. Best
> > we can do is terminate back to DOS. 
> 
> 	Other Operating System paging mechanisms seem to have gotten
> around this problem. You may be correct, but the situation you describe
> above sounds like a good candidate for disk thrashing at worst -not a
> terminate to DOS. There MUST be a code page around you can give up -
> even a random one. Anyway, I have been using a ram disk for swap space
> lately instead of the physical disk. That way I can 'tune' my swap space
> size somewhat like Unix. I'd like to test this with some kind of
> benchmark though to see if this scheme actually works.... -gerryt
> 

Yes, other OS kernels have gotten around it, but remember, the extender
is not an OS kernel. And (say this all together, folks) DOS is not
re-entrant.

And you can get yourself into a situation where there is not a code page
to give up... if you malloc() enough, there could only be one code page
resident - the one that's executing. Now, if the extender takes over,
say, sbrk(), it could fail mallocs and keep going. Otherwise you are most
certainly dead.

I'm playing the DJ's extender now, so if people have workable ideas, I'm
open to hearing them.


alane AT wozzle DOT linet DOT org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473

- Raw text -