=============================================================================

****
**** The WIN32DLL technical article can be downloaded from the
**** file 14-1.zip in library section number 14
****

DLLs in Win32

Randy Kath
Microsoft Developer Network Technology Group

Created: September 15, 1992

Abstract

The ability of an application to load and execute code from an external
source at run time is one of the most useful features in software technology
today. The Win32 Application Programming Interface (API) provides this
functionality through dynamic-link libraries (DLLs). They are implemented as
separate source modules that are compiled and linked into libraries,
independent of the application that uses them. Also, DLLs are reentrant code,
allowing multiple threads of execution to use the same DLL simultaneously.
DLLs have been a part of the Microsoft Windows operating system for some
time, remaining pretty much the same through Windows version 3.1. In Win32,
however, DLLs have been changed to take advantage of new, Win32
memory-management features and to improve the interface between applications
and DLLs.

This article explores DLLs in their Win32 form. It describes how DLLs exist
in memory when loaded, how to build a DLL, how to use a DLL for sharing
memory between processes, and how to dynamically load and execute code in a
DLL.

The code examples in this article were extracted from the source code
written for the PortTool program. The only exception is the example on using
function tables to call functions in a DLL.


=============================================================================

=============================================================================

****
**** The MMFILE technical article can be downloaded from the
**** file 14-3.zip in library section number 14
****

Managing Memory-Mapped Files in Win32

Randy Kath
Microsoft Developer Network Technology Group

Created: February 9, 1993

Abstract

Determining which function or set of functions to use for managing memory in
your Win32 application is difficult without a solid understanding of how each
group of functions works and the overall impact they each have on the
Microsoft Windows NT operating system. In an effort to simplify these
decisions, this technical article focuses on the use of the memory-mapped
file functions in Win32: the functions that are available, the way they are
used, and the impact their use has on operating system resources. The
following topics are discussed in this article:

o  Introduction to managing memory in Windows operating systems

o  What are memory-mapped files?

o  How are memory-mapped files implemented?

o  Sharing memory with memory-mapped files

o  Using memory-mapped file functions

In addition to this technical article, a sample application called
ProcessWalker is included on the Microsoft Developer Network CD. This sample
application is useful for exploring the behavior of memory-mapped files in a
process, and it provides several useful implementation examples.


=============================================================================

=============================================================================

****
**** The VIRTMM technical article can be downloaded from the
**** file 14-4.zip in library section number 14
****

Managing Virtual Memory in Win32

Randy Kath
Microsoft Developer Network Technology Group

Created: January 20, 1993

Abstract

Determining which function or set of functions to use for managing memory in
your Win32 application is difficult without a solid understanding of how each
group of functions works and the overall impact they each have on the
Microsoft Windows NT operating system. In an effort to simplify these
decisions, this technical article focuses on the Win32 virtual memory
management functions: which ones are available, how they are used, and how
their use affects the operating system. The following topics are discussed in
this article:

o  Reserving, committing, and freeing virtual memory

o  Changing protection on pages of virtual memory

o  Locking pages of virtual memory

o  Querying a process's virtual memory

A sample application called ProcessWalker accompanies this technical article
on the Microsoft Developer Network CD. This sample application is useful for
exploring the virtual address space of a process. It also employs the use of
virtual memory functions for implementing a linked list structure.

The first version of the Microsoft Windows operating system introduced a
method of managing dynamic memory based on a single global heap, which all
applications and the system share, and multiple, private local heaps, one for
each application. Local and global memory management functions were also
provided, offering extended features for this new memory management system.
More recently, the Microsoft C run-time (CRT) libraries were modified to
include capabilities for managing these heaps in Windows using native CRT
functions such as malloc and free. Consequently, developers are now left with
achoice---learn the new application programming interface (API) provided as
part of Windows version 3.1 or stick to the portable, and typically familiar,
CRT functions for managing memory in applications written for Windows 3.1.

With the addition of the Win32 API, the number of choices increases. Win32
offers three additional groups of functions for managing memory in
applications: memory-mapped file functions, heap memory functions, and
virtual memory functions. These new functions do not replace the existing
memory management functions found in Windows 3.1; rather, they provide new
features that generally make life easier for developers when writing the
memory management portions of their applications for Win32.

In all, six sets of memory management functions exist in Win32, as shown in
Figure 1, all of which were designed to be used independently of one another.
So, which set of functions should you use? The answer to this question
depends greatly on two things: the type of memory management you want and how
the functions relevant to it are implemented in the operating system. In
other words, are you building a large database application where you plan to
manipulate subsets of a large memory structure? Or maybe you're planning some
simple dynamic memory structures, such as linked lists or binary trees? In
both cases, you need to know which functions offer the features best suited
to your intention and exactly how much of a resource hit occurs when using
each function.


=============================================================================

=============================================================================

****
**** The PORTING technical article can be downloaded from the
**** file 14-2.zip in library section number 14
****

Porting 16-Bit Windows-Based Applications to Win32

Randy Kath
Microsoft Developer Network Technology Group

Created: July 15, 1992

Abstract

