FIELD OF THE INVENTION This invention generally relates to function libraries and, more particularly, to identifying function calls that are transmitted from executing application programs to functions in function libraries.

BACKGROUND OF THE INVENTION Many application programs call functions in function libraries (e. g., dynamic link libraries) to perform specialized functions. OPENGL", for example, is a known application program interface that includes a specialized library of graphics functions. Functions in the OPENGL"function library are called by executing programs to render drawings on a computer display device. In a manner similar to many other function libraries, calls to OPENGLTM functions typically include the function name and parameters (a/k/a"arguments") to be processed by the function.

Figure 1 schematically shows an exemplary prior art system 100 that utilizes a function library 102 for controlling computer hardware 104. By way of example, the function library 102 may be the OPENGLTM function library and the hardware 104 may be a display device. More particularly, the disclosed prior art system 100 includes an executing application program 104 that directs function calls to the function library 102. As noted above, the function calls each include the information that is necessary for performing a

desired operation (e. g., rendering drawings on the display device). The function call information may include the name of the function library 102 to receive the call, the name of the function in the designated library 102 to be accessed, and the function parameters. Once the function in the library 102 processes the function parameters, it directs a generic library message to a hardware driver 106. The hardware driver 106 then converts the generic library message into a driver message having the hardware specific instructions for controlling the hardware 104 to perform the desired function.

Programs may malfunction (i. e., have"bugs") when improper calls are made to functions in the function libraries. Such bugs may occur, for example, in programs utilizing the OPENGLTM application program interface. Accordingly, prior to release to desired end users, application programs like that show in figure 1 typically are tested by selected users (often software developers) to determine if the programs operate as intended. Since the tested programs include no source code and include only executable program code to be received by intended end-users (i. e.,"executable software"), the selected users testing the programs cannot review the program source code to locate bugs in the source code. Improper function calls therefore cannot be identified by the testing users.

Even with the assistance of a debugging program ("debugger"), improper function calls that cause programs to malfunction still cannot be located when the improper calls are made by executable software. Specifically, as is known by those skilled in the art, debuggers cannot identify the functions and their parameters when used on the executable software because debuggers require the source code to identify function calls.

Accordingly, it would be desirable to provide a method and apparatus that enables software developers to identify function calls that are directed from executable software to functions in a function library.

SUMMARY OF THE INVENTION In accordance with one aspect of the invention, an apparatus for logging data relating to a call from a program to a function library includes a mechanism for intercepting the call

from the program, and a mechanism for storing the data relating to the intercepted call in a log file. The apparatus also includes a mechanism for transmitting the intercepted call to the function library either while the data is being stored in the log file, or after the data is stored in the log file. In further embodiments, the program is an application program and the function library is a dynamic link library. In other embodiments, the data in the log file includes the name of the function and input parameters to the function. In still other embodiments of the invention, a text program may be executed to display the stored data on a display device.

In accordance with another aspect of the invention, the data is stored in the log file in a predetermined format. That format may be in the form of computer program source code such as, for example, program source code in the"C"programming language. The source code may be compiled to form a log executable file that may be run to display a graphical image on a display device. This aspect of the invention preferably stores the log file in a non- volatile storage medium.

In accordance with other aspects of the invention, a graphical user interface may be provided for entering configuration information relating to the log file. For example, the configuration information may be the name of the function library containing the functions to be logged.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other objects and advantages of the invention will be appreciated more fully from the following further description thereof with reference to the accompanying drawings wherein: Figure 1 schematically shows an exemplary prior art system that utilizes a function library for controlling computer hardware.

Figure 2 illustrates the system architecture for an exemplary computer system on which the disclosed method and apparatus for logging function calls can be implemented.

Figure 3 shows a preferred logging system for implementing the disclosed apparatus

and method for logging function calls.

Figure 4 shows a preferred process that may be utilized by the logging system for logging a function call.

Figure 5 schematically shows a graphical user interface that may be utilized in preferred embodiments of the invention to configure the logging system.

Figure 6 shows a preferred process for displaying a log file.

Figure 7 shows a preferred process for controlling hardware with an executable log file.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS In accordance with a preferred embodiment of the invention, a method and apparatus for logging function calls first intercepts function calls transmitted from an application program to functions in a function library. Once intercepted, information relating to the function calls are stored in a log file (identified as log file 310 in figure 3) that preferably is stored in a non-volatile storage medium. The log file may be formatted as a text file that can be displayed on a display device by a text editing application program. In preferred embodiments, the text in the log file is formatted as source code for compilation by a software compiler to produce an executable code file. The executable code file then may be run to display a graphical image on a display device.

