DosSetMem can be used to commit or decommit a range of previously allocated pages in either a private or shared memory object. It also can be used to create a sparse population of committed private or shared pages within a memory object. DosSetMem can also change the access protection applied to already-committed pages within a memory object.

Each page in the virtual-address space of the process is either free, private, or shared.

The virtual address for free pages is not reserved, not committed, and not accessible. An attempt to commit or decommit a free page results in the return of an error.

The virtual address for pages in a private or shared memory object is reserved during the allocation of the memory object. Each page within a memory object can be in one of two states:

Committed

These pages have allocated backing storage, with access controlled by a protection code. A committed page in a private memory object may be decommitted; a committed page in a shared memory object may not be decommitted. An attempt to commit a previously committed page results in the return of an error.
Decommitted
These pages are not committed and are not accessible. A decommitted page may be committed if the backing storage is available. An attempt to decommit a previously decommitted page results in the return of an error.

The commitment of a reserved page in a shared object causes the page to be committed in the context of each process sharing the shared memory object.

Any access protection can be applied to committed private pages. Decommitted pages are given an access protection of "no access".

When pages are committed, they are backed by demand pages. The first attempt to read or write the page causes a page of zeros to be created.

Decommitting a private page causes the backing storage for the page to be released.

Setting the protection on a range of previously committed pages causes the old access protection to be replaced by the desired access protection. The access protection can be set only on committed pages.

Setting the access protection to PAG_GUARD causes a range of guard pages to be established. If access to this range of pages is attempted, an access violation (page fault) is generated. This fault sets the protection of the accessed page to the desired access protection, and generates a condition that signifies that a guard page has been entered. This capability is intended to provide automatic stack checking. It can also be used to separate other data structures when appropriate.

If a failure occurs, the attributes are not changed on any pages, and an appropriate error code is returned.

As each page is considered for protection, its state is determined. If the state of the page is not committed, or is not being committed, an appropriate error code is returned. Otherwise, the new protection of the page is set.

With the Intel 80386 processor, execute and read access are equivalent. Also, write access implies both read and execute access.

Note: DosAllocMem and DosAllocSharedMem both allocate a block of memory of the size requested rounded to the nearest page. On OS/2 Warp, the system allocates a 64K object without attributes on every allocation.

For example, for a DosAllocMem call with a size of 1, the following occurs:

• On OS/2 Warp Connect, the system allocates a 4096-byte block of committed memory. 
  On OS/2 Warp, the system allocates a 4096-byte block of committed memory plus 61440 bytes without attributes.

  Note:

  When you allocate a memory object with the PAG_EXECUTE attribute, it is implied that this memory object also has the PAG_READ attribute. However, when querying the attributes of a memory object, you will get the following results:

  • On OS/2 Warp Connect, both PAG_EXECUTE and PAG_READ attributes are returned.

  • On OS/2 Warp, only the PAG_EXECUTE attribute is returned. However, PAG_READ is still implied.

  ---

  [Back] [Next]