Section Navigation

Installation API - Functional Specification

Description

In order for us to meet our goal to be an "embedded" database, we need to facilitate the installation process for those customers who deploy InterBase. Currently we provide an Install Shield program which prompts the user for information needed to install, and then performs the install displaying the InterBase billboards. While this process is perfectly acceptable for end users, it is unacceptable for someone trying to deploy InterBase with their application, using their own install program.

The solution to this problem is to provide an install "engine" which can be invoked programmatically by the developer. This same engine can then be called by a GUI designed by us, to perform our own end user installation. In this manner we will have only one install process satisfying the needs of the end user as well as the developers deploying InterBase.

This engine would have to be in the form of a library (most likely a DLL) which can be called by any windows program, and thus any install program the developer might choose to use, including Install Shield. This implies that we move away from using Install Shield, and completely re-write of our install process. This is necessary since our current install is not very maintainable, nor expandable, and does not satisfy the needs of our developer community.

User Interface/Usability

The Install API has ten entry points:

isc_install_set_option
isc_install_unset_option
isc_install_clear_options
isc_install_precheck
isc_install_execute
isc_uninstall_precheck
isc_uninstall_execute
isc_install_get_message
isc_install_load_external_text
isc_install_get_info

For convenience to the user, and maximum flexibility of the design, we will define the following types:

OPTIONS_HANDLE which is a void*
TEXT which is char
MSG_NO which is a long
OPT which is an unsigned long
FP_STATUS which is a function pointer of type int (*fp_status)(int status, void *status_arg, const TEXT* description)
FP_ERROR which is a functions pointer of type int (*fp_error)(MSG_NO msg_no, void *status_arg, const TEXT* description)

These functions have the following interfaces.

MSG_NO isc_install_set_option(OPTIONS_HANDLE* phandle, OPT option)

return

The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, The VAR may call the function isc_install_get_message to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.

phandle

The address for the handle. The handle will need to be set to 0L be the user before calling this function the first time. Once the functions completes succesfully, it will point to an options list managed by the install engine.

option

For the InterBase product, this can be any one of the following values:

INTERBASE: Install all InterBase components, and their related files. This is the same as specifying IB_SERVER, IB_CLIENT, IB_CMD_TOOLS, IB_GUI_TOOLS, IB_DOC, IB_EXAMPLES, and IB_DEV.
IB_SERVER: Install the Server component of InterBase. This includes the server, the license file (if present), the message file, the guardian, the server configuration tool, the database information tools (GSTAT, and GDS_LOCK_PRINT/IBLOCKPR), the UDF library, the international character set library, and the help files (Windows only). Also make all necessary additions to the registry, including the creation of the InterBase service on NT (Windows only). Modify the services files to add 3050/tcp.
IB_CLIENT: Install the Client component of InterBase. This includes the client library, the license file, the message file. Also make all necessary additions to the registry (windows only). Modify the services file to add 3050/tcp.
IB_CMD_TOOLS: Install all the command line tools for InterBase. These are GBAK, GFIX, GDEF (when applicable), GSEC, GSTAT, GDS_LOCK_PRINT (IBLOCKPR on Windows), QLI (when applicable), and ISQL. This option will issue a warning if the IB_CLIENT option has not been specified. Note: This option has the same effect as specifying IB_CMD_TOOLS_DB_MGMT, IB_CMD_TOOLS_USR_MGMT, and IB_CMD_TOOLS_DB_QUERY.
IB_CMD_TOOLS_DB_MGMT*: Install the command line tools used for database management. These are GBAK and GFIX. This option will issue a warning if the IB_CLIENT option has not been specified.
IB_CMD_TOOLS_USR_MGMT*: Install the command line tools used for user management. This is GSEC. This option will issue a warning if the IB_CLIENT option has not been specified.
IB_CMD_TOOLS_DB_QUERY*: Install the command line tools used for database query. These are ISQL, GDEF, and QLI when applicable. This option will issue a warning if the IB_CLIENT option has not been specified.
IB_GUI_TOOLS: Install all the GUI tools for InterBase, and their related help files. These are currently only available on Windows and they are Server Manager (IBMGR32) and WISQL. This option will issue a warning if the IB_CLIENT option has not been specified. Note: This option has the same effect as specifying IB_GUI_TOOLS_DB_QUERY, and IB_GUI_TOOLS_DB_MGMT.
IB_GUI_TOOLS_DB_QUERY*: Install the GUI tools used for database query, and their related help files. This is WISQL. This option will issue a warning if the IB_CLIENT option has not been specified.
IB_GUI_TOOLS_USR_MGMT*: This is reserved for future use and is the same as IB_GUI_TOOLS_DB_MGMT
IB_GUI_TOOLS_DB_MGMT*: Install the GUI tools used for database management, and their related help files. This is Server Manager (IBMGR). This option will issue a warning if the IB_CLIENT option has not been specified.
IB_DOC: Install all of the InterBase documentation. This is currently all of the PDF files and their indexes.
IB_EXAMPLES: Install all the InterBase examples. Note: This options has the same effect as specifying IB_EXAMPLE_API and IB_EXAMPLE_DB. This option will issue a warning if the IB_SERVER, IB_CLIENT, and IB_DEV options have not been specified.
IB_EXAMPLE_API: This installs all API, SQL, DSQL, and ESQL example files. This option will issue a warning if the IB_CLIENT and the IB_DEV options have not been specified.
IB_EXAMPLE_DB: This installs all example databases. This option will issue a warning if the IB_SERVER option has not been specified.
IB_DEV: Install the development tools and files for InterBase. These are GPRE, the import libraries, and the header files.
IB_ODBC: Install the ODBC driver and the ODBC 3.0 driver manager.

