Determining compatibility of an application with different versions of an operating system

[0001] 1. Technical Field

[0002] The present disclosure relates to compatibility checking in computing systems, and more specifically to determining compatibility of an application with different versions of an operating system.

[0003] 2. Related Art

[0004] Operating systems generally refer to programs that control access to various hardware resources present in a computing system. An operating system typically provides various interfaces (typically as libraries, functions, etc.), which are invoked by the applications that may share the hardware resources. Operating systems are typically loaded and executed soon after the corresponding computing systems are booted (powered on). The operating systems thereafter provide a run-time environment in which different applications can be executed.

[0005] Several versions of a same operating system (OS) often exist. Typically, a newer version of an OS is designed to provide more functionality (or for other reasons, such as fixing known bugs, enhanced resource usage efficiency, etc.), compared to a older version. In such newer versions, the interfaces and other utilities (e.g., directory structure, fonts, etc.) provided to applications, may differ from those provided by other (e.g., older) versions of the OS. In general, a utility refers to any facility provided by the OS to the applications for coordinating usage of hardware resources, organization of data according to pre-defined conventions, etc.

[0006] Hence, a same application designed for proper operation with one version of an operating system may not operate properly (i.e., may not be compatible) with another version of the operating system. Determination of compatibility of an application with different versions of an operating system is therefore desirable. For example, application vendors would benefit from information on changes required in their applications to ensure proper operation on a newer version of an OS.

[0015] In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

[0016] An aspect of the present invention detects usage, by an application process, of a utility provided by a first version of an operating system, and determines whether a later version of the operating system is incompatible with identical usage of the detected utility. If the usage is determined to be incompatible, the corresponding information on the incompatibility is included in a report.

[0017] According to another aspect, the determination of compatibility is performed by maintaining data (e.g., in a database) indicating incompatibility information related to a set of utilities, which are incompatible with the second version. The data is examined to determine incompatibility.

[0018] Another aspect of the present invention facilitates determination of compatibility with respect to libraries, by using an operating system designed to trap invocation of a library upon registration of the library for monitoring. Such a feature is used to determine compatibility issues with libraries, which are linked dynamically during run-time. In one embodiment, a set of dynamically linked libraries is identified. The data in the database is examined to determine a subset of libraries which are not supported by a later version. Each of such libraries is registered for monitoring by the operating system and if any function of the library is invoked, the corresponding information is included in the report.

[0019] Another aspect of the present invention facilitates determination of compatibility with respect to specific functions (of otherwise supported libraries). The data in the database is examined to determine specific ones of such functions (of libraries marked for potential use) indicated to be incompatible, and the determined functions are registered with the operating system for monitoring. If any of such functions are invoked, the corresponding information is also included in the report.

[0020] Several aspects of the present invention are described below with reference to examples for illustration. However, one skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific details or with other methods, components, materials and so forth. In other instances, well-known structures, materials, or operations are not shown in detail to avoid obscuring the features of the invention. Furthermore, the features/aspects described can be practiced in various combinations, though only some of the combinations are described herein for conciseness.

[0021] FIG. 1 is a block diagram illustrating the details of an example system in which several aspects of the present invention can be implemented. Computing system 100 is shown containing hardware 130, OS 120, application process 110 and run-time analysis module 150. The details of computing system 100 are shown merely by way of illustration, and computer system 100 may contain other blocks as well.

[0022] Hardware 130 represents the hardware components (e.g., central processing unit, memory, bus controllers, hardware resources such as printer interface, serial interfaces, network interfaces, etc.) of computing system 100. The hardware components can be shared among various user applications, which are possibly distributed across multiple computing systems as well.

[0023] Application process 110 represents a user application that is presently executing in computing system 100. As may be readily appreciated, a user application is generally represented in the form of executable modules, which when executed, creates the corresponding application process. The application process represents an active entity capable of performing various actions (for which the corresponding user application is designed). Though only a single process is shown in FIG. 1 for illustration, it should be appreciated that many application processes (related to same or different user applications) may be executed simultaneously and/or in multi-tasking fashion, based on hardware 130.

