Copyright: Copyright (c) 1995-1996 Chicago-Soft Ltd.


About WinMiser Pro

WinMiser Pro is a unique system monitor and problem resolution tool for the Microsoft Windows 3.1, 3.11, and Windows for Workgroups 3.11 operating systems.

Like other system monitors, WinMiser Pro provides information on critical resources such as limited memory areas.  However, unlike other systems, WinMiser Pro was designed to provide information you can use to enhance your system's performance, not just provide statistics because they are available.  Extensive effort was placed on getting the most detailed information on the most critical items.

WinMiser Pro presents the following information:

Windows DOS Memory Usage by Module.

Windows Local Memory Usage by Module.

Memory Leakage by Module.

In addition, WinMiser Pro is able to alert users of problems with their systems.  It is disturbing to know that there is a problem with your system and not be able to identify the cause of the problem.

WinMiser helps identify the following types of problems:

Module Load Failures

Windows DOS Memory Allocation Failures.

Windows Local Memory Allocation Failures.

Windows Local Memory Leakage.

Finally, WinMiser Pro is able to help users resolve most of these problems.

This includes the following features:

The ability to enhance Windows memory management logic in order to increase available Windows DOS Memory.

The ability to release Windows Local Memory that has been leaked.

The ability to offload GDI Local Memory to a different memory area thus providing 10% to 30% more useable GDI memory.

These features along with this extensive help facility make WinMiser Pro one of the most useful system monitors and performance tools available.


About WinMiser

WinMiser is a scaled down version of WinMiser Pro that only supports Window DOS Memory problems.  It is sold as a unique product for customers who do not have problems with insufficient System Resources.

Insufficient Windows DOS Memory is a distinct problem from Insufficient System Resources.  For many customers it is the only reason to purchase WinMiser Pro.  For these customers, WinMiser provides full Windows DOS Memory support at a lower cost than WinMiser Pro.

We recommend you try WinMiser Pro first to determine which product you really need.  If you have problems with Insufficient System Resources, memory leakage, or other memory related problems, you should use WinMiser Pro.  If you only have problems with Insufficient Windows DOS Memory, you should use WinMiser.

WinMiser supports the following features found in WinMiser Pro:

Windows DOS Memory Usage by Module.

The ability to enhance Windows memory management logic in order to increase available Windows DOS Memory.

These features along with its very informative help facility make WinMiser a cost effective alternative to WinMiser Pro.


Windows DOS Memory Configuration

By default, WinMiser manages the entire Windows DOS memory area.  In some situations, you may encounter a problem because an application or driver you are using allocates Windows DOS memory incorrectly.

To date we have found only a few products that are not compatible with WinMiser's default settings.  Chicago-Soft has worked with the vendors of these products to correct this problem.  The WinMiser configuration options are based on the results of this effort.

If are having problems with WinMiser, please contact Chicago-Soft for technical support.  In most cases, we will know how to resolve the problem.  If not, we will determine which applications are not comptible with WinMiser and find the optimum solution.

You can also try to resolve the problem yourself by configuring WinMiser to manage a smaller portion of the Windows DOS memory area.  The Windows DOS Memory Configuration dialog contains two controls that determines how much memory WinMiser manages.

Allow Shared Memory Low

The Allow Shared Memory Low check box alters WinMiser's standard memory protection logic to allow shared memory to use Windows Dos memory.  This is only required when you have an application that needs shared memory from the Windows Dos memory area.

Managed Memory Amount

The Windows DOS Memory Configuration dialog contains a slide bar that determines how much memory WinMiser manages.  To manage less memory, simply slide the bar to a smaller value.

If you decide to change this value, start with 64K.  If the problem goes away, you can increase this value if needed (in most cases 64K is sufficient).  If the problem does not go away, please contact Chicago-Soft for support.


WinMiser Contents

Contents for WinMiser Shareware Help

About...

WinMiser
WinMiser Pro

How To...

Install WinMiser Shareware
Configure WinMiser Shareware
Uninstall WinMiser Shareware

WinMiser Shareware Tutorials

Windows DOS Memory
System Resources
Memory Leakage
GDI Memory Offload


WinMiser Shareware Display

The WinMiser Shareware display contains two sections; Windows DOS memory Usage and WinMiser Pro Offload Potential.

The Windows DOS Memory Usage section shows how much Windows DOS memory is allocated or free for use.  Values below 16K bytes may indicate a problem with your system which could be corrected by WinMiser or WinMiser Pro.  See the Windows DOS Memory Tutorial for more information on Windows DOS memory.

The WinMiser Pro Offload Potential sections shows the potential amount of GDI memory that could be offloaded by WinMiser Pro.  WinMiser Pro has the ability to move memory from specific GDI objects to a different memory area.  This reduces GDI memory usage so that more GDI intensive programs can execute at the same time.  The technique used by WinMiser Pro is both very efficient and effective on all Windows 3.1 systems.

The value displayed in this section gives you an estimate of the amount of GDI memory WinMiser Pro would offload from your system at the time you selected the Refresh button.  The GDI heap is limited to about 60K Bytes.  Our tests have found most systems will get between 10% and 30% (6,000 to 18,000 bytes) reduction from a heavily loaded system (GDI Memory Usage greater than 80%).  See the GDI Memory Offload Tutorial for more information on GDI Memory Offload.


Windows DOS Memory - Index

Introduction
Technical Background
DOS Limitations
Windows 3.1 Limitations
Windows Memory Management
Insufficient Memory Symptoms
WinMiser Shareware Problem Resolution

Note:

This tutorial was adapted from the Windows DOS Memory tutorial provided with WinMiser Pro.


Windows DOS Memory - Introduction

Microsoft Windows Version 3.1 is a remarkable PC operating system in both functionality and in user acceptance.  However, there are a number of problems with Windows memory management.  In particular, Windows is vulnerable to problems with insufficient "DOS" or "low" memory.  Systems which experience these problems may be unable to launch new programs, or they may need to start programs in a particular order.

WinMiser Shareware can correct problems associated with insufficient Windows DOS Memory.  Once installed and configured, WinMiser Shareware acts as a guardian of this precious resource, only allowing applications that specifically request Low Memory to receive memory from this region.  Since most programs use very little Windows DOS Memory, WinMiser Shareware prevents Low Memory from being exhausted in all but the most extreme cases.


Windows DOS Memory - Technical Background

One of the problems of dealing with Windows memory problems is the complexity of the whole issue.  In particular, there is a seemingly endless list of memory related terms such as:

Conventional Memory
Upper Memory Block (UMB)
High Memory Area (HMA)
Expanded Memory (EMS)
Extended Memory (XMS)
Physical Memory
Virtual Memory
Linear Memory
Global Memory
Local Memory
User Memory
GDI Memory

Most users of Windows do not and should not understand all of these terms.  It is only because of memory limitations within DOS and Windows that these terms are even discussed.


Windows DOS Memory - DOS Limitations

When DOS was first introduced, it was built for the 8088 chip.  One limitation of this processor is that programs can only address 1 megabyte of storage.  In addition, the designers reserved 384K bytes for system use, leaving only 640K available to programs.  At first this was not an issue.  However it soon became a major problem as programs got larger and users tried to execute more programs at the same time.