Figure 2 illustrates the system architecture for an exemplary computer system 200, such as an IBM THINKPAD 701@ computer (distributed by International Business Machines of Armonk, New York), on which the disclosed method and apparatus for logging information relating to function calls can be implemented. The exemplary computer system of Figure 2 is discussed for descriptive purposes only, however, and should not be considered a limitation of the invention. Although the description below may refer to terms commonly used in describing particular computer systems, the described concepts apply equally to other computer systems, including systems having architectures that are dissimilar to that shown in Figure 2.

The computer 200 includes a central processing unit (CPU) 205 having a conventional

microprocessor, random access memory (RAM) 210 for temporary storage of information, and read only memory (ROM) 215 for permanent storage of read only information. A memory controller 200 is provided for controlling system RAM 210. A bus controller 225 is provided for controlling a bus 230, and an interrupt controller 235 is provided for receiving and processing various interrupt signals from the other system components.

Mass storage may be provided by known non-volatile storage media, such as a diskette 242, a digital versatile disk (not shown), a CD-ROM 247, or a hard disk 252. Data and software may be exchanged with the computer system 200 via removable media, such as the diskette 242 and the CD-ROM 247. The diskette 242 is insertable into a diskette drive 241, which utilizes a diskette drive controller 240 to interface with the bus 230. Similarly, the CD-ROM 247 is insertable into a CD-ROM drive 246, which utilizes a CD-ROM drive controller 245 to interface with the bus 230. Finally, the hard disk 252 is part of a fixed disk drive 251, which utilizes a hard drive controller 250 to interface with the bus 230.

User input to the computer 200 may be provided by a number of devices. For example, a keyboard 256 and a mouse 257 may be connected to the bus 330 by a keyboard and mouse controller 255. An audio transducer 296, which may act as both a microphone and a speaker, is connected to the bus 230 by audio controller 297. It should be obvious to those reasonably skilled in the art that other input devices, such as a pen and/or tablet and a microphone for voice input, may be connected to computer 200 through bus 230 and an appropriate controller. A direct memory access (DMA) controller 260 is provided for performing direct memory access to system RAM 210. A visual display may be generated by a video controller 265, which controls a display device 270.

A network adapter 290 also may be included to enable the computer system 200 to be interconnected to a network 295 via a network bus 291. The network 295, which may be a local area network (LAN), a wide area network (WAN), or the Internet, may utilize general purpose communication lines that interconnect a plurality of network devices.

The computer system 200 preferably is controlled and coordinated by operating system software, such as the WINDOWS NT'operating system (available from Microsoft Corp., Redmond, WA). Among other computer system control functions, the operating

system controls allocation of system resources and performs tasks such as process scheduling, memory management, networking, and I/O services. The operating system preferable includes an OPENGL application program interface for rendering non-trivial graphical indicia on the display device 270.

Figure 3 shows a preferred system (hereinafter"logging system 300") for implementing the apparatus and method for logging information relating to function calls (hereinafter referred to as"logging function calls"). The system includes an interceptor function library 302 for intercepting function calls directed from an executing application program 304 to a system function library 306 (e. g., a dynamic link library). The interceptor function library 302 includes a plurality of functions having the same names as the functions in the system function library 306. For example, if the system function library 306 includes a function named"shade", the interceptor function library 302 also will have a function named "shade."It is important to note, however, that although the functions in the interceptor function library 302 have the same name as those in the system function library 306, they perform vastly different tasks. Namely, the interceptor functions merely gather and format the data to be stored in the log file 310, and then direct the function call to the system function library 306 for processing. Details of this process are discussed below with reference to figure 4.

The logging system 300 further includes a logging function library 308 for storing the formatted data in the log file 310, and a configuration utility 312 for configuring the logging system 300 (discussed below). The logging system 300 preferably is utilized with hardware 314 and a hardware driver 316 for driving the hardware 314. In preferred embodiments, the executing application program 304 is a graphical drawing program such as, for example, Softlmage" (distributed by Microsoft Corp.). In addition, the system function library 306 preferably is an OPENGI : M function library, and the hardware 314 preferably is a computer display device. The logging function library 308, intercept function library, and configuration utility 312 preferably are loaded into the non-volatile memory of the computer system 200 when the logging system 300 is installed.

Figure 4 shows a process that may be utilized by the logging system 300 for logging a

function call. The process may be repeated each time a function call is made by the application program 304. The process begins at step 400 in which it is determined if the system has been configured to log function calls. The logging system 300 must be configured at least once before it can log function calls. Once configured, designated function calls within the computer system 200 are logged each time the application program 304 executes.

In some embodiments, logging (i. e., the process of storing function calls in a log file 310) may be turned"off'to stop logging any time after the system is configured. Similarly, logging may be turned"on"again at any subsequent time by either re-configuring the system, or turning the logging function on via a graphical user interface (discussed below).

The configuration information may be entered by a user via a graphical user interface (identified as GUI 500) that is a part of the configuration utility 312. Information entered into the GUI 500 preferably is stored in the operating system registry (present in the Microsoft NTTM operating system), which includes the operating system configuration and computer system 200 set-up data. Figure 5 schematically shows one such graphical user interface that may be utilized in preferred embodiments of the invention. The GUI 500 includes several fields for enabling a user to enter configuration information into the system. Among the fields in the GUI 500 is a"NAME OF FUNCTION LIBRARY"field 502 for entering the name of the function library to be logged, a"NAME OF EXECUTABLE TO LOG"field 504 for entering the name of the application program 304, and a"LOCATION OF LOG FILE" field 506 designating the name of the resulting log file 310 and a path statement identifying the intended storage location of the log file 310 within the computer system 200. In preferred embodiments, the log file 310 is stored in the hard disk 252.

Once configured, the logging system 300 logs all function calls from the designated application program 304 to a designated function library each time the application program 304 executes. Accordingly, each subsequent time the program 304 runs, the logging system 300 either overwrites the existing log file 310 in the hard disk 252, or creates another log file 310. To that end, an"OVERRIDE"field 508 also may be included in the GUI 500 that enables the system to either overwrite an existing log file 310 for the same function library, or to create a new log file 310 in addition to the existing log file 310. Each new log file 310

preferably is stored in the same directory as the existing log file 310 with a name that distinguishes it from related earlier created log files 310 created for the designated program 304. For example, each succeeding log file 310 for a specified program 304 may be named XXX1, XXX2, XXX3,... XXXN, where N is an integer indicating the number of times the program 304 has been logged. The"OVERRIDE"field 508, for example, may be a box or button that, when selected, alternatively displays"OVERRIDE YES"or"OVERRIDE NO." The override button preferably is defaulted to override existing log files 310 because of the large amount of memory (e. g., ten megabytes in many graphical applications) that may be required for such files.

The GUI 500 also may include additional buttons such as a"FUNCTIONS ONLY" button 510 for logging the function names only and not the input parameters required for the functions. In the preferred embodiment, the system is set to default to logging both the functions and their input parameters. The GUI 500 also may include a"LOGGING ON/OFF' button 512 to turn the logging function on or off.

Returning to step 400, if the system has not been configured or logging is off, then the process skips to step 406 (discussed below). Conversely, if the system has been configured and logging is on, then the process continues to step 402 in which the intercept function library intercepts a function call transmitted from the program 304 to the system function library 306. Calls are intercepted because during the configuration step, the configuration utility 312 both assigns the name of the system function library 306 to the intercept function library, and renames the system function library 306. It should be noted, however, that the configuration utility 312 subsequently renames the system function library 306 to its initial name when logging is turned off. Accordingly, when logging is on, function calls (which include a header having the name of the function library having the function) locate and execute the function in the intercept function library because such function library name matches the function library name in the function call header.

The function in the intercept function library that receives the function call (i. e., the "receiving function") consequently gathers the required data from the function call and formats the data into a character string in a predefined format. More particularly, when the

"FUNCTION ONLY"button 510 in the GUI 500 is not selected, the receiving function reads the call, which includes, among other things, the name of the function and the input parameters to that function. The function name and its parameters thus are copied into the character string and transmitted to the logging function library 308. Conversely, when the "FUNCTION ONLY"button 510 in the GUI 500 has been selected, then only the function is copied into the character string and transmitted to the logging function library 308.

The process then proceeds to step 404 and 406 substantially simultaneously.

Alternatively, the process may proceed to step 406 after step 404 is completed, or may proceed to step 404 after step 406 is completed. At step 404, the data is logged by a logging function in the logging function library 308. More particularly, the logging function first determines if the current function call is the first function call from the designated program 304 to the designated function library to be logged. If it is the first such function call, then the logging function initializes a log file 310 to store the data. As suggested above, it determines if another log file 310 has been created for the designated program 304 and function library and reacts accordingly. The logging function then determines if logging is on or off. If logging is off, then the received text string is not stored in the log file 310. If logging is on, then the received text string is stored in the log file 310 in the format received.

