ITK Programmer's Guide

---

Installing ITK

First of all, you need 4D 3.2.5 International or 4D 5.2.5 French or above to use ITK.

Starting with this version of 4D, external package can be FAT (containing old 68K code and native PowerPC code) and can be a stand-alone icon instead of resources that need to be installed usinf some "mover" app into the structure file.

To use these "new style external packages", you must put their icon or an alias of it in a MAC4DX folder (or WIN4DX folder under Windows) located in the same folder as your database structure file.

So, create a folder called "MAC4DX" (or WIN4DX) in your database folder if it does not already exist and put ITK's icon (or an alias of it) into that folder.

ITK is now ready to be used in your database.

For more information about the new style external packages and the MAC4DX/WIN4DX folder, see 4D/4D Server manuals and addendums.

The Mac version of ITK is also provided as windows "transported" files named "ITKMxx.4DX" and "ITKMxx.RSR", these files can be used on a Windows version of 4D Server with Mac version of 4D Client and should go into the MAC4DX folder.

Do not confuse these Mac version files with the real Windows version files, which are named "ITKWxx.4DX" and "ITKWxx.RSR".

Windows users:

ITK is composed of 2 files "ITKWxx.4DX" (the package's code) and "ITKWxx.RSR" (the package's resources).

You must put these two files in a directory named "WIN4DX", located in the same directory as your database structure file. If a directory named "WIN4DX" does not already exist, you must create it.

ITK has been tested on Windows 95 and Windows NT.
ITK is not supported with previous versions of Windows (eg. Windows 3.x).

Note: To avoid any conflict with 4D Compiler when compiling for both MacOS and Windows, you should use the same names for all your packages in both the MAC4DX and WIN4DX folders.

For example, if you named a package "PACK.4DX" and "PACK.RSR" in the WIN4DX folder, you should name the Mac version "PACK.4DX" in the MAC4DX folder.

Tips for using ITK

---

Asynchronous vs. synchronous

In order to get the best performances with ITK, here are the rules we followed while implementing ITK:
- ITK routines tries to let 4D's multiprocessing work as fast as possible by calling 4D's Idle entry point when needed,
- all TCP/IP layers are called asynchronously to get the best performances.

Default values

Any missing parameter is considered equal to 0 for numeric data or empty string for string or text data (this is automatically handled by 4D and 4D Compiler).

Ex: ITK_TCPSend($c) equals ITK_TCPSend($c;"";0)

Multihoming

ITK 1.1 and further versions provide some new features that support multihoming when running under Windows NT. Multihoming is also supported in ITKv2 and above on the MacOS with OpenTransport 1.3 or above installed.
Some routines like ITK_TCPOpen, ITK_TCPListen and ITK_TCPStrmInfo have some parameters to support multihoming.

ITK_TCPOpen has a parameter used to specify the local IP address of the stream.

ITK_TCPListen has a parameter to restrict listening on a specific local IP address.
By default, ITK_TCPListen listens on all local IP addresses.

ITK_TCPStrmInfo returns the local IP address of a connected stream.

Using ITK in demo mode

In demo mode, ITK is fully functional (like the "Pro" version) for 30 minutes.
After that delay, ITK will only return error codes or empty results.

License numbers are different for the MacOS and Windows versions of ITK.
ITK_Init can accept two licence numbers so that a multiplatform application does not have to store different license numbers.

To get your license number, you can use the order form which is available on ITK's Web site (http://www.internet-toolkit.com/).

Internet ToolKit Y2K compliance

The first two routines (ITK_Date2Secs and ITK_Secs2Date) are using dates in 4D format which is Y2K compliant, so, these routines are also Y2K compliant.

For the last two routine, Y2K compliance depends on RFC#822 and RFC#1123 which are defining date formatting. RFC#822 defines a format were the year uses only 2 digits. RFC#822 formatted string are not Y2K compliant.

RFC#1123 updates RFC#822 format to use 4 digits for the year (see RFC#1123 page 55). This makes RFC#1123 formatted dates Y2K compliant.

ITK_Secs2RFC converts a date/time value into an RFC#1123 formatted string, so, this routine is Y2K compliant.

ITK_RFC2Secs converts an RFC#822 or RFC#1123 formatted string into a date/time value.So there are two cases:

• If the string is formatted according to RFC#1123 (4 digits for the year), this routine is Y2K compliant.
   
• If the date is formatted according to RFC#822 (2 digits for the year), this routine is not Y2K compliant.
  To reduce the effect of RFC#822 formatted dates, all years below 40 and considered after year 2000 and all years above 39 are considered before 2000.
  Example:
  • "Fri, 28-Jul-95 22:50:10" -> will be considered as 1995
  • "Sat, 01-Jan-00 00:00:00" -> will be considered as 2000
  • "Fri, 25-Dec-20 00:00:00" -> will be considered as 2020

---

CQ/2-Jan-99