Mail Archives: djgpp/2001/08/17/05:45:06
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 -