The introduction of the 80286 chip allowed programs to address up to 16 megabytes of memory when operating in Protected Mode.  The problem is that DOS was written for Real Mode and does not use Protected Mode to address the additional memory directly.  Even today on 80836, 80846 and Pentium PCs with more than 16 megabytes of memory, DOS can only address the first megabyte.


Windows DOS Memory - Windows 3.1 Limitations

Windows 3.1, for all of its abilities, is still based on DOS and therefore inherits the limitations of DOS.  In order to work, Windows must be able to share memory with DOS as well as device drivers and TSRs that were loaded before Windows was started.  These "pre-Windows" modules are based on Real Mode and can only access the first megabyte of memory.  Thus, for Windows to work with these modules, it must have a way to place specific items in Low Memory.

This is where Windows "DOS" or "low" memory comes in.  Windows DOS Memory is simply the lowest 640K bytes of memory.  This memory area is unique because it can be accessed by programs that operate in Real Mode (DOS), and programs that operate in Protected Mode (Windows).


Windows DOS Memory - Windows Memory Management

Windows has two conflicting memory management schemes that lead to Windows DOS Memory shortages.

First, Windows provides the ability for programs to specifically allocate memory in the Windows DOS Memory area.

The actual API is called "GlobalDosAlloc".  Programs are only supposed to use this API when they need memory that will be used by DOS, Device Drivers, or TSRs that operate in Real Mode.  In most cases, there is little need for this type of memory.

All programs that execute under Windows use 512 bytes of this area in order to store information needed by DOS.  Only specific types of applications need to use additional memory from this area, and then only a small amount of it.

Second, when a Windows based application allocates memory from Windows, it can specify different types of memory.

In particular, it can specify whether the memory will be fixed memory, moveable memory, or discardable memory.  For the sake of this discussion, the important difference between these types of memory is that fixed memory is allocated from the lowest available memory.  This was done to reduce memory fragmentation due to islands of fixed memory.

This means that requests for fixed memory will first be filled from the Windows DOS Memory area.  Fixed memory allocations will only come from higher memory addresses after this limited memory area is depleted.

Thus, most problems with insufficient Windows DOS Memory are due to programs allocating fixed memory.  This is very common in applications that use hardware features of the PC such as Local Area Network (LAN) connections or multimedia.  This type of program can consume large portions of fixed and thus Low Windows Memory.

If applications with fixed memory requirements allocate all of the available Windows DOS Memory, then other application that need to use this limited resource will be unable to execute.


Windows DOS Memory - Insufficient Memory Symptoms

One of the problems with insufficient Windows DOS Memory problems is that they are hard to diagnose.  There is no error message that says you are out of Windows DOS Memory.  Windows doesn't provide a statistic for Windows DOS Memory usage like it does with total memory and free system resources.  Typically all the user will notice is the following types of problems:

1)  Insufficient Memory to Load this Application.

When an attempt to start a new program from Program Manager, File Manager, or from an icon fails,  Windows will display this error message.  One reason for this message is insufficient Windows DOS Memory.  Windows must allocate a 512 byte block of Windows DOS Memory for every Windows task.  If Windows is unable to allocate this block, a new task can not be started.

The other common reason for this error is insufficient System Resources.  You can confirm this problem by selecting the "About Program Manager..." menu item under Program Manager's "Help" menu selection.  The System Resources field at the bottom of this dialog box shows the percent of free system resources.  If this value is below 10%, Windows will not start any new programs.

If this is not the case, the most likely problem is insufficient Windows DOS Memory.

2)  Erratic Program Behavior

Sometimes one Windows based program will attempt to start another program.  For example, when using the Windows Help facility, the Windows Help program is started when you click on a "Help" button.  If Windows is unable to start the requested task, the desired action will not be taken.  If the calling program has not been coded to account for this condition, you will not receive an error message.  Instead it will appear as if the system ignored your request.

This is the same problem as in the previous case except that there is no error message.  In the previous case Windows Program Manager has been coded to display the Insufficient Memory error message.

3)  Specific Programs will not Load

Only specific types of programs require more than 512 bytes of Windows DOS Memory.  If there isn't enough Windows DOS Memory, then these programs will not load.

To test this condition, try loading a program that does not need Windows DOS Memory such as Clock or Notepad.  If these programs will load but others won't, there is a good chance the other programs need additional Windows DOS Memory.

4)  Programs need to Load in a Particular Order

This is a common situation where if you load Program A before Program B, Program B will not load.  However, if you load Program B before Program A, both will load.

This condition is caused when Program A uses enough fixed memory to cause an insufficient Windows DOS Memory condition when Program B loads.

Note:

You cannot use the DOS MEM command to determine the amount of free Windows DOS Memory.  MEM is a DOS program which can only report on the amount of free memory in a DOS Virtual Machine.  Windows DOS Memory is associated with the Windows Virtual Machine.  Because the use of Low Memory in one virtual machine has no impact on other virtual machines, the MEM command is unable to report on memory usage by Windows based applications.


Windows DOS Memory - WinMiser Shareware Problem Resolution

If you suspect that your system has insufficient Windows DOS memory, you should install WinMiser Shareware so that it can manage this memory area.  Once installed, WinMiser Shareware examines all requests to allocate Windows Memory.  If the request is for Windows DOS Memory, it is allowed to use memory in the first megabyte of Linear Memory.  However, if it is for Fixed Memory, it is forced to use memory above the first megabyte.

This technique is very fast and  wastes almost no Windows DOS memory.  Memory fragmentation is still avoided because fixed memory will be allocated at the lowest address above 1 megabyte.

The end result of WinMiser Shareware's memory management logic is resolution of Windows DOS memory problems in almost every environment.


Glossary Index

WinMiser Pro Glossary

A
API
Application Programming Interface

B
Bitmap
Brush

C
Conventional Memory

D
DC
Device Context
Device Drivers
Discardable Memory
DLL
DOS
DOS MEM Command
DOS Virtual Machine
Dynamic Link Library

E
EMM386.EXE
EMS
Expanded Memory
EXE
Extended Memory

F
Fixed Memory
Font
Font File

G
GDI
GDI Heap
GDI Memory
GDI Object
GDI String Heap
GDI String Memory
General Protection Fault
Global DOS Memory
Global Memory
GPF

H
High Memory Area
HIMEM.SYS

L
Linear Memory
Local Memory
Locked Memory
Low Memory

M
Menu
Menu Heap
Menu Item
Menu Memory
Menu String
Menu String Heap
Menu String Memory
Module
Module Name
Moveable Memory

P
Page Tables
Paging
Palette
Pen
Physical Brush
Physical Font
Physical Object
Physical Pen
Physical Memory
Protected Mode

R
RAM
Real Mode
Region

S
Selector
SVM
Swap File
System Resources
System Virtual Machine

T
TSR

U
UMB
Upper Memory Block
User
User Heap
User Memory
User String Heap
User String Memory

V
Virtual Machine
Virtual Memory
VM

W
Windows
Windows DOS Memory
Windows Local Memory
Windows Memory
Windows Virtual Machine

X
XMS


Application Programming Interface
An Application Programming Interface (API) is a standard by which a program written by one vendor can use functions provided by another vendor.  For example, Windows based programs use the Windows API to execute functions within Windows.