[0024] OS 120 controls access of application processes to the various utilities. In case of functions (assumed to be same as procedures), the appropriate function call (e.g., requests for writing data to and reading data from memory in the form of file commands) is made by the application process and the invoked function contains the instructions that operate to access the resource on behalf of the application. In general, OS 120 provides interfaces (e.g., in the form application programmer's interface or API) to enable application process 110 to use the resources provided in hardware 120. The API typically is provided in the form of various function (or procedure) calls that can be invoked by application process 110.

[0025] As noted above, an operating system may have several versions, and OS 120 represents one such version. Thus, while application 110 may (currently) be executing in conjunction with such one version of OS 120 in computing system 100, it may be desirable to determine compatibility of application 110 with another version of the operating system (which is currently not executing in system 100, but which can replace the current version in system 100).

[0026] Run-time analysis module 150 operates to determine compatibility of application 110 with other versions of OS 120 (other than the currently executing version) according to several aspects of the present invention, as illustrated with some examples in sections below.

[0027] FIG. 2 is a flowchart illustrating the manner in which compatibility of a user application with another (here, later or newer, for illustration) version of an operating system, in an embodiment. The flowchart is described with respect to the blocks of FIG. 1 merely for illustration. However, many of the features can be implemented in other environments also without departing from the scope and spirit of several aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. The flow chart begins in step 201, in which control immediately passes to step 210.

[0028] In step 210, run-time analysis program 150 detects usage, by application process 110, of a utility provided by (executing/present version of) OS 120. Detection of invocation by an application process implies that such detection is performed during execution time of the application process. The utility can be a file, a function in a library, a font setting, etc, as noted above. In case of functions, the usage is initiated by invocation of the corresponding function call by pre-specified interface/convention. In case of directories, the usage is when the content of the directory is sought to be accessed. Similarly, in case of fonts type resources also, the usage occurs when data representing the font is accessed. Any approach to such detection (during the run-time of the application process) may be employed, though example embodiments are described in sections below for illustration. Control then passes to step 230.

[0029] In step 230, run-time analysis program 150 determines whether a later version of the operating system is incompatible with identical usage of the detected utility. An incompatibility is said to exist if the utility cannot be invoked using the same syntax/semantics and/or the effect/result is not suitable/same for the newer version. For example, in case of function calls, functions may not exist, or such usage may differ in the invocation and/or the effect (result) provided by execution of the function In case of libraries the library may not exist, upgraded to a newer version or moved to a different location. In case of directories, the directory may not exist in later versions or located at a different path. In case of fonts, font support may be discontinued or different file names may be used for the same path. Thus, the determination (during run-time) can depend on the type of utility, and any facility provided within the operating/execution environment of computing system 100 can be suitably used.

[0030] Control passes to step 250 if there is incompatible, and to step 270 otherwise. In step 250, run-time analysis program 150 records the details of the utility in a compatibility check report for application process 110 (or the corresponding user application). Control then passes to 270.

[0031] In step 270, run-time analysis program 150 determines if a compatibility check needs to be performed for at least one more utility. If a compatibility check needs to be performed for one more utility, control then passes to step 220, otherwise control passes to step 299, in which the flowchart ends.

[0032] Run-time analysis program 150 thus provides information indicating potential incompatibilities of an application with other versions of an operating system. The approaches described above can be implemented in several forms, an example of which is described in sections below.

[0033] FIG. 3A is a block diagram illustrating the details of implementation of at least some of the features described above, in an embodiment of the present invention. Some of the blocks of FIG. 1 are shown repeated to illustrate the interactions between the various blocks. FIG. 3A is thus shown containing application process 110, OS 120, run-time analysis program 150, database 310, input files 315 and report 330. Each block is described below in further detail.

[0034] Input files 315 contains data specifying the incompatibility in the usage of various utilities between those in the current/executing version of OS 120 and the newer version of the OS 120. The details of input files 315 in an embodiment of the present invention are described in a section below.

[0035] Database 310 stores the data specified in input files 315, and responds with specific data when presented with corresponding queries. Thus, queries are received specifying a detected utility (of step 210) and database 310 provides a response containing an indication of any incompatibility in the usage of the corresponding utility. The data in input files 315 can be examined for equivalent information, but querying database 310 provides a more efficient interface, as will be apparent to a skilled practitioner.

[0036] Run-time analysis program 150 interacts with OS 120 to determine specific utilities invoked by application process 110. Run-time analysis program 150 further queries database 310 to determine any incompatibilities in the usage of the corresponding utilities. Report 330 is generated based on such incompatibilities. It should be appreciated that run-time analysis program 150 may be executed prior to or after start of execution of application process 110. The description is continued with respect to input files in an example environment.

[0037] In an embodiment, input files 315 contains the following data, and each item of below may be organized as a corresponding table in database 310 (accordingly data and table are used interchangeably). In addition, the description is provided assuming that the executing version is Oracle Solaris 10.0 and later version of interest is version 11, merely for illustration. It should be however appreciated that the invention can be implemented in conjunction with various other operating systems, provided by different vendors. Some of input files are noted below:

[0038] 1) Missing Files: The table contains the details about the those files (Libraries, fonts, configuration files, etc.), which are found in OS 120 but are not available or moved to a different location in a later version of the OS.