Porting an application from one operating system to another is a chore that
many software engineers find they must repeatedly perform to keep up with the
rapidly changing software industry. Fortunately for developers of
applications for the Microsoft Windows operating system, the Win32
Application Programming Interface (API) specification was designed to
eliminate this frustration. In fact, the Win32 API so resembles the Windows
version 3.1 Software Development Kit (SDK) that many applications need only
minor adjustments and a recompile for a complete port. Yet other
applications, those that take advantage of operating system or
hardware-specific features, require more time to rework incompatibilities.

Several measures, however, can significantly reduce the amount of time
required to complete this process. This article focuses on measures that
reduce the porting effort and introduces a porting tool that further assists
in porting 16-bit Windows-based applications to the Win32 environment.


=============================================================================

=============================================================================

****
**** The NTVMM technical article can be downloaded from the
**** file 14-5.zip in library section number 14
****

The Virtual-Memory Manager in Windows NT

Randy Kath
Microsoft Developer Network Technology Group

Created: December 21, 1992

Abstract

This article provides an in-depth survey of the memory management system in
Windows NT. Specifically, these topics are explored in detail:

This article does not discuss the Win32 memory management application
programming interface (API). Instead, several other technical articles on the
Microsoft Developer Network CD should be referenced for issues related to
understanding how to manage memory with the Win32 API. Those articles provide
both insight into the system and understanding of the functions themselves.
While this article primarily deals with Windows NT-specific memory management
issues, it does refer to some of the memory objects in the Win32 subsystem
(like memory-mapped files and dynamic heaps) in an attempt to shed some light
on the age-old dilemma of performance vs. resource usage as it applies to
applications written for the Win32 subsystem in Windows NT. 

As the size of applications and the operating systems that run them grow
larger and larger, so do their demands on memory. Consequently, all modern
operating systems provide a form of virtual memory to applications. Being the
newest of the operating systems to hit the main stream, Windows NT will
likely have applications ported to it that will evolve into larger
monstrosities that require even more memory than they did on the last
operating system on which they ran. Even applications being written
exclusively for Windows NT will be written with the future in mind and will
no doubt take advantage of all the memory that is available to them.

Fortunately, Windows NT does, in fact, offer virtual memory to its
applications (or processes) and subsystems. Windows NT provides a page-based
virtual memory management scheme that allows applications to realize a 32-bit
linear address space for 4 gigabytes (GB) of memory. As a result, each
application has its own private address space from which it can use the lower
2GB---the system reserves the upper 2 GB of every process's address space for
its own use.

If only we had PCs with similar memory capacities. . . . Actually, a
computer doesn't really need 4 GB of physical memory for Windows NT to
operate effectively---though the general rule of virtual memory systems is
the more physical memory, the better the performance. Windows NT's memory
management system virtualizes memory such that to each application it appears
as though there is 2 GB of memory available, regardless of how much physical
memory actually exists. In order to do this, Windows NT must manage memory in
the background without regard to the instantaneous requests that each
application makes. In fact, the memory manager in Windows NT is a completely
independent process consisting of several threads that constantly manage
available resources.

Windows version 3.x has realizable limitations to the maximum amount of
memory available to it and all of its applications; these are often barriers
to large applications for this environment. Windows NT's limits are far more
theoretical. Windows NT employs the PC's hard disk as the memory-backing
store and, as such, has a practical limit imposed only by available disk
space. So, it is reasonable to assume that a Windows NT system could have an
extremely large hard disk or array of disks amounting to 2 GB or more of
physical memory and provide that much virtual memory to each of its
applications (minus the portions used by the system, occupied by the file
system, and allocated by files stored within the file system). In short,
Windows NT provides a seemingly endless supply of memory to all of the
applications running on it. 


=============================================================================

=============================================================================

****
**** The DEBUG technical article can be downloaded from the
**** file 14-6.zip in library section number 14
****

The Win32 Debugging Application Programming Interface

Randy Kath
Microsoft Developer Network Technology Group

Created: November 5, 1992

Abstract

This article demonstrates how the debugging support in the Microsoft Win32
Application Programming Interface (API) can be used by developers to create
custom debugging applications that behave exactly the way they want,
including any specific features they desire. Specifically, this article
discusses the following topics:

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Exploring the built-in
debugging support of Win32, including Win32 debug events and Win32 debug
functions

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Looking at the
relationship between a debugger and the process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Representing
information about a process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Using event objects
for communicating between debugger threads

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Managing the
debugger's graphical user interface (GUI)

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Responding to user
commands in debug threads

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Controlling the
threads of a process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Accessing thread
context information from threads of a process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Terminating and
exiting a process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Calling debug
functions from a process being debugged

o  {3 {5 \*SYMBOL 183 \f "Symbol" \s 10 \h}5 {5 }5 }3 Expanding on this
debugger model

Each of the key concepts presented is supported with code segments extracted
from a sample debugging application called DEBUGAPP.EXE, whose source is
included with this article. The sample application stands on its own as a
multiprocess debugging application, or its source code can be used as the
framework for a more elaborate custom debugger.


=============================================================================

