delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/02/01/13:20:12

Date: Sun, 1 Feb 1998 20:19:25 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: Physical memory, virtual memory. DJGPP+CWSDPMI, how they work?
In-Reply-To: <TymnIGA6CH10EwwX@talula.demon.co.uk>
Message-ID: <Pine.SUN.3.91.980201201318.16390T-100000@is>
MIME-Version: 1.0

On Sun, 1 Feb 1998, Shawn Hargreaves wrote:

> CWSDPMI doesn't have nearly enough information to do something like
> that. The program code is loaded by the startup stub, and the DPMI
> server has no idea where the data came from, what the executable format
> is, or even which bytes are code at all!

This is not entirely accurate.  There *is* a bit in the selector 
descriptor which says whether the segment is code or data.

> Demand-loading code directly from the executable is widely used by other
> systems, and can significantly improve the swapping performance because
> code can just be discarded from physical memory and then reloaded from
> the original location, rather than needing to be written out into a
> swapfile.

However, note that this method has its drawbacks.  For example, you 
cannot write into a running executable's .exe file on such systems.  This 
would mean that e.g. you cannot build a new version of a program as long 
as the old version is running (this is especially painful when you debug 
or develop an editor which you also need to edit the sources).

> But I think you need to be a proper operating
> system in order to have enough control over exactly how programs are
> run: it isn't something that can be tacked onto a DPMI system.

I think with DPMI 1.0, you can.  Too bad it is only supported by a single 
DPMI server.

- Raw text -


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