Installation utility for device drivers and utility programs5715463Abstract An improved method of installing device drivers or utility programs on a data processing system is disclosed. Provided are a plurality of command specifications relating to installation operations for the device drivers or the utility programs. Installation programs on media introduced to an auxiliary memory units are identified, wherein the program include statement instances invoking selected command specifications. A list of the identified installation programs is built and the selected command specifications invoked by the statement instances called. Executing the command specification returns interpretable code for the installation programs. Upon running the installation program the interpretable code is interpreted. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
":COPY", ParseCopy
":LI", ParseLineIns
":UPDATE", ParseUpdate
":EUPDATE", ParseUpdateEnd
":TXT", ParseTxt
":ETXT", ParseTxtEnd
":MSG", ParseMsg
":IF", ParseIf
":ELSE", ParseElse
":EIF", ParseEndIf
":RUN", ParseRun
":CANCEL", ParseCancel
":INSTALL", ParseInstall
":EINSTALL", ParseInstallEnd
":HELP", ParseHelp
______________________________________
The subroutine invoked by each command function is elaborated upon below with reference to flowcharts depicted in FIG. 4-18. Each of the installation data profile files present on the installation source medium is parsed into pseudo code. The parsing function builds a list of all installation data profile files present on the installation source drive and tokenizes the ASCII character data sets into run-time structures. FIG. 3 illustrates execution of a parse function to provide control and routing required to parse an individual installation data profile file. FIG. 3 corresponds to a more detailed description of the step represented by block 84 in FIG. 2. Parsing is entered at step 200 where the file designated by a pointer in a parameter block is opened. Next, at step 202, it is determined if the attempt to open the file was successful. If the file was not opened successfully, the process is aborted and returned to the calling routine. If the file is successfully opened, steps 204, 206 and 208 are executed relating to initialization of appropriate data structures to handle the parse operation. Next, at step 210, the first line from the file is read. At step 212, it is determined if the last operation resulted in an input/output or parsing error. If error is detected, operation is advanced to step 228. If no error is detected, step 214 is executed to retrieve a first token from the last recovered line. The first token in the line should be one of the fifteen tags listed in Table 1. At step 216, it is determined if the recovered token appears on the list of Table 1. If the token is not a valid installation data profile tag, it is next determined if the line is blank or a comment. If the line is neither blank nor a comment, a parsing error indicator is set and the process is returned to step 212 where the error indication will force taking the YES branch from step 212 down to step 228. The YES branch from step 218, corresponding to determination that the line was blank or a comment result in execution of step 226 which is recovery of the next line. The process returns to step 212 for analysis of the new line. If the token recovered at step 214 was determined to be a valid installation data profile tag at step 216, step 222 is executed which results in a call to the command function identified by the tag in Table 1. The command or "subparsing functions" are set out in detail in FIGS. 4-18. Success in execution of the call is detected at step 224 with a result that the next line from the file is read. If the call was unsuccessful, the process is returned directly from step 224 to step 212 with a parsing error indication. Upon parsing of a complete file, a file input/output error will be detected and execution will advance from step 212 to step 228. At step 228, the file is closed. At step 229, the command pointer and the count in the installation sections' header are saved. Next, at step 230, it is determined if any parsing errors occurred during the parse operation. If such errors did occur, step 232 is executed resulting in release of all memory allocated for the parse data from the file and the setting of the sections' error flag to TRUE. The process is then returned to the calling process of FIG. 2. If no errors relating to parsing were detected, steps 234 and 236 are executed which relate to setting of pointers appropriate for continued parsing of the link list and incrementation of the count of successfully parsed files. Operation is then returned to the calling program. Fifteen separate functions may be specified through use of the tags of Table 1. FIG. 4 illustrates the command function relating to the tag :INSTALL. The :INSTALL tag relates to starting an installation section and specifies whether the user is to be allowed to choose the target drive and if so whether only the drive or the drive and subdirectory are to be gathered from the user and the default target subdirectory for installation. The function is also responsible for determining the default installation target drive. The default target drive will be either the current computers' first hard drive, first removable media drive if there is no hard drive, or a first network drive if the computer has no local drives. The :INSTALL tag must appear in installation data profile, and all remaining tags within the file must come after the :INSTALL tag. The function has two attributes a "choose=" attribute and a "path=" attribute. The subroutine is entered at step 300 with recovery of three attribute tokens from the current line. One more token than allowed is recovered to detect incorrect use of the tag. At step 302, the default target drive is determined, if required. At step 304, it is determined if the first attribute is CHOOSE. The attribute is invalidated if the value set is not none, both or drive. At step 308, it is then determined if the second attribute is PATH. If it is, the value presented is used as the default path (step 310). Next, step 312 is executed which invalidates either attribute if they were supplied without selection of a value. Next, at step 314, it is determined if the default path value is valid. If not, step 316 is executed to invalidate the second attribute. Next, step 318 is executed which tests whether a previous :INSTALL tag has been found, if either the first or second attribute is invalid, or whether a third attribute token was supplied. Occurrence of any of these conditions is an error in syntax or semantics and results in execution of step 320 where the parsing error indicator is set. The process is then returned to the parse routine described in FIG. 3. If no error was located, steps 322, 324, 325 and 326 are executed to modify the command buffer for future interpretation and to add space to the buffer to hold the next command found. The InstallFnd flag is set true for use by later command functions in syntactic analysis. Operation is then returned to the parse routine. FIG. 5 depicts a flowchart specifying the command function relating to the tag :EINSTALL. The function is called by parse when the tag present in the current line is that responsible for validating that all ending conditions have been specified in the file and that a valid :HELP tag has been processed. Essentially the tag is utilized to conclude an installation data file and if successfully parsed, results in addition of a command to the command buffer that will result in the interpreter returning to the main menu. The command takes no direct inputs. The process is entered at step 402 where the following four conditions are tested: absence of a prior :INSTALL tag, absence of a :ETXT or :EUPDATE tag, absence a :EIF tag or absence of a help text for the section. Occurrence of any of these conditions results in step 404 being executed which is a return of a set parsing error indicator. If none of the conditions are met, step 406 is executed resulting in return of an appropriate operational code to the command buffer and a return of operation to the parse routine. FIG. 6 illustrates a flowchart for a command function named ParseHelp which is called by the parse routine when the tag :HELP is encountered. The :HELP tag specifies the text the program uses on its main menu for the installation, the text the program uses in the help windows, and the language identifier associated with the text. The function processes all lines following the line up to and including an :EHELP tag. If the tag is successfully parsed and the text for the tag is associated with the program's customized language, the function sets the section's title string and help text pointers within the section header. The function validates that the attributes "ID" and "LANGID" are specified. The help text lines are either read into an unformatted buffer, and if in the program's current language, the unformatted buffer is then formatted into up to ten pages of help text. The process is entered at step 500 with recovery of the three attribute tokens from the :EHELP tag line. Next, at step 502 it is determined if the first attribute is "ID". If it is, step 504 is executed to determine if the attribute contains a value. If no value is specified, step 506 is executed to invalidate the first attribute. Next, step 508 is executed to determine if the second attribute is "LANGID". If true, step 510 is executed to determine if the value for LANGID is a currently supported national language. If the value is a currently supported national language, step 510 is executed to determine if help text has already been processed for the current language. If help text has already been processed, step 514 is executed to invalidate the second attribute. Next, step 516 is executed to determine if a previous :INSTALL tag has not been found, if the first attribute is not ID, if the second attribute is not LANGID, or if a third attribute has been supplied. Occurrence of any of these events indicates error. Step 518 is executed to set the parsing error indicator and force immediate return to the parse routine. If no error was located, step 520 is executed with the result that all lines of the file up to a :EHELP tag are read and saved to an unformatted buffer. Next, at step 522, it is determined if the text read is for the current language. If the text is a current nationally supported language, the text is formatted and at step 526 it is determined if the format was successful. If the format attempt is successful, steps 528 and 530 are executed to save the installation title in a header and to set fixed areas for a help block including width and height of its window for display. The process is then returned to the parse control routine. FIG. 7 illustrates a ParseCopy command function called by parse when the tag present in the current line of installation data profile is ":COPY". The COPY tag causes the program to copy a file from the source drive onto the target drive. Information supplied with the tag controls how the program performs the operation. The command function is entered at step 600 with initialization of an operation code to nonforcing and nonlocate. The tag takes up to four attributes. At step 602, five attribute tokens are recovered from the current line. Steps 604, 606 and 608 relate to determination of the first attribute as a syntactically valid file name and whether the file exists on the source medium. Next, steps 610, 612 and 614 relate to the second attribute which should be PATH. It is determined if the path name is syntactically valid or whether it is a successful reference to a path macro. Next, at steps 616, 618, 620 and 622 it is determined if the next attribute is LOCATE. If "LOCATE" is found, the operational code set is step 600 is modified and the value is tested against a valid range. Next, at steps 624, 626, 628, 630 and 632 it is determined if the next attribute is equal to force and if a value supplied is YES, which modifies operational code forcing form. At step 634, any of the first four attributes which were supplied but not given a specified value are invalidated. Step 636 provides error detection functions which occur if no prior INSTALL tag has been used, if the first attribute is not for a file name, if and of the second through the fourth attributes are all invalid or if a fifth attribute is supplied. Again, occurrence of any error results in the setting of a parsing error indicator at step 638. Absence of error results in execution of steps 640 and 642, which provide addition of a command to the command buffer and incrementation of the size of the command buffer to hold the next command. FIG. 8 depicts a flowchart for command function invoked by the tag :UPDATE. The :UPDATE tag specifies the name of the file to be updated, a subdirectory for the file and a file name to which any existing file is to be renamed prior to making the update. The function sets a parsing data flag called "updating" to true to indicate occurrence of an :UPDATE tag in the current installation data profile. This flag is used by the subparsers of the functions for the ":TXT" and ":LI" tags, since those tags are valid only within the boundaries of a :UPDATE and a :EUPDATE tags. The process is entered at step 700 for initialization and at step 702 four attribute tokens from the current line are recovered. Steps 704, 706 and 708 are executed to determine if the first attribute is an "FN" attribute with a value conforming to a syntactically valid filename. Next, steps 710, 712 and 714 are executed to determine if the next attribute is the "path" attribute and if the value specified therefor is a syntactically valid path name or an appropriate reference to a path macro. Next, steps 716, 718, 720, 722 and 724 are executed to determine if the next attribute is the "Rename" attribute. A filename is saved from a rename operation if the value is syntactically valid. Next, step 726 is executed to invalidate any of the first three attributes which were supplied but for which no value was specified. Next, step 728 is executed to determine if appropriate conditions for use of the :UPDATE tag have been satisfied (items 1 and 2 relating to location of an :INSTALL and :UPDATE tags) and if appropriate attributes have been specified. Occurrence of any error results in the parsing error indicator being set and a return to parse (step 730). Absence of any error conditions results in execution of steps 732, 734 and 736 which relate to addition of a command to the command buffer and augmentation of the command buffer to hold the next command. The updating flag is set to true (step 730). Associated with each :Update tag is an :EUpdate tag. This command function ParseUpdateEnd is illustrated in FIG. 9 which is entered at step 800. An :EUpdate tag must follow occurrence of an :INSTALL tag, occurrence of an :UPDATE tag, and occurrence of an :ETXT tag. These conditions are determined at step 800 and should any fail, a parsing error indicator is set by execution of step 802. If none of the conditions fail, steps 804, 806 and 808 are executed to an appropriate command to the command buffer, to increment the size of the command buffer, and to reset the updating flag to false. The :TXT tag invokes the command function ParseTxt. The :TXT tag is used to find any existing line within the file to be updated and, optionally, to remove that line. The tag also specifies the location (top, bottom, before a file and line, or after a file and line) at which the text lines are to be added to the updated file. If the tag is successfully parsed, the command function adds a command to the command buffer only if that tag contain the check attribute. The function also sets the parsing data flag :TXTFND to true to indicate that text addition is allowed. The :TXT tag is allowed to occur only within lines delimited by the :UPDATE and :EUPDATE tags, i.e. while the parsing data flag updating has the value TRUE. The process is entered at step 900 with appropriate initializations. Next, at step 902, three attribute tokens are recovered from the current line. Steps 904-908 relate to validation of the first attribute including the appropriate identity and inclusion of an appropriate check value. Next, steps 910, 912, 914, 916, 918, 920 and 922 are executed relating to validation of the second attribute "place" and determination of the value specified for the attribute. Next, step 924 results in invalidation of any attribute which was supplied but for which no value was assigned. At step 926, it is determined if the position of the :TXT tag is correct and whether appropriate attributes were supplied and value specified therefore. Essentially, use of the :TXT tag is inappropriate if no prior :INSTALL or :UPDATE tag has been used. Use of the :TXT tag is inappropriate if parsing data flag "updating" is true. Invalidated attributes or inclusion of too many attributes (here three) are also considered error. Occurrence of any error condition results in step 928 being executed. If no error is generated by step 926, step 930 is executed to determine if a check attribute was specified. If one was, a check command is added to the command buffer and the count of commands and size of the command buffer are incremented. Next, at step 936 the text found flag, TXTFND, is set to true and an operational code value is added to be used by any :LI tags up to the next :ETXT tag. The :TXT tag invokes the command function ParseTxtEnd. The function is executed to reset the parsing data flag :TXTFND to false. Essentially the function is appropriately executable, and the occurrence of the tag syntactically correct, if a prior :INSTALL tag and :UPDATE tag and :TXT tag are present in the installation data profile. The process is illustrated in FIG. 11. Syntax and semantics are analyzed at step 1000. At step 1002, a parsing error indicator is set if the conditions are not met. At step 1004 the set :TXTFND flag is set to false if the syntax was correct. The command function named ParseLineIns is called by the parse when the tag present in the current line is :LI. The :LI tag adds lines to the file named by the previous :UPDATE tag at the location specified by the previous :TXT tag. The parsing of the :LI tag is handled differently from all other tags since the :LI tag contains both an optional attribute and textual information all on one line. The :LI tag is allowed only within lines delimited by the :TXT and :ETXT tags, i.e. while the parsing data flag "TXTFND" is true. The process is entered at step 1100 with retrieval of all characters from the line that contains the :LI tag. Next, at step 1102 the first nonblank character in the line is located. At step 1104, it is determined if the next four characters are :OPT=:, i.e. whether the option attribute is present. At step 1106, it is determined if an option value has been supplied. If the attribute token has been used but no value supplied, the option value is invalidated at step 1108. Next, at step 1110, all characters following the option override data are added as text. Next, step 1112 is executed to validate the syntactic location of the :LI tag or if an error in use of the option attribute token was made. Any error results in execution of step 1114 and results in a parsing error indicator being set. If the tag has been appropriately used, steps 1116 and 1118 are executed to modify the command buffer. The :MSG tag invokes the function ParseMsg from the parse routine. The :MSG and :MSGTXT tags are used to cause the program or display a message to the end user. Messages are defined at specific warning severity levels, those being: informational; warning; or error and further specifies specific processing options to present to the use, consisting of "enter key active", "escape key active", "both enter and escape keys active", and "yes/no" keys active. Occurrence of the :MSG tag results in process by the command function of all lines up to the next :EMSG tag. Successful parsing of the tag adds a message command to the command buffer depending upon the attribute value of the "SEV" attribute for the tag. The command function further determines if the message text present in the file is in the current national language of the system. Text lines are read into an unformatted buffer pending determination of whether the language is current. Formatting occurs upon determination that the language of the message is current. FIG. 13 illustrates the ParseMsg process which is entered at step 1200 with recovery of three attribute tokens from the current line. Steps 1202, 1204, 1206, 1208, 1210, 1212, 1214 and 1216 are all related to evaluation of the "SEV" or message severity attribute. The attribute can assume one of three attribute values which are specified using letter codes. The attribute value must be compared against each possibility before generation of the pseudo code command for inclusion in the command buffer. Specification of an incorrect value results in invalidation of the first attribute. Steps 1218, 1220, 1222, 1224, 1226, 1228, 1230, 1232, 1234 and 1236 relate to evaluation of the second attribute. The second attribute relates to specification of active keys and can take one of four values, occurrence of each which must be checked for. Validation of the second attribute occurs if a correct value for the attribute is specified. At step 1238, syntactic analysis is performed on the tag and its attributes. If error is detected a parsing error indicator is set at step 1240. If no error is found, the process continues to step 1242 which provides the next line from file be read. Step 1244 provides for looping control through steps 1246 through 1273. So long as no errors are found and no :EMSG tag is found in the intervening step, the process will continue to loop. At step 1246, it is determined if a line contains the :MSGTXT tag. Steps 1248, 1250, 1252, 1254 and 1256 relate to validation of the attributes for the :MSGTXT function. Next, at step 1258, analysis of a line including a :MSGTXT is performed and if error is found step 1260 is processed to set the parsing error indicator and to return the process to step 1244 to escape the loop. If the :MSGTXT tag passes analysis in step 1258, step 1262 is executed resulting in all lines of the file being read up to a :EMSGTXT tag. The material is conditionally saved in unformatted text and at step 1264 it is determined if error occurs in the text or if the end of the text is for the current language. If no errors are present and the text is in the current language, step 1266 is executed resulting in the text being formatted up to one page in length. If errors occurred or the text was not for the current language, step 1273 is executed to read the next line from the file. The NO branch from step 1246, relating to a line containing :MSGTXT tag should be encountered only upon the conclusion of treatment of text lines following that tag. Accordingly, the NO branch from step 1246 leads to processing of step 1268 which determines if the line contains the :EMSG tag. If it does, processing is returned to step 1244 to exit the loop. If the line does not contain the :EMSG tag, it is determined at step 1270 if the line is a comment line or a blank. If the line is a comment line or a blank, step 1273 is executed to recover the next line from the file. If the line is not a comment or a blank, an error has occurred and the parsing error indicator is set and the processing returns to step 1244 to terminate the loop on the basis of location of error. Upon exit from the loop, step 1274 determines if the tag was successfully parsed, i.e. no error was returned from exit of the loop at step 1244. Return of error results in immediate return to the parse routine. If the tag was successfully parsed, steps 1276 and 1278 are executed to modify the command buffer appropriately. FIG. 14 illustrates the command function relating to the parse run function invoked by the tag :RUN. The tag is used to specify that a program, named by the tag and required by the program to be present on the drive on which the installation data profile file was found, be run. The process is entered at step 1300 with recovery of three attribute tokens from the current line. At step 1302, it is determined if the first attribute relates to file name and if so whether the value specified is a syntactically valid file name and whether the file exists on the source media. If either condition fails, the first attribute is invalided. Next, step 1308 is executed to determine if the next attribute relates to parameters. If YES, at step 1310, it is determined if data is supplied with the parameter and, if not, the attribute is invalidated. At step 1314, either attribute is invalidated if supplied but not provided with a value. Next, at step 1316, semantic and syntactic analysis is performed on the line to make sure that all conditions for its use have been met. If the appropriate conditions are not met, the parsing error indicator is set at step 1318. If use of the tag is appropriate, steps 1320 and 1322 are executed to modify the command buffer appropriately. FIG. 15 depicts a logical flowchart relating to a command function invoked by occurrence of the tag :IF, which is named ParseIf. The :IF, :ELSE and :EIF tags provide conditional processing support in the language. Up to six levels of conditional nesting are allowed. When an :IF tag is located, all tags up to the next :ELSE or :EIF tag (whichever comes first) are executed unless the condition specified is false. If the condition is false, the interpreter will be required to branch the next command in the sequence. The process is entered at step 1400 with recovery of three tokens from the current line. At step 1402 it is determined if the second token is a conditional operation. If it is not, step 1406 is executed to invalidate the operation code. If the token is a conditional operation, step 1404 is executed to set the conditional operation code based upon the inverse of the conditional operation specified. Next, at step 1408, syntactic analysis is performed on the tag and its attribute value tokens. Conditions for valid use include: previous occurrence of the :INSTALL and :UPDATE tags; absence of any invalid operation code; avoidance of exceeding the maximum conditional nesting allowed; and absence of too many attributes associated with the tag and supplying of a value for the second attribute. Any syntax error results in a set of the parsing error indicator and immediate return to the parse routine. Absence of error results in an incrementation of the current conditional nesting level (steps 1412 and 1414). The addition of a conditional branch command to the command buffer, setting of appropriate flags and counters respecting occurrence of the :ELSE and functions and modification of the command buffer appropriate occurs at steps 1416 and 1418. FIG. 16 illustrates the command function ParseElse invokes by occurrence of the :ELSE tag in an installation data profile file. The function is responsible for concluding the branch associated with an :IF tag. The :ELSE tag stops conditional processing provided by the previous :IF tag. The process is entered at step 1500 with syntactic analysis which essentially assures that the current :ELSE tag is associated with one and only one :IF tag and that an appropriate operator has been specified with the tag. Failure of any condition results in the set of a parsing error indicator at step 1502. Appropriate use of the tag results in the addition of an unconditional branch command to the command buffer at step 1504, inclusion of an appropriate GO TO command in the parse data at step 1506, and appropriate modification of the command buffer at step 1507. Step 1508 relates to the setting of a branch location of the previous :IF tag. FIG. 17 depicts a command function for a ParseEndIf function invoked by the :EIF tag in the installation data profile. The :EIF tag adds no command to the command buffer but rather serves to delimit a conditional processing section. The process is entered at step 1600 for immediate determination of appropriate syntactic and semantic use. Essentially the :EIF tag must be associated with a prior :IF tag. Error is handled at step 1602. At step 1604, it is determined if the previous conditional operation was based on a :ELSE tag. If YES, step 1606 is executed to fix a "GO TO command branch offset". Step 1610 is executed to decrement the current conditional nesting level. If the previous conditional operation was not a :ELSE tag, step 1608 is executed to fix a "conditional branch commands branch offset" prior to decrementation of the current conditional nesting level. FIG. 18 illustrates a command function entitled ParseCancel invoked upon occurrence of the tag :CANCEL in an installation data profile. Occurrence of the tag is used to cancel an installation and is intended for use particularly within conditional processing sections. Step 1700 relates to syntactic analysis again relating to occurrence of an :INSTALL tag or absence of an :UPDATE tag. If no installation tag is present or an :UPDATE tag is present, a parsing error indicator is set (step 1702) indicating an inappropriate syntactic use of the tag. Otherwise, a return to menu command is added to the command buffer at step 1704 and the buffer is modified appropriately to handle the line at step 1706. Installation information, such as the drive letter to which the installation is to be performed, is communicated from one command function routine to another through macros. One macro relates to dissemination of the installation target, including the drive and path which the installation is to be performed. When a user selects an installation option, the program displays a window for the user to specify the installation target drive based on the "choose" attribute of the :INSTALL tag. This sets the disk drive value in each of the drive macro values. The path value entered is set in each of six path macro values. The user specifies the installation target only once and the remaining installation data profile tags make use of this one input. Some installations require a source file to be copied to the target drive, replacing an existing file on that drive in whatever directory the files happens to exist. When the installation uses a :COPY tag with the "locate" attribute, the program first tries to locate the named file on the target drive. If the file is found in any directory on the target drive, the program copies the source file to that directory overriding the existing file. Otherwise, the program copies the source file to the location specified by the "path" attribute of the :COPY tag. In either case, the program sets the path macro specified by the attribute to contain the path value to which the file was actually copied. These macro values can be used in :TXT tags to ensure that updated files with reflect the drive/path values to which the required files were copies. One macro allows control within help windows for forcing a new page of help text. Another macro allows an installation "script" to require a file to be updated with information using the :TXT tag. Yet another macro saves the return code from either a message display or the return code of a program which was called by a :RUN tag. Another macro contains a symbolic name of the operating system that is installed on the target drive. This allows a single IDP file to be developed for both OS/2 and DOS device drive installations. All default textual information displayed by the general installation utility will exist within a separate code module, allowing that information to be provided in various languages. While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||