Mail Archives: djgpp/1996/07/25/18:01:28
> The code fails with: _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY;
> but works otherwise: I get a segmentation fault in morecore (of libc malloc.c)
> at the op->ov_next = 0; line of morecore, just before it exits.
> This happens under csdpmi (v0.90 r2 and later). Windows hapilly allocates more
> memory than I have, so I guess it does not know about CRT0_FLAG_LOCK at all!
What is happening:
1) crt0.s does not check the return status of the lock call. What this does
is return unlocked memory under most DPMI providers if you ask for more
locked memory than can be provided.
2) When you try to lock too much memory in CWSDPMI, it partially locks the
block, then returns with no room for paging in other memory. Any access
to memory on disk (or uncommitted) will puke with a page fault, since
there is no way to find a free 4K block to bring it in.
The lock memory flag was a quick hack for small programs where people didn't
want to worry about the locking calls. It's inappropriate for almost all
uses, so the best thing to do is not use it.
We could bloat the crt0.o linked into every image to handle checking of
the lock return, then free the block and back out changes to the other
structures, which would make it work under Win et al (returning NULL
instead of just using unlocked memory). Then I would have to fix
CWSDPMI to return an error flag ... ummm.
- Raw text -