The PCK block describes a package in the current or an external archive. This can only be specified in the HEAD block. At least one package must be specified to make WarpIN do anything meaningful. See the "Installation Scripts" page for an overview where this tag should be placed.

The <PCK> ... </PCK> block has the following syntax:

<PCK INDEX=x
     PACKAGEID="vendor\application\package\major\minor"
     TITLE="title"
     TARGET="path"
     [BASE] [FIXED] [SELECT] [NODESELECT]
     [REQUIRES="vendor\application\package\major\minor"]
     [CONFIGSYS="statement[|modifiers...]"]
     [REGISTERCLASS="classname|dllpath"]
     [REPLACECLASS="oldclassname|newclassname"]
     [CREATEOBJECT="[REPLACE] classname|title|location[|config]]"]
     [EXECUTE="execfile params"]
     [PROFILE="profile[\application[\key]]"]
>package description displayed to the user</PCK>
In between the <PCK> and </PCK> tags, you must specify the package description as it will be displayed to the user in the "Information" window on the WarpIN container page. This description will also be stored in the global database so that it is available during de-installation too.

The opening <PCK> tag can have the following attributes:


INDEX=x
Required. This specifies the index of the package in the current archive (i.e. a decimal number). Since packages are referenced by number in the archive, WarpIN cannot find a package if you don't specify this number.

Note that this index only has to be unique for the current archive. It is not stored in the global database and only used during the installation process.

PACKAGEID="vendor\application\package\major\minor"
Required. This identifies the package for the global database. From this identification string, WarpIN determines whether the package is already installed on the computer and, if so, whether the installed package is older or newer than the package in the archive.

