Computer system with context switch and program development therefor6003063Abstract When a first application program raises an error condition, a context switch, in one embodiment, transfers control to one of several Help programs, as selected automatically without user or system operator intervention. Such a first application program operates on a computer system that includes a file system, a data structure in memory, and a processor that executes in sequence an operating system, the first application program, a constructor, and a second application program, for example, a Help program. For each candidate Help program, the constructor looks for prerequisite files in the file system. If a candidate Help program's prerequisites are met, the constructor sets a link value in the data structure that directs a subsequent call from the first application program to the Help program selected by the constructor. In a second embodiment, a general method of developing the first application program for context switching incorporates the step of including, in the first application program, a transfer of control to a destination program identified by a constructor, wherein the constructor, precluding manual direction by an operator, identifies the destination program from several candidates by testing an operational prerequisite. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
struct {
char *search.sub.-- volume.sub.-- and.sub.-- path;
char *found.sub.-- volume.sub.-- and.sub.-- path;
void second.sub.-- app(int);
void second.sub.-- app.sub.-- setup();
char *second.sub.-- app.sub.-- name;
};
______________________________________
The link value in the foregoing syntax is the entry point to function second.sub.-- app. The link value, to be assigned by constructor 34, is pivotal to the operation of a context switch. A context switch is an interruption in the execution of a first program so that a second program may be executed. In some operating systems operation of the first program continues only after the second program has returned control to it. In other operating systems the second program can continue to operate after returning control to the first program. A context switch is more than a program call instruction. Not only is the flow of program control interrupted, but the displays presented to the user and the controls made available to the user are governed not by the first program's operating rules but by the second program's operating rules. As illustrated in FIG. 1, a first context 64 is replaced with a second context 66 having an overlaid window that indicates possible return to context 64. The interior of the overlaid window is controlled by the second program. A context switch is conventionally used in several situations. A few conventional examples include: (a) when an operating system offers the user the opportunity to select an application for execution, (b) when a spreadsheet program alternates between tabular and graphics display of numerical data, (c) when a wordprocessor alternates between document entry and use of a dictionary, (d) when a test program development tool alternates between test program syntax entry and test program dynamic debugging. In example (a) the second or destination program is identified by user choice. In examples (b), (c), and (d) the destination program is conventionally identified by program developer's or installer's choice. In the computer system of FIG. 1, the destination program of the context switch is identified by constructor 34. Prior to the first time that a context switch is to be used, first application 33 sets parametric values in data structure 35 and then calls constructor 34. First application 33 defines the string search.sub.-- volume.sub.-- and.sub.-- path to identify a subset of the files in file system 50 to be searched for prerequisite files. First application 33 calls constructor 34 either as a preliminary activity or at a time immediately prior to use of the context switch. Constructor 34 reads data structure 35 and performs a search of file system 50 for prerequisite files. File system 50 includes APP.CAT file 52, APP.HLP file 54, HELP2.EXE file 56, and HELP2.HLP file 58. When first application 33 was installed, APP.HLP and APP.CAT were loaded in file system 50. File APP.CAT contains brief numbered messages. File APP.HLP contains indexed messages operative with Help program HELP2.EXE as an on-screen first application operator manual. File HELP2.HLP contains indexed messages operative with Help program HELP2.EXE as an on-screen Help2 operator manual. In addition, HELP2.HLP contains operator manual information describing features of operating system 32 which may be explored by the user who needs fundamental assistance in operation of computer system 10. Constructor 34 is a subroutine prepared with conventional programming techniques. Constructor 34 was developed with foreknowledge of several Help systems: a primitive message display subroutine that is part of first application 33, a help system HELP1 that uses files having filenames identified with the wildcard *.hv, and a help system HELP2 that uses files having filenames identified with the wildcard *.hlp. As an example of the operation of constructor 34, consider the following first session (not illustrated). Constructor 34, using conventional operating system calls, searches file system 50 beginning at the search.sub.-- volume.sub.-- and.sub.-- path for the existence and accessibility of files with wildcard *.hv. None are found. Constructor then continues the search for files having wildcard *.hlp. None are found. After verifying the existence of APP.CAT, constructor 34 then (1) assigns an appropriate value to string found.sub.-- volume.sub.-- and.sub.-- path of data structure 35; (2) determines the entry point for simple help as a subroutine call within constructor 34 and assigns the appropriate value to second.sub.-- app; (3) determines the entry point for the initialization subroutine (if any) for the subroutine and assigns the appropriate value to second.sub.-- app.sub.-- setup; (4) instantiates a file buffer and loads files APP.CAT 52; (5) assigns a value to the string second.sub.-- app.sub.-- name; and (7) returns control to first application 33. These actions by constructor 34 effectively couple first application 33 to a simple help subroutine in constructor 34 based on the choice of possible applications made by constructor 34. Because no opportunity for operator selection exists either before, during, or after operation of constructor 34, constructor 34 precludes operator manual direction by the user, a system operator, if any, or an installer. As a further example of the operation of constructor 34, consider the following second session illustrated by FIG. 1. Constructor 34, using conventional operating system calls, searches file system 50 beginning at the search.sub.-- volume.sub.-- and.sub.-- path for the existence and accessibility of files with wildcard *.hv. None are found. Constructor then continues the search for files having wildcard *.hlp. Files 54 and 58 are found to exist and are currently available for access. Having found the prerequisite files for Help program HELP2, constructor 34 then searches for file HELP2.EXE. Having found the executable code file for Help program HELP2, constructor 34 (1) assigns an appropriate value to string found.sub.-- volume.sub.-- and.sub.-- path of data structure 35; (2) loads file HELP2.EXE 56 as dormant second application 36; (3) determines the entry point of a parameter transformation subroutine in constructor 36 and assigns the appropriate value to second.sub.-- app; (4) determines the entry point for the initialization subroutine for second application 36 and assigns the appropriate value to second.sub.-- app.sub.-- setup; (5) instantiates file buffers 37 and 38 and loads files APP.HLP 54 and HELP2.HLP 58, respectively; (6) assigns a value to the string second.sub.-- app.sub.-- name; and (7) returns control to first application 33. These actions by constructor 34 effectively couple first application 33 to second application 36 based on the choice of possible applications made by constructor 34. Because no opportunity for operator selection exists either before, during, or after operation of constructor 34, constructor 34 precludes operator manual direction by the user, a system operator, if any, or an installer. The structure of files *.HLP follow conventions widely used in application program development for UNIX and Microsoft Windows applications. The file APP.CAT takes advantage of an existing conventional structure for *.CAT files to implement novel means for converting an integer message number to a locator for use in a file having the structure of a *.HLP file. In the first session the integer parameter passed from first application 33 to the constructor subroutine is sufficient for locating a simple message in file APP.CAT. In the second session, constructor 34 reserves the entry point to second.sub.-- app for use by the parameter transformation subroutine. At the time of a context switch, when first application 33 has determined an integer value to be passed to second.sub.-- app, the parameter transformation subroutine reads the integer. Then the parameter transformation subroutine (1) uses a transform from file APP.CAT to determine a corresponding word or phrase; (2) calls second.sub.-- app at the entry point reserved; and (3) passes the word or phrase as the parameter, in place of the integer. The parameter transformation subroutine is developed using conventional programming techniques including string to integer conversion and string substitution. Transform data and the structure of file APP.CAT will be described with reference to FIG. 2 at step 320. In an alternate embodiment, constructor 36 discards the possibility of loading a candidate second application when other system prerequisites are not first met. Examples of such other prerequisites include, but are not limited to, obtaining sufficient memory for loading and operating the candidate; obtaining access to a particular communication channel, file server, peripheral, instrument, or process control device; or verifying schedule prerequisites such as operation only during predetermined times of day or selected days. On the other hand, in yet another alternate embodiment, constructor 36 uses prior results to choose more quickly. For example, constructor 36 chooses the same second application program as chosen in a prior call that obtained nonexclusive access to a particular candidate second application. FIG. 2 is a flow chart of a method of application program development of the present invention. The method involves three parallel paths amenable to development by independent groups or members of a program development team. Steps 210 through 240 provide the executable code file for the application. Steps 310 through 330 provide prerequisite *.CAT files and steps 410 through 430 provide prerequisite *.HLP flies for one or more candidate second application programs. The first and second application programs cooperate as already described for processes 33 and 36, respectively, with reference to FIG. 1. In the discussion below, development of first application 33 and prerequisite files for second application HELP2.EXE will be described to clearly illustrate a few embodiments of the present invention. Development is described using terminology which has come to have specific meaning to those who use the conventional C programming language. At step 210 a header file is prepared and included in the source code for first application. The header file contains declarations for data structure 35 and a prototype for the call to second.sub.-- app. Initialization of variables, allocation of dynamic variable space, and calls to initialization entry points for various routines including constructor 34 are made using conventional techniques. At step 220, use of the call to second.sub.-- app is made when a context switch is deemed appropriate by the application developer. The application developer, at each instance where a context switch is desired, specifies the level of support appropriate to the instance, and specifies a parameter. The parameter may be either a word or phrase for use with level 1 and higher programs; or it may be the string representation of an integer message number for quick level 0 support. By specifying level 0 support, the time required by constructor 34 to choose and load a candidate second application is avoided. At step 230, the source code prepared in steps 210 and 220 is submitted to a compiler for generation of a relocatable object. At step 240, the relocatable object from step 230 is linked to various libraries. One of the libraries of subroutines contains constructor 34 with a simple message posting subroutine and a parameter transformation subroutine. The library having constructor 34 is developed using conventional programming techniques as directed by the functional and operational descriptions of constructor 34 detailed above. The result of linking at step 240 is an executable file, which for first application 33, is APP.EXE. At step 310, numbered messages are written. Each message corresponds to a condition anticipated by first application 33. Such a condition may be an abnormal condition or an opportunity for the user to call for help prior to an abnormal condition. Each message is identified with digits corresponding to an integer, though the text of the message may be in any human language. Example numbered messages are as shown:
______________________________________
$001 File not found.
$002 A graphics file (.GRF) cannot be opened in this directory
having the name you specified.
. . .
______________________________________
At step 320 a transform is written for every numbered message. Each transform includes digits representing the respective integer and a word or phrase indexed in a .HLP file. At step 330, transforms written at step 320 are combined with numbered messages written in step 310. The resulting hierarchical file has a structure consistent with the conventional Natural Language Support system familiar to application program developers whose application programs are compatible with the UNIX operating system. The hierarchical structure of the file distinguishes primitive numbered help messages from transforms by grouping transforms in a first set and messages in a second set. An example of a portion of a hierarchical file is as shown:
______________________________________
set $123
$001 pathname
$002 graphics filename
. . .
set $124
$001 File not found.
$002 A graphics file (.GRF) cannot be opened in this directory
having the name you specified.
. . .
______________________________________
The hierarchical file consists of two sets. The first set includes transforms; the second set includes numbered messages. File APP.CAT results from a conventional compilation of the hierarchical file at step 310. At step 410, the content of an operators manual is used to prepare a large number of topical explanations. At step 420 these explanations are reviewed and meaningful words and phrases are selected. The selected words and phrases are then listed for use as an index into the topical explanations. Selection of the words and phrases is made in cooperation with the development of transforms at step 320. At step 330, the index and explanations are conventionally combined into a file or files of conventional structure indicated generally as file APP.HLP. At step 510, APP.EXE, APP.CAT, and APP.HLP are installed on a user's computer system. Any number of candidate programs known a priori by constructor 34 may be concurrently or subsequently installed on the user's computer system. Each candidate program will have several files such as HELP2.EXE and HELP2.HLP as shown for the Help2 program in FIG. 1. Future installation of other candidate programs will be supported by APP.EXE without change to APP.EXE. Future revisions to constructor 34 and consistent revisions to the hierarchical file are made by distributing a revision to first application 33 as a revised set of files APP.EXE (possibly containing a revised constructor), APP.CAT (possibly including other sets), and APP.HLP. In an embodiment with additional capability, first application 33 calls second application program in one of two ways by using one of two entry points. Data structure 35 is expanded to include the second entry point and constructor 34 is equipped to distinguish and process either of the types of calls. The first entry point operates with integer numbered messages as discussed with the first session, above. The second entry point operates with phrase substitution for the integer as discussed with the second session, above. Operation from the first entry point is significantly faster, providing a more responsive user interface. The dual entry point capability is compatible with conventional Help programs, such as "VUE" by Hewlett-Packard, "CDE" by COSE Alliance, and "HyperHelp" by Bristol Technologies. The foregoing description discusses preferred embodiments of the present invention, which may be changed or modified without departing from the scope of the present invention. For example, in an alternate embodiment, computer system 10 is a personal computer and files 52 through 58 are conveyed to processor 20 in part via a public communication channel. In still another alternate embodiment, computer system 10 is a distributed processing system hosted on a network of workstations wherein processes 33 and 36 are executed on physically separate but logically coupled platforms. Processor 20 in an alternate embodiment is a microprocessor. Memory 30 in alternate embodiments includes a mix of read only and dynamic read/write memory. Operating system 32 in a preferred embodiment is a UNIX compatible operating system, however in alternate embodiments compatibility is with other multitasking operating systems such as Microsoft "DOS", "NT", or "Windows" operating systems. Network 80 in one embodiment is a bus between circuit cards and in a second and equivalent embodiment is a company-wide data network. Monitor 60 and keyboard 62 are omitted in an alternate embodiment for process control wherein support for first application 33 is not intended to improve user interaction but for supporting variation in instrument compatibility, accuracy, system response, sparing, and similar systems operational objectives. Still further, those skilled in the art will understand that first application program 33 and candidate second application programs are not limited to the examples discussed herein. First application program is representative of any software and second application program is representative of any separately compiled program or library including those enforcing a convention such as spell checkers, grammar checkers, CAD design rule checkers, and program syntax checkers, as well as member programs of functional sets such as documentation viewers (including help systems), tutorials, simulators, signal processors, software and system diagnostics, graphic processors, system performance monitors, numerical and statistical analyzers, data entry/edit tools, database applications, and speech and musical processors, to name just a few functional units. These and other changes and modifications are intended to be included within the scope of the present invention. While for the sake of clarity and ease of description, several specific embodiments of the invention have been described; the scope of the invention is intended to be measured by the claims as set forth below. The description is not intended to be exhaustive or to limit the invention to the form disclosed. Other embodiments of the invention will be apparent in light of the disclosure to one of ordinary skill in the art to which the invention applies.
|
Same subclass Same class Consider this |
||||||||||