Option's marked with * are not available in the current install. They are included for maximum flexibility, however it should be recognized that they represent more work. If it is determined that this level of flexibility in not needed, then they may be omitted.

Note

The install engine itself, will always be installed, whenever any option is installed. Whereas the install engine import libraries, and header files will be installed as part of the IB_DEVoption.

Note

These constants will be pre-defines in a C header file made available to all who will use the API. The user will be free to translate this header to any other language. It is possible that we may choose to also provide a Delphi unit, this is yet to be determined.

Note

All the options begin with IB_ since they are subsets of options for INTERBASE, in this way we could have options named IC_ as subsets of options for INTERCLIENT. In the first release of this product we will not include the IC_ options.

This function will evaluate the option specified and add all necessary nodes to the linked list of options represented by handle. Each node can represent a file being copied, or a registry entry to be created.

This function will need to be called once for every option the user wishes to add.

MSG_NO isc_install_unset_option(OPTIONS_HANDLE* phandle, OPT option)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, The developer may call the function isc_install_get_message to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
phandle: The address for the handle. The handle represents the list of options requested using isc_install_set_option. If this is set to zero an error message will be returned.
option: This can be any one of the values listed above in isc_install_set_option. If option is the only member of the list then handle will be set to zero to indicate an empty options list.

This function will access the options list pointed to by handle and remove the option specified by option. This function will need to be called once for every option the users wishes to remove. If the option to be removed is the only option currently set then the call is equivalent to isc_install_clear_options.

MSG_NO isc_install_clear_options(OPTIONS_HANDLE* phandle)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, the function isc_install_get_message may be called to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
phandle: The address for the handle representing the list of options requested using isc_install_set_option. If this is set to zero an error message will be returned.

This function will clear all the options stored in handle. This needs to be called anytime the options need to be rebuilt, and may be called at the end of the install process. Upon succesful completion handle is set to 0L.

MSG_NO isc_install_precheck(OPTIONS_HANDLE handle, TEXT *source_path, TEXT *dest_path)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, the function isc_install_get_message may be called to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
handle: The handle to the list of options requested using isc_install_set_option. If this is set to NULL an error message will be returned.
source_path: The path where the files to be installed are located. In most cases this will be a path on the CD-ROM, since this will most-likely be our source media. If this is set to NULL then this check is skipped, otherwise the existence and readability of this path is checked. This parameter is needed so that the pre-check can verify that InterBase is actually located in the source directory. The function will return n error if it could not read the path attributes.
dest_path: The path to which we wish to install. If this is set to NULL then the disk space check is skipped. This path is checked for existance, and if it does not exist the rest of checks is skipped. If the path does exist, then we will check it for writability.

This function will perform all the pre install checking needed, such as:

