Electrical computers and digital processing systems: memory – Address formation – Address mapping
Reexamination Certificate
1998-11-13
2002-10-01
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: memory
Address formation
Address mapping
C711S173000
Reexamination Certificate
active
06460126
ABSTRACT:
This invention relates to a system and method for managing computer resources in cooperation with an operating system, and more specifically to a system and method capable of reducing limitations on resources, particularly certain GDI and USER resources, under Microsoft Windows.
BACKGROUND OF THE INVENTION
Computers, including personal computers, perform their functions by processing instructions, in the form of binary numbers, which can be interpreted by the central processing unit (CPU) of the machine. Programs written in assembly language use these instructions in a form that is easier for programmers to work with than binary numbers, and the resulting code is “assembled” into machine language for use by the computer. Programs written in higher level languages are “compiled” into machine language, and in this way, many different programs written in different languages can run on one machine. It was recognized early in the development of computer technology that many programs would require or could benefit from a common set of services, such as routines for handling input and output, managing files, interfacing with the user, and in some circumstances, multitasking two or more programs. These and other services are commonly provided by an operating system (e.g. DOS) or an operating environment acting in cooperation with an operating system. An important function of an operating system or environment is to manage resources available to or in use by programs running on the computer. In this context, a resource is any data object allocated to or from a limited memory space designated for use by the operating system or environment.
The Microsoft Windows® operating environment has a history of greater than ten years. It was originally designed to run on the Intel 8088 and 80286 microprocessors, both of which are 16-bit microprocessors. By way of background, the largest number representable with 16 binary bits is 65,536, and hence the largest amount of memory that is directly addressable at one time by a 16 bit operand is 64K (64×1024, or 65,536). As a consequence of the design of the processors, although more memory is available to these microprocessors through a segment-mapping concept, all system memory used in a computer utilizing an 8088 or 80286 microprocessor is divided into 64K chunks known as segments.
Although version 3 of Microsoft Windows® is optimized to use certain features of the Intel 80386 microprocessor (and later processors), if available, the original memory scheme was carried over, largely for compatibility reasons. Other processing and addressing modes are also available in these newer processors, most notably protected mode, which can handle 16 and 32 bit programs, and permits direct addressing of up to 4 GB of memory. In the version 3 releases of Windows, the primary modules of the operating environment continue to be 16-bit programs, although the 80386, 80486, and Pentium processors can accommodate 32-bit programs.
The three primary modules of Windows® 3.1 are KERNEL, which provides the lowest level of services to application programs; USER, which implements the windowed multitasking user interface; and GDI (Graphics Device Interface), which implements a device-independent methodology for displaying graphics on a screen or printer.
The USER module maintains its data in four 64K segments: the Window segment, the Menu segment, the Menu Atom (or Menu String) segment, and the Global Atom (or USER Atom) segment. The Window segment contains a variety of data defining window classes and characteristics. The Window segment is also the default data segment for the USER module, and as a result tends to contain a wide assortment of data. When the USER module requires temporary data space to perform an operation, it frequently allocates such space out of the Window segment. The Menu and Menu Atom segments are reserved specifically to hold data pertaining to drop-down menus, which are maintained by USER on behalf of the application programs that use them. The Global Atom segment exclusively contains alphanumeric strings registered by applications; it rarely contributes to resource shortages.
The GDI module maintains its data in two 64K segments: the GDI Object segment and the GDI Atom segment. The GDI Object segment contains information on pens, brushes, fonts, device contexts, and other items contained in data structures which can frequently be relatively large. The GDI Atom segment contains only font names; since it holds only a small amount of information, it rarely contributes to Windows® resource shortages.
While the amount of available physical memory on computers running Windows® has increased dramatically over the years, from 2M or 4M several years ago to 16M and higher today, and the sophistication of Windows® applications has also increased, the size of the data areas maintained by USER and GDI has remained constant. Thus, as systems have been experiencing higher and higher demand for resources, the availability of resources has begun to become more and more scarce.
The resource shortage problem has been recognized and solutions have been proposed. The product WinProbe by Quarterdeck (1994) attempts to solve the problem of GDI “resource leaks.” WinProbe includes a component that tracks the task ownership of any GDI resources allocated by application programs. For this purpose it adds several bytes to the size of each such resource. Upon the user's direction or at a settable interval, WinProbe will attempt to clean up any resources that exist for tasks that are no longer running. This releases unused resources, but has several serious drawbacks. By increasing the size of each resource, WinProbe tends to aggravate resource shortages in one way while attempting to mitigate them in another way. Furthermore, resources cannot always safely or accurately be associated with the task context in which they were allocated. In Windows® 3.1, a library unassociated with the running task may allocate GDI resources; in such a case, it would be inappropriate and potentially unstable to free the resources at the time the task exits. Moreover certain resources may be allocated by a task and then placed into the system clipboard; these clipboard resources are required to remain allocated after the task has exited and it would be improper to free them. Finally, WinProbe requires user intervention or an elapsed time period before cleaning up unused resources.
Another prior art method for reducing GDI resource use is performed by the AnyView Professional product (Binar Graphics, 1994). AnyView relocates a certain class of object that GDI normally allocates in its own object segment into AnyView's own private memory. However, the objects that AnyView can deal with in this way are limited to objects for which GDI is custodian but does not need to access directly. This class includes primarily device-brush objects that are created by the display driver in memory allocated by GDI in the GDI Object segment and used only by the display driver. This solution does not sufficiently reduce resource load by itself.
The AnyView program also attempts to resolve resource scarcity by maintaining one of the system resource segments on a per-process basis. AnyView recognizes that the contents of the USER Menu segment represents a limited variety of data pertaining exclusively to drop-down menus, and that such data is primarily useful to the process that caused it to be created. Therefore, AnyView creates for each running application a separate copy of the USER Menu segment; the appropriate segment is activated whenever a different application is executed. AnyView's methodology is effective, but only for the USER Menu segment. It cannot be applied to the USER Window segment because that segment contains a large amount of data that cannot be associated with a single process; that data is required by USER to implement the windowing system. Moreover, though menus are typically accessed solely by their owning applications, they must be visible to other applications. This is mandate
Daub Jonathan A.
Spilo Michael L.
Courtenay III St. John
Hamaty Christopher J.
Networks Associates Technology Inc.
Silicon Valley IP Group, LLC.
Zilka Kevin J.
LandOfFree
Computer resource management system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Computer resource management system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Computer resource management system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2999777