[0039] 2. Missing Symbols: The table contains the details of the Symbols (Functions) which are available in Oracle Solaris 10 but no longer available in Oracle Solaris 11

[0040] 3. Modified Files: The table contains the list of Libraries (stored as files) in Oracle Solaris 10 version operating system, which have been modified/upgraded or moved to a different location (i.e., to a directory of a different path) in Oracle Solaris 11. The table provides the link between the existing file on Oracle Solaris 10 and it's equivalent on Oracle Solaris 11. Report 330 may accordingly contain information on the modified files if a corresponding file is sought to be accessed in the earlier version.

[0041] 4. Modified Symbols: The table contains the details about the Symbols (Functions) from Libraries that have either changed in signature (i.e., invocation convention such as parameters, type of parameters, etc.) or in behavior (i.e., the effect provided by execution of the function) on Oracle Solaris 11.

[0042] 5. Private Symbols: The table contains the private (undocumented and internal) symbols (Functions) of Libraries in Oracle Solaris 10 which may be removed in future versions of Oracle Solaris and hence shouldn't be used by the applications. Report 330 may accordingly contain use of any such private symbols in the operation of the earlier version of the operating system, such that a vendor of later version can take appropriate measures.

[0043] 6. Deprecated symbols: The table contains the symbols (Functions) of Libraries in Oracle Solaris 10 which are marked for removal in the upcoming releases of Oracle Solaris 11. These help in detecting those applications that are using such functions and provide a suitable warning.

[0044] 7. Missing Packages: This table contains details about Oracle Solaris 10 (earlier version) packages, which are no longer available in Oracle Solaris 11 (later version). As is well known in the relevant arts, a user application is shipped in the form of multiple packages, and a utility may be present in one of such packages. It is often possible that an entire package is not shipped in the later version, and accordingly tables are maintained indicating the specific packages not shipped, as well as utilities within such missing packages, which are not supported in the later version. The report generated may accordingly indicate the missing package information if a corresponding (contained) utility is not supported by the later version.

[0045] 8. Modified Packages: This table provides a link between the modified packages on Oracle Solaris 10 and it's equivalent on Oracle Solaris 11. A package may be said to be modified, if there is a change (removal, addition, or change to signature or behavior) to at least one utility in the (modified) package, in relation to the corresponding package of the later (or newer) version of the operating system. Report 330 may accordingly indicate the identity/name of the modified package when a corresponding utility is detected to be changed, compared to use in the previous version of the operating system.