Bitmap
A Bitmap is a GDI Object that is commonly used to draw items such as logos.


Brush
A Brush is a GDI Object that is used when drawing to set background colors and patterns.


Conventional Memory
Convetional Memory is the lowest 640K bytes in memory.  It is critical to DOS and Windows because Real Mode programs can only address memory in this area.


Device Context
A Device Context (DC) is a GDI Object that is used when drawing items.  It provides programs with a logical view of an output device such as a CRT or printer.  This logical view prevents programs from having to know specific details about the output device.  It contains information about the other GDI objects such as Pens and Brushes.  These selected items are used when a program draws using the Device Context.


Device Drivers
Device Drivers are programs designed to add functionality to the base PC system configuration.  Rather than have every PC support all types of hardware, additional components can be supported by adding the proper device driver.

For example, if you add a CD ROM drive to your PC, you need to add a device driver that knows how to communicate with your specific CD ROM drive.  This technique of adding device drivers allows your PC to be customized to meet your needs.


Discardable Memory
Discardable Memory is a Global Memory object that Windows can remove from Linear Memory under tight memory conditions.  The most common use of discardable memory is to store executable code.  After memory is discarded, it can be restored by retrieving it from the original source file.


DLL
Windows uses Dynamic Link Libraries (DLLs) as a method of supporting shared program code.  Programmers place common functions in DLLs so they can be shared by multiple applications.  This provides modularity as well as reduced memory usage.


DOS
DOS is the Real Mode operating system which Windows Version 3.1 runs on.


DOS MEM Command
DOS provides the "MEM" command to display how DOS memory is being used.  This is very useful when trying to resolve insufficient Conventional Memory problem.  However, it is of limited value under Windows because it only displays information for a DOS Virtual Machine.  It does not show the Windows DOS Memory usage for the Windows Virtual Machine.


DOS Virtual Machine
Each DOS program you execute under Windows runs in a separate Virtual Machine called a DOS Virtual Machine.  This allows each DOS program to think it is running under DOS instead of running under Windows.


EMM386.EXE
EMM386.EXE is a program provided with DOS and Windows to provide both Expanded Memory and support for Upper Memory Block usage.


EXE
An EXE file contain the main portion of an executable program.


Expanded Memory
Expanded Memory (EMS) is a method of providing more memory for programs to use under DOS.  It was originally designed to work with an expanded memory card.  Memory was swapped between a 64K byte region in the Upper Memory Block and memory on this card.  Now programs such as EMM386.EXE and Windows provide expanded memory compatibility by using Extended Memory.


Extended Memory
Extended Memory (XMS) is the range of memory above 1 megabyte.  The original PC could only address 1 megabyte of memory.  This limitation was removed starting with the 80286 processor.  However, to access this memory directly, the processor must be running in Protected Mode.  While programs written for Real Mode such as DOS, can not access this memory directly, they can access extended memory indirectly with the help of programs like HIMEM.SYS.  Programs written for Protected Mode such as Windows based programs can access this memory directly.


Fixed Memory
Fixed Memory is a Global Memory object that was allocated not to move in Linear Memory.  It is used by programs that need to be sure the memory is at the same linear address and not moved to the Swap File.


Font
A Font is a GDI Object that describes how to present characters when drawing text strings.


Font File
A Font File contain information about a Windows Font.


GDI
GDI is a component of Windows that supports graphics features.


GDI Heap
The GDI Heap is a local memory area used to store GDI Memory.


GDI Memory
GDI Memory is memory used by the Windows GDI component to store graphics information.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store information about GDI Objects.


GDI Object
A GDI Object is a logical resource used by the Windows GDI Component when doing drawing operations.  It includes Bitmaps, Brushes, Device Contexts, Fonts, Palettes, Pens, and Regions.


GDI String Heap
The GDI String Heap is a local memory area used to store GDI String Memory.


GDI String Memory
GDI String Memory is memory used by the Windows GDI Component to store character string information.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store character string information needed by GDI.


Global DOS Memory
Global DOS Memory is another term for Windows DOS Memory.


Global Memory
Global Memory is the memory allocated to the System Virtual Machine.  It is the memory space used by all Windows based programs.  Windows has a limit of 8192 Global Memory objects.


General Protection Fault
A General Protection Fault (GPF) is a common indication of a program failure.  Most GPFs are due to programming errors or memory shortages.


High Memory Area
The High Memory Area (HMA) is the 64K byte memory range just above 1 megabyte.  On the original PC this area did not exist because PCs had less than 1 megabyte of memory.  On newer PCs with Extended Memory, this memory area does exist.  It is a special area because it is the only portion of Extended Memory that is directly addressable by Real Mode programs.  It is typically used to store a portion of DOS using the command "DOS=HIGH" in CONFIG.SYS.


HIMEM.SYS
HIMEM.SYS is a program that is used to execute the PC in Protected Mode.


Linear Memory
Linear Memory is the entire 4 gigabyte address space that can be addressed by Virtual Memory.  It is addressed using Page Tables.  Because 4 gigabytes is more memory than is needed by most systems, a majority of the linear address space is not mapped with Page Table entries.


Local Memory
Local Memory is a subset of a Global Memory object.  Programs use local memory objects to store small items because there are a limited number of Global Memory objects.  Under Windows 3.1 local memory is limited to 64K bytes.


Locked Memory
Locked Memory is a Global Memory object that has been locked so that it will not be moved in Linear Memory.  It is used by programs that need to be sure the memory is at the same linear address and not moved to the Swap File.


Low Memory
Low Memory is another term for Windows DOS Memory.


Menu
A Menu is a resource used by the Windows User Component to store window menu information.  Each Menu requires 20 bytes of Menu Memory.


Menu Heap
The Menu Heap is a local memory area used to store Menu Memory.


Menu Item
A Menu Item is a resource used by the Windows User Component to store window submenu information.  Each Menu Item requires 28 bytes of Menu Memory per submenu item.


Menu Memory
Menu Memory is memory used by the Windows User Component to store window menu information.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store currently available window menus.


Menu String
A Menu String is a resource used by the Windows User Component to store window menu strings.  Each Menu String requires variable (string length + 4) bytes of Menu String Memory per submenu item.


Menu String Heap
The Menu String Heap is a local memory area used to store Menu String Memory.


Menu String Memory
Menu String Memory is memory used by the Windows User Component to store window menu item information.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store currently available window menu strings.


Module
A Module is a separate unit of executable code.  It is either an EXE, DLL, or Font File.


Module Name
A Module Name is a unique 8 byte identifier Windows uses to keep track of each active module in the system.  Module Names are assigned by the module's developer.


Moveable Memory
Moveable Memory is a Global Memory object that Windows can move in Linear Memory.  Moveable Memory can be moved to the Swap File when Windows can no longer allocate Global Memory.


Page Tables
Page tables are used by Windows to support Virtual Memory.  Linear Memory is divided into 4K byte pages.  Each page is referenced by an entry in a page table.  This reference contains the information needed by Windows to locate the memory addressed by this page.


Paging
Paging is a process used by Windows to support Virtual Memory.  When all Physical Memory has been allocated,  Windows can move 4K byte pages of memory to the Swap File.


Palette
A Palette is a GDI Object that is store information about colors.


Physical Brush
A Physical Brush is a copy of a Brush that has been converted for a specific output device.


Physical Font
A Physical Font is a copy of a Font that has been converted for a specific output device.


Physical Object
A Physical Object is a copy of a GDI Object that has been converted for a specific output device.  Physical Brushes, Physical Fonts, and Physical Pens are all physical objects.


Physical Pen
A Physical Pen is a copy of a Pen that has been converted for a specific output device.


Pen
A Pen is a GDI Object that is used to draw lines.


Physical Memory
Physical Memory is the memory provided by RAM chips on your PC.  Typical PCs have between 4 and 16 megabytes of physical memory.


Protected Mode
Protected Mode is one of two execution modes of the 80x86 processor, the other is Real Mode.  Windows uses the Protected Mode features to address more then 1 megabyte of memory.


RAM
RAM or Random Access Memory is Physical Memory on your PC that is used by the processor to temporarily store programs and data.  Physically RAM consists of a number of chips designed to store binary data.


Real Mode
Real Mode is one of two execution modes of the 80x86 processor, the other is Protected Mode.  It is mainly used for compatibility with the original 8088 processor.  The most important feature of Real Mode is that only 1 megabyte of memory can be addressed in this mode.  This is what leads to Conventional Memory and Windows DOS Memory shortages.


Region
A Region is a GDI Object that describes an area that is being drawn.


Selector
A Selector is a PC memory management item that is used to reference or address a block of memory.  There are only 8,192 Selectors available per Virtual Machine.


Swap File
The swap file is used by Windows to support Virtual Memory.  The disk space assigned to the swap file is combined with Physical Memory to provide Windows virtual address space.  The size of the swap file can be set using the 386 Enhanced icon under control panel.


System Resources
System Resources is a term used to define the availability of shared Windows Local Memory areas.  The Free System Resources percentage reported by Windows programs is based on the amount of memory that can be allocated from the User, GDI, Menu, and Menu String memory areas.


System Virtual Machine
The System Virtual Machine (SVM) is the Virtual Machine where all Windows based programs execute.


TSR
A TSR or Terminate and Stay Resident program is a DOS program that loads and then stays active in the background of your PC.  They are typically used to add background functionality such as print or network support.


Upper Memory Block
The Upper Memory Block (UMB) is the 384K byte region of memory between 640K and 1 megabyte.  When the original PC was designed, this memory area was set aside to be used by hardware components such as video drivers.  The demand for Conventional Memory has lead to portions of this memory to be used by device drivers and TSR programs.  Programs such as EMM386.EXE are designed to allow free memory in the UMB range to be used by these system programs.


User
User is a component of Windows that supports window display features.


User Heap
The User Heap is a local memory area used to store User Memory.


User Memory
User Memory is memory used by the Windows User component to store windowing information.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store information about all window objects.


User String Heap
The User String Heap is a local memory area used to store User String Memory.


User String Memory
User String Memory is memory used by the Windows User component to store character strings.  It is a critical memory area because it is shared by all Windows based programs and is limited to 64K bytes.  It is used to store character strings that are accessible to all programs.


Virtual Machine
Windows executes programs in separate areas called Virtual Machines.  All Windows based programs execute under the System Virtual Machine.  All DOS based programs execute under a separate Virtual Machine.


Virtual Memory
Virtual Memory is a memory allocation technique used by Windows that allows the PC to store more information than it has Physical Memory to support.  To support virtual memory, memory addresses used by programs point to Page Tables instead of Physical Memory addresses.  These Page Tables contain the information needed by Windows to find the Physical Memory associated with a virtual memory address.  Windows combines Physical Memory with Swap File space to create its virtual memory space.  Thus you can increase the Windows virtual memory space by adding more Physical Memory or by defining a larger Swap File.  This allows you to run more programs with less Physical Memory.


Windows
For ease of reading, "Windows" is used in this document to refer to the Microsoft Windows operating system.  Windows is a trademark of Microsoft Corporation.


Windows DOS Memory
Windows DOS Memory is the range of Linear Memory in the System Virtual Machine that can be mapped to Conventional Memory.  It is a critical memory area because it is limited in size (less than 640K bytes), and is required by all Windows based applications.  It is also referred to as Low Memory or Global DOS Memory.  This document uses the term Windows DOS Memory to distinguish it from this linear address range in other Virtual Machines.


Windows Local Memory
Windows uses six local memory areas to support common functions.  These memory areas are called User Memory, User String Memory, GDI Memory, GDI String Memory, Menu Memory, and Menu String Memory.  It is important to keep track of the memory allocated in these areas because they are limited to less than 64K bytes.  Programs will either not start or behave erratically if one of these memory areas is over allocated.


Windows Memory
Windows Memory is another term for Global Memory.


Windows Virtual Machine
Windows Virtual Machine is another term for the System Virtual Machine.


Memory Leakage - Index

Introduction
Technical Background
GDI Objects
Menu Objects
Identification
Verification
Memory Recovery

Note:

This tutorial was adapted from the memory leakage tutorial provided with WinMiser Pro.


Memory Leakage - Introduction

One of the problems with Microsoft Windows 3.1 is that the shared memory areas called System Resources can be depleted.  When this happens, new programs can't be started and running programs behave erratically.

A major reason that Windows System Resources become depleted is that applications "leak" memory from the Windows Local Memory areas.  Memory leakage occurs when an application allocates memory from Windows and does not return it.  This can happen due to programming errors, program failures such as a GPF, or problems with the Windows operating system.

Memory leakage has long been a suspected reason for insufficient System Resource problems.  Until now, it has been very difficult for most users of Windows to accurately identify when a module has leaked System Resource memory.  Simply looking at the amount of free System Resources before and after an application executes does not work.  There are a number of factors which invalidate this technique.

Even if you were able to determine that a module was leaking memory, there is no inherent method within Windows to reclaim this memory.  Aside from not running applications that leak memory or having the application developer correct the problem, there is nothing the application user you can do to correct memory leakage.

In most cases, the correction to memory leakage has been to reload Windows.  While this might be acceptable for casual users, it should not be acceptable for production systems.  Since problems usually occur at the worst time, the loss to productivity and business flow can be enormous.  Minimally, having to reload Windows due to memory leakage is a frustrating process.

WinMiser Pro has been designed to eliminate problems with memory leakage.  Once configured, WinMiser Pro can not only identify when a module has leaked memory, it can also release this memory back to Windows.  This powerful technique can reduce the occurence of insufficient memory errors on systems with memory leakage problems.

This tutorial explains the how and why of memory leakage.  It also explains the capability of WinMiser Pro to correct this problem.


Memory Leakage - Technical Background

Memory leakage occurs when a module fails to return memory allocated from the Windows Local Memory areas.  These shared memory areas form what are commonly called System Resources.  Refer to the System Resources Tutorial for more information on System Resources.

Windows based applications allocate memory from the Windows Local Memory areas using Windows API calls.  Internally, Windows uses these calls to create well defined memory objects.  These memory objects are used by applications to interact with Windows.  This interaction includes the creation of windows and drawing on output devices.

For many types  of Windows Local Memory objects, Windows keeps track of which module owns the allocated memory objects.  When a module exits, Windows automatically releases all tracked memory objects which the exiting module failed to release.  This tracking logic applies to Window, Window Class, and in some cases Window Menu objects.

However, there are also many types of Windows Local Memory objects for which Windows does not keep track of ownership.  In particular, Windows does not track ownership of any GDI memory objects and some Menu memory objects.

The following sections explain how this failure to track memory ownership can lead to GDI and Menu memory leakage.


Memory Leakage - GDI Objects

GDI memory objects are used by applications to draw to output devices such as display screens and printers.  There are two types of GDI objects, logical and physical.

Logical GDI Objects

Logical GDI objects include items such as Pens, Brushes, Fonts, Palettes, and Bitmaps.  They are called logical objects because they are used to accomplish drawing tasks independent of the output device.

For example, a logical pen is used to draw lines of a specific width, color, and pattern.  When an application wishes to draw a line, it doesn't need to know how to draw a line on a specific output device, it just uses logical pens to accomplish this task.

Logical GDI objects are created by calling Windows APIs such as CreatePen.  When the object is no longer needed, it should be deleted using a DeleteObject API call.  If an allocated logical GDI memory object is not deleted, its associated memory is leaked.

Physical GDI Objects

Physical GDI objects include items such as Physical Pens and Physical Brushes.  They are called physical objects because they are related to a specific output device.  Physical GDI objects are created by the device drivers that manage a particular output device.

For example, a physical pen for a display screen must be able to draw a line on the CRT.  Likewise, a physical pen for a printer must be able to draw a line on a piece of paper.

Physical GDI objects are created by calling Windows APIs such as SelectObject.  When the physical object is no longer needed, it should be deleted using another SelectObject API call.  In some cases if this is not done, the memory associated with the physical GDI memory object is leaked.

Windows does not track GDI memory object ownership because these objects were designed to be sharable by multiple modules.  The reasoning behind shared GDI objects was probably to reduce the overall GDI memory requirement.  If modules could share GDI objects, then there would be fewer memory objects thus reducing GDI memory usage.

In reality, there is very little GDI memory sharing between modules.  Only very specialized systems use this feature.  This means that systems like WinMiser Pro can be used to identify and release memory associated with leaked GDI objects for most applications.


Memory Leakage - Menu Objects

Windows based applications use menus to provide a common interface to the application.  When a user selects a menu item, a message is sent to the application responsible for the menu.  This message usually informs the application that it should take some pre-defined action.

From Windows' perspective, menus consist of menu items and menu strings.  Each selection can be considered a menu item.  The character string you use to identify an select this item is stored in a menu string object.

For example, the main menu for this help facility consists of the File, Edit, Bookmark, and Help menu items.  Menu string objects are used to store the words File, Edit, Bookmark, and Help.

In most cases, a single menu is associated with a window.  When the application that created the window exits, the window and its associated menu are automatically destroyed by Windows.

However, in some cases an application uses multiple menus per window.  This happens when the possible actions changes under different conditions.

For example, in a word processing application, the menu may change depending on whether a document has been loaded.  Prior to loading a document, the application may only offer menu selections to load a document or configure the application.  After a document has been loaded, it may add new menu options that support document processing functions.

When an application uses multiple menus for a window, it is the developers responsibility to code the application to destroy any menu that isn't associated with a window.  If these un-associated menus aren't destroyed, the memory associated with the menu item and menu string objects is leaked when the application that created the window exits.


Memory Leakage - Identification

WinMiser Pro has been designed to identify Windows System Resource memory leakage.  Once leakage has been identified, WinMiser Pro can also be used to release any leaked memory.

The first step in memory leakage detection is to associate GDI and Menu objects with the module that allocated each object.  When memory leakage alerts are requested, WinMiser Pro activates the System Resource Memory usage by module logic for the GDI, Menu, and Menu String memory areas.  Thus, even if you haven't directly requested this option via the System Resources Configuration Dialog, the Windows Local Memory Windows for these memory areas will contain usage by module data.

When a module exits, WinMiser Pro checks to see if any Windows Local Memory objects owned by this module are still allocated.  If any GDI, Menu  or Menu String memory objects are found, they are considered to be leaked memory objects.

Objects left in the User, User String, and GDI String memory areas are not considered to be leaked.  Windows deletes all module specific objects from these areas automatically.  The remaining objects are shared resources which must remain in the system.

Once memory leakage has been detected, WinMiser Pro will produce an alert if this configuration option is selected.  Even if memory leakage alerts are not selected, WinMiser Pro will show memory leakage information in the Memory Leakage Window.


Memory Leakage - Verification

While memory leakage detection is important, the ultimate goal of WinMiser Pro is to recover leaked memory.  The ability to release leaked memory is based on a partnership between you and WinMiser Pro.  While WinMiser Pro is able to detect and release leaked memory, it is up to you to make the final decision about releasing leaked memory.

WinMiser Pro does not automatically release leaked memory because it could cause problems on your system.  While WinMiser Pro handles most conditions, it can't handle all situations.  Because of this, WinMiser Pro errs on the side of caution rather than optimization.

For example, assume two active modules are using a shared GDI memory object.  Next assume that the module that created this memory object exits first.  Based on the way WinMiser Pro works, this memory object will be flagged as a leaked memory object when in reality it is still in use.  If WinMiser Pro releases this object, your system may behave erratically.

While this scenario is unusual, you must always verify WinMiser Pro's memory leakage alerts are valid before releasing any leaked memory objects.  The following describes a process that can help verify memory leakage.

Enable memory leakage alerts.

When a leakage alert is displayed, select the leakage button to determine what type and how many objects were leaked.

Run the reported application again and see if the same leakage alert appears.  Note that the leakage count on the Module Leakage Window is cumulative.

If the same module was reported to leak, use the Module Leakage Window to release all of the leaked memory manually.  You should save all information in any active application before releasing this memory.  There is a slight chance that this could cause Windows to behave erratically.

If there are no visible problems after releasing this memory, try repeating the previous step once or twice more.  If you still do not have a problem, you can configure WinMiser Pro to release memory for this module automatically.

If there are problems after releasing this memory, configure WinMiser Pro to ignore future memory leakage alerts.

Using this technique, you will find that the vast majority of leakage alerts are accurate.  It is just better to be safe than sorry when doing this type of operation.


Memory Leakage - Memory Recovery

After you have verified a module is leaking memory you can use WinMiser Pro to release this lost memory.  This can either be done manually or automatically.

Releasing Memory Manually

WinMiser Pro uses the Module Leakage Window to release leaked memory manually.  This window can be reached from the Memory Leakage Summary Window or from a WinMiser Pro Alert Window for a memory leakage alert.

Refer to the Module Leakage Window for more information on using this window to release leaked memory.

Releasing Memory Automatically

By default, WinMiser Pro only produces an alert when memory leakage is detected.  You can also configure WinMiser Pro to ignore memory leakage conditions or automatically release leaked memory for specific modules.  This configuration option can be set for each of the different types of Windows Local Memory objects that WinMiser Pro keeps track of.  You should use these options to fine tune WinMiser Pro to match the applications you run on your system.

Refer to the Module Leakage Configuration Dialog for more information on how to configure WinMiser Pro leakage actions for specific modules.


WinMiser Shareware Setup - Index

Introduction
Source Path
Destination Path
SYSTEM.INI Backup File
Installation
Program Group
Completion


WinMiser Shareware Setup - Introduction

The WinMiser Shareware setup program can be used to install WinMiser Shareware on your system.  The installation process consists of the following steps:

1) Copying the WinMiser Shareware files from a source path to a destination path.

2) Modifying the Windows SYSTEM.INI file.

3) Adding the WinMiser Shareware program group to the Program Manager (optional).

First, the WinMiser Shareware setup program prompts you for the source and destination paths.  The selected paths are shown prior to installation processing beginning.  Once verified, the WinMiser Shareware files are copied if the source and destination paths are not equal.

In either case, the current SYSTEM.INI file is backed up to SYSTEM.WMI, and the SYSTEM.INI file is modified to support WinMiser Shareware.  You may change the default SYSTEM.INI backup file name.

Next, you are prompted to add the WinMiser Shareware program group.  If you select this option, the WinMiser Shareware program group will be added to the Program Manager window.

The WinMiser Shareware setup program will display a message box if it encounters any errors during the setup process.

Select the Continue button to proceed with the installation.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - Source Path

The WinMiser Shareware Setup Source Path dialog is used to specify the location of the WinMiser Shareware source files.  The default value is the path where the setup program is located.  You may change this value to any valid path which contains the WinMiser Shareware source files.  An error will be displayed if the setup program can not find the source path or if can not find all of the WinMiser Shareware source files.

The WinMiser Shareware source files are:

WINMISER.EXE
MISERDLL.DLL
MISERDRV.DLL
MISERVXD.386
WINMISER.HLP
SETUP.EXE
UNINST.EXE
MISERUNI.EXE
README.TXT

In addition, if the WINMISER.INI file is found on the source path and not in the Windows directory, WinMiser Shareware will copy the source WINMISER.INI file to the Windows directory.  Use this feature to maintain settings when re-installing WinMiser or when installing on a new PC.  Simply copy the existing WINMISER.INI file from the Windows directory to the source path.  The WinMiser setup program will copy the file and make the necessary changes.

Select the Continue button to accept the specified Source Path and proceed with the installation.

Select the Back button to display the Welcome dialog.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - Destination Path

The WinMiser Shareware Setup Destination Path dialog is used to specify the path where you want to install WinMiser Shareware.  The WinMiser Shareware source files will be copied to the specified destination path.  You may specify any valid path name.

The initial default path is C:\WinMiser.  After WinMiser Shareware has been installed, the current WinMiser Shareware path is the default path.

If the specified path does not exist, you will be prompted to add the new path.  If the specified path is invalid, you must enter a valid destination path.

Select the Continue button to accept the specified Destination Path and proceed with the installation.

Select the Back button to change the source path.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - SYSTEM.INI Backup File

The WinMiser Shareware Setup SYSTEM.INI Backup File dialog is used to specify the file name to be used to save a backup copy of your current SYSTEM.INI file.  The WinMiser Shareware setup program modifies your Windows SYSTEM.INI file.  In case WinMiser Shareware fails to operate properly, it is helpful to have a backup copy of your current SYSTEM.INI file.

By default, WinMiser Shareware will create a file named SYSTEM.WMI in your Windows directory.  You may use this dialog to change the default value to any valid file name.

WinMiser Shareware will display a message if the specified file already exists.  You may ignore this warning and reuse the existing file or specify a new file name.

Select the Continue button to accept the specified Backup File Name and proceed with the installation.

Select the Back button to change the destintation path.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - Installation

The WinMiser Shareware Setup Installation dialog is used to verify the installation options before proceeding.  The selected source and destination paths and SYSTEM.INI backup file name are shown at the bottom of the dialog.

Select the Continue button to proceed with the installation.  If the source and destination paths are different the WinMiser Shareware files will be copied.  In either case, the setup program will copy the current SYSTEM.INI and make the necessary changes to support WinMiser Shareware.

Select the Back button to change either of the selected paths.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - Program Group

The WinMiser Shareware setup Program Group dialog is used to specify if you wish to create a WinMiser Shareware program group.  The WinMiser Shareware program group can be used to execute the WinMiser Shareware programs.  Check the box to add the WinMiser Shareware program group.  Uncheck the box to proceed without adding the WinMiser Shareware program group.

The following programs will be added to the WinMiser Shareware program group.

WinMiser Shareware
WinMiser Shareware Help
WinMiser Shareware Uninstall
WinMiser Shareware ReadMe

Select the Continue button to proceed with the installation.

Select the Exit button to exit the WinMiser Shareware setup program without installing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Setup - Completion

Once the WinMiser Shareware setup process is complete, you have the option to restart Windows.  Because WinMiser Shareware requires changes to the SYSTEM.INI file, Windows must be restarted before you can use WinMiser Shareware.

Select the Restart Windows button to restart Windows from the setup program.

Select the Return to Windows button to exit the setup program and return to Windows.

Select the Help button to display this Help panel.


System Resources - Index

Introduction
Technical Background
Problems
Monitors
WinMiser Pro Statistics
Problem Identification
Problem Resolution

Note:

This tutorial was adapted from the System Resources tutorial provided with WinMiser Pro.


System Resources - Introduction

Microsoft Windows Version 3.1 is a remarkable PC operating system in both functionality and in user acceptance.  However, there are a number of problems with Windows memory management.  In particular, Windows is vulnerable to problems with insufficient "System Resources".  Systems which experience these problems may be unable to launch new programs, or they may behave erratically.

WinMiser Pro includes features that help identify and resolve problems with System Resources.  While WinMiser Pro may not solve all problems with System Resources, it can explain why you are having these problems.  This information is critical when trying to resolve system problems.

The following sections explain what Windows System Resources are, why they are a limiting factor, and what can be done to avoid problems with System Resources.


System Resources - Technical Background

System Resources are common memory areas that are shared by Windows based applications.  WinMiser Pro refers to these shared memory areas as the Windows Local Memory areas.

Most products that monitor System Resources identify two memory areas; User and GDI.  In reality there are six Windows Local Memory areas:

User Memory
User String Memory
GDI Memory
GDI String Memory
Menu Memory
Menu String Memory

Windows based applications store objects in these memory areas in order to communicate with the Windows operating system.  These memory objects are allocated and released using Windows API calls.  The System Resource memory objects contain information about display windows, menus, drawing tools, and common character strings.

The System Resource memory areas can be a limiting factor for the Windows operating system because by design they are all smaller than 64K bytes.  Applications that uses a large portion of these limited memory areas can prevent other applications from executing or working properly.  It is up to the application designers and developers to build applications that conserve System Resource memory.


System Resources - Problems

Based on the experience of many Windows users, limited System Resources is a major problem.  The root cause of System Resource problems stems from applications allocating a disproportionate amount of memory from these areas.  This can either be by system design or through leakage.

Application Design Problems

Application designers are always faced with performance tradeoffs.  In many cases, you can use more resources such as memory to improve the responsiveness of your application.  If there is no noticeable penalty for the use of more resources, they are usually taken.

In the case of System Resources, there is no inherent way within Windows to track how much System Resource memory each module is allocating.  This leads designers to use more memory than they should.

In some cases, the additional memory is used because of ignorance.  Without feedback on how memory is being used, the designer may use some technique which consumes large blocks of memory.  If System Resource usage was known, the application designer could make changes to limit the application's memory usage.

In other cases, the additional memory is used by design.  The designer is aware of the cost of certain techniques but feels safe that users will not know that his application is the cause of System Resource problems.  If System Resource usage was known, the application user could identify this application as the problem.

Memory Leakage Problems

Application developers know that their applications should return all allocated memory back to Windows.  If the application fails to return this memory, it is considered to be leaked.

Developers have a number of tools at their disposal to identify and remove memory leakage from their applications.  Windows even provides a special version of its operating system to help with this process.

Even with all of this help, there are a large number of applications that leak System Resources.  While it is not a deliberate misuse of these limited memory areas, it can still cause problems with the Windows environment.

If all applications were built with knowledge of their System Resource use, there would be far fewer problems with System Resources.  Thus the real problem with the System Resource memory areas is not their 64K byte limit.  Rather it is the lack of Windows Local Memory usage accountability that leads to these memory areas being depleted.


System Resources - Monitors

The problems associated with insufficient System Resources is well known.  This has lead to the creation of a number of System Resource monitoring products.

These products typically report on the percentage of free System Resources.  They either show one number called System Resources, or two numbers called User and GDI.  They do not identify the User String, GDI String, Menu, or Menu String memory areas.

The reason that other monitors only show User and GDI memory usage is that these are the easiest statistics to retrieve.  Windows provides an API called "SystemHeapInfo".  This function returns the percent of free memory in the User and GDI memory areas.  Most monitors simply report the numbers provided by this function.

The free User memory percentage returned by this function is actually the lowest free percentage from the User, Menu, and Menu String memory areas.  The statistics for these three memory areas are combined into one value because under Windows 3.0, the memory objects for all three areas were contained in the User memory area.

One of the major changes with Windows 3.1 was the division of the User memory area into the User, Menu, and Menu String memory areas.  This helped to reduce the demand on the User memory area, thus allowing more Windows based applications to run at the same time.  Because the SystemHeapInfo API must work under Windows 3.0 and 3.1, Microsoft simply combined the statistics from these three areas into one number.

The Free System Resources statistic that is displayed in many Windows Help About dialogs is simply the lower of the User and GDI free memory percentage.

Notice that these statistics fail to report on the User String and GDI String memory areas.  While both of these areas tend not to be highly utilized, unexplainable problems can still appear if an application is unable to allocate memory from either of these shared memory areas.


System Resources - WinMiser Pro Statistics

WinMiser Pro has been designed to provide detailed usage statistics about all six Windows Local memory areas.  This not only includes information on free memory but also the usage, overhead, and total memory.  For each of these categories, the byte counts are provided as well as the percentages.

These improved statistics provide a greater level of detail than other monitors that simply use the SystemHeapInfo API.  Because of this, WinMiser Pro's statistics will not match those provided by other monitors.  This is not a problem, just a difference in reporting philosophy.

In most cases the difference between WinMiser Pro's statistics and other monitors will be minimal.  However, in some cases they can be quite large.  For example, assume that the User memory areas is 85% free and the Menu memory area is 70% free.  WinMiser Pro will report User at 85% free while other monitors will report User at 70% free (the lower of User and Menu).

One of the major features of WinMiser Pro is the ability to show how much Windows Local memory each module is responsible for.  This provides the first accurate way to determine which modules are allocating a large percentage of the available memory.  Without WinMiser Pro, you can only guess or have a vague feeling that a module is a large user of System Resources.

With WinMiser Pro, developers and users can know how much Windows Local Memory their applications require.  Without this knowledge, users couldn't complain to developers about "piggy" applications.  Now they can.


System Resources -  Problem Identification

WinMiser Pro has the ability to help you identify problems with insufficient System Resources.  This includes help with Memory Usage, Module Load Failures, Memory Allocation failures, and Memory Leakage.

Memory Usage

WinMiser Pro contains a free memory summary window as well as a detailed memory usage window for each of the six Windows Local Memory areas.  The memory summary window provides a quick overview of available memory in each area.  The detail memory usage windows provide more detailed information for a specific memory area.  Also, WinMiser Pro can be configured to show how much Windows Local Memory each module has allocated.

These display windows can be used to prevent and resolve insufficient System Resource problems.  They can also be use to identify modules with large System Resource requirements.

Module Load Failures

WinMiser Pro can be configured to generate an alert when a module fails to load.  Once enabled, an alert will be generated anytime a module fails to load due to the System Resource value being below 10% free.  When this happens, the alert will show which of the Windows Local Memory areas was the cause of this problem.

Memory Allocation Failures

WinMiser Pro can be configured to generate an alert when an attempt to allocate memory from a Windows Local memory area fails.  Once enabled, an alert will be generated anytime the System Resources are depleted to the point where memory allocation fails.  When this happens, the alert will show which of the Windows Local Memory areas was the cause of this problem.

Memory Leakage

WinMiser Pro can be configured to generate an alert when a module fails to return all Windows Local Memory that it has allocated.  Once enabled, an alert will be generated anytime WinMiser Pro has determined that an exiting module has leaked memory.  When this happens, the alert will show which module leaked the memory and how much memory it leaked from each of the Windows Local Memory areas.

Refer to the Memory Leakage Tutorial for more information on memory leakage.


System Resources - Problem Resolution

Once you have determined you have a problem with System Resources, you can use WinMiser Pro to help resolve the problem.  The following lists possible solutions:

Release Leaked Memory

WinMiser Pro has the ability to track Windows Local Memory usage by module.  This allows WinMiser Pro to be able to identify when an exiting module fails to return all memory allocated from the Windows Local Memory areas.  This condition is commonly called leakage.

You can use the Memory Leakage Window to determine if any memory has been leaked.  If so, select the modules listed on this window to release any leaked memory.

Refer to the Memory Leakage Tutorial for more information on memory leakage.

Close High Usage Applications

If freeing leaked memory does not solve your problem, you can close applications which are using a large amount of System Resources.  To do this use the following steps:

First, determine which of the six Windows Local Memory areas is over utilized.  If you have enabled the WinMiser Pro alerts for Module Load failures or Windows Local Memory allocation failures, these alerts will display the over utilized memory area.  See the Alert Configuration Details Dialog for more information on enabling these alerts.

Next, display the memory usage window for the problem memory area.  If you have enabled memory usage by module for this memory area, this window will show how much memory each module has allocated.  See the System Resources Configuration Dialog for more information on enabling this display feature.

Finally, use this display to find which modules are using significant amounts of memory from the problem area.  If possible, shut down the application(s) associated with these modules.

While this may not be the best solution, at least you can use WinMiser Pro to select the modules you can close down to provide the most memory relief.  This is far better than the guess based techniques that must be used without WinMiser Pro.

Replace or Upgrade High Usage Applications

If you find a module that is using a disproportionate amount of memory you can either upgrade this application or replace it.  While it may not help, you can at least try to work with the application developer to remedy this usage problem.  Without WinMiser Pro, it is difficult for developers to determine if they over using Windows System Resources.  Now, you have the information to work with the developers to correct this type of problem.

You can also use WinMiser Pro to analyze an application before you buy or use it.  If you find that it uses a large amount of Windows System Resources, you should include this in your decision to purchase this product.

Upgrade to Windows 95, Windows NT, or OS/2

If you really need to run all of your applications at the same time and there is no way to upgrade these products, then you should consider upgrading to a new operating system.  At this time Windows 95, Windows NT, and OS/2 all provide more System Resources.  Converting to any one of these operating systems should correct problems with insufficient System Resources.

Use a System Resources Expansion Product

If all of these options fail you can purchase a product that increases the size of the Windows Local Memory areas.  There are a number of products on the market that provide this capability.

HOWEVER, be aware that these products alter the way Windows works.  In many cases they may cause unexplainable application failures.  Even if they do not cause failures, they can add a great deal of processing overhead to your system.  Be sure to test all of your applications while using a System Resource expansion product before using this type of solution.

Also note that WinMiser Pro may not be compatible with these products.  In most cases, the techniques used by these expansion products prevent WinMiser Pro from working.  Without WinMiser Pro, you will not get the alerting and usage capabilities.


GDI Memory Offload - Index

Introduction
GDI Background
GDI Memory Depletion
WinMiser Pro Support


GDI Memory Offload - Introduction

One of the limiting features of Windows 3.1 is System Resources.  System Resources are shared memory areas used by all Windows based programs to display windows, menus, text, and graphics.

The three most important System Resource areas are called User, Menu, and GDI.  These areas or heaps are important because they are limited to 64K bytes and are commonly depeleted.  Once one of these memory areas is depleted, new applications can not be started and existing applications behave erractically.

Of these three heaps, the one that tends to give the most problems is GDI or Graphics Device Interface.  Starting with Version 1.1, WinMiser Pro has the ability to move specific GDI objects from the standard GDI heap to a different memory area.  This memory movement or offload has the effect of increasing the amount of usable GDI memory.  This in turn allows Windows to run more GDI intensive programs concurrently.


GDI Memory Offload - GDI Background

GDI memory usage is a mystery to most people but in reality it is fairly straight forward.  Basically, Windows based applications create and use GDI memory objects to display text and graphics on output devices such as CRTs and printers.

The most important GDI object is called the Device Context or DC.  A DC can be thought of as the canvas on which the application does its drawing.  It is a logic view of a physical device such as a CRT.

The other GDI objects are Pens, Brushes, Palettes, Fonts, Regions, amd Bitmaps.  These are also logical views of a physical object.  For example, a logical pen is given attributes such as color, width, and pattern.  These attributes are logical because they have nothing to do with any specific output device.

It is only when one of these logical objects gets "selected into" or "realized" into a DC for a specific device that the object become real.  For example, drawing a blue line on the CRT requires the CRT to know how to draw a line with a blue pen.  When the logical blue pen is selected into a DC for the display, the display driver stores the necessary information to be able to draw blue lines.


GDI Memory Offload - GDI Memory Depletion

The original concept of GDI objects was that Windows would supply many of the drawing object required by Windows based applications.  When an application needed to use a non-standard object, it was supposed to create the object, use it, and delete it.  If used this way GDI memory would never be depleted.

However, application developers in search of better performance have changed this.  Now many applications start by creating their own set of GDI objects and leave them allocated for the entire duration of the application's execution.  If you execute enough applications that use these "long term" GDI onjects, you will quickly run out of GDI memory.


GDI Memory Offload - WinMiser Pro Support

There are two ways WinMiser Pro can help with GDI memory depletion; Memory Leakage Detection and Memory Offload.

WinMiser Pro has the ability to determine when applications fail to return all of the GDI memory they allocated.  This is called leakage.  Once detected, WinMiser Pro can return this memory to GDI either manually or automatically.  This technique will help you keep Windows active longer.  See the tutorial on Memory Leakage for more information on this feature.

Starting with Version 1.1, WinMiser Pro has the ability to offload memory for specific GDI objects from the GDI heap to a different memory area.  This technique works with the standard GDI logic to place memory used by the graphics drivers outside of the GDI heap.  The technique used by WinMiser Pro has almost no overhead and is effective on all systems.

The resulting savings on most systems is between 10% and 30% reduction in GDI memory usage when at peak load.  This yields a significant amount of additional GDI memory for use by other applications.  In many cases with this enhancement, the other System Resource areas (User or Menu) will be depleted before GDI.


WinMiser Shareware Uninstall - Index

Introduction
SYSTEM.INI Backup
Removal
Completion


WinMiser Shareware Uninstall - Introduction

The WinMiser Shareware uninstall program can be used to remove WinMiser Shareware from your system.  The uninstall process consists of the following steps:

Deleting the WinMiser Shareware files from the WinMiser Shareware directory and removing the directory if empty.

Modifying the Windows SYSTEM.INI file.

Deleting the WinMiser Shareware program group from the Program Manager.

The current SYSTEM.INI file is backed up to SYSTEM.WMU, and the SYSTEM.INI file is modified to remove support for WinMiser Shareware.  You may change the default SYSTEM.INI backup file name.

The WinMiser Shareware uninstall program will display a message box if it encounters any errors during the uninstall process.

Select the Continue button to proceed with the uninstall process.

Select the Exit button to exit the WinMiser Shareware uninstall program without removing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Uninstall - SYSTEM.INI Backup File

The WinMiser Shareware Uninstall SYSTEM.INI Backup File dialog is used to specify the file name to be used to save a backup copy of your current SYSTEM.INI file.  The WinMiser Shareware uninstall program modifies you Windows SYSTEM.INI file.  In case the WinMiser Shareware uninstall program fails to operate properly, it is helpful to have a backup copy of your current SYSTEM.INI file.

By default, WinMiser Shareware will create a file named SYSTEM.WMU in your Windows directory.  You may use this dialog to change the default value to any valid file name.

WinMiser Shareware will display a message if the specified file already exists.  You may ignore this warning and reuse the existing file or specify a new file name.

Select the Continue button to accept the specified Backup File Name and proceed with the uninstall process.

Select the Back button to return to the Welcome dialog.

Select the Exit button to exit the WinMiser Shareware uninstall program without removing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Uninstall - Removal

The WinMiser Shareware Uninstall Removal dialog is used to verify the uninstall options before proceeding.  The WinMiser Shareware directory and SYSTEM.INI backup file name are shown at the bottom of the dialog.

Select the Continue button to proceed with the uninstall process.  The uninstall program will copy the current SYSTEM.INI and make the necessary changes to remove WinMiser Shareware.  It will also delete all WinMiser Shareware files and remove the WinMiser Shareware Group from the Program Manager window.

Select the Back button to change the backup file name.

Select the Exit button to exit the WinMiser Shareware uninstall program without removing WinMiser Shareware.

Select the Help button to display this Help panel.


WinMiser Shareware Uninstall - Completion

Once the WinMiser Shareware uninstall process is complete, you have the option to restart Windows.  Because WinMiser Shareware requires changes to the SYSTEM.INI file, Windows must be restarted to remove all of the WinMiser Shareware drivers.

Select the Restart Windows button to restart Windows from the uninstall program.

Select the Return to Windows button to exit the uninstall program and return to Windows.

Select the Help button to display this Help panel.