delorie.com/archives/browse.cgi | search |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |