Message-Id: <199708011309.JAA16070@delorie.com>
From: Oberhumer Markus <k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at>
Subject: DPMI page-locking counts
To: djgpp-workers AT delorie DOT com (djgpp-workers),
        sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Date: Fri, 1 Aug 1997 15:04:43 +0200 (METDST)
Return-Read-To: markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Subject: DPMI page-locking counts ?

I've recently ported Peter Gutmann's cryptlib to djgpp.
( http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html )

cryptlib is a very high quality crypto implementation.
For security reasons all sensitive information used by the
library will be page-locked to ensure it is never swapped
to disk.

I'm searching a reliable way to find out if the underlying DPMI host
maintains page locks in a binary form (like CWSDPMI) or a true lock
count - in the latter case I can safely unlock memory blocks.

My current (paranoid) implementation simply ignores unlocking requests,
but this may lead to a shortage of virtual memory in long-running
applications.

Other workarounds or tricks like rounding up the minimum allocation size
to the page size are not acceptable in this situation. As a very last
resort I could provide a special malloc which handles locking
internally, but I'd really prefer something less errorprone.

Markus