This section contains most of the actual code that the script runs. It expects to receive the name of an option and an index as parameters. It also checks to see that the language specified in STF_LANGUAGE is supported. It then checks the NTN_InstallMode variable to determine what it should do. Before proceeding to the section of code that will complete the required task, the script sets up default values for all the variables of the particular option being installed.
This section checks the value of the NTN_InstallMode variable and determines the label of the code that will complete that operation. It also assigns defaults values for the variables.
This section sets the default values for the options; among them are the service name, title, and description. These three must be set in this section; however, more variables can be added as needed.
This section checks to see if there are any instances of this component already installed. If there are none, it sets the install index to one and continues. Otherwise, if one instance exists, it checks for the value of the ProductExclusive variable to determine what it should do. If it needs to install another instance of the component, it executes the utility file and finds the next available index to use.
When it is ready, the script determines the service name for this component using an algorithmic definition (install_nextstep). If the ProductServiceQuery variable is set to TRUE, the user is presented with this value and is allowed to change it. When all the variables are ready, it proceeds to the parameter modification section.
This section determines whether or not the component in question is installed. If the component is not installed or if the index is invalid, it fails with an error. Otherwise, it reads the parameters for this component from the registry (read_params). This code reads the parameters from the Parameters and ExtraParameters keys in the registry and creates a list of their values. It then loops through the list and assigns the values to the variables using a switch/case construct (assign_value_option). When that is done, there is an extra section (assign_extra_option) where other parameters that do not reside in the standard location can be read or any other code that assigns values to variables can be placed. When the variables are all assigned, the code proceeds to the parameter modification section.
This section contains the code that modifies the variables or calls out other code that modifies them. As soon as this section is entered, control is routed to subsections, one for each option (modify_params_option). These subsections should contain all of the actual modification code. When this section is done, the variables are ready to write to the registry and the code proceeds to the adjustment section.
This section takes control from the parameter modification section. If the script is supposed to configure an existing component, the control is routed directly to the code that writes the parameters to the registry. Otherwise, control falls to code that creates the appropriate service entries in the registry before it writes out the variables.
This section creates the service and registry entries for this component. It also writes out some of the values that the product entry under the SOFTWARE\Microsoft key needs to contain. This section is also currently in charge of the NCPA bindings information. If the product files have not been copied, this code shells out to the installation section that handles file copying (InstallRemove). When all the keys are created, control falls to the section that writes out the variable values to the registry.
This section first ensures that the appropriate handles are open and then routes control to a subsection that prepares the appropriate variables for registry output (write_params_option). Each of these sections must prepare the ProductParams and ProductExtraParams variables to be written to the registry. Each of these parameters is a list of registry creation lists. Each registry creation list must contain the name of the entry to be created, the NoTitle variable, the type of entry to create, and the value of the entry. See the existing link service .INF scripts.
The ProductParams variable must contain the name and option entries. Both variables can contain any additional entries that are needed. Also, any other parameter-writing code should be written in these sections. For an example, see the setup script for the NDIS 802.2 link support (SNADLC.INF).
After the subsections are finished, control is passed to the code that actually adds the list of entries to the registry. It also prepares the data return structure and finishes by using the successful escape hatch.
This section is responsible for communicating the option bindings back to SNA Server Setup. It queries the NCPA bindings, sets the information in the data return structure, and returns it to SNA Server Setup. SNA Server Setup then uses this information to determine whether this particular instance can be removed or not. An instance can be removed if it is not needed (bound to) by any other component.
This code is in charge of removing one or all of the instances for a particular product. In the case of a complete removal, it also removes the files and software entries for this product. In the case of a single instance removal, the code passes control to the remove_one_piece subsection, which handles a single removal. Otherwise, code control goes to the remove_all_pieces subsection.
For a full removal, the setup script loops through all of the instances and calls the remove_one_piece subsection for each of those instances. When the loop is complete, the code control is passed to a common point for both removal types (remove_product). The subsection remove_one_piece removes the software entry for the instance and deletes the service from the Service Control Architecture. If it is dealing with a complete removal, it returns control to the loop, otherwise, it falls to the remove_product subsection. This subsection determines whether files should be removed (full removal) and calls the appropriate installation section (InstallRemove). After all is done, it uses the successful escape hatch to return control to SNA Server Setup.
These are all the available hatches that can be used throughout the setup script.