previousupnext

8.1 Program Correctness

Implementation Dependencies

The most obvious threat to program correctness is that applications may rely on heap manager implementation details. For example they may try and read a block header, or assume that HeapCreate returns a valid address in memory. No such dependency has yet been encountered; even Microsoft applications are disciplined in this respect.

Native Heap Non-conformities

Occasionally the behaviour of the NT heap manager seems at odds with the API specification. A call to HeapAlloc for a size of zero might be expected to be classed as a parameter error, causing the call to fail. However the native heap returns an eight byte allocation in this circumstance. The LeapHeap implementation has been modified to bring it in line with the native heap for all non-conformities like this that have come to light.

LeapHeap Non-conformities

Section 4.7 API Conformance contains a description of the LeapHeap routines, including areas where they do not match the heap API specification. These generally relate to the debugging functions. For example if an application makes some allocations then verifies their existence by using HeapWalk, it will fail with LeapHeap. As a loosely-related point, third-party applications that monitor heap usage are obviously unlikely to work on systems where LeapHeap is in use.

Obsolescent Features

The operating system still supports a number of dated constructs, such as the moveable memory that 16-bit applications were fond of. LeapHeap avoids that particular complication by delegating to the relict heap; however there are others. One such is cross-process state, for example window handle identification, that exists outside the NT kernel. Because LeapHeap creates copies of system DLLs, an application that relies on inter-process communication may fail with LeapHeap. If an application involves more than one running executable it is prudent to ensure that all such executables run with LeapHeap.