Not allow a SuperServer to be installed if a ClassicServer is present.
The function will check source_path. The source_path will be checked for existence, that is actually a directory and for readability. The path shall be a valid directory path. To determine whether a particular path is valid check your OS manauls. The check is omitted if source_path is NULL.
The dest_path is checked whether it is a directory, if it is writeable and whether it has enough space to install the selected components. The path shall be a valid directory path. To determine whether a particular path is valid check your OS manauls. The check is omitted if dest_path is NULL or it does not exist.
Check if the destination drive/volume has enough disk space to install selected options.
Check for pre-existing, newer or older, versions of the product already running.
Check the dependencies of the options required. For example, generate a warning if the tools are being installed without the client.
Check for a valid operating system.
Check for the correct user permissions needed to install. When installing on NT the user needs an administrative priviliges.

Note

Handle should be a valid handle obtained by calling isc_set_option. Handle cannot be NULL. If this is the case, an error will be returned.

MSG_NO isc_install_execute(OPTIONS_HANDLE handle, TEXT *source_path, TEXT *dest_path, FP_STATUS *fp_status, void *status_arg, FP_ERROR *fp_error, void *error_arg, TEXT *uninst_file_name)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, the function isc_get_install_message may be called to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
handle: The handle of the options requested using isc_install_set_option.
source_path: The path where the files to be installed are located. In most cases this will be a path on the CD-ROM, since this will most-likely be our source media. This may NOT be set to NULL.
dest_path: The path to which we wish to install. If dest_path does not exists it will be created. This can not be NULL nor it can be an empty string. If you wish to get a suggested destination use isc_install_get_info function.
fp_status: A call-back function which accepts an integer from 0 to 100 indicating % completion. If this function is supplied by the user, it will be called as progress is made within the engine to allow the user to display a status bar, bill-boards, or what ever other form of progress they wish. This may be NULL, in which case no status information will be supplied to the user. The 'func' type will be pre-defined in the header.
status_arg: User defined data to be passed to fp_status. This helps the user establish the context of the function.
fp_error: A call-back function which accepts an error number. This function will process the error (such as the file is in use) and return isc_install_fp_retry for retry, isc_install_fp_continue for continue, and isc_install_fp_abort for abort. If abort is specified, the function will fail and the original error is returned. This allows the user to handle errors and inform us of the action we need to take. This may be NULL, in which case if an error occurs the function will fail and return the error.
error_arg: User defined data to be passed to fp_error. This helps the user establish the context of the function.
uninst_file_name: A pointer to a buffer in which the name of the uninstall file will be returned. This file name will be of the type ib_uninst.xxx where xxx is a sequence number. This information is to be used to create the uninstall icon. If this is set to NULL the file name will not be returned.

This function will perform the actual install, that is:

Call isc_install_precheck to ensure that the install may be performed.
Log all actions to a file called ib_install.log. This file is initially created at the temporary directory and it is moved to the destination directory upon successful completion.
Create the destination directory if it does not already exist.
Copy the files using all the correct version checks, and delayed copying methods necessary.
Increase the reference count of shared files.
Create the registry entries needed.
Install the guardian in the Services Manager on Win NT, or add the guardian to the Run section of the registry on Win 95.
Modify the TCP/IP services file (if necessary).
Write the options installed into the uninstall file for later use.
Return the name of the uninstall file.

Note

If any of the call-back functions attempt to call the Install API functions, other then isc_install_get_message, the result will be undetermined. Thus, these functions should not be calling back into the Install Engine.

MSG_NO isc_uninstall_precheck(TEXT *uninstall_file_name)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, the function isc_install_get_message may be called to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
uninstall_file_name: The name and path to the uninstall file. This will allow us to determine if InterBase has been instlled, and which options were installed. This may not be left NULL.

This function will perform all pre uninstall checking needed, such as:

Check that the uninstall file is valid.
Check that the server is not running if the server was installed.
Check for the correct user permission needed to uninstall.

MSG_NO isc_uninstall_execute(TEXT *uninstall_file_name, FP_STATUS *fp_status, void * status_arg, FP_ERROR *fp_error, void *error_arg)