[0046] 9. Modified SymLinks: The table provides details about “Symbolic Links” in Oracle Solaris 10 whose destinations have changed in Oracle Solaris 11. As is well known, a symbolic link provides a convenient convention by which a file in one directory (“physical directory”) can be conveniently referred to in another directory (or with a different name) by specifying appropriate links (symbolic link) in the referring directory. A symbolic link is said to be modified if it refers to a different location, has changed name/directory, or is removed altogether.

[0047] It may thus be assumed that database 310 contains tables corresponding to information such as that described above. The manner in which such information can be used in generating report 330 in an example embodiment, is described below in detail. Some of the underlying concepts in such example embodiment are first established.

[0048] In an embodiment, operating system 120 corresponds to Oracle Solaris 10.0 operating system, which provides DTrace utility. In general, DTrace can be used to obtain a global overview of a running system, such as the amount of memory, CPU time, file system and network resources used by the active (application) processes. It can also provide much more fine-grained information, such as a log of the arguments with which a specific function is being called, or a list of the processes accessing a specific file. The Dtrace utility is described in further detail in a document entitled, “Solaris Dynamic Tracing Guide” available from Oracle Corporation and also a book entitled, “DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD (Oracle Solaris Series)”, ISBN-10: 0132091518, Publication Date: Apr. 11, 2011, by Brendan Gregg and Jim Mauro.

[0049] According to that utility, one needs to register (or specify) the specific functions or libraries, that are of interest, and OS 120 thereafter traps the invocation of such functions. Such ability to trap invocation of only selective functions minimizes any adverse impact on throughput performance, even though alternative implementations can be chosen to trap invocation of more (including all) functions (e.g., those in selected libraries).

[0050] The output generated by OS 120 upon such trapping can be suitably processed to generate report 330, with respect to libraries and functions, as described in sections below.

[0051] Identification of such specific libraries (or utilities therein) presents different challenges with respect to statically linked libraries and dynamically linked libraries. As is well known in the relevant arts, the statically linked libraries are included into the executable while compiling (generating machine/object code from corresponding source code from higher level programming languages such as C, etc.) and linking (generating an executable file from potentially multiple object codes/files). With static linking, the library gets embedded into the executable itself.

[0052] In contrast, dynamically linked libraries are not included in the executable file. The executable file/code may include references to those which were specified during the compilation and linking, and are thus commonly used associated with shared libraries (i.e., a library that can be potentially shared by different user applications or application processes). The operating system links the referenced library prior to execution of the user application (i.e., before instantiation for execution of the corresponding application process).

[0053] The dynamically linked libraries for a running (executing) application can be determined (at any time instance) during run time by invocation of PLDD command in Solaris 10 Operating System environment. Thus, even if run-time analysis program 150 is executed when application process 110 is operative, the PLDD command can be used to determine all the dynamically linked libraries. Several aspects of the present invention operate in conjunction with such dynamically linked libraries, as described in sections below.

[0054] A different set of challenges are presented with ‘dynamically loaded libraries’. In general, the specific dynamically loaded library need not be known prior to instantiation of application process, and application process 110 can determine the specific library to load during execution (based on the program logic internal to the user application). Thus, a dynamically loaded library is not referenced in the executable, but directly loaded and used by the program at execution time. These libraries may be specified as inputs while initiating execution of the user application or determined by execution logic during the execution time. Therefore, these libraries may not even be available (exist) at compile time. In Solaris 10.0 operating system libraries are dynamically loaded using calls such as “dlopen” (an example of a system call to dynamically load a library). The specific library to open is specified by indicating the corresponding file name as an argument to the dlopen system call.

[0055] In the context of Solaris 10 Operating system, the “dlopen” internally uses a sequence of “open” and “mmap” systems calls to dynamically load the specified library. Run-time analysis program 150 traps this sequence of system calls using Dtrace facility, to detect the event of library being dynamically loaded by the running program that is being monitored. Whenever this is detected the name of the library that is being dynamically loaded is recorded and this data is further checked during the post processing phase to ascertain whether the usage library has any compatibility issue in the later version of the Operating system.

[0056] Now turning to the challenges with respect to dynamically linked libraries, one general problem with usage of libraries in large/enterprise applications is that many libraries are often marked for potential use by an application program, but only some of them are actually used (i.e., at least one of the function in the library being invoked). For example in Solaris 10, the command “pldd” can be used on a running process to obtain the list of dynamically linked libraries for a running program. The implementation uses this command inside a shell script to determine the dynamically linked list of libraries that may be potentially used by the program. It may not be possible to determine upfront (i.e., before execution) whether all of the marked libraries would be actually used during run-time. Therefore, the absence of support (presence) for specific libraries marked for potential use, is not necessarily a problem. A problem is thus deemed to exist for a vendor only if a library marked for potential use is actually used by the user application during execution.

[0057] Now turning to the challenges with respect to dynamically loaded libraries, it is generally required to identify such dynamically loaded libraries. The facilities available for such identification typically depends on the operating environment (including the operating system), and any/all such available facilities can be suitably used for determining the dynamically loaded libraries. In case of Solaris 10.0 operating system, the dynamic loading is effected by using function calls such as “dlopen”.

[0058] The operation of run-time analysis program 150 using the above noted concepts in an embodiment, is described below in further detail.

[0059] FIG. 3B is a flowchart illustrating the operation of run-time analysis program 150 in an embodiment. The flowchart is described with respect to the blocks of FIGS. 1 and 3 merely for illustration. However, many of the features can be implemented in other environments also without departing from the scope and spirit of several aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. The flow chart begins in step 351, in which control immediately passes to step 360.

[0060] In step 360, run-time analysis program 150 identifies the libraries loaded for application process 110. In one embodiment implemented in the context of Oracle Solaris 10.0 operating system, a ‘pldd’ command is used to identify (from OS 120) libraries linked dynamically to application process 110. The output of pldd indicates the dynamically linked libraries. However this list may not have the dynamically loaded library which has been loaded using functions such as dlopen.

[0061] In step 370, run-time analysis program 150 determines the utilities requiring monitoring. In case of dynamically linked libraries, database 310 may be queried to determine the utilities within the identified libraries that require monitoring. In case of libraries that are entirely missing (i.e., not supported in the later version of the operating system), those libraries require monitoring. In case of libraries that are modified in the later version, only those utilities of the library (but not the entire library) that have been changed are required to be monitored. In an embodiment, all libraries loaded dynamically by the application processes, and child processes of the application processes, are deemed to require monitoring.

[0062] In step 380, run-time analysis program 150 registers the determined utilities with the operating system. In the case of Solaris 10.0 operating system, the DTRACE utility is used to register the various utilities that are required to be monitored. However, the corresponding facilities provided in other operating environments can be used, to achieve a similar effect.

[0063] In step 390, run-time analysis program 150 receives notification of use of a utility. Thus, if any function in a missing/registered library is invoked, the invocation is trapped. Similarly, if a registered function is invoked, the corresponding information is also trapped. The operating system may similarly be used for detecting the use of other resources as well, as described below with examples.

[0064] In step 395, run-time analysis program 150 incorporates the information of use of a utility in the report. It should be understood that the loading of a dynamic loaded library by the application being monitored would imply the automatic use of such a library, and accordingly the loading of such a library is included in the log. In one embodiment, operating system 120 traps each instance of invocation of a registered utility and provides a log of all such uses. Run-time analysis program 150 thereafter processes the information in the log to provide an understandable report. The flowchart ends in step 399.

[0065] The description is continued with respect to some of the implementation details for the features described above. In particular, as noted above, the registration of step 380 may be performed using DTRACE feature of Solaris 10.0 operating system in that environment. The content of a script used for such registration is illustrated below with examples.

[0066] FIG. 4 illustrates a portion of a script used for registering the specific functions and libraries that are determined to be incompatible. The content of the script is generated by run-time analysis program 150 based on querying of OS 120 (using PLDD command) for dynamically linked libraries, and thereafter checking in database 310 for those libraries and/or specific functions therein, which are incompatible with identical usage in a later version of the operating system.

[0067] Each line between 410 and 440 indicates the registration of a corresponding library (e.g., libglib-2.0. so.0.400.1 of line 410) with respect to an application process having process identifier (PID) of 1886. The keyword ‘Entry’ indicates that invocation of any function within the library be trapped. Lines 441-443 indicate the specific output to be provided to the script upon occurrence of such trap. In particular, the process id, the name of the module/library, and the name of the function are provided to run-time analysis program 150 for further processing. This particular section in the script represents a scenario where a set of libraries (one per each line) are removed, upgraded or moved to a different location in the newer version of the Operating system (Oracle Solaris 11)

[0068] Lines 450-460 similarly indicates the corresponding output to be provided to the script when a function within libc.so.1 is invoked. Thus, the lines between 450-460 represent a scenario in which a number of internal functions (Private or Deprecated) of the library have been removed but the library continues to exist in newer version of the operating system. Since number of functions removed were more than a few, the script was generated to detect usage of all functions from this library and record it. This would make sure that the size of the generated script remained manageable. The output was refined further with query from the database to eliminate any functions that have not changed in the newer version of the operating system.

[0069] On the other hand, lines 470-475 indicate the specific functions (e.g., “_—1cH_CimplWnew_atexit_implemented6F_b_”) within a library (libCrun.so.1), which are to be trapped (corresponding to a situation when a library is supported in a future version, but at least some of the functions therein are not identically usable in the later version).

[0070] OS 120 generates an output (also shown specified by lines 441-443, 450-460, etc.) when any of the events represented by the script of FIG. 4 occur. It should be appreciated that multiple occurrences of the same event-type (i.e., that represented by a corresponding line of FIG. 4) causes corresponding number of outputs to be provided to run-time analysis program 150. All such outputs may be suitably processed to generate understandable reports.

[0071] It should be appreciated that run-time analysis program 150 may similarly instruct OS 120 to monitor opening of any dynamically loaded libraries. In particular, another script (using portions of the logic shown in Appendix A) may request OS 120 to trap all invocations of DLOPEN, and examine the output of such trap (e.g., the input parameters to DLOPEN to check whether a file representing a library is sought to be retrieved, based on appropriate file name extension) to determine whether a library is sought to be dynamically loaded. As noted above, the mere loading of such a library is deemed a use of that utility, and thus the event may be logged for inclusion in the eventual report based on the results of querying database 310.

[0072] Furthermore, database 310 can be queried for any specific functions of interest within such a dynamically loaded library, and such functions may also be recorded as described above with respect to FIG. 4. Report 330 accordingly contains the corresponding recorded information.

[0073] FIG. 5 depicts a portion of such a report after consolidation of similar outputs. It may be readily observed that lines 510, 520, 530 and 540 respectively are caused due to the registrations represented by lines 420, 440, 430 and 450-460 of FIG. 4.

[0074] It should be appreciated that report 330 contains information related to only that common duration in which both run-time analysis program 150 and application process 110 are operative. The application process can be specified to be monitored by run-time analysis program 150 by corresponding process identifier (uniquely identifying the process) or selected through a Graphical User Interface, and run-time analysis program 150 may thereafter operate as described above (including querying the operating system, generating scripts, registering the various utilities of interest using the scripts, and generating the report from the logs).

[0075] Thus, from examination of report 330 represented by FIG. 5, vendors of user application corresponding to application process 110 may recognize possible issues in compatibility with later versions of an operating system, and suitably develop further versions of the application to address such incompatibilities. It may be readily appreciated that incompatibilities with dynamically linked libraries are also identified in view of run-time operation of the features described above.

[0076] However, additional challenges are often presented with child processes that are often created by (parent) processes. According to an aspect of the present invention at least some of the compatibility related information is readily ascertained, as described below with examples.

[0077] In general, when a child process starts, it loads each of the linked library that it requires. The DTRACE facility noted above, does not provide a direct method for trapping the event of dynamic loading of the library by the child processes spawned by the process that is being monitored. By studying the sequence of kernel calls that the OS makes to load the library, it was observed that a library the OS provides, internally translates the load request into a sequence of “open” and “mmap” kernel calls with certain arguments passed around. As is well known, kernel is a part of a operating system, but executed in a protected mode outside of the user space. The kernel further is typically associated with direct control of the hardware resources.

