delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/08/17/05:45:06

Message-ID: <3B7BFD22.9020004@edu.stadia.fi>
From: Antti Koskipaa <antti DOT koskipaa AT edu DOT stadia DOT fi>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Compiling Quake
References: <3B7AC29A DOT 9080305 AT edu DOT stadia DOT fi> <3b7ae00b DOT sandmann AT clio DOT rice DOT edu>
Lines: 33
Date: Thu, 16 Aug 2001 20:04:34 +0300
NNTP-Posting-Host: 212.38.225.93
X-Trace: uutiset.nic.fi 997981427 212.38.225.93 (Thu, 16 Aug 2001 20:03:47 EET DST)
NNTP-Posting-Date: Thu, 16 Aug 2001 20:03:47 EET DST
Organization: NIC Tietoverkot Oy - NIC Data Networks Ltd.
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Charles Sandmann wrote:
> I haven't looked at the source but I helped them build it.  What do you
> want to know about the memory management?

Basically I'd like to know, when I compile it and run it, it works
fine but randomly crashes on exit, then I take the binary to another
machine and it throws a page fault right away, try it on a third
machine and it may run with "-mem 16" or something like that.
Why did they ever need this contraption? Wouldn't just a malloc()
be enough when they needed it?
I know it can be done, I've written my own Quake-like engine...

> The release was built with DJGPP V2.0 beta 3 pre-release, which only had
> unixy sbrk() at the time (which is now not the default).  To make the
> unixy sbrk() be non-moving extra memory was allocated (to DPMI commit it)
> and then a negative sbrk() sent to leave extra for various libc usages.

I ask again: why?? It's virtual memory, it's the DPMI provider's
task to take care of it. If the app mallocs it, it has it, period.
I personally wouldn't care less it it all didn't stay paged in all the 
time. If the user does not have enough memory, it's his/her fault.

> Then there was the locking stuff to get around W95 DPMI lies and 
> strangeness on DMA buffers.

I have seen that. When I tried to fix it, I played around with
this stuff. Removed locking, used one single malloc to allocate a huge 
pool of memory and so on. It didn't work. The question remains.

--
- Antti


- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019