delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/09/27/21:39:39

From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: C Library: mmap() function
Date: Wed, 27 Sep 2000 17:06:01
Organization: Aspen Technology, Inc.
Lines: 25
Message-ID: <39d228f9.sandmann@clio.rice.edu>
References: <970034480 DOT 596718 AT shelley DOT paradise DOT net DOT nz>
NNTP-Posting-Host: dcloan.hou.aspentech.com
X-Trace: selma.aspentech.com 970092787 4044 10.32.115.107 (27 Sep 2000 22:13:07 GMT)
X-Complaints-To: postmaster AT aspentech DOT com
NNTP-Posting-Date: 27 Sep 2000 22:13:07 GMT
X-NewsEditor: ED-1.5.8
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> I understand that DPMI is not supposed to provide support for mmap().  Can
> we extend it? (or is that just _not_ done?)

DPMI 1.0 provides enough functionality to implement mmap().  You would need
to provide a user supplied page fault handler.

> Windows: does DJGPP under Windows rely on the OS for virtual memory
> management?  If so, then there's probably not much to be done about it,
> right?

You could write VXDs to extend Window's DPMI features.  Borland did this,
but they were a partial solution and buggy.

> CWSDPMI: can this server be extended to provide mmap() functionality?

If someone had the motivation, time and skills additional DPMI 1.0 features
could be added to CWSDPMI.  In particular, you would need to support the
alternate exception frames described in the DPMI 1.0 document.  Exceptions
handlers are hard to debug - since if you make a mistake the machine 
reboots leaving no trace of why it rebooted.

You would then need to modify the DJGPP exception handling code to use
DPMI 1.0 frames if they were available.  Again, very painful debugging.

So, it's feasible, but very unlikely anyone will do this.

- Raw text -


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