At step 406, the receiving function in the intercept function library 302 directs the function call to the system function library 306 for processing. After the function call is processed, the function in the system function library 306 directs to the hardware driver 316 a library message having generic instructions for controlling the hardware 314 (step 408). The hardware driver 316 responsively directs a hardware message to the hardware 314 with hardware specific instructions for performing a specified task such as, for example, darkening a pixel on a computer display device.

The log file 310 may be displayed on a display device after all of the calls have been logged. Figure 6 shows a preferred process for displaying the log file 310. The process begins at step 600 in which a text program is executed. The text program may be any text program such as, for example, MICROSOFT WORD 97 tu, distributed by Microsoft Corp.

The process continues to step 602 in which the text program accesses the log file 310. The

location of the log file 310 is that designated in the GUI 500. The text program then is controlled to display the text in the log file 310 (step 604).

As noted above, the log file 310 preferably includes a plurality of strings in a selected format having the function names and function parameters. Function parameters may include, among other things, integers, characters, text, and other functions in the function library with their own input parameters. In the preferred embodiment, the text strings are formatted into programming source code in the"C"programming language. The configuration utility 312 therefore initializes the log file 310 to include various"C" commands such as"main."The receiving function in the intercept function library therefore formats the text string into the format of a"C"function call by positioning the function name and the function parameters in the string in an predefined order required for a"C"function call. In alternative embodiments, the configuration utility 312 and receiving function in the intercept function library together format the log file 310 to be in other programming languages such as"C++", JAVA, or FORTRAN.

The log file 310 may be compiled to produce an executable file for performing the functions of the logged function calls. Such log file must be the embodiment having both the function calls and their respective input parameters. The executable file then may be run to control the hardware 314 in a substantially identical fashion to that done by the application program 304. For example, if the program 304 is a graphics program calling OPENGL functions in an OPENGLTM function library, then the executing compiled log file 310 should produce substantially the same graphical indicia on the display device as the application program 304 had when it generated the function calls. Figure 7 shows a preferred process for controlling the hardware 314 in such fashion. The process begins at step 700 in which the log file 310 is compiled. Once compiled, it may be executed, thereby calling the functions in the system function library 306 (step 702).

A user therefore may initiate the logging process by running the configuration utility 312. Once the configuration data is entered, the logging system 300 repeatedly logs the designated function calls each time the application program 304 is used. The log file 310 may be utilized for many purposes. One use, for example, may be to run software

demonstrations showing use of the application program 304. Another use may be to analyze the uncompiled log file 310 to determine if any bugs exist in the application program 304.

Analysis may be performed with post processing tools that simplify the analysis process.

In addition to logging the function name and/or the function parameters of each designated function, the interceptor functions in the interceptor function library 302 may be configured to log additional information relating to the function calls. For example, a return value for a function may be intercepted and logged either in the log file 310, or in another log file. The return value may be intercepted by configuring the interceptor function to assign a location in system memory for returning (i. e., temporarily storing) a copy of such return value. When the return value is returned by the system function, the logging function logs it into the designated log file.

The interceptor functions also may be configured to log the time required by the system function to execute the called system function ("function execution time"). This time may be ascertained by first recording the time that the call to the system function library was made by the intercepting function ("first time"), and then recording the time that the function execution was completed by the system function ("second time"). The difference between the first time and the second time is the total function execution time.

The interceptor functions also may be configured to log the thread identification number of the function call. Specifically, a call may be made to a log function that logs the thread identification number in any log file. Each of these examples of information relating to the function calls is intended to be exemplary and thus, should not be construed to limit the scope of the invention.

In an alternative embodiment, the disclosed function call logging processes may be implemented as a computer program product for use with a computer system. Such implementation may include a series of computer instructions fixed either on a tangible medium, such as a computer readable media (e. g., a diskette, CD-ROM, ROM, or fixed disk) or transmittable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. Medium may be either a tangible medium (e. g., optical or analog communications lines) or a medium implemented

with wireless techniques (e. g., microwave, infrared or other transmission techniques). The series of computer instructions embodies all or part of the functionality previously described herein with respect to the system. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation (e. g., shrink wrapped software), preloaded with a computer system (e. g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e. g., the Internet or World Wide Web).

Although various exemplary embodiments of the invention have been disclosed, it should be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the true scope of the invention. These and other obvious modifications are intended to be covered by the appended claims.