Background of the Invention
1. Field of the Invention
The present invention generally relates to a computer method and apparatus for modifying the allocated memory space assigned to a program running under control of an operating system. More particularly, the invention relates to a computer method and apparatus for expanding the memory space presently allocated to a program running under WINDOWS.RTM. 95 or NT (registered Trademark of Microsoft Corporation)operating systems while requiring a zero footprint in programs running under WINDOWS.RTM. 95 or NT operating systems, or their like.
2. Description of the Related Art
There are instances, such as in a debugging program, that it is desirable to add instructions to a program running under WINDOWS.RTM. 95 and NT operating systems, or their like. However under the architecture of WINDOWS.RTM. 95 and NT operating systems, or their like, a program is allocated memory space in memory referred to as a virtual memory. Further to allow multiprocessing of programs resources are allocated to a program which are referred to as a virtual processor. The virtual processor includes a series of programmable registers, including but not limited to programmable register commonly referred to as registers eip, esp, eax, ebx and ecx which are used by the operating system in executing the program. The state of the programmable registers is commonly referred to as the context of the program.
WINDOWS.RTM. 95 and WINDOWS.RTM. NT operating systems, or their like, includes a "Just In Time" (JIT) debugging facility which detects fatal error occurring in programs presently being processed. Upon the occurrence of a fatal error JIT will stop the program and collect data about the status of the program and the virtual processor running the program experiencing the fatal error (hereinafter referred to as a target program). The user has no choice but to exit the target program thereby losing any updated data that had not previously been stored.
There are debugging programs designed to prevent errors within WINDOWS.RTM. 95 and WINDOWS.RTM. NT programs from causing the target program from being immediately terminated. These debugging programs achieve this end by intercepting all errors and exceptions within the running programs, which in turn requires code associated with the debugging program (a debugging footprint) to be loaded into all programs before the programs are executed. The loading of the code associated with the debugging programs has been accomplished by the use of virtual device drivers (Vxd) and by the use of system hooks. Although the hooks pose the greatest risk, debugging programs have the drawback that they must load code into every program and the code might actually cause malfunctions in the programs that they are supposed to protect.
It is known that additional code can be loaded into a program by the library function (LoadLibrary) which implicitly expands the program's virtual memory. However the library function requires interaction with the program and where the program has incurred a fatal error, the use of the library function poses unknown risk one of which could be a system shutdown destroying not only the data of the crashed program but of all other program being run under the operating system.
Summary of the Invention
It is an object of the present invention to provide a computer method and apparatus that does not require a computer footprint in the programs running under WINDOWS.RTM. 95 or WINDOWS.RTM. NT, or their like, to facilitate the expansion of the memory space allocated to such a program.
It is another object of the present invention to provide a computer method and apparatus that do not require a computer footprint in the programs running under WINDOWS.RTM. 95 and WINDOWS.RTM. NT, or their like, and which prevent errors within such a program from causing that program from being immediately terminated.
It is another object of the present invention to provide a computer process and apparatus that do not require any action by the program's original code for adding memory space to the program's virtual memory.
Briefly the invention is an apparatus and computer method for controlling the operation of a computer running under an operating system such as WINDOWS.RTM. 95 and WINDOWS.RTM. NT operating system, or the like, that do not require a footprint in the programs running under the operating system. A program, hereinafter referred to as CrashGuard.TM., is stored and installed in a computer thereby being established as the "debugger" in the user's systems. Once so established CrashGuard.TM. may be stored elsewhere then the computer memory. Whenever a fatal error occurs Just in Time debugging facility of the WINDOWS.RTM. 95 and WINDOWS.RTM. NT operating system, or their like, will suspend the target program, will load CrashGuard.TM. as the designated "debugger" into memory space not allocated to the target program, identifies the target program to CrashGuard.TM. and executes CrashGuard.TM.. CrashGuard.TM. will cause additional memory space to be added to the virtual memory of the target program. Thereafter CrashGuard.TM. will store into the additional memory space a routine that will allow the user to take such actions as to execute a Save or Save As command thereby not losing data that would otherwise have been lost.
An advantage of the invention is that CrashGuard.TM. need not be loaded into memory unless needed.
Another advantage of the invention is that memory space is not used to store a debugger footprint in any program stored in memory.
Brief Description of the Drawings
The invention will be described with respect to the particular embodiments thereof and references will be made to the drawings, in which:
FIG. 1 illustrates a computer system embodying the present invention;
FIG. 2 illustrates a computer memory wherein a debugger footprint is stored in every program;
FIG. 3 illustrates a computer memory without a debugger footprint being stored in every program;
FIG. 4 illustrates a computer memory wherein newly allocated memory space has been allocated to program 2 by the invention; and
FIG. 5 is a flow chart illustrating the operation of CrashGuard.TM..
FIG. 6 is an illustration showing the interaction between the operating system, the program's virtual processor and memory and CrashGuard.TM..
Detailed Description of the Invention
Referring to FIGS. 1 and 6, a computer system is shown comprised of a mouse 13, a display 11 and a keyboard 12 and a computer 10 which includes a floppy disk drive 16, a hard disk drive 17 and a random access memory 15 (not shown in FIG. 1). The computer 10 is operating under the control of WINDOWS.RTM. 95 or WINDOWS.RTM. NT operating system 32. Under the architecture of WINDOWS.RTM. 95 and WINDOWS.RTM. NT operating systems 32, or their like, a program is allocated memory space in memory referred to as a virtual memory 30. Further to allow multiprocessing of programs resources are allocated to a program which are referred to as a virtual processor 31. The virtual processor 31 includes a series of programmable registers, including but not limited to programmable register commonly referred to as registers eip, esp, eax, ebx and ecx which are used by the operating system 32 in executing the program. The state of the programmable registers is commonly referred to as the context of the program or the program's context.
WINDOWS.RTM. 95 and WINDOWS.RTM. NT operating systems 32, or their like, includes a "Just In Time" (JIT) debugging facility which detects fatal error occurring in programs presently being processed. Upon the occurrence of a fatal error JIT will stop the program (hereinafter referred to as the target program) and then collects data about the status of the target program and the virtual processor 30 (i.e., the program context) running the program experiencing the fatal error.
Disk 14 is a magnetic disk widely used in the computer industry to store programs and data. Disk 14 has recorded thereon a debugging program, hereinafter referred to as CrashGuard.TM. 33. When disk 14 is inserted into floppy disk drive 16, computer 10 has the ability to coact with CrashGuard.TM. 33 stored upon disk 14 so as to control the operation of computer 10. Computer 10 may transfer CrashGuard.TM. 33 to be stored onto hard disk drive 17 or into the random access memory (RAM) 15 of computer 10 thereby allowing disk 14 to be removed from the floppy disk drive 16. While CrashGuard.TM. 33 was described as being recorded upon a floppy disk, CrashGuard.TM. 33 may be recorded onto any recording medium (i.e. magnetic tape, magnetic cards, optical disc or, tape or card, flash memory units, semiconductor memories) that may be used as a memory unit for a computer system running under WINDOWS.RTM. 95 or WINDOWS.RTM. NT operating system 32.
FIG. 3 illustrates the RAM 15 having stored therein the operating system 32 stored in virtual memory 20, programs 1 through N stored in virtual memories 21, 22, 23 and 24 and unallocated memory space 25.
FIG. 2 illustrates RAM 15 having stored therein the operating system stored in virtual memory 20, program 1 through N each having a debugger footprint 21a through 24a stored in virtual memories 21, 22, 23 and 24 and unallocated memory space 25.
When CrashGuard.TM. 33 is first installed in computer 10, CrashGuard.TM. 33 is designated as the "debugger" associated with the JIT debugging facility of WINDOWS 95.RTM. and WINDOWS NT.RTM. operating system 32. CrashGuard.TM. 33 acts as a tool within the WINDOWS.RTM. 95 or WINDOWS.RTM. NT operating system 32 and when called by JIT is stored in its own virtual memory of RAM 15 and thereby isolated from the virtual memory for the target program. As such CrashGuard.TM. 33 can modify target program instructions stored in the virtual memory 31 for the target program but cannot add additional memory space to the virtual memory 31 allocated to the target program.
Referring to FIG. 5, prior to step 101 JIT will have stopped and identified the target program in response to JIT detecting a fatal error in the target program.
In step 101 JIT calls CrashGuard.TM. 33 into RAM 17 and initiates execution of CrashGuard.TM. 33.
In step 102, CrashGuard.TM. 33 will acquire the identity of the target program.
In step 103, CrashGuard.TM. 33 will execute a memory allocation routine for allocating additional memory space to the target program's virtual memory 31. In order for this to be accomplished, the routine will alter the target program and then resumes execution the target program such that the target program will cause the additional memory space to be allocated to the target program,s virtual memory 31. One such memory allocation routine, hereinafter referred to as "ROUTINE A", will store the status of the target program and the program context (the values in the programmable registers of the virtual processor assigned to the target program). Next, ROUTINE A will identify the location of the first n bytes of the target program stored in the virtual memory 31 assigned to the target program and will copy first n bytes of the target virtual memory 31 to be temporarily stored. It has been noted that the first few bytes in most program are relatively inactive after the programs has been initiated and therefore little damage will be caused to the program if these bytes are temporarily changed. In practice the ROUTINE A only uses the first 11 bytes of the target program.
ROUTINE A will then write the following instructions into the first 11 bytes of virtual memory 31 for the target program:
ROUTINE A then adjusts the target program's context by placing the address of the first instruction of the memory allocation routine in the target program's register eip so that, when the target program resumes execution, the target program will start at the first instruction of that ROUTINE A stored in the target program. The context is adjusted such that register ecx contains the number of additional bytes of memory to be allocated to the virtual memory 31 of the target program and register eax contains the address of the system GlobalAlloc memory allocating function.
ROUTINE A then causes the target program to begin executing the ROUTINE A's instructions which are now a part of the target program. These instructions will store the number of bytes requested, the type of memory request (global) and will then will call the system GlobalAlloc memory allocating function which will allocate the amount and type of additional memory to the virtual memory 31 for the target program. When system GlobalAlloc memory allocating function returns after completing its task, register eax will contain the start address of the additional memory allocated to the virtual memory 31 for the target program. The move instruction is next executed which places an arbitrary value (herein corresponding to the message "A-OK" into register ebx to indicate that the system GlobalAlloc memory allocating function has been completed.
Finally an interrupt 3 (DebugBreak) is issued which is interrupted as a fatal error by the JIT. JIT will stop the target program and will transferred control over ROUTINE A of CrashGuard.TM. which is already loaded into RAM memory 15. ROUTINE A will recognized the interrupt 3 as the DebugBreak scheduled in the memory allocation routine store in the target program.
Upon sensing the occurrence of the interrupt, ROUTINE A checks register ebx for the arbitrary value indicated in the ROUTINE A's instructions stored into the target program. If the arbitrary value in register ebx is correct, Routine A reads and stores the starting address of the added memory from register eax of the virtual processor 30 of the target program and stores it in a programmable register of the virtual processor for CrashGuard.TM.. ROUTINE A then store the original 11 bytes of the target program back into the first 11 bytes of the target program thereby removing ROUTINE A's instructions from the target program and returning the target program to the target program's original state. Optionally the original context of the virtual processor 30 may be restored.
An alternative memory allocation routine, hereinafter referred to as ROUTINE B, modify's the target program's stack to directly call the system GlobalAlloc memory allocating function. ROUTINE B identifies the target program's stack and adds the following to the target program's stack:
ROUTINE B modifies the eip register of the target's virtual processor 30 so as to call the system GlobalAlloc memory allocating function when the target program resumes execution and modifies the esp register (stack pointer) of the target's virtual processor 30 to point to the values that had been added to the target's stack in the target's virtual processor 30. When the target program is caused to resume execution, the target program will cause the system GlobalAlloc memory allocating function to be initiated which will read the type of memory and the amount of memory from the target program stack. The system GlobalAlloc memory allocating function will then allocate the addition type and amount of memory space to the target program's virtual memory 31 and the target program's register eax will have the starting address of the newly allocated memory. However when the system GlobalAlloc memory allocating function is complete it will point to the DebugBreak function and not the target program which would normally be the case. The DebugBreak function is an interrupt 3 which is interrupted as a fatal error by the JIT. JIT will stop the target program and will transfer control over ROUTINE B of CrashGuard.TM. which is already loaded into RAM memory 15. ROUTINE B will recognize the interrupt 3 as the DebugBreak scheduled in the system GlobalAlloc memory allocating function processed by the target program.
Referring to FIG. 4, memory 15 is shown with the additional memory space having been allocated, for example, to Program 2 in accordance with the invention. The amount of additional memory space allocated is arbitrary and should be sufficient to store within the target program that code necessary to perform the desired function of that code. While the application of adding memory to a target program virtual memory was described in a debugging program environment, it will be realized by those skilled in the art of programming for WINDOWS.RTM. 95 or WINDOWS.RTM. NT operating system that the computer method and apparatus herein disclosed may be adapted to add memory to an existing program virtual memory for other purposes than for debugging.
In step 104, CrashGuard.TM. now can effectively write a fix routine into the new memory space of the virtual memory 31 for the target program without overwriting any instructions of the target program. Once the fix routine has been stored into the virtual memory 31 of the target program, CrashGuard.TM. will store the starting address of the fix routine into register eax of the target program's virtual processor 30 and will start the target program to execute instructions starting with the first instruction of the fix routine. In essence the target program is now executing the fix routine as part of the target program.
A fix routine that will restore a degree of control over the target (crashed) program is as follows:
This fix routine will allow the user to save the users data and quit the target program.
For a 16 bit processor the system should be rebooted and for a 32 bit processor it is recommended that the system be rebooted and if not rebooted the program should be exited and the restarted.
While the invention has been particularly shown and described with references to the preferred embodiments thereof, it will be understood by those skilled in the art that changes in form and detail may be made therein without departing from the spirit and scope of the invention. Given the above disclosure of general concepts and specific embodiments, the scope of the protection sought is defined by the following.