ID Number: Q77226
3.00
WINDOWS
Summary:
Applications that will run solely in one of Windows protected modes
(standard mode or enhanced mode) can take advantage of the attributes
of protected mode to reduce the size and improve the speed of the
application.
These techniques do not apply to applications that can be run in
Windows real mode.
More Information:
To assure compatibility with future versions of Windows, an
application should not make any assumptions about the protection ring
of memory selectors the system provides for memory allocations.
Using global memory can be more straightforward when an application is
developed for the protected-mode environment. The following four steps
provide a procedure for using memory:
1. Use the GlobalAlloc() function to allocate memory. Applications
should ALWAYS use the GMEM_MOVEABLE attribute, which signifies that
the linear address of the memory block can be changed by the
system. The selector or handle to this block will not change unless
the application calls GlobalRealloc() to modify the handle, and
changes the number of 64K blocks required to satisfy the request.
For example, the selector can change if a 60K block is increased to
70K or if a 70K block is reduced to 60K.
2. Use the GlobalLock() function to obtain the corresponding selector.
In protected mode, there is no need to bracket each use of an
object with GlobalLock/GlobalUnlock calls. These calls are required
in real mode because the Windows memory management algorithm cannot
move locked objects in memory. In protected mode, locked objects can
be moved without changing the selector value that is used to refer
to the object.
3. Use the selector and the range of offsets (from zero to the size of
the block) to access the memory.
4. When the memory block is no longer required, unlock the memory
block using the GlobalUnlock() function, and free the selector using
the GlobalFree() function.
Some applications introduce incompatibilities by implementing a
private version of the GlobalLock() function to translate a handle to
a selector. While a private function can be made to work for any one
version of Windows, it is not guaranteed to work in future versions.
The four steps above may be used for discardable memory. However,
Windows cannot discard the memory while it is locked. Therefore, even
in protected mode, applications that use discardable memory objects
should unlock each object when it is not in use. This makes these
memory blocks candidates for discarding should the system run out of
memory.
Selectors should not be shared between applications unless the rules
outlined in the dynamic data exchange (DDE) specification are
followed. In particular, the GMEM_DDESHARE or GMEM_SHARE flag must be
specified in memory allocation requests. Future versions of Windows
may implement separate address spaces; any applications that
improperly share memory will not function properly in any such
release.
An application that uses any of these techniques should specify the
Resource Compiler -T switch when resources are added to the
application. This will prevent the application from running in real
mode.
Additional techniques to decrease the size and increase the speed of
an application developed for protected mode can be found by searching
on the words:
prod(winsdk) and streamlined
Additional reference words: 3.00