return: The return value is isc_install_success if the function executed successfully, larger than isc_install_success if an error occurred, and less than isc_install_success if the function completed with warnings. In the case of a non isc_install_success result, the function isc_install_get_message may be called to obtain the error message. An exhaustive list of the error codes and messages will be generated once the high level design has been completed. Note: These will be available to the user in the header file as well as in the documentation.
uninstall_file_name: The name of the file containing the options which were installed. This information will be used to decide what we will uninstall. This can not be NULL
fp_status: A call-back function which accepts an integer from 0 to 100 indicating % completion. If this function is supplied by the user, is will be called as progress is made within the engine to allow the user to display a status bar, bill-boards, or what ever other form of progress they wish. This may be NULL, in which case no status information will be supplied to the user. The 'func' type will be pre-defined in the header.
status_arg: User dafined data to be passed to fp_status. This helps the user establish the context of the function.
fp_error: A call-back function which accepts an error number. This function will process the error (such as the file is in use) and return -1 for retry, 0 for continue, and 1 for abort. If abort is specified, the function will fail and the original error is returned. This allows the user to handle errors and inform us of the action we need to take. This may be NULL, in which case if an error occurs the fp_status is not called and the function will return the error.
error_arg: User defined data to be passed to fp_error. This helps the user establish the context of the function.

This function will perform the actual uninstall, that is:

Call isc_uninstall_precheck to ensure that the uninstall may be performed.
Remove all InterBase files that are installed. ODBC Core Files, msvcrt.dll, setupapi.dll, cfgmgr32.dll, isc4.gdb, isc4.gbk and ib_license.dat will not be removed.
Remove registry entries.
Decrease reference counts of shared files.
Remove shared files which have a reference count less than 1 except for those files which Microsoft has pre assigned to 0, such as MSVCRT.DLL.
Uninstall the InterBase Guardian and InterBase Server services on NT. Remove ibguradian.exe at Run registry key on 95/98 systems.

Note

MSG_NO isc_install_get_message(MSG_NO msg_no, TEXT *msg, int msg_len)

return: The function actually returns MSG_NO which can be checked. It may return error codes when something goes wrong. The best practice is to check the error code to ensure that the message returned is credible.
msg_no: The error/warning value to be translated. This is the same value that is returned from the functions above.
msg: A buffer in which to place the message.
msg_len: The length of the buffer sipplied in bytes. If the error/warning message does not fit in the space provided, as much of the message that will fit will be placed in msg.

This function converts the error/warning value stored in msg_no and returns the corresponding error/warning message for use by the programmer. The message returned will always be zero terminated.

MSG_NO isc_install_get_info( info_type,  option,  info_buf,  buf_size);

return: The function returns a MSG_NO which can be later used in isc_install_get_message to obtain a human readable error information. When the option parameter is used the option is validated. If the option specified is invalid, info_type specified is not valid or the buffer pointer is not valid the function will return an error . The caller should always check the return value. The contents if the info buffer is undetermined when the function returns something other than isc_install_success
info_type: This can be one of the constants defined at ibinstall.h The function will return an error of the info_type specified is not known to the install API.
option: The option we would like to receive information about. The function will return an error when the option specified is not valid. The option value is ignored when a destination suggestion is requested.
info_buf: A pointer to a buffer where the infomation requested will be returned. The buffer can not not NULL. The function will return an error if the buffer is NULL.
buf_size: This specifies a size of the buffer in bytes. The buffer length of 0 is unacceptable. It is the responsibility of the user to ensure that the actual buffer size is passed to the function. It is also the responsibility of the calller to ensure that the buffer is large enough to hold the requested information. If text information is requested then the buffer is recommended to be at least ISC_INSTALL_MAX_MESSAGE_LEN bytes. If the destination suggestion is requested then the recommended buffer size should be ISC_INSTALL_MAX_PATH. For diskspace information the result will be of unsigned long size.

The function will return the information requested by info_type. If the info_type is not option specific then the option argument is ignored. The information is returned at info_buf location. This parameter can not be NULL. A proper buf_size in bytes should be specified. If either info_buf or buf_size are NULL(0) an error will be generated. Currently 4 types of the information can be expected from the function but it is possible to add additional ones as necessary. The types of information are:

Suggested destination directory. This functionality is taken over from isc_install_precheck (5.5 undocumented functionality). isc_install_precheck will no longer suggest a destination path (Option parameter is ignored in this case).
Disk space required to install a particular option (Requires a valid option)
A human readable option name (Requires a valid option)
A human readable option description. (Requires a valid option)

MSG_NO isc_install_load_external_text(external_path)

return: The function returns a MSG_NO which can be later used in isc_install_get_message to obtain a human readable error information. When the option parameter is used the option is validated. IF the file can not be loaded a warning is returned. This is because this functionality is not essential for the rest fo the install.
external_path: This is full path to where the .msg file can be found. Most of the time this is the source_path form where the customer installs the product. A developer may choose to place the file or several .msg files into a separate sub directory and load it from there.