[0078] Thus, a script (shown in Appendix A, in further detail) is generated, and executed by a program when the monitoring of the parent process is sought to be started. In an embodiment, a Java program is executed to initiate monitoring of the parent/child processes, and such program executes the script which runs as a separate process. The script registers the interested sequence with DTRACE, thereby helping in trapping occurrences of such a sequence of events to detect the top level event of library being loaded by a parent process or child processes of the parent process. The script is shown referring to progenyof (1886)), indicating that the events with respect to the child processes of parent process having identifier 1886, are monitored.

[0079] This script also has additional logic to ensure that the sequence is from the process or child of the process that is being monitored and also to filter out certain kind of files (for example java jar files, which are generally not affected by upgrade to a higher level version of the OS) or from certain internal directories used for temporary storage or caching (/proc, /var/cache) etc.

[0080] Once the loading of libraries is detected using such kernel calls, the data in database 310 may be examined to determine any incompatibility issues with respect to identical usage of the library (e.g., if it is missing/unsupported) or functions therein.

[0081] The approach demonstrated in Appendix A can be further extended to provide more features, shown demonstrated associated with the parent process, as will be apparent to one skilled in the relevant arts. Furthermore, alternative embodiments can be implemented where the Operating System is itself designed to trap various events of interest, that occur due to the operation of child process (similar to those explained with respect to the parent process).

[0082] While the description of above is provided substantially with respect to functions and libraries, the approaches can be extended to cover other types of utilities such as fonts, symbolic links, etc., as described below with examples.

[0083] In an embodiment implemented with respect to Solaris 10.0 operating system, the various system calls made to Kernel and the operating system are examined (using DTRACE) to determine when the specific fonts are accessed or symbolic links used. It may be appreciated that fonts are generally stored in the form of files and thus the calls are monitored for accessing the specific files storing the content representing the fonts. The arguments of open( ) and close( ) calls may be examined for determining whether the corresponding font is accessed. If the arguments indicate files representing the font data, the corresponding font is deemed to have been accessed.

[0084] Thus, a vendor may be able to identify potential incompatibilities, when an application needs to be migrated to execute on another version (new in the above embodiments) of the operating system. The description is continued with respect to a digital processing system in which various features are operative when the corresponding executable modules are executed.

[0085] FIG. 6 is a block diagram illustrating the details of digital processing system 600 in which several aspects of the present invention are operative by execution of appropriate executable modules. Digital processing system 600 may correspond to computing system 100. Digital processing system 600 may contain one or more processors (such as a central processing unit (CPU) 610), random access memory (RAM) 620, secondary memory 630, graphics controller 660, display unit 670, network interface 680, and input/output interface 690. All the components except display unit 670 may communicate with each other over communication path 650, which may contain several buses as is well known in the relevant arts.

[0086] CPU 610 may execute instructions stored in RAM 620 to provide several features of the present invention. CPU 610 may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU 610 may contain only a single general-purpose processing unit. Execution of such instructions may provide each of application process 110, run-time analysis program 150 and operating system 120.

[0087] RAM 620 may receive instructions from secondary memory 630 using communication path 650. RAM 620 is shown currently containing software instructions constituting shared environment 625 and/or user programs 626. Operating environment 625 contains utilities shared by user programs, and such shared utilities include operating system 120, virtual machines, etc., which provide a (common) run-time environment for execution of user programs/applications (including run-time analysis program 150). User programs 626 contain run-time analysis program 150 and application process 110.

[0088] Graphics controller 660 generates display signals (e.g., in RGB format) to display unit 670 based on data/instructions received from CPU 610. Display unit 670 contains a display screen to display the images defined by the display signals. Input/output interface 690 includes input as well as output devices to enable a user to interact with system 600, for example, to start execution of modules representing run-time analysis program 150. Network interface 680 provides the physical, electrical and protocol implementations that enable system 600 to communicate with other systems using protocols such as TCP/IP.

