Xref: news2.mv.net comp.os.msdos.djgpp:5929
From: malcolm AT manawatu DOT gen DOT nz (Malcolm Taylor)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking RAM for hardware interrupts
Date: Fri, 12 Jul 1996 09:11:50 GMT
Organization: Grafik Software
Lines: 18
Message-ID: <4s58rb$t9j@news.manawatu.gen.nz>
References: <836858848 DOT 164 DOT 0 AT abwillms DOT demon DOT co DOT uk> <31e1d37f DOT sandmann AT clio DOT rice DOT edu> <836949496 DOT 23711 DOT 0 AT abwillms DOT demon DOT co DOT uk>
Reply-To: malcolm AT manawatu DOT gen DOT nz
NNTP-Posting-Host: malcolm.manawatu.gen.nz
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams) wrote:

>> The
>>routine at a time method is better, but here's a simple example...

>Why? Which is 'best'? 
>Surely locking the image is 'blanket security', without effectively
>disabling virtual memory?

AFAIK many dpmi providers tell you that your lock memory call worked
even if it didn't (I'm pretty sure that CWSDPMI does this, CS correct
me if I'm wrong). If you lock your code, etc. routine by routine then
you'll be much less likely run into this problem as it's more likely
that your calls will succeed. Also it leaves more memory for virtual
memory paging (ie less HD thrashing). 

Malcolm