The function addresses the internationalization issues. It attempts to load the external .msg file from external_path location. Normally the developer would supply one .msg file. It is, however, possible to write the setup program in such a way that it can switch the languages on demand. In this case the developer should provide several .msg files.

This essentially means that we are providing a feature that will enable customers easily replace english language messages that our API issues with their own messages in a different language. For this we provide an API call isc_install_load_external_text to load a customer defined text strings stored in a disk file.

The messages that we have to store in the .msg are

error messages
options names and options descriptions
actions text. It will contain actions descriptions and actions status messages that will be logged to a text ibinstall.log file.

This might possibly end up in 3 or more different sets of messages that we have to handle. Since we know better how the messages file will look like we have to supply s necessary tool to create such a file. The proposed scenario is:

The proposed name for the tool is MAKEMSG.
The customer using our tool extracts the set of predefined text messages out to a text file that is readable and can be edited. The text file is created in such a form that it could be fed back to our tool.
The customer edits the file and runs our tool against it. The tool parses the file and creates ibinstall.msg.
It is the responsibility of the customer to copy the ibinstall.msg file to a proper location during the installation process. This is if the customer wants that the uninstall program use his messages file.
It is also the responsibility of the customer to remove the file upon uninstall.
To make use of the customized ibinstall.msg file the customer has to call isc_install_laod_external_file function.

It is possible to create several msg files. The setup program might ask the user which language he prefers to receive the install messages and switch the language momentarily. The program may switch the language as many times as it wishes. The default english messages becomes unavailable as soon as the user switches to another language unless the user also creates an external english language msg file.

These ten entry points are necessary and sufficient to write an application which will programmatically install and uninstall the InterBase product. By the way of example, here is an example of algorithm which we could use to make our end user install. The error handling is moderate and should be more elaborate in a real program.

begin
    OPTIONS_HANDLE  handle;
    boolean    done=false;
    LANG_TYPE  language;

   {
     Get user preference if desired. This is if you created translated ibinstall.msg files
     in different directories
   }
    language=get_language_choice();
    if (language <> english)
       isc_install_load_external_text(lang_dirs[langauge]);

    { Query install for all the possible option names }
    while(not all options)
    begin
       isc_install_get_info(isc_install_info_opname, option, opname buffer, ISC_INSTALL_MAX_MESSAGE_LEN);
       isc_install_get_info(isc_install_info_opdescription, option, opdesc buffer, ISC_INSTALL_MAX_MESSAGE_LEN);
       isc_install_get_info(isc_install_info_opspace, option, opspace buffer, sizeof(unsigned long));
    end;

    { Get a suggested destination directory }
    isc_install_get_info(isc_install_info_destination, 0, dest_buffer, ISC_INSTALL_MAX_PATH);

   { Present the user his choices and interact with them }
    interact_with_user();

  {
    Use isc_install_set_option and isc_install_unset_option either when interacting with the user
    or after the user pushes Install button. Zero the handle the very first time.
   }
   handle=0L;
   while (not all options)
   begin
     if(option is selected)
          isc_install_set_option(&handle, option); // Check for errors. Don't be like me
    end;
  { You can check with source_dir and dest_dir. In this case no check is performed on
     directories. Also not all of the checks are performed on the dest_path if it does not exist
  }
    error=isc_install_precheck(handle, source_path, dest_path)
    if (error > isc_install_success) then
        begin
            { if a classic server is installed, or any server is running
             * then give error and exit }
        isc_install_get_message(error, message, length(message))
            user_choice=display(message);
            do_user_choice() { I.e. terminate, return to options selection screen }
        end
    else
        if (error < isc_install_success) then
            begin
                { Some warning has occured, display it and continue }
            isc_install_get_message(error, message, length(message))
                display(message)
            end

    display_file(install.txt)
    display_file(license.txt)

   {
     You can supply no callback functions but it is not recommended because install will abort on any error.
     Some of the errors might be ignored. Some problems might be fixed by hand after the install.
     If you do not use callbacks you will not be able to appraise the user of the status
   }
    error=isc_install_execute(&handle, source_path, dest_path, NULL, NULL, NULL, NULL, NULL)
    if (error < 0) then
        begin
        isc_install_get_message(error, message, length(message))
            display(message)
            exit()
        end
    else
        if (error > 0) then
            begin
            isc_install_get_message(error, message, length(message))
                display(message)
            end
    display_file(readme.txt)

  { This is mandatory. If you do not clear options it will result in memory leaks }
    isc_install_clear_options(&handle)
    display_done()