[0089] Secondary memory 630 (representing a non-transitory storage/medium) may contain hard drive 635, flash memory 636, and removable storage drive 637. Secondary memory 630 may store data and software instructions (for example, for performing the steps of FIG. 2), which enable digital processing system 600 to provide several features in accordance with the present invention, as described above.

[0090] Some or all of the data and instructions may be provided on removable storage unit 640, and the data and instructions may be read and provided by removable storage drive 637 to CPU 610. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 637.

[0091] Removable storage unit 640 may be implemented using medium and storage format compatible with removable storage drive 637 such that removable storage drive 637 can read the data and instructions. Thus, removable storage unit 640 includes a computer readable storage medium having stored therein computer software and/or data. However, the computer (or machine, in general) readable storage medium can be in other forms (e.g., non-removable, random access, etc.).

[0092] In this document, the term “computer program product” is used to generally refer to secondary memory 630. These computer program products are means for providing software to digital processing system 600. CPU 610 may retrieve the software instructions, and execute the instructions to provide various features of the present invention described above.

[0093] It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. For example, many of the functions units described in this specification have been labeled as modules/blocks in order to more particularly emphasize their implementation independence.

[0094] Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0095] Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the above description, numerous specific details are provided such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention.

[0096] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0097] It should be understood that the figures and/or screen shots illustrated in the attachments highlighting the functionality and advantages of the present invention are presented for example purposes only. The present invention is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown in the accompanying figures.

[0098] Further, the purpose of the following Abstract is to enable the Patent Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way.

[0099]

APPENDIX A
#pragma D option destructive
#pragma D option quiet
BEGIN
{
self->true=1;
self->newfile=0;
self->filename=“NULL.NULL”;
self->openfd=0;
self->mmapfd=0;
self->tmpfile=NULL;
}
syscall::open*:entry
/(zonename == “global”) && (uid == 100) && (execname == “soffice.bin”) && (pid == 1886 ||
progenyof(1886)) && (pid != 1821 && !progenyof(1821))/
{
self->tmpfile = arg0;
}
syscall::open*:return
/(zonename == “global”) && (uid == 100) && (execname == “soffice.bin”) && (pid == 1886 ||
progenyof(1886)) && (pid != 1821 && !progenyof(1821)) && self->tmpfile != NULL/
{
self->openfd=(int)arg1;
self->newfile=1;
self->filename=copyinstr(self->tmpfile);
self->tmpfile=NULL;
}
syscall::mmap*:entry
/(zonename == “global”) && (uid == 100) && (execname == “soffice.bin”) && (pid == 1886 ||
progenyof(1886)) && (pid != 1821 && !progenyof(1821)) && self->newfile != 0 && self-
>openfd > 2 && self->filename != NULL && self->filename != “NULL.NULL” && strstr(self-
>filename,“/proc/”) == NULL && strstr(self->filename,“/var/cache/”) == NULL && strstr(self-
>filename,“.jar”)==NULL/
{
self->mmapfd=(int)arg4;
}
syscall::mmap*:return
/(zonename == “global”) && (uid == 100) && (execname == “soffice.bin”) && (pid == 1886 ||
progenyof(1886)) && (pid != 1821 && !progenyof(1821)) && self->mmapfd > 2 && self-
>openfd == self->mmapfd && self->filename != NULL && self->filename != “NULL.NULL”
&& strstr(self->filename,“/proc/”) == NULL && strstr(self->filename,“/var/cache/”) == NULL
&& strstr(self->filename,“.jar”)==NULL/
{
printf(“%s|%d|%d|%s|%s|%s\n”,zonename,  uid,  pid,  execname,curpsinfo->pr_psargs,self-
>filename);
self->newfile=0;
self->openfd=0;
self->mmapfd=0;
self->filename=“NULL.NULL”;
}
tick-1min
/++n == 10/
{
exit(0);
}