The ID string must consist of exactly five substrings, separated by backslash ("\") characters. Avoid ASCII characters above 127 to make sure these strings work on all computers with all codepages. You may however use spaces in the substrings. The substrings are:

  1. vendor: your company or personal name. This is displayed to the user.
  2. application: the name of the application to which this package belongs. Since only packages, not archives, are stored in the global database, this groups applications together. This is displayed to the user only during de-installation.
  3. package: package ID. This is only stored in the global database to identify the package. The user sees what is specified with the TITLE attribute instead (below).
  4. major: the major version number of the package.
  5. minor: the minor version number of the package.
Example:
SuperSoft\Super Word Processor\SpellingDict\1\0
TITLE="title"
Required. This specifies what will be displayed on the Container page in WarpIN. This can, but does not have to be, the same as the "package" substring in the PACKAGEID attribute.

This is also stored in the global database and re-displayed during de-installation. However, this is purely informational and not used to identify the package.

TARGET="path"
Required. This specifies the full path (e.g. "C:\TEST") which WarpIN will initially propose to the user as the installation path for the package. Normally, the user can then change this target path, unless you also specify the FIXED attribute (below).

This attribute supports macro resolution.

WarpIN will translate macros into actual directory names before displaying the paths to the user. If an error occurs, e.g. because a variable could not be found in the environment, WarpIN will complain and prompt for a value when the container page is entered.

BASE
Optional. If you specify this keyword, the package's path is considered a path on which the paths of other packages depend. That is, if the user changes the path of this package on WarpIN's container page, WarpIN goes through the paths of the other packages and automatically updates them too if it finds the old base path in the paths of other packages.

Example:

<PCK INDEX=1 ... TARGET="C:\TEST" BASE>Package 1</PCK>
<PCK INDEX=2 ... TARGET="C:\TEST\SUBDIR">Package 2</PCK>
<PCK INDEX=3 ... TARGET="D:\OTHER">Package 3</PCK>
If the user changes the path of the base package (index 1) to "D:\TEST2", the path of package 2 will automatically be changed to "D:\TEST2\SUBDIR". However, package 3 will not be changed since it does not contain the "C:\TEST" substring.
FIXED
Optional. If you specify this keyword, the path of this package specified by the TARGET attribute cannot be changed by the user. Otherwise the user may change this on WarpIN's container page. This is useful for files which must be written to the OS/2 system directories.
SELECT
Optional. If you specify this keyword, the package is selected for installation per default. Otherwise, it will not be selected.
NODESELECT
Optional. If you specify this keyword, the package cannot be deselected. It will always be selected for installation. Useful for "base" packages on which other packages depend.
REQUIRES="vendor\application\package\major\minor"
Optional. This allows you to specify a certain package which must be installed for your package to work. The string works just as in the PACKAGEID attribute. This is useful if a package in your product is an add-on to some other software which is distributed in WarpIN archive format also. This requires you to know the ID string of that package.

Note that in this context, the version substring ("major\minor") is understood as the minimum version of that package which is required for your package to work.

When this attribute is specified, WarpIN will query the user computer's global database for the specified package. If that package is not installed or too old, WarpIN will give the user a warning message.

CONFIGSYS="statement[|modifiers...]"
Optional. This allows you to update the CONFIG.SYS file, depending on the "statement" and optional "modifiers".

If this is specified for any package which has been selected for installation, WarpIN will display a corresponding checkbox on the "System Configuration" page (see the PAGE tag for more on that).

This supports macro resolution.

See "CONFIG.SYS changes" for about this attribute.

Examples:

<PCK INDEX=2 ...
    CONFIGSYS="SET PATH=$(1)\BIN | ADDRIGHT"
    CONFIGSYS="BASEDEV=CRASHSYS.ADD /DOCRASH | UNIQUE"
    >

REGISTERCLASS="classname|dllpath"
Optional. Registers the SOM class "classname" with the WPS, which must reside in the "dllpath" DLL. There can be several such attributes per package, all of which will be processed in the order specified in the script.

If this is specified for any package which has been selected for installation, WarpIN will display a corresponding checkbox on the "System Configuration" page (see the PAGE tag for more on that).

"dllpath" must be the full path name of the DLL containing the class. If this DLL resides on the LIBPATH, no path is required though. It is not recommended however to place WPS DLL's on the LIBPATH, because this makes de-installation more difficult.

The "dllpath" substring supports macro resolution.

Example: <PCK INDEX=2 ... REGISTERCLASS="XFolder|$(1)\bin\xfldr.dll">

REPLACECLASS="oldclassname|newclassname"
Optional. Replaces the WPS class "oldclassname" with "newclassname". "newclassname" must have been registered using the REGISTERCLASS attribute before replacing. (All REGISTERCLASS attributes are processed before the REPLACECLASS attributes by WarpIN.) There can be several such attributes per package.
CREATEOBJECT="[REPLACE] classname|title|location[|config]"
Optional. Creates a WPS object. This is similar to the REXX SysCreateObject function, except that due to the HTML-like syntax you cannot use quotes in the argument to this attribute. I hope this is acceptable. The different substrings need to be separated by "|" characters. There can be several such attributes per package.

Parameters:

REPLACE
Optional. Just as the "R" parameter to SysCreateObject. Note that this must be specified first.
classname
The WPS class of the new object. All REGISTERCLASS attributes are processed before the CREATEOBJECT attributes by WarpIN.
title
The title of the new object. Do not enclose this in quotes, and do not use commas.
location
Where the object should be created. This can either be an object ID (e.g. "<WP_DESKTOP>" or a full path.

The "location" substring supports macro resolution.

config
Optional class-specific setup strings. Everything coming after the last comma is considered to be the setup string so you can use more commas here.

The "config" substring supports macro resolution.

Note: You should give all your objects object ID's (like "OBJECTID=<APP_OBJECT>"), because otherwise WarpIN will not be able to delete your WPS objects upon de-installation.

Example: This will create a "SuperWord" folder on the Desktop and a program object for the "suprword.exe" executable in that new folder, using the target path specified with this package.

<PCK INDEX=1 ...
    CREATEOBJECT="WPFolder|SuperWord Installation|<WP_DESKTOP>|OBJECTID=<SUPERWORDFOLDER>"
    CREATEOBJECT="WPProgram|SuperWord|<SUPERWORDFOLDER>|EXENAME=$(1)\bin\suprword.exe;OBJECTID=<SUPERWORD>"
>

EXECUTE="execfile params"
Optional. This will execute a program after the package has been installed. This might be useful if you need to have additional configuration performed which is not supported by WarpIN keywords directly. "execfile" will be started in a separate session using "CMD.EXE /C execfile params" so that you can also start a REXX script.

Both "execfile" and "params" support macro resolution.

[PROFILE="profile[\application[\key]]"]
Optional. Here you can specify profile (INI file) data which WarpIN should clean up upon de-installation of this package. Note that WarpIN does not support setting INI data directly during installation. This attribute is only for de-installation.

We strongly recommend specifying this attribute if your application stores any data in the system profiles. You can specify more than one PROFILE attribute per package.

"profile" specifies the INI file which should be cleaned up upon de-installation. This can be "USER" or "SYSTEM" for the user or system profiles (usually OS2.INI and OS2SYS.INI) or an explicit full path specification of an INI file. This supports macro resolution.

"application" specifies the application to be cleaned up in the profile. If this is not specified, the whole profile is deleted.

"key" specifies the key to be cleaned in "application" of "profile". If this is not specified, the whole application is deleted.