end

Note

This algorithm does not display a status, not does it handle errors during the install process. If an error occurs, isc_install_execute would fail, and the install would not happen.

Requirements and Constraints

The first implementation of this feature will only be available on the Wintel platform (Windows 95 and Windows NT 4.0.) Once this work is complete we will use the same design to implement this feature for the UNIX platforms. Furthermore, the install API will currently only be written to install the InterBase Client/Server product, although products such as InterClient/InterServer will be kept in mind as this feature is designed. Whenever possible, the install will be written in such a way that little or no modifications have to be made to the API to allow for the installation of other InterBase products.

This install will NOT have any feature for cutting diskettes, instead it will always assume that the source is uncompressed, placed on a CD or in a temporary location on the hard drive. If our developers have a need to make a diskette installation, then we can assume that they will have a disk cutting system. In this case they can compress and cut up the InterBase distributable, and their install program will be responsible for uncompressing and reassembling our install image in a temporary location for us to use.

We will write our own GUI install program which will interact with the user and call these API's. In this way we can minimize the number of install programs in the field. This will be the installation program which we put on our CD to allow our end users to install InterBase. At this time we are not planning to provide the source to our install GUI as an example of how to call the install API. Although Pubs is welcome to the source code to use as code snippets for the documentation of the API.

It is the responsibility of the user of this API to program the following aspects:

Prompt the installer for any information needed at install time, such as destination directory, and install options, or to provide these answers for the API.
Display progress information as the install is being performed as supplied by the fp_status function.
Provide prompts for processing errors as the install is being performed as supplied by the fp_error function.
Installation of the InterBase ODBC driver, if desired, as specified by the Microsoft ODBC 3.0 SDK.
Starting of the InterBase Guardian service, if desired, on Windows NT using the Services Manager API.
Launch the InterBase License Tool to create a license based on the installers certificate ID and Key, or concatenate a valid license file to the current one, if one exists.

There are several features which were available in the previous (<=5.1) install, which will not be supported by this API in order to simplify the install process, and to increase the DBA-lessness of our product. These options are:

Prompting the user to choose the server should run as an application or as a service. In 6.0 the InterBase Guardian will be installed as a service on Windows NT and as an application on Windows 95. The server and guardian can still run as an application on Windows NT, but we will no longer present this as an install option. We might choose to document how to run the server as an application on Windows NT.
Prompting the user to choose between starting the server manually or automatically. In V6.0 the InterBase Guardian will start automatically when windows starts. If the user wishes to have it start manually, he/she may still use the services manager to make that modification, but we will no longer present this as an install option. We might choose to document how to start the server manually.
Prompting the user to choose between having the InterBase Guardian start the server every time it goes away, or only once. The Guardian can be configured either way but by default it will always re-start the server. We will no longer offer this as an install option. We already document how to configure the Guardian.
Prompting the user to choose to add the 3050/tcp entry to the services file. We are the registered users of this port, thus we should not be asking them to confirm this change. If TCP/IP is supported on the machine we will automatically add this entry.

Migration Issues

This is a completely new feature. In the past a developer would have used Install Shield to call or 'emulate' our install program. In order for the developer to take advantage of this API they will need to modify their install code. This is an acceptable change since there is a great request for this feature and much discontent with the previous solution. Of course this new feature must provide the same functionality as the current install. For example, the ability to delay copying files if they are in use, to prompt the user for any necessary input, and to be able to uninstall, amongst many other features.

This feature will NOT support Windows NT 3.51, thus our products will no longer install on this platform. In InterBase 5.0 we stated that we did not certify on Windows NT 3.51, but that it did work, as of InterBase 6.0 we will no longer be able to make this statement.

This feature represents a new application programming interface for InterBase. The implication of this new API is that technical services will have to support our customers attempting to use it and help them through any potential problems.

The V6.0 changes will cause our install program to change. This includes introduction of isc_install_get_info API call.

Sign In

Section Navigation

Installation API - Functional Specification

Description

User Interface/Usability

Requirements and Constraints

Migration Issues