1: Introduction, highlights and main topics

Click on any the following links for immediate help or introduction to various important topics:

NEW USERS
TABLE OF CONTENTS
MAJOR FEATURES
HELP ON HELP
FAQ
NEWS SCREEN
USER OPINIONS

Shortcut to All IVT.RC commands
Shortcut to All script keywords
Shortcut to All script function names
Shortcut to All script reserved variables

Welcome to the HELP-system of IVT. Click on this link if you want to find out what IVT is...

Below you'll find the most important topics in a logical order. There is also a table of contents that lists all chapters and sections. See "about" to get an idea of the size of these manual pages (when printed, the total manual is over an inch thick!).

Overview of topics in order of importance:

                  __ IVT supports serial lines __

                  __ IVT supports a scripting language __

                  __ Support programs for IVT __

1.1: Global description

IVT is a multi-session, LAN-oriented (but serial lines supporting) VT220 terminal emulation program for Windows.
Besides TELNET, this build also supports the SSH protocol.
The URL to download it from is described here.

If you are a Unix user who normally uses a PC to run some sort of VT100 emulator to contact your Unix hosts, this program is for you! IVT contains many features to make life easier  and is meant to be a program you want to spend most of your (working) time in.

"Multi-session" means it supports several simultaneous connections to one or more hosts in a SINGLE window.
Creating sessions is very easy, and there are numerous ways to switch between sessions, to monitor background session activity and to close sessions. The command line parameters can be used to do a variety of things, including automatic creation of all your sessions (including login).
There is the session group editor to allow interactive editing of groups.

When output scrolls from the screen, the history pager can bring it back.

One of the major features is copy and paste with the mouse and/or the keyboard. Check out the special way to copy words and phrases from the screen.
This really saves a lot of typing!

IVT is very, very configurable, using IVT.RC files.
This Windows version is also able to save the setup in the Windows registry.
See "IVT and the Windows registry" for details.

Also, IVT supports a scripting language. This powerful language can automate many tasks. It has variables and complex expressions.
It can, for example, automate the login process, while keeping your passwords hidden by encryption. The standard setup comes with a password learning system that does this for you already.

The bottom line of the screen is normally a status line that displays many important bits of information. Click the fields to change them, right-click them for help.

The keyboard is very customisable and programmable. It can automate many tedious tasks for you. You can program keys, for example. It can also lock the keyboard under timer control (or manually with ALT+l).

Almost all settings of IVT can be viewed and changed by using the setup screens.

IVT can drive a printer to save all output (or explicit screen prints) to a real printer or to a file. Printouts are automatically sized to fit the paper.

AUTOLOG is very handy for making transcripts of sessions (log to file).

IVT also transfers files, using X/Y/Zmodem protocols with automatic recognition of a ZMODEM file transfer. If you have RZ on Unix, you can drop a file on the IVT window and it will start the transfer.

If you use IVT over a serial line you can still run several sessions over that single modem connection by using the Multiplex protocol and the ivtm multiplexing program.

There are many more features - see the table of contents for ideas...

1.2: Where can I obtain IVT?

Currently, IVT can be obtained from http://www.softwarevoordelig.nl/en

This is the commercial version of IVT with support for Kerberos V5 authentication and DCE/Gradient integration.
It also supports SSH.

1.3: List of major features.

Throughout the manual you'll find topics that are highlighted as being a "major feature". All such topics have a hyperlink to the previous and next topics. This screen serves as a start and an end of the list.

Follow this list to get a quick impression of the strong points of IVT.
Follow this link to go to the first such item.

1.4: Licence agreement

BEARSTAR SOFTWARE PRODUCT LICENSE AGREEMENT

This BearStar Software Product License Agreement (the "Agreement") is made between you, the end user customer ("Customer"), and BearStar Software, a Dutch Corporation  ("BearStar").

IMPORTANT - BY CLICKING ON THE "YES" OR "ACCEPT" BUTTON, OR INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR OPENING THE PACKAGE, YOU ARE CONSENTING TO BE BOUND BY AND ARE BECOMING A PARTY TO THIS AGREEMENT AND ARE REPRESENTING THAT YOU ARE DULY AUTHORIZED TO EXECUTE THIS AGREEMENT ON BEHALF OF YOUR COMPANY.  IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, CLICK THE "NO" OR "DO NOT ACCEPT" BUTTON, DO NOT USE, INSTALL OR DOWNLOAD THE SOFTWARE, OR IF APPLICABLE, DO NOT OPEN THE PACKAGE, AND, IF APPLICABLE, RETURN THE SOFTWARE TO BEARSTAR.  IF YOU HAVE EXECUTED A WRITTEN MASTER SOFTWARE LICENSE AGREEMENT WITH BEARSTAR FOR THIS SOFTWARE AND THE TERMS AND CONDITIONS OF THE MASTER SOFTWARE LICENSE AGREEMENT CONFLICT WITH THE TERMS AND CONDITIONS OF THIS AGREEMENT, THE APPLICABLE TERMS AND CONDITIONS OF THE MASTER SOFTWARE LICENSE AGREEMENT SHALL APPLY.  THIS LICENSE AGREEMENT CONTROLS AND SUPERSEDES ANY PURCHASE ORDERS ISSUED BY YOU FOR THIS SOFTWARE.
THIS SOFTWARE IS PROTECTED BY COPYRIGHT LAWS AND INTERNATIONAL COPYRIGHT TREATIES, AS WELL AS OTHER INTELLECTUAL PROPERTY LAWS AND TREATIES.

1.      Grant of License.  During the term of this Agreement, Customer will have a non-transferable and non-exclusive license (without right to sublicense) to: (i) use the specified version of the BearStar Software Product(s) in object code form and associated documentation, if any (collectively, the "Product") for the specified number of machines or servers and in accordance with the terms and conditions of this Agreement and (ii) reproduce the Product as reasonably needed solely for inactive backup or archival purposes.

2.      Intellectual Property Protection; Restrictions.  The Product and all intellectual property rights therein, including code, operation, architecture, implementation, and look and feel, are and shall remain at all times the exclusive property of BearStar and its licensors.  The Product is protected by international and United States copyright laws and treaty provisions.
Nothing contained in this Agreement shall give or convey to Customer any right, title or interest in the Product, except to the extent of the license rights expressly granted by this Agreement. Customer may not modify, translate, reverse engineer, decompile, disassemble, or create derivative works or emulators of the Product except to the extent that BearStar is required to grant such rights under law for the purposes of achieving compatibility with third-party software or hardware and in such event Customer shall notify BearStar and BearStar shall have a reasonable opportunity subject to a reasonable fee for doing so to create a version of the Product which is compatible with Customer's platform and environment.
However, BearStar shall not be obligated to create such version.
Customer may not use the Product in a service bureau or outsourcing arrangement.  Customer may not delete or alter any copyright, trademark or other proprietary rights notices of BearStar and its licensors, if any, appearing on the Product and Customer will reproduce such notices on all copies made of the Products.  Customer may not distribute, sublicense, rent, lease, sell, transfer or grant any rights for the Products in any form to any third party without the express written consent of BearStar.
In the event of any breach of this section BearStar has the right to seek injunctive or other equitable relief.

3.      License Fee; Payment.  In consideration of the rights granted herein, Customer will pay BearStar the associated license fees within thirty (30) days of invoice date in U.S. dollars or other agreed currency to the attention of accounts payable.  If Customer does not pay an invoice(s) when due, BearStar may charge a late payment fee on the unpaid amounts equal to the lesser of ten percent (10%) per annum, or the maximum legal rate.  Customer will be responsible for, and will promptly pay, all taxes of whatever nature (including but not limited to value added, sales and use taxes) and shipping charges associated with this Agreement or Customer's receipt or use of the Product, except taxes based on BearStar's net income.  Such taxes shall not be considered a part of, a deduction from or an offset against license fees.
At BearStar's option, once per calendar year, an independent certified public accountant selected by BearStar and reasonably acceptable to Customer may, at BearStar's expense, and upon reasonable notice and during normal business hours, and subject to a confidentiality agreement, audit the appropriate records of Customer to verify that Customer's use of the Product is in compliance with the terms of this Agreement and the associated license fees.
If the associated license fees pursuant to the audit are different than those paid, Customer will be invoiced or credited for the difference, as applicable.

4.      Termination. This Agreement is effective until terminated pursuant to this Agreement.  Either party may terminate this Agreement at any time on written notice to the other in the event of a material breach by the other party (which includes failure to pay license fees) and a failure to cure such default within a period of thirty (30) days following receipt of written notice specifying that a default has occurred.  Upon (i) the institution of any proceedings by or against Customer seeking relief, reorganization or arrangement under laws relating to bankruptcy, insolvency, receivership or liquidation which proceedings are not dismissed within sixty (60) days; (ii) the assignment for the benefit of creditors, or the appointment of a receiver, liquidator or trustee, of any of Customer's property or assets; or (iii) the liquidation, dissolution or winding up of Customer's business; then and in any such events this Agreement may immediately be terminated by BearStar upon written notice.  Upon termination, all licenses granted hereunder shall terminate and the Customer agrees to cease using the Product, purge from its electronic memory devices all copies of the Product and return to BearStar, promptly, the Product and all related documentation.  Termination shall not relieve Customer from paying all fees accrued prior to termination.
The provisions entitled Intellectual Property Protection, Confidentiality, Disclaimer of Warranties, Limitation of Liability and General Provisions shall continue in force even after termination of this Agreement.

5.      Confidentiality.  For purposes of this Agreement, "Confidential Information" shall mean any confidential, trade secret or other proprietary information, including the Product and software code, disclosed by one party to the other under this Agreement, except for information that: (i) was previously known by the receiving party free of any obligation to keep its confidence; (ii) is now or subsequently becomes generally known to the public through acts not attributable to the receiving party; or (iii) the receiving party rightfully obtains from a third party who has the right to transfer or disclose it.  Confidential Information (A) shall be used by the parties only for the purposes set forth in this Agreement; (B) shall not be reproduced or copied, in whole or in part, except as necessary for use as authorized herein; (C) shall be distributed only to those employees of receiving party with a "need-to- know" in order to exercise rights and to perform tasks or services called for under this Agreement; and (D) shall be treated in confidence by the receiving party, and not disclosed to any third party without the prior written consent of the disclosing party.
The terms of this Agreement are deemed Confidential Information and may not be disclosed without the prior written consent of the other party, except (i) either party may disclose such terms to the extent required by law, rules and regulations or as necessary to enforce this Agreement; (ii) either party may disclose the existence of this Agreement; (iii) either party may disclose the terms of this Agreement to such party's auditors, attorneys, bankers or investment bankers as necessary for their rendition of services to a party; and (iv) BearStar shall have the right to disclose that Customer is a customer of BearStar and the Product, including in BearStar's marketing materials and Web site.  This section shall survive termination of this Agreement.  In the event of any breach of this section the non-breaching party has the right to seek injunctive or other equitable relief.

6.      Maintenance and Support; Updates. Maintenance and support or updates may be purchased separately by Customer from BearStar in accordance with the BearStar maintenance and support plan and associated fees paid by Customer.

7.      LIMITED WARRANTY.  During the initial thirty (30) day period from the date the Product is shipped, BearStar warrants that the Product will perform substantially in accordance with the applicable accompanying published Product documentation.  Customer's sole remedy for breach of the foregoing limited warranty shall be to have the deficiencies remedied or the Product replaced or to receive a refund of the pro rata amount of the fees allocable to the use of the Product, at BearStar's option. The limited warranty hereunder is void if failure of the Product has resulted from the misapplication, abuse or unauthorized modification of the Product.  Any replacement Product will be warranted for the remainder of the original warranty period.
        
8.      DISCLAIMER OF WARRANTIES. EXCEPT FOR THE LIMITED WARRANTY SET FORTH HEREIN, THE PRODUCT IS PROVIDED "AS IS" WITHOUT ANY WARRANTY WHATSOEVER.  BEARSTAR AND ITS LICENSORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED OR STATUTORY, AS TO ANY MATTER WHATSOEVER, INCLUDING, WITHOUT LIMITATION, ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY RIGHTS.  WITHOUT LIMITING THE FOREGOING, BEARSTAR AND ITS LICENSORS DO NOT WARRANT THAT THE PRODUCT WILL MEET CUSTOMER'S REQUIREMENTS, THAT OPERATION OF THE PRODUCT WILL BE UNINTERRUPTED OR ERROR FREE OR THAT ERRORS IN THE PRODUCT WILL BE CORRECTED.  IF IMPLIED WARRANTIES MAY NOT BE DISCLAIMED UNDER APPLICABLE LAW, THEN ANY IMPLIED WARRANTIES ARE LIMITED IN DURATION TO THE ABOVE WARRANTY PERIOD.  NO BEARSTAR DEALER, AGENT OR EMPLOYEE IS AUTHORIZED TO MAKE ANY MODIFICATIONS, EXTENSIONS, OR ADDITIONS TO THIS WARRANTY.
        
9.      Indemnity.  BearStar at its own expense shall (i) defend, or at its option settle, any claim or suit against Customer on the basis of infringement of any UK patent, copyright, trademark, or trade secret by the Product in any country that has a bilateral trade agreement on intellectual property rights with the U.K. and (ii) pay any final judgement entered against Customer on such issue or any settlement thereof; provided (a) BearStar has the right to control and direct the defence and/or settlement, (b) Customer notifies BearStar promptly in writing of each such claim or suit and gives BearStar all information known to Customer relating thereto, and (c) Customer cooperates with BearStar in the settlement and/or defence. If all or any part of the Product is, or in the opinion of BearStar may become, the subject of any claim or suit for infringement of such intellectual property rights, BearStar may, and in the event of any adjudication that the Product or any part thereof does infringe or if the use of the Product or any part thereof is enjoined, BearStar shall, at its expense, have the option to: (i) obtain the right to continue use of the Product; (ii) replace or modify the Product so that it is no longer infringing and has substantially equivalent functionality; or (iii) if none of the foregoing remedies is commercially feasible, refund the license fees paid by Customer hereunder, if any, less depreciation for use assuming straight line depreciation over a five (5)-year useful life and terminate this Agreement. Notwithstanding the foregoing, BearStar shall have no liability under this section if the alleged infringement arises from (i) the use of other than the current unmodified release of the Product, (ii) use of the Product in a manner other than that specified in this Agreement, or (iii) modification of the Product or combination of the Product with other equipment or software not provided by BearStar, in each case if such action would have been avoided but for such use or combination.  Notwithstanding anything to the contrary in this Agreement, the foregoing states BearStar's entire liability and Customer's exclusive remedy for proprietary rights infringement relating to the Product.
        
10.     LIMITATION OF LIABILITY.  EXCEPT FOR A BREACH OF SECTION 5 (CONFIDENTIALITY), NEITHER BEARSTAR NOR ITS LICENSORS SHALL BE LIABLE TO CUSTOMER OR TO ANY THIRD PARTY FOR CONSEQUENTIAL, INDIRECT OR INCIDENTAL, SPECIAL OR EXEMPLARY DAMAGES, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOST DATA, RE-RUN TIME, INACCURATE INPUT, USE OF DIGITAL CERTIFICATES OR DIGITAL SIGNATURES, WORK DELAYS, INABILITY TO ACCESS THE INTERNET, TELECOMMUNICATIONS FAILURES, HACKERS, BUSINESS INTERRUPTIONS OR LOST PROFITS, EVEN IF CUSTOMER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, ARISING OUT OF THIS AGREEMENT OR USE OF THE PRODUCT OR SERVICES PROVIDED BY BEARSTAR.  EXCEPT FOR A BREACH OF SECTION 5 (CONFIDENTIALITY), UNDER NO CIRCUMSTANCES SHALL BEARSTAR'S LIABILITY TO CUSTOMER OR TO ANY THIRD PARTY ARISING OUT OF OR RELATED TO THIS AGREEMENT OR THE PRODUCT OR SERVICES, EXCEED THE AMOUNT PAID BY CUSTOMER HEREUNDER, REGARDLESS IF ANY ACTION OR CLAIM IS BASED ON CONTRACT, WARRANTY, INDEMNITY, NEGLIGENCE, STRICT LIABILITY OR OTHER TORT OR OTHERWISE.  

Customer acknowledges that no computer system or software can be made completely secure, and that the use of the Product does not guarantee the safety or security of Customer's systems or information.  Customer is responsible for implementing and monitoring appropriate security procedures and for making appropriate back-up copies of all data.

11.     Export Compliance and Foreign Reshipment Liability.
THE PRODUCT IS SUBJECT TO EXPORT, REEXPORT AND IMPORT RESTRICTIONS.  CUSTOMER SHALL NOT EXPORT, REEXPORT, OR IMPORT, DIRECTLY OR INDIRECTLY, THE PRODUCT OR INFORMATION PERTAINING THERETO TO ANY COUNTRY TO WHICH SUCH EXPORT, REEXPORT OR IMPORT IS RESTRICTED OR PROHIBITED BY THE GOVERNMENT OF THE UNITED STATES OF AMERICA OR THE LOCAL LAWS OF CUSTOMER'S JURISDICTION, OR AS TO WHICH SUCH GOVERNMENT OR ANY AGENCY THEREOF REQUIRES AN EXPORT OR IMPORT LICENSE OR OTHER GOVERNMENTAL APPROVAL AT THE TIME OF EXPORT, REEXPORT OR IMPORT WITHOUT FIRST OBTAINING SUCH LICENSE OR APPROVAL.
        
12.     U.S. Government End Users.  For any Products acquired directly or indirectly on behalf of a unit or agency of the United States Government, this provision applies.  For civilian agencies: the Products were developed at private expense; are existing computer software and no part of them were developed with government funds; are a trade secret of BearStar for all purposes of the Freedom of Information Act; are commercial items and thus, pursuant to Section 12.212 of the Federal Acquisition Regulations (FAR), the Government's use, duplication or disclosure of the Products is subject to the restrictions set forth in this Agreement and is incorporated into the contract or purchase order between BearStar and the U.S.  government agency; in all respects are proprietary data of BearStar; and are unpublished and all rights are reserved under the copyright laws of the United States.  For units of the Department of Defense ("DoD"): The Products are commercial computer software (and commercial computer software documentation), and pursuant to DoD FAR Supplement Section 227.7202, use duplication or disclosure of the Products is subject to the restrictions set forth in this Agreement and is incorporated into the contract or purchase order between BearStar and the U.S. Government agency.

13.     General Provisions.  This Agreement shall be governed by and construed in accordance with the laws of the Netherlands, irrespective of its choice of law principles.  The parties agree that the United Nations Convention on Contracts for the International Sale of Goods shall not apply to this Agreement.  Except as otherwise provided herein, this Agreement shall be binding upon, and inure to the benefit of, the successors, executors, heirs, representatives, administrators and assigns of the parties hereto.
Notwithstanding the foregoing, Customer shall not have the right to assign this Agreement, by operation of law or otherwise, without BearStar's prior written consent, not to be unreasonably withheld.  Any such purported assignment of this Agreement without obtaining written consent shall be void and of no effect.  If any provision of this Agreement shall be found invalid or unenforceable, the remainder of this Agreement shall be interpreted so as best to reasonably effect the intent of the parties hereto.  The failure of a party, at any time or from time to time, to require performance of any obligations of the other party hereunder shall not be deemed a waiver and shall not affect its right to enforce any provision of this Agreement at a subsequent time.  Any purchase orders or similar documents relating to the Product issued by Customer or otherwise will have no effect on the terms of this Agreement.  This Agreement constitutes the entire understanding and agreement of the parties hereto with respect to the subject matter hereof and supersedes all prior and contemporaneous agreements, understandings, or purchase orders between the parties.  Any term or provision of this Agreement may be amended, and the observance of any term of this Agreement may be waived, only by writing signed by the parties to be bound thereby.
Except as otherwise provided for in this Agreement, any notice, demand, or request with respect to this Agreement shall be in writing and shall be effective on the date received (unless the notice specifies a later date) only if it is sent by a courier service that confirms delivery in writing, or if sent by certified or registered mail, postage prepaid, return receipt requested, addressed to the respective address of the party, attention to Legal Department.  Any party may change its address for such communications by giving notice thereof to the other party in conformity with this Section.
In any action to enforce or interpret any part of this Agreement, the prevailing party shall be entitled to recover, as an element of the costs of the suit and not as damages, reasonable attorneys' fees to be fixed by the court (including without limitation, costs, expenses and fees on any appeal).

Snipweg 33,
7331 LS Apeldoorn, The Netherlands.

1.5: Copyright Notice PuTTY

Much was learned from studying the source of PuTTY, an SSH/TELNET client that is open source. Bits were copied and modified, improved and merged with IVT, as permitted by the licence as long as it is stated clearly and the text of the licence is copied. Unicode character handling and full-screen mode are examples of such derived code. So:
Start quote:
------------------
PuTTY is copyright 1997-2001 Simon Tatham.

Portions copyright Robert de Bath, Joris van Rantwijk, Delian Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry, Justin Bradford, and CORE SDI S.A.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
------------------
End of quote.

And I would once more like to thank the authors of PuTTY for making this available. IVT also borrowed most of the SSH code from PuTTY, which was modified to support the multi-session feature of IVT and extended in various ways to integrate better with the rest of IVT. Having the source of a working SSH client for Windows made this a *lot* easier.

1.6: Command line parameters of IVT

IVT accepts the following parameters on the command line (click on any of the hyperlinks for more information):

VERSION: xx.yy. USAGE: IVT [{-|+}<options>] [VARS] <host> <loginname> [args]

   -A    : Automatic startup from CREATE statements in IVT.RC
   -agrp : Automatic startup, use group code 'grp'.
   -B    : Suppress display of graphic introduction (banner) screen.
           See also SPLASHTIME.
   -Cscr : Call script scr when connection to host established (see ONCONNECT).
   -cfile: Use 'file' as the ONLY IVT.RC file.
   -h    : Enter hypertext manual of IVT (complete on-line documentation!)
   -n    : No attempt to do autologin.
   -p    : Secure mode - No sub-processes started ever
   -s    : Secure mode - No multiple sessions, no sub shell
   -u url: Parse URL and open a new tab in a running instance (or starts IVT).
   -x    : Turns status line off
   -L    : Suppress appending of .LOGIN to NetBios hostnames
   -N    : Use NetBios protocol stack
   -d    : Direct mode (Ignored, no LAURA NAMESERVER support compiled)
   -l    : List (Ignored, no LAURA NAMESERVER support compiled)
   -Pprof: Select prof as startup PROFILE.
   -S    : Use serial protocol
   -D    : use DUMMY protocol.
   -W    : Use WINSOCK/TELNET protocol.
   -2    : Use SSH Version 2 protocol.
   -4    : Force use of IPv4
   -6    : Force use of IPv6
   Multiplex protocol available.
   File transfer available.
   Scripting language available.
   Receive file (ESC g) and Run command (ESC R) available.
   Support for encrypted .RC files available.
   Challenge/response protocol available.

1.7: Version number of IVT

IVT is under continuous development. New features get added regularly and the few bugs that may exist get fixed real fast.

When problems exist, it is important to be able to identify the version used.
Therefore, the version number is displayed when IVT is invoked with bad parameters (see usage).
It is also displayed in the about screen.
Furthermore, the support e-mail address is displayed there too, so you know where to send questions for support.

See the news screen for a detailed description of new features.

Compile time features are shown when you invoke IVT with bad parameters.

1.8: The news screen explained

The F4-N screen documents the development of IVT.

The $IVTBUILDNR uniquely identifies each build of IVT. Every time something significant is changed in the functionality, the change is documented in the news screen, identified by date and IVT version number.
The idea is that, every time you get a new version of IVT, you use F4-N to read up on the changes and extensions in functionality that might affect you.
When you run a new version for the first time, IVT will show this news screen automatically (but see NO_SHOWNEWS).

The last character of the version number is changed every time an executable is released (bug fixes, very minor changes).
The minor digit of the version number is changed every time something significant is changed (new features, changed functionality).
The major digit of the version number is changed after major overhaul.

1.9: Passing command line options

As shown in the usage screen of IVT, it is possible to specify a lot of different options on the command line. The options can either be preceded by a + or by a -. Using a - will turn an option ON, using a + will reverse the meaning of an option.

So -s will turn secure mode ON and +s will turn it off.

Some options take an argument. This must NOT be separated by spaces from the option letter itself, so:

  -cc:/my/startup.rc

must be used to force IVT to read only the specified start-up file and no others (the option is -c and the argument is c:/my/startup.rc).

You can also use the OPTIONS keyword in an IVT.RC file to change the options that were specified on the command line.

Currently, options are not stored in IVT variables so there is no easy way to find out (in a script) what options are in effect.

1.10: Assigning script variables from the command line

Between the last option and the hostname on the command line, you can specify multiple arguments in the form of:

   Variable=value
   "Variable=Value with spaces"

IVT will GSET all variables to the specified values, making these variables available in all subsequent sessions (unless destroyed using UNSET).

This way, you can pass information into IVT from the command line.
See also ONCONNECT, to start a script as soon as the session is established.
See also BATCHMODE, to specify you are using IVT as a batch application.
See also $ENV_ variables to reference the environment.

1.11: Specifying a hostname on the command line

The hostname IVT is to connect to initially, is either specified on the command line directly or specified using a CREATEGRP statement combined with the -A or -agrp options on the command line.

Hostnames depend on the protocol that you use to contact a host. For example, when you use a serial line connection there really is no 'host', but only a communications device that you must specify (a modem port). So a command line might look as follows:

        IVT -S com2,9600,n,8,1

This will direct IVT to use a serial protocol, and the initial connection should be to COM port 2, with a given baud rate, parity, data bits and stop bits setting. Once IVT is started, you can create other sessions (either to another serial port, or by changing the PROTOCOL, to an entirely different type of host).

I'm very proud of the multi-protocol support of IVT - it will run anything over anything, and different sessions are supported on different protocols simultaneously. I have used TCP/IP sessions from my home-PC to my home Unix box while at the same time using the modem to dial out to another Unix box that used IVTM to enable me to run several sessions there also.

You can read more about these protocols in this chapter.

1.12: Passing a URL on the command line (-u)

IVT is integrated with a browser (like Firefox or IE) as of version 22.1a.
A browser can follow a link of type:

   ivt://hostname/[Statement[;Statement;...]]

This will cause IVT to be executed, passing it the URL with a preceding "-u" option. This new instance of IVT will first determine if there is an instance of IVT already running and available for a new session. If no instance is running, or the instance found is busy in some way, IVT continues with normal startup. If an instance is available, the URL is passed to it.

Either way, the URL is interpreted as a command to open a new session.
If that instance of IVT is viewing the built-in manual, or using setup, or using some other dialog or feature, the user will have to return to normal session mode before the session can be created.

The hostname can be any form of hostname IVT normally accepts, and if that is the only information in the URL, IVT will open a session to that host with default settings.
However, additional information can be passed in the URL.
As an example:

   "ivt://rohan.snipweg.wxs.nl/PROTOCOL SSH;NO_GUI_RESIZE"

Would cause IVT to behave as if those commands were read as part of a script, so the protocol will be SSH and resizing will be disabled.
There is no limit to the number of statements that can be passed this way.
All statements heve to be separated using semicolons (;).
IVT understands escaped characters in the URL of form %XX (two hex digits) to encode a single ASCII character. So the above can be written as:

   ivt://rohan.snipweg.wxs.nl/PROTOCOL%20SSH;NO_GUI_RESIZE

All commands are synthesized into a script that is executed just like a PRECONNECT script - before the session is established. The same rules apply.
Another example:

   ivt://rohan.snipweg.wxs.nl/USER=ruurdb

This will connect to the given host and attempt to login as the given user.
By default (when no user is given), IVT will use the auto login system, which will select a default user for the host.

Note that this can be used from a command file (shell script) to cause new sessions to be opened inside a running IVT, or have an HTML page with links to your machines that IVT will connect and login to by clicking on those links.
For this to work, there must be a HKEY_ROOT_CLASSES\IVT key in the registry of windows with the appropriate values to point the browser to the IVT executable.
IVT will attempt to insert those values into the registry every time it is started and when it is installed. However, this requires admin priviliges, so depending on your environment, this may or may not work.

The -u command line option is always available from a command file, however.

If you have multiple copies of IVT running, the first one returned by Windows is asked to open a new session (the others are ignored).
It is, however, against the design idea to have multiple instances of IVT, the multi-session features of IVT make this unnecessary.

See also $IVT_URL_STARTUP and $URLUSER.

You are viewing this in a browser. If this feature works on your PC, clicking here:
ivt://DummySession/PROTOCOL "DUM";BEEP;Call NonExistingProc
should open a session to a host called DummySession using the DUMMY protocol. It should also BEEP and emit an error message about a CALL to a procedure that does not exist.
Every time you click it, the same IVT instance should open a new tab with an identical session.

This is an important feature, others are prev/next

2: Several useful facilities of IVT

2.1: The scroll back buffer

IVT can store text that has scrolled from the top (or bottom) of the screen. This is one of the major features of IVT, and one that you quickly learn to rely upon. Long running make's with lots of output, error messages that get displayed to be cleared immediately by broken software - IVT can bring it back to the screen.

The amount of memory that is used can be specified using HISTORY.
The default number of saved screens is 10.

IVT can page through the history screens by entering the pager, which is accomplished by typing one of the commands below. Once in paging mode, the ALT is optional, and the keys move the screen in the expected direction:

Using the scrollbar is an even easier way to access this history data.
Also, you can use the mouse wheel to scroll.
NOTE: When you use the mouse wheel, an extra feature is available. If data arrives on the session while you are viewing history, older versions of IVT would display all that data in a flash when you exited from the history viewer.
Starting with version 23.0 of IVT, this data silently becomes part of the history, so when you use the mouse to scroll to the end, more and more of this new data is displayed just as if it were part of the history data all along.
This works only when you use the mouse to scroll. When you use the keyboard and try to keep up with incoming data, some of the PgDown or Cursor-Down keys would be seen as history-viewng commands (and handled locally by IVT), but when you actually catch up with the incoming data and IVT exits the viewer, all these keystrokes would suddenly go to the remote host, with unpredictable results. So, when you use the keyboard, only ESC exits the viewer and all data that has arrived in the meantime is displayed as fast as IVT can manage.

Of course, you can also cut from the screen or print it (F2).
This can also be combined (use mouse or ALT+c to select part of the screen, then use F2 to print just the selected part).

Typing ESC exits the pager. Typing any data-generating key other than ESC will also exit the pager and send that keystroke on the session.
If you use the scrollbar or mouse wheel, the pager exits automatically when you reach the end (i.e. current screen) part of the history.

You can search through the history buffer using the same method as in the IVT manual pages, which look familiar to users of VI:

• The '/' character starts a search. In this case the default is to search from the end of the buffer towards the beginning (most recent data first). As an alternative, you can use F3 or Ctrl-F to start a search. Matching strings are highlighted using the colors specified using the COLORSEARCH keyword, default is a bright-yellow background. This is very convenient to quickly spot matches.
• The '?' character searches in the opposite direction. Multiple matches in a single line are supported.
• An 'n' command searches for the next occurrence.
• An 'N' command reverses the search direction.

Searches can also be started from the pager menu bar.

Incoming data on a session is blocked while you are viewing history.
You can switch to another session from the history-pager! However, the session stays blocked until you return it to normal mode. This allows you to view error-messages from (say) a compiler on one session while fixing them on another.

For reasons of efficiency, duplicate lines are filtered from the history file.
For example, when the Unix 'vi' editor starts, it clears the screen, then prints a ~-character at the start of every line. Only one blank line and one line with a ~ are stored in the history file. This may sometimes distort the images of screens, but usually nothing important is lost this way.

The entire contents of the history buffer (for the current session only, of course) can be saved to a file. This makes it easier to search or edit it outside of IVT. This is only possible when the secure option is disabled.
To save the file, type ALT+s while in the pager (or use the menu).

The "Edit" menu on the menu bar contains two items to manipulate the scroll back buffer:

• Clear scroll back.
  This simply deletes the contents of the scroll back buffer.
• Copy all to clipboard.
  This places the entire contents of the scroll back buffer on the Windows clipboard. This can also be accomplished by using a normal mouse copy command but this can be a time-consuming operation when you have a large buffer.

Note that the 'Extra' menu on the session menu bar has a command to print the contents of the clipboard.

This is an important feature, others are prev/next

2.2: Using the mouse

I have gone through considerable lengths to make the mouse usable in IVT.
The following possibilities exist:

• Configuring the default mouse action.
• Configure IVT to behave like PuTTY/XTERM with word-selection.
• Simple cutting and pasting with the mouse.
• Cutting and pasting with the keyboard.
• Advanced cutting and pasting with the mouse.
• Using multiple cut/paste buffers with the mouse.
• Programming the mouse in combination with the keyboard.
• Leaving the current selection visible.
• Resizing the terminal window with the mouse.
• Clicking on the various parts of the status line.
• Selecting a session in the F4-S screen with the mouse.
• And, of course, navigating these manual pages.

Click on any of the above for more information.

2.2.1: Configuring the default mouse action.

The default action for the mouse can be programmed with the MOUSE command in your IVT.RC file.
The default is CUTPASTE, which means the LEFT mouse button will initiate a CUT operation, the RIGHT mouse button will paste the default buffer.
The default buffer is the clipboard.
You can, of course, change the mouse-action from this setup-screen and save the new setting into the registry.

Furthermore, the MOUSE_KEY command can be used to program actions that are initiated when a mouse button is clicked in combination with keyboard keys.
Such actions can be programmed for individual sessions (MOUSE_KEYLOC) or for all sessions (global MOUSE_KEY statements).

2.2.2: Simple cutting and pasting with the mouse

The basic mouse-driven CUT operation is started by clicking the LEFT mouse button (see MOUSE command to change this behaviour).
At the start of the CUT, you have a select window (the colours of which can be set with the COLORCUT command).
Drag the mouse around to select the part of the text you wish to copy.
When the mouse nears the top or bottom of the screen, it will auto scroll up or down to show history data, see GUI_COPYSPEED. Pressing SHIFT will triple the scroll-speed.
Release the mouse button, the window will disappear (DO NOT BE ALARMED).
X-windows leaves the selection on-screen, which I think is wrong, since it alters the display more or less permanently. IVT will restore the application screen when you have finished a CUT operation.
Update: see the LEAVE_COPY_SELECTION to change this behaviour.
Update: see the MOUSE_SELECTION make IVT behave like PuTTY/XTERM.

The selected area is now stored in the default buffer. It can be viewed by typing F4-K. It is also stored on the Windows clipboard, so you can paste the contents into other applications.

Pasting is accomplished (by default) by using the RIGHT hand mouse button.
This will actually paste the Windows clipboard again (in case you have used another application to modify the clipboard).
The contents are pasted into the current session.

For people with a minimalist mindset, this is all you need to know.
However, IVT supports various advanced actions to cut words and sentences in various efficient ways. See below for details. Please take the time to read that, it can save you lots of time in the long run!

2.2.3: Advanced cutting and pasting with the mouse.

A common action is to select words and phrases from the screen. This can be done with the simple cutting, but there are quicker ways:

• Click in a word, AND KEEP THE LEFT BUTTON DOWN. Then click AND RELEASE the RIGHT mouse button. IVT will select the current word. Every time you click and release the right mouse button, IVT will extend its definition of a 'word', until the entire line is selected. This works only when the current selection is WITHIN a single line. See MOUSE_SELECTION to alter this.
• The F12 key accomplishes the same as the right-hand mouse button.
• The PageUp key extends the selection to the top of the screen.
• The PageDown key extends the selection to the bottom of the screen.
• The HOME key extends the selection to the beginning of the history.
• The END key extends the selection to the end of the history.
• The F11 key is an 'undo', it DECREASES the selection instead of extending it (undoes mouse-click, and all listed keys).
• The F2 key prints the selected area to the current printer.
• Any alphanumeric key: store in a named buffer.
• F10: Interpret selection as host names and connect to all of them.
• The ESC key aborts the cut operation.

The F1 key can be used to toggle between BLOCK-select and LINE-select.
In the default BLOCK-select mode, IVT selects a rectangular block of characters. In LINE-select mode, all lines between the first and last are selected entirely (like most word-processors do).
The default behaviour can be changed using the CUTMODE keyword.

All these keys allow you to quickly select a particular area of the screen using the default paste-buffer. See below for a description of MULTIPLE buffers.

2.2.4: Using multiple cut/paste buffers with the mouse.

The previous paragraphs describe how text can be selected and stored in the default paste-buffer. However, sometimes a single buffer is inadequate. An editor like VI maintains multiple (named) buffers to store text in. IVT can do the same.

During a CUT operation you can type a single alphanumeric key. This will end the CUT-operation and store the selected text into a paste-buffer with that name. A PASTE can be done either with the mouse or from the keyboard:

• Press the RIGHT mouse button and KEEP IT DOWN (when you release it, the DEFAULT buffer is pasted). Press the same alphanumeric key again, the named buffer will be pasted.

• Type SHIFT+ALT+p (just ALT+p will paste the default buffer). Release the keys and then press the named alphanumeric key again; the named buffer will be pasted.

Special feature: When the alphanumeric key you type is in UPPER case, IVT will APPEND data to the buffer with the lower-case name, rather than replacing data. This is similar to what VIM (Vi Improved) does.
You can use this to grab bits and pieces of text into the same buffer. You cannot append data to the default (unnamed) buffer this way.
See also ESC<space>e, which allows the host to control the contents of the clipboard and the named IVT copy/paste buffers.

The current contents of all named (and default) paste buffers can be viewed on the F4-K screen.
Use F4-K-W to save them to a file. F4-K-R will read such files.
See also the LOAD keyword in IVT.RC files.

2.2.5: Programming the mouse in combination with the keyboard

It is possible to configure the mouse to send data on a session, or even to interact with the host in complex ways by means of a SCRIPT.
See the MOUSE_KEY statement, which allows you to configure this, either as the default action for a mouse button or an action that happens when you press a keyboard key in combination with a mouse button.

2.2.6: Cutting and pasting with the keyboard.

Normally, you would perform cut and paste operations with the mouse.
However, you can also perform cut/paste operations using the keyboard. You enter cut-mode by typing ALT+c. As a bonus, you can also edit the screen contents while performing a keyboard-driven cut-operation. This allows you to edit mistyped commands in environments that do not support command-editing.

The idea is to first move the cursor to the position on the screen that is the start of the area to cut (using cursor keys, HOME/END, etc). Then you press control (and keep it down) and use the same keys to extend the selected area. Press RETURN to terminate the cut-operation. Press ESC to abort.
When you do a SHIFT+RETURN, you can type a key to store the named buffer.

Valid keys while cutting with the keyboard are listed below:

A keyboard paste is done by typing ALT+p (default buffer).
See also SHIFT+ALT+p for pasting named buffers.

2.2.7: Resizing the terminal window with the mouse.

The window can be resized in the normal Windows ways.
The new size will also be communicated to the remote host if the current protocol allows it (TELNET and MULTIPLEX, for example).
The upshot of this is that, when for example VI is running in a TELNET session, it will receive a notification from Unix that the window size has changed. This will cause VI to redraw the screen according to the new number of rows and columns.

The new window size will be the default for sessions created from the resized one. Different sessions can have different window sizes and positions, IVT will try to make the behaviour of these sessions 'logical' (position of the window when switching between sessions of different sizes).
You can also choose to propagate a size change to all sessions using the SIZE4ALL feature (normally, every session's size is independent of the others).

The new size can also be saved into the registry by typing F3, followed by a click on <SAVE>. The chosen size is now the default terminal size for future invocations of IVT.

2.2.8: Clicking on the various parts of the status line.

The status line in an IVT session is mouse-aware. The following possibilities exist:

• Click on the numbers indicating the current and total number of sessions.
  The FIRST number will perform a 'switch to previous session'. This is equivalent to CTRL+Cursor-Left.
  The SECOND number will perform a 'switch to next session'. This is equivalent to CTRL+Cursor-Right.
  This allows you to switch between sessions without touching the keyboard. Another way for this is to use the WINDOW item on the menu bar.
• The part that shows the the status line hostname will give the F4-S (session management) screen. Here you can click on a line that describes a session and IVT will switch to that session (equivalent to typing F4-S followed by the number of the selected session).
• Clicking on the status line clock will cycle through the various possibilities this part of the status line (see STATMIDDLE).
• A right-click on any of the status line parts will show instant help for that particular item.
• Clicking on the various icons does various logical things. Right-click on them for help.

When you hover the mouse over the various parts of the status bar little tooltip windows try to make you aware of the possibilities.
These can be turned off using NO_TOOLTIPS.

2.2.9: Selecting a session in the F4-S screen with the mouse.

The F4-S screen allows session maintenance. It is entered by either typing the F4 key followed by an 's', or by clicking on the appropriate part of the status line.
Another way is to use the WINDOW item on the session menu bar, select the "Session overview" item there.

All existing sessions are displayed here. Simply double-click on the line that describes the desired session and IVT will switch to that session.

You can also rearrange the order of the sessions here by using the up/down buttons.

2.2.10: Interpret selection as host names and connect to them all

If you select text on the screen using either the mouse or the keyboard and press the F10 function key while selecting, IVT will interpret all words in the selection as host names and will create an instant group of sessions to them all. This can be very convenient if you have some selection of hosts on screen that you need to correct some problem on.

This function is also available from the "Edit" menu, so you can use some other application to store information on the clipboard and let IVT interpret the contents of the clipboard as host names.

This function will use the current value of $URLUSER as the name of the user to login. When not set, the password learning system will attempt to find a default user. If you have disabled password learning, you will have to login manually.
You can also use a PRECONNECT script to set the value of $URLUSER dynamically.

When the number of hosts in the selection is less than 4, a failed connection is treated normally (error messages, the session is kept so you can read the errors and close the session manually). For a larger number of sessions, the failures are quietly deleted, so if you select a large number of words, some of which are valid host names and many are not, the result will be that you end up with sessions (tabs) for the valid hosts only.

2.3: Locking the keyboard

It is possible to lock the keyboard either explicitly or under timer control.
Unlocking the keyboard is done by typing the password followed by a RETURN.
First, the password must have been defined. This can be done by using the PASSWORD directive in an IVT.RC file. The password can be:

• A simple literal word (unsafe);
• An encrypted password (very safe).

An encrypted password can be obtained by using the 'IVT-locking password' on this basic setup-screen. When a password is typed here, the one-way encrypted version is displayed. This 13-character long string must be used as the parameter for the PASSWORD directive in the IVT.RC file.

For your convenience, the encrypted version of the password is placed on the Windows clipboard, so it can be pasted into a PASSWORD statement in your IVT.RC file.

The keyboard is locked by typing ALT+L. A lock-icon (keys) will appear on the status line.

Another possibility is to use the LOCKTIMER keyword in the IVT.RC file (or by setting it using setup). This specifies the number of minutes that must pass before the keyboard is locked automatically when no keyboard activity is detected. 30 seconds before the keyboard is locked, IVT will beep and start a countdown in the status line. Type a key to abort the countdown.

2.4: The "Scripts" menu

IVT has had the possibility to create a "Custom" menu for many years. This allows you to have a home-rolled entry on the menu bar that contains entries to start scripts of your own making. Few people use this powerful feature, so in release 21.1 is has been made more prominent.

The standard configuration file of IVT now uses this to define an entry called "Scripts", and creates 4 menu-entries in there:

• Key broadcasting.
• Project file loading.
• A script to manage a local address book.
• A "Help" entry that explains how to extend the menu (which takes you here).

By editing the IVT.RC file, or - better - overriding or extending the default configuration in your own local IVT.RC file you can start your own scripts with just a few mouseclicks, too. The standard IVT.RC file uses INCLUDE_OPT on the HOMEDRIVE/HOMEPATH environment variables to load a personalized configuration file (normally C:\Documents and Settings\YOUR NAME\ivt.rc).
That file is typically intended to extend/alter (or suppress) such a menu.

See the stock IVT.RC file for more examples, and the MENU keyword.
See also DELSCRIPT to delete a loaded script.

2.5: Project files

IVT is very configurable, through very many means, and can be used for very large projects, large groups of users, and is able to provide all sorts of powerful features to make life easier for those large groups of users.

Unfortunately, all this power is not always easy to find, or to use.
A script, added in December 2007, called "Projects.ivt" tries to make configuration of IVT in such complex environments easier.

In short, a "project" presents itself to the user as magically appearing entries in the address book, and magically appearing "Create groups" in the GROUP menu. Connecting to a host also uses a proxy when required, and "knows" how to connect and login (ssh, telnet, special attributes, special login constraints like OS hardening, etc).

In more detail, what a "project" tries to achieve is:

• Provide a central place where complex IVT configuration files can be stored to be shared by all users who want it;
• A single place for the address book of a project, where all hosts required for a project are named and described and specific attributes can be specified for every host or group of hosts;
• Optional HOSTS files to translate names to IP-addresses for a project's hosts (for organizations that do not have DNS entries for all (temporary) hosts);
• Optional SSH-key files so you are not presented with a "Host-key unknown" dialog the first time you connect to a host using SSH;
• Projects can be loaded when IVT starts, using the command line or the new "Scripts" menu bar entry, or user-specific configuration files.
• Project files can be private, or stored in a number of configurable places.

The project files themselves must be written using a text editor. Every project has at least:

• A main configuration file.
  The name of the file can be any name with a ".rc" extension (acme.rc).
• A title.
  The first line of the configuration file must be a comment with a description of the project. E.g.:

  # This is the ACME example project

  The rest of the file intended to have at least a bunch of HOSTLIST commands to list and describe the hosts of the project, and all settings and scripting required to manage the hosts of the project. See the example files for suggestions.
• Optionally, a file with the same basename as the project.rc file called project.hosts. So, if you have an acme.rc file, this would be called acme.hosts. The file must be a Unix style /etc/hosts file that can be used by the RESOLVE statement to translate host names into IP-addresses. It is meant to list all names and IP-addresses of the hosts in the project. If you have a decent DNS infrastructure, you probably do not need this.
• Optionally, a file with the same basename as the project.rc file called project.ssh. This can contain SSH keys created by the "export keys" feature of IVT (Menubar, Setup->Setup system->SSH->Manage SSH keys->export to file). Having such a file will prevent that every user will be asked to accept the host key of a host when the first SSH connection is made.

All files of a project (acme.rc, acme.hosts and acme.ssh) must be in the same directory. There is one directory built into the projects.ivt script where IVT will look for project files ($IVTDIR/Projects).
The standard distribution of IVT has an example project there. But that directory is private, and one of the major benefits of projects is that they can be shared by all people who work on a project.

To facilitate this, the projects.ivt script will use a FORALL on variables named "PROJECTSDIR_*".
Every such variable is assumed to name a directory that is searched for .RC project files. For example:

GSET PROJECTSDIR_ACME_GENERAL = "Q:/Program files/IVT/Projects"
GSET PROJECTSDIR_ACME_SALES   = "P:/Sales/IVT/Projects"

would cause IVT to look in those (network) directories for projects.
It is not an error to have variables for non-existing directories, the script will simply look for valid files and ignore bad directories, bad files or empty directories.

So, to summarize:

• Projects can be stored in directories pointed to by PROJECTSDIR_ variables.
  You can set these in the main IVT.RC file (see there for examples) or on the command line of IVT when you start it.
• Each project has at least one configuration file with at least a title.

So, this tells the projects.ivt script where to FIND project files, but these files are not READ (loaded) automatically. There are various ways to get a project loaded:

• After startup (while looking at the "Create session" panel), click on the menu bar "Scripts" entry and choose "Load project files". You can pick a single project or use the "Load all" button.
• On the command line, use a PROJECT variable and assign it the basename of a project. You can also specify multiple projects, similar to project directories, by assigning multiple variables. For example, a shortcut that starts IVT might contain:

  IVT PROJECT_1=AcmeMain PROJECT_2=AcmeSales1

  This would scan all project directories for projects named AcmeMain and AcmeSales1 (identified by at least an AcmeMain.rc and AcmeSales1.rc file) and load them at startup.
• You can assign the PROJECT variables in other places (like the main IVT.RC file, or the ivt_start.rc file in your home directory or any other file that is included from the main ivt.rc file).
• If you have few projects (or only one), a simpler way is to set the variable PROJECTS_ALL to 1 (command line, file, wherever). This will simply cause all projects to be loaded at startup.
• As a compromise, you can have PROJECTSMATCH variables, which are just like PROJECT variables, only they can use wildcards (see MATCH) to select multiple projects:

  PROJECTSMATCH_1="*Sales*"

  Would select all projects in all project-directories that have the word "Sales" in them.

See the example file in the distribution directory ($IVTDIR/Projects) for an example project. Since the whole project feature is not built into IVT itself but handled entirely by scripting, you are also free to modify or extend the script itself to better suit your needs.

This is an important feature, others are prev/next

2.6: The session groups editor

A major new feature was introduced in version 16.1a of IVT - the group editor.
Before, the very powerful CREATEGRP statement was available only to people who took the trouble to read the manual, understand what it was trying to say, then use a text editor to edit the IVT.RC file and add the proper incantations. The reward would be the creation of multiple sessions with a single mouse click, all of them logged in and ready for action (if you are new to creation groups, you are urged to read this).

However, it appeared only a small percentage of the user base actually found this functionality, so 16.1a adds a number of dialogs which require only the use of a mouse and a few keystrokes to add and maintain group definitions.
These definitions are stored in the registry, are loaded on start-up and can be modified and deleted at any time.
Obviously, CREATEGRP and CREATE statements in the IVT.RC file still work as before, but these cannot be edited with this interface (if you try you will get an error message, but interactively created groups and groups from the IVT.RC file are all shown together and are started the same way).

The editor is available from the F4-G screen (or the <GROUPS> button from the login dialog, and various other ways).
It contains <ADD>, <EDIT> and <DELETE> buttons.
The <ADD> and <EDIT> bring you to a dialog that allows the maintenance of a single group. A group is identified by its name and an optional description which will appear in the F4-G screen.
You can also specify an optional script and parameters here. When given, the script is executed before the first session in the group is created. It can be used to set global variables to be used by all sessions in the group. The parameters are parsed before being used, for example:

   "First parameter" "Second parameter"

will pass two parameters to the script. Use quotes to protect parameters with spaces in them.

For descriptions of the "Preconnect" and "Onconnect" scripts, see the details at the CREATEGRP manual page.

One of your groups can have the "Start group when IVT starts up" option set.
If you check this box, IVT will pretend you have used the "-agroupname" command line option, and start all the sessions in the group automatically every time you start IVT. The saves you the trouble of having to create a special shortcut with special options to start IVT in a special way, at the price of ALWAYS having the sessions created when you start up.
Only ONE group can have this checkbox set.

A group can contain zero or more CREATE statements, of which the most important attributes are shown in the dialog box. Choose <ADD> or <EDIT> to get a dialog to define a single CREATE statement. The attributes are:

• Host name. This is the name of the host you want to connect to. If you want to connect to a non-default port, use hostname:portnumber.
• User. This is the name of the account you want to use. It is assumed that you have logged in before to that host with that account, and IVT has used its password learning system to learn the password for that account. Because only when IVT can do the actual login and get to a prompt, will it be able to run a script and initialise the session. Besides basic user-id passwords pairs, IVT can use Kerberos authentication and SSH key pairs.
• Protocol. This is the PROTOCOL string for the session. You can use a few abbreviations like TLN (WINSOCK,TELNET), SSH (WINSOCK,SSH) here. It has to be a valid specification of an IVT supported protocol.
• Group code. This is the application group code. Basically, all sessions with the same group code behave as if they run in a separate instance of IVT. The current group is shown in the status line.
• Repeat factor. Leave empty for a normal, single session. Any number you enter will clone that many sessions, which differ only in the comment (it shows the cloned sequence number).
  Be careful: if you enter 500 here, IVT will attempt to log you in 500 times in parallel (and it might even succeed), but few hosts will take kindly to such abuse.

• Start in a new window.
  When this is checked, the session is not created in the current instance of IVT, but a separate instance is started (a new window opens) and that IVT does all normal startup and then connects to that particular single host. See "Starting a session in a new window" for more information.
• Title. This ends up in the status line for that session as comment. What you enter here overrides the automatic comment (user@host + number).
• Script. The name of the script called when the session is established. See below for details.
• Params. Optional parameters for the optional script.

These last 2 items offer very interesting possibilities. Take, for example, the script from the IVT.RC standard distribution called DirCmd (for change DIRectory and run a CoMmanD). It takes 3 parameters, the first being a directory, the second being a command to start after changing to that directory, the third the optional name of yet another script.
The DirCmd script looks like this:

Script DirCmd dir cmd ScriptNm
   HIDE
   LOCAL x

   # Give a decent error message when this script does nothing...
   x = Call IvtWaitLoggedIn
   IF $x == 0 THEN                                      \
      ECHO Concat("DirCmd: Cannot do ",                 \
           ($dir != "") ? "CD $dir " : "",              \
           ($cmd != "") ? "do $cmd " : "",              \
           "because login failed or is disabled.\n") :  \
      RETURN

   # When a directory is passed, CD to it.
   IF $dir != "" THEN Send "cd $dir\n" : \
                      Call WaitPrompt

   # When an initial command is given, execute it
   IF $cmd != "" THEN Send "$cmd\r"

   # If a scriptname is given, call it
   IF $ScriptNm != "" THEN CALL $ScriptNm
END

So, you could set the "Script" field to "DirCmd", and the "Params" to e.g.: /tmp "ls -lab\r" MyScript

Note that the parameters are parsed as if they occurred in an IVT.RC file, so they can be string expressions, reference variables, and so on.
Quotes are significant and important when you have spaces in arguments!

The example will change directory to /tmp, run ls -lab there, and then call the MyScript script (this will have to be written with a text editor, but it is optional, i.e. normally you will pass only two parameters to DirCmd).

After defining any number of entries for the group, click OK and you will return to the F4-G screen. All definitions are automatically saved for you.

The defined group can now be launched by double-clicking it (or select it and click the <LAUNCH GROUP> button).

2.7: Fixing broken groups

As explained in the previous chapter, a CREATEGRP is a very powerful way to quickly create and initialise a number of sessions. If you use this feature often, you'll find that you rely on the fact that certain sessions are in certain logical positions (session 1 for your editor, 2 for the compiler, 3 for test runs, etc). However, sometimes one or more of these sessions can be lost due to network outage, machine crashes, accidental logout, etc. This leaves you with one or more "holes" in your logical ordering of sessions: a broken group.

One way to fix that would be to manually create the missing sessions and drag them to the proper position using the tab bar or the session re-ordering dialog. A better and quicker way is to use the "Fix" button in the create session groups dialog (Sessions->Start groups of sessions).
If you select a group there that has one or more sessions missing, but at least ONE session of a group left, clicking it will re-create the missing sessions in the proper sequence and place, restoring the normal situation.

When zero sessions of the current group are left, or all sessions of the current group are still intact, the "Fix" button will be disabled (you can't fix it if it ain't broken).

If you have a CREATEGRP script, it will be run again with an adjusted value of the $IVT_GROUP_COUNT variable (the number of missing sessions).

The current state of a group can also be queried using the QuerySetting function with an argument of GROUPSTATE.

When you use IVTFUNCTION to start a group fix, the 3d parameter must specify the name of the group to fix.

2.8: Starting a session in a new window.

The CREATEPROT statement (used in an IVT.RC file) and the interactive session group editor both allow you to specify the "NEWWIN" option, indicating that a particular session should be started in a separate instance of IVT (in a new window).

Actually, this feature goes against the general design of IVT, which is a "multi-session terminal emulator". The multi-session features allow you to create and manage many sessions in a single instance of IVT. The idea behind its design is that you have one large window to view all that goes on in all sessions. Still, some users are so used to having a window-per-session that they have trouble working any other way. This NEWWIN feature is intended to allow such users to use the session-group features of IVT, so they can still create many sessions with a few mouse-clicks.
Of course, you can always start multiple copies of IVT and run single sessions in them, but is is tricky to manage that properly when you have many sessions.

In a normal session group, all sessions have the same size and color scheme, and share a single window position. You switch between the sessions by using the tabsbar, the keyboard or the mouse.

When you want to start a group of more than two or three windows, it becomes necessary to automatically position and size the various windows on your monitor. The easiest way is to assign a profile to each session that you start in a group. For example, suppose you have a group of 5 sessions, and you want to run each of those sessions in a separate window. You want each window to have its own size and position, and possibly color scheme.
To set this up, do:

• Start the first session manually, and size and position it as you like it.
• Change other attributes (like colors, or any other setup item).
• You probably want to turn the tabsbar off, since there is not much use for it in an IVT running only a single session (Setup, windows setup, uncheck the "TABs bar enabled" option).
• Similarly, you may want to turn the menu and status bar off, to save space.
• Go into setup (F3), click on "Window setup".
• For "Window position", choose "Positioned".
• Click "Ok".
• In the main setup panel, click on "Save as".
• Type a name for the current setup, like "group-1".
• Click "save".

You have now created a session profile (called "group-1") for the first session in your group. This profile stores all the ALTERED setup attributes of the session. Repeat as required for the other sessions, uniquely naming the profile (like group-2, group-3, etc).

Now create the group. If you use the interactive group session editor, enter the name of the profile (group-1, group-2) in the "Profile" text field and check the "Start in a new window" checkbox.
If you use CREATEPROT statements in an IVT.RC file, use the PROFILE=group-x clause and the NEWWIN option.

Now you can start the group. Every session that has the NEWWIN attribute will start in a new window and gets the specified profile assigned to it.
The profile will load and apply all settings (size, position, etc.) for that session. If something is not OK for a session, just use setup for that session, alter it, and re-save (overwrite) the profile.

Note that all your profiles are based on the default profile. So, if you change a setting in the default profile which is not explictly set in the group profiles, the group-profiles will inherit the new default setting. That can save lot of work when you want to change a default setting and you have many profiles.

This is an important feature, others are prev/next

2.9: Learn mode & Keyboard macros

It is possible to store a number of keystrokes under any key so when that key is pressed the pre-recorded keystrokes are 'played'. A key can be programmed in learn mode. Programmed keys can be saved in the F4-K screen and loaded upon IVT start-up by the LOAD command in an IVT.RC file.

Alternatively, programmed keys can be saved as part of setup, either as the default profile or a special profile.

Learn mode is entered through this setup screen (choose the button labelled <Keyboard macros>) in setup. An 'L' is a shortcut for this button.

SUMMARY:

• Every possible key-combination can be programmed, the macro recorder can (optionally) distinguish between left & right shift, left & right alt and left & right ctrl keys.
• Optionally, the current state of the CAPSLOCK key, the NUMLOCK key and the SCROLL-LOCK key can be programmed, so you can have separate sets of keyboard mappings for all combinations of Ctrl/Shift/Alt/Caps/Numlock/Scroll-lock!
• Optionally, you can distinguish keys on basis of the scan-code, so e.g. the DEL key on the numeric keypad and the DEL key on the main keyboard can be distinguished.
• You can have macros for *all* sessions or just for the current session.
• Recorded keys can be saved to a file and loaded on start-up of IVT, or saved as part of setup.

Every programmed key can either:

• Be the equivalent of a predefined string. The string is evaluated when the key is pressed and can reference script variables.
• Play a recorded sequence of keys using the recorder. Optionally, the recorder will also record the delays between keys and use the same delays when the key is played back.
  There is no limit on the maximum length of a recording, other than imposed by available memory.
• Invoke a script, either synchronously (the script must be simple and quick and is not allowed to do a blocking operation such as a WAIT) or asynchronously (a THREAD is started in the background and can do whatever it likes and take as long as it needs). Synchronous scripts are useful to perform actions in a known order, since IVT waits for every invocation of the script to finish before processing the next keystroke.
  Asynchronous script are useful when you want to start a complex action when you type a key.
  See also KEYMACRO, BIND and BIND_ASYNC.

Type F3 and click on "Keyboard macros" to bring up a dialog that allows you to treat one key at a time.
First, you have to choose the key to program (or handle otherwise). Click on the button marked <Choose key to program>. The key you type next is always treated "raw", so if there is an action associated with that key it will not be executed when you type it now.

The original dialog will now show the full name of the key you typed, according to the options selected below.

There are a quite a few options you can choose:

• This session only.
  When selected, the key will have special meaning for the current session only, all other sessions are unaffected. When de-selected, the key will be special in all current and future sessions, but is lost when IVT exits (but see <Read/Write macro files>, and you can save ther current setup and the keys will be saved as part of that). When the key already exists in the selected context, the <Delete key> button is enabled. It can be used to delete the programming of the selected key, so the normal meaning of the key is restored (unless an identical key is programmed in another context).
• Match LEFT/RIGHT Shift/Ctrl/Alt.
  When any of these is selected, IVT will distinguish between the left and right keys on the keyboard when the key is defined, and only match the key when typed in the same way. It even distinguishes *both* keys being pressed simultaneously, so you can program a key by itself, the same key left- shifted, right-shifted and both-shifted, each combination is a uniquely recognized key-macro!
  If that is not enough, you can also combine shift, ctrl and alt, so you might have "Right-Shift + Left-Alt + Right-Ctrl + F7" if you can manage to press all those keys together!
  When an option is selected, the name of the key will change to show the significance of the left/right selection. When an option is deselected, the choice of left/right is unimportant. The name of the resulting key can be stored on the clipboard using the button "Copy text to clipboard". This is for use in a KEYMACRO command that you could enter in an IVT.RC file.
• Match CAPSLOCK/NUMLOCK/SCROLL LOCK.
  When the above is still not enough, the state of the locking keys can also be taken into account. When these options are selected, the state of the locking keys during definition of the macro must match the state when the key is typed. This allows you, for example, to have one set of key definitions when Scroll-Lock is off, and an entirely different set when Scroll-Lock is on! And yet other sets for all the possible combinations of Capslock, Numlock and Scroll-lock!
  When an option is deselected, the state of that particular key is unimportant. However, you will find it hard to type a lower-case character when CAPSLOCK is on and you have programmed a lower-case character :-)
• Match Scan Code.
  Some keys have duplicates on some keyboards. Common examples are the INS and DEL keys on both the numeric keypad and the main keyboard. Others are the cursor keys, PageUp/PageDown and so on which are duplicated on the numeric keyboard when NUMLOCK is off. Normally, when you program the PageDown key, any of the duplicates can be typed to trigger the macro. When this option is selected, IVT distinguishes (on the internal scan-code) which key you used during definition of the macro, and you must type the exactly same key to trigger the macro.
• Recursive expansion.
  When not selected, the key that you program can contain keys that are also programmed without expanding them. When selected, typing keys that are already programmed while programming a key will result in the playing of that second key. As an example, suppose ALT+p (paste the default buffer) is programmed to emit bar.
  If you now program ALT+b to be fooALT+p, the result will be foobar WITH recursion, and fooALT+p WITHOUT recursion. In the first case, reprogramming the ALT+p (default paste buffer) has no effect on the ALT+b, in the latter the new contents will be pasted.

Various fields and buttons will be enabled or disabled according to this choice. All selections are retained between various macro-definitions so you can quickly create many similar definitions.

• <Delete key>.
  When you choose a key that already has a definition in the selected context (session or global), this button will be enabled. Clicking it will remove the definition (and all recorded data and associated settings) for that key. In other words, this restores the standard action for the particular key. Note that you can have key-macros for both the session and the global list, so you may have to delete TWO key-definitions to make a key "behave" again.

Type of programming.
When you type a programmed key, the action the macro can take depends on this setting. It can be 4 different actions:

• Keyboard recorder.
  You must record the keys once (after pressing <Start recorder>). IVT will remember everything you type until you end the recorder (either by pressing Ctrl+Shift+End, by using the menu bar or by using F3-L. When the key is typed, playback is at maximum speed.
• Keyboard recorder + timing.
  Same as above, but IVT also records the delays between the keystrokes as you type them, and uses the same delays when during playback. Be careful: Long recordings take long to play back, and during this time the keyboard - by its very nature - cannot be used for other tasks! The time to the FIRST keystroke recorded is reset to zero, so you can start the recorder, organize your thoughts and then record a macro quickly and efficiently. When you play the macro, the first keystroke is played immediately, the rest at the same speed as you typed them. The maximum delay between 2 keystrokes is 32 seconds. If you wait longer than that, IVT silently records 32 seconds.
• Fixed string.
  The string you type here is actually a string expression! It can contain special characters (\n, \t and so on), hexadecimal characters (\XX where XX must be two valid hexadecimal digits) and even references to IVT script variables. The expansion is done every time when the key is typed, so this can be used for various tricks. If you want to send a $ sign, make sure you escape the $ sign with a backslash. By defining an EMPTY string, you effectively DISABLE the key, since it will evaluate to nothing. If you want to program an ESC sequence, you can do this like: \1B[17~ Since the "\1B" is an escape character. The field can be much longer then it would seem - the contents of the textbox will scroll as you type.
• Script call - blocking.
  Script call - asynchronous.
  You will have to specify a value for "Script to invoke". This field is - like the one above - a string expression. Every time the key is pressed, IVT will read the FIRST token from what you type here and evaluate it as a string expression. The result should be the name of a valid script. The rest of the string you type is seen as a list of expressions that are passed as parameters to the script. The field can be much longer then it would seem - the contents will scroll as you type. A script can either be: blocking or asynchronous. Blocking means that when the key is pressed IVT executes the script and waits for it to complete, the script will be killed when it attempts to perform a blocking operation.
  Asynchronous means the IVT will start a background thread for the script and continues immediately, it does not wait for the processing of the script to complete, and thus there are no restrictions on what the script is allowed to do.
  Note that IVT can become quite busy if the scripts you invoke in async mode takes a long time and you press the key repeatedly, since many instances of the script will run simultaneously. Perhaps this script feature is best illustrated with a few examples: MyMacro a
  Results in the script "MyMacro" being called with a single parameter with the value "a". MyMacro "Test Example" demo
  Two parameters, one containing a space. $COMPLICATED "$IVTBUILDNR" demo 2
  First obtains the current value of the variable "COMPLICATED", interprets that as the name of a script, calls it with 3 parameters, first of which is the value of a built-in IVT variable and the next two are constants. When the script does not exist, you will get an "Undefined script" error message.
• Internal IVT function.
  The key is tied to one of the internal functions of IVT, see IVTFUNCTION. You will have to select the desired function from a long list. This allows you to re-assign all the built-in features of IVT to key combinations you desire.

For the "Fixed string" or "Script call" types you will have to click <OK>.

When you click on the <Start recorder> button, programming will start for the other types.
You will now be returned to your session. Everything you type will now be remembered 'under' that key. The status line will show an icon to indicate learn mode ON.

Programmed keys can be nested (when recursion is in effect) up to ten levels deep. There is no practical limit to the length of the recording. Mouse action is NOT recorded.

Ending learn mode can be done by clicking on the menu bar (Keyboard, Stop recorder), or by going to setup and clicking on the <MACRO> button again (which will now be labelled <END MACRO>.
You can also type SHIFT+CTRL+END.
You can also click on the recorder icon in the status line, and it will disappear (stop the recorder).

The macro can be triggered simply by typing the key again. As explained before, you may have to use the exact same keys (left/right shift, ctrl and alt), and optionally have to match the Capslock, Numlock and Scroll-lock keys.
By default, all the distinctions are turned off, so any way to produce the same character executes the macro.

All the macro's you program can be saved to the registry by saving setup.

Keys can also be saved to file using F4-K-W. The resulting file can be read using F4-K-R or the LOAD keyword in an IVT.RC file.
For your convenience, the <Read/Write macro files> button is a shortcut to the F4-K screen, where you can click on <Save keys>.
Files can be loaded interactively there by clicking on <Read keys>.

There is no way a key can be edited, but it can always be re-programmed or restored to the standard meaning by clicking on <Delete key>.

The Unix keyp program can also be used to program keys. This allows per session function keys AND keyboard macros to be defined by a UNIX application.

See also KEYBOARDMOD for simple key translations, and BIND to bind scripts to a key from an IVT.RC file.
Most of all, see KEYMACRO to allow complex key-combinations to be defined in the IVT.RC file.

2.10: Help on help - The IVT manual system

IVT comes with its own built-in hypertext manual. You can get into the help system in many ways:

• By clicking on the HELP button in the create session dialog;
• By right-clicking ANY button, field or other dialog item;
• From the session screen by typing F4 (Help) followed by F1;
• Type F1 in any setup screen;
• Right-click on parts of the status line;
• Right-click on any menu-item;
• by invoking IVT with the -h option;
• and so on...

Exiting the manual-page system is done by typing ESCape. Click here for a list of valid keys in the help system.

You can scroll through the manual using the normal means (Cursor Up/Down, PageUp/Down, Home and End will do the expected things). You can also use the mouse to click on the appropriate places on the status line.
You can, of course, also use the vertical scroll at the right of the screen.
This bar also shows the size of each item.

Use F5 to go to the previous topic, F6 to go to the next topic.

The manual is a hypertext manual, which implies that there are words on the screen that are links to other parts of the manual. A link has to be selected first (by using the TAB key until that word is highlighted). The link is then followed by typing RETURN. This will take you to the appropriate part of the manual.
You can, of course, also simply CLICK on a link with the mouse.
Pressing BACKSPACE or clicking the RIGHT button of the mouse will return you to the previous place in the manual. IVT maintains a list of places when you follow hyperlinks, so you can backtrack your links.

You can, at any time, find where you are located inside the manual-system by typing an l for (Location) a w (for Where) or an F8. This will show a popup with the name of the chapter, topic (if any) and paragraph (if any).
This is taken from the table of contents which can also give you an idea about the contents of these manual-pages.

You can also search the entire manual for a word or phrase. Type a ?, or a / will prompt you for a word or phrase (just like VI!).
CTRL+f also works (just like Internet Explorer).
IVT will first check any word you type against the known list of keywords and topics in this manual. When a match is found, that topic will be jumped to.
This first topic-matching search is case insensitive. So, for example, if you type 'if', this will get you to the manual page of the IF statement, rather then one of the 2106 occurrences of the string 'if' in these manual pages :-)

If no match is found, the search restarts at the start of the manual, looking for a not-so-strict match.
Typing an n will take you to the next occurrence of the word or phrase, typing an N will take you to the previous occurrence (looks like VI!).
When no (more) matches are found, you will get a message stating this.
Normally, searches are case-sensitive, but you can toggle this with a C or c (for case). A popup will show the current setting.
The nearest hyperlink to the search-phrase will be automatically selected.

You can save the current topic to a file using ALT+s.
This is especially handy for the examples - save them and they are ready for use in your own IVT.RC files.

Finally, you can print the entire manual (or parts of it) by typing F2.
You will be prompted to select the appropriate part to print.
Printing will be done on whatever printer is selected.
You can print the entire manual, the current chapter (with all the topics and paragraphs it includes), the current topic (with all the paragraphs it includes) or the current paragraph (all the pages it includes), or just the current screen.
Whenever the printed output covers more then a few items, IVT will automatically generate a printed table-of-contents with correct page numbers.
Every page will also have a header showing the chapter, topic and paragraph names where appropriate. Topics are separated from each other by a solid line.

2.11: Hypertext help keyboard commands

2.12: Save current help-topic to a file.

One of the nice(r) features of the help-system is that it allows you to save the current topic to a file.
This is achieved by typing ALT+s while viewing a topic.
A popup will appear showing the description of the current topic (as taken from the table of contents).
When you acknowledge this popup with a RETURN (ESC aborts), you will be asked for a filename. When a valid filename is given, IVT will write the topic to the file you specify. Since I assume you want to use this feature to save examples of configurations and/or scripts, the following modifications are made to the output in the file:

• A comment is generated that names the chapter, topic and paragraph this came from (as shown in the initial popup).
• All lines that are NOT valid IVT.RC lines are prepended by a # character to turn them into comments. This way, you get annotated files that can be read directly as part of IVT.RC files.

Note: Saving files is impossible in secure mode.

2.13: Encrypting .RC files

IVT.RC files can contain passwords as part of logon-scripts. To avoid readable passwords in such files, IVT can read DES-encrypted files. Also, you might have other reasons to make your IVT scripts non-human readable.
This is, by the way, how the IVT password learning system works.
To set this up, do the following:

• Write an IVT.RC (include) file using any editor. The file could contain a SCRIPT (for example, 'IvtLogMeIn') that knows how to log you on to a particular host as a particular user. Examples are included.
• Use an INCLUDE statement to include this file from within your 'main' IVT.RC file (makes maintenance of the rest of the configuration easier).
• Crypt this file using SETUP (choose <Crypt files> to take you to the encrypt/decrypt panel).
  Choose a safe password, and do not forget it!
• Alternatively, choose the 'Default' password. This is a password that cannot be typed by a user (8-bit characters). This means that the file cannot be decrypted ever again! Keep a copy of the plain text file in a safe place (floppy). For an alternative approach, see the CRYPTPWD statement, though.

Upon start-up, IVT will ask for the proper password whenever it encounters an encrypted .RC file. When you do not know the proper password, type ESC (this will skip that particular .RC file). When you have multiple encrypted files, IVT will attempt to use the same password for all of them, and automatically prompt for all files that have different passwords.
Of course, IVT will always FIRST try the 'default' password, and if that works, it will not ask for a password at all.

The encrypt/decrypt feature can be used to encrypt ANY file. The algorithm is a slightly modified DES, and a proprietary IVT file format (i.e. pretty safe).

You can also manipulate encrypted files using SCRIPT functions:

• CRYPTFLPWD: Set the password to use for a particular file;
• CRYPTFL : Encrypt a file, either one-way or decryptable;
• DECRYPTFL : Decrypt a file.

2.14: Secure mode

When you pass the -s option on the command line or use the OPTIONS command in an IVT.RC file, IVT switches itself into secure mode.

This mode is intended to lock users into a particular session on a particular host without possibilities to create extra sessions, invoke sub shells or otherwise change the environment in which they work.
See also IVT_DIALOGSTATE.

This more or less assumes that you use IVT on an MS/DOS PC without windows, since on Windows PC's there are plenty of other ways a user may gain access to the environment. Anyway, when IVT works in secure mode the following things are not allowed:

• Use of the escape sequences to send and receive files from the local PC to or from the sessions (see getting files and running commands).
• Start a sub shell with CTRL+F6.
• Use of file transfer.
• Creating new sessions with CTRL+PgUp or CTRL+PgDown.
• Reading or writing key-bindings from the F4-S screen.
• Saving topics from this help system to a file.
• Saving the history data to a file.
• Dynamically adding a printer from setup.

In other words, everything to do with files and processes is forbidden. Also note IVT_DIALOGSTATE, which allows you to disable buttons, menu items or any other part of the IVT dialogs and menus.

See also the NO_STATUSCLICKS option.

2.15: Challenge response protocol

The LOGINC program can be incorporated into most modern Unices.
It is part of the distribution kit of IVT. It should be substituted for "/bin/login", at least for sessions initiated from IVT (TELNET/RLOGIN and/or serial connections you want to protect). Usually, you can specify the login program on the command line of "telnetd" in your inetd.conf file.

When used, LOGINC will do a normal prompt for a user name. It will then prompt for a "Password:" (which will appear on screen) and issue the challenge.
IVT will recognize the challenge. The next line of input you type is used to calculate the response. When you hit ENTER this response is transmitted back to LOGINC, which will check it. When OK, it is accepted as a normal password would have been, when not, it will ask again for a password (just like a normal login program would).

The upshot is that login using challenge/response is totally transparent.
I have changed IVT to issue a message Challenge received so you can see that it actually happens!

2.16: Show current cursor position

Sometimes, when you have a very large screen and a relatively small font and cursor, it is hard to find where the cursor is.
The IVTFUNCTION "Show current cursor position" briefly flashes a large red cross through the cursor so you can easily locate it.

The idea is to use a KEYMACRO to bind this function to a key you find easy to remember so you can hit that key to find the cursor.

3: IVT FAQ: Frequently Asked Questions

This chapter lists the answers to the most commonly asked questions about IVT. This is intended to be as complete as possible.
Please mail to ivtsupport@softwarevoordelig.nl if you find anything missing.

How do I start a new session?
How do I exit a session?
How can I select words/phrases on the screen with the mouse?
How do I view scrolled-away data?
I want to use colors. Can IVT do it?
How do I change and save the configuration of IVT?
The status line of IVT is hidden by the Windows taskbar. What to do?
CAPSLOCK seems to have no effect!
IVT beeps every time I touch a key
Password learning does not work if I don't HAVE a password
Can I use ALT as meta-key for EMACS?
Could IVT be used to emulate the MS Windows command prompt?
Why is there no Linux (or Unix) version of IVT?
Host-printing (controller mode) does not seem to work
HP-UX bizarre one-line display on bottom line problem
IVT fails VTTEST tests it claims to pass!

3.1: How do I start a new session?

QUESTION
I hear IVT is multi-session. How do I create an extra session?

ANSWER
Lots of ways.

• Click on the SESSIONS part of the menu bar.
• Ctrl+PageDown is the most common one.
• Ctrl+PageUp is another one, which will prevent auto-login.
• Use a CREATE statement in an IVT.RC file.
• Use a CREATEGRP statement in an IVT.RC file.
• Use a FORK.

Go to FAQ start page.

3.2: How do I exit a session?

QUESTION
How do I quit sessions? How do I get out of IVT?

ANSWER
Normally, NO_RECONNECT is in effect, which means that logging out of your host will normally make the session disappear. Quitting the last session will cause IVT to exit.
When RECONNECT is in effect, IVT will automatically reconnect to the same host whenever the session is normally terminated. Use ALT+F4 in this case to force a hang-up.
Another way is to use F4-S (or click on the hostname part of the status line) and use the DEL key. You will be asked to confirm the kill.
When the last session is deleted, IVT will exit. However, see EXPLICIT_EXIT to change this.

Yet another way: Click the close button. IVT will cleanly kill all sessions and exit ASAP.

Go to FAQ start page.

3.3: How can I select words/phrases with the mouse?

QUESTION
How can I quickly select words or phrases for pasting?

ANSWER
Configure the mouse for CUT/PASTE (default).
Point the mouse somewhere in the word. Click-AND-HOLD left mouse button.
While holding the left button, click-and-release the right-hand button.
Every time you do a right-click, IVT extends the definition of 'word'.
Release left button to finish cutting, the selection is removed from the screen (unlike X, which leaves the selection visible).

Click right-hand button to paste (or type ALT+p).
See here for more info.

See also MOUSE_SELECTION, which allows a more traditional multiple-click selection mode to be configured.

Go to FAQ start page.

3.4: How do I view scrolled-away data?

QUESTION
When data has scrolled of the screen, how do I get it back? What if I want to store more lines?

ANSWER
Type Alt+PgUp or Alt+CursorUp or Alt+Home or Alt+End to enter the viewer. The status line shows the amount of history data.
The scrollbar or mousewheel is a better way in newer versions of IVT.
The HISTORY command can be used to configure the number of retained screens.

Go to FAQ start page.

3.5: I want to use colors. Can IVT do this?

QUESTION
I have this application (like Midnight Commander or the vim editor) that normally displays beautiful colors on the console. It looks drab in IVT.

ANSWER
To be compatible, IVT transmits 'vt220' at the terminal type to TELNET hosts.
The host thinks a vt220 is a monochrome terminal, thus it will not send color commands. The solution is to install the ivt.tic file from your distribution on your Unix box (it must be compiled with the terminfo compiler called tic). This will add an ivt terminal-type to the terminfo database of the host.
Next, instruct IVT to transmit 'ivt' as the terminal type:

        TELNET_TTYPE "ivt,vt220"
        SSH_TERM "ivt"  # When you use SSH instead of TELNET

The vt220 is used as fallback in case you connect to some other host that does not have the 'ivt' terminfo entry - see TELNET_TTYPE.
Now, you should see 'ivt' in your TERM environment variable.
Unix curses programs supporting color should now work.

BTW: Midnight commander can be forced into color mode using 'mc -c'.

Go to FAQ start page.

3.6: How do I change and save the configuration of IVT?

QUESTION
I want to make changes to the setup of IVT but can't be bothered to learn all that complex IVT.RC stuff.

ANSWER
Use F3 to get to the setup screens (or use the menu bar).
Try the myriads of settings there.
Modifications will only affect the current session.
When you are satisfied, click on SETUP and "Save into registry".
Choose the default profile to change default startup settings.
Save as another profile allows you to select that profile when creating a new session.

See "IVT and the Windows registry" for details.

Go to FAQ start page.

3.7: The status line of IVT is hidden by Windows. What to do?

QUESTION
When the screen size of IVT is set to 100% using the WINDOW_SIZE command, it can happen that the resulting window is slightly too large for the physical screen. Part of the TITLEBAR or the status line is obscured by the Windows task bar at the bottom of the screen.

ANSWER
Option 1: Use 98%, or 95% instead of 100% for the screen size. IVT will calculate the number of rows based on the font and such, and should end up with one fewer row.

Option 2: Use the WINDOWPOS command with a small negative value for the Y coordinate. This will position the top of the window off-screen, making the bottom of the window visible. A value of -6 (six pixels) usually suffices.

Go to FAQ start page.

3.8: CAPSLOCK seems to have no effect!

QUESTION
CAPSLOCK is on, yet IVT still produces lower case!  What gives?

ANSWER
It's not a bug - it's a feature - see CAPSLOCK!

Go to FAQ start page.

3.9: IVT beeps every time I touch a key

QUESTION
Every time I type something, or every time the host sends something, IVT rings the bell. How do I turn the noise off?

ANSWER
You probably typed ALT+a (toggles Alert Mode). Again, it is a feature, not a bug, meant to wake you up if the machine is quiet for a long time before producing some output. Another ALT+a disables it.

Go to FAQ start page.

3.10: Password learning fails if I don't HAVE a password

QUESTION
The password learning system does not recognize that I am already logged in, it keeps waiting for a "Password:" prompt until it times out. This account has no password...

ANSWER
Correct. It is surprisingly difficult to analyse all different responses hosts can give when logging in. Therefore, you have to tell the system explicitly to set an empty password. Use F4/X, choose the password learning configuration. From the menu, choose "Add a user manually". When prompted for the password, type RETURN.
Of course, not having a password is not such a good idea...

Go to FAQ start page.

3.11: Can I use ALT as meta-key for EMACS?

QUESTION
I use EMACS extensively, how can I get IVT to send meta- commands (i.e. M-x <command>). I can, of course, use ESC-, but is there I way to get the ALT key to function as a meta key?

ANSWER
Yes. IVT supports keyboard macros that can be used to customize the keyboard.
Newer versions of IVT support the EMACS command.

Go to FAQ start page.

3.12: Could IVT be used to emulate the MS Windows command prompt? 

QUESTION
Could IVT be used to emulate the MS Windows command prompt?

ANSWER
Short answer: No.

Long answer: Just because a Unix (or VMS) prompt looks like the CMD prompt of Windows does not mean they are the same thing. IVT uses some sort of transport protocol to connect to a host (telnet, rlogin, ssh) and the host talks back in a well-defined way. There is no such protocol to connect to a command prompt on Windows. There *do* exist telnet servers for Windows which turn the Windows machine into something that IVT can connect to, but then it is not IVT doing the hard work. Depending on how well such a telnet server works, you may be able to run multiple IVT sessions to it and use IVT's session switching and cut/paste.

But even then, if you start anything on the CMD prompt that requires a GUI interface (and even NOTEPAD needs that), it won't work, since the TELNET interface is restricted to text only.
On the other hand, if you install Unix-like text-utilities such as available from Cygwin, that might provide a workable environment.

See also the next FAQ: Why is there no Linux (or Unix) version of IVT?

3.13: Why is there no Linux (or Unix) version of IVT?

QUESTION
Why is there no Linux or Unix version of IVT?

ANSWER
IVT is a VT220 emulator for the Windows platform. When you run on Linux (or Unix), a text-mode application is already running on a terminal (such as a console). Emulating a terminal is done by the operating system, so IVT would be solving a non-existent problem. Even if IVT were ported (for example because its emulation of a VT220 is better and more complete than what an Xterm has to offer), a platform like Linux already offers multi-session (multiple windows), TELNET, RLOGIN and serial lines support.
What people usually mean is "I would like to use the session switching and cut/paste possibilities of IVT in my Linux environment". I consider that a compliment, since this indicates that these mechanisms are better in IVT than in operating systems such as Linux.

Porting IVT to Unix is possible, but it is a huge amount of work:

• Fundamentally different way of doing mouse, keyboard and screen I/O;
• Very different way of doing serial I/O;
• All the special Windows stuff (resizing, titles and so on) has to be rewritten.

In other words, it would be a re-write, not a port, and I have not got the time to do it in, so sorry.

Go to FAQ start page.

3.14: Host-printing (controller mode) does not seem to work?

QUESTION
When the host tries to print data on an IVT-connected printer, it produces a print job but the printer prints nothing.

ANSWER
Your printer driver probably does not support RAW-mode printing. Turn on COOKED mode with GUI_PR_CONTROLLER (for all printers) or in this setup-screen for individual printers.

Go to FAQ start page.

3.15: HP-UX bizarre one-line display on bottom line problem.

QUESTION
When IVT is used to login to an HP-UX machine, all output gets printed on the bottom line of the display. Scrolling is broken.

ANSWER
The problem is the TERMINFO entry for a vt220 terminal on HP-UX.
There is an "is2" command in there to reset the terminal (initialisation string 2). That command contains the wrong sequence "\E[1;24r".
What that INTENDS to do, is to reset the scroll-region of the terminal to the entire screen. The assumption there is that the terminal has 24 lines. The error is that the command "\E[r" explicitly means "reset scrolling region to entire screen", so it works for ANY size screen. That error has been there since forever. Other terminal emulators work because either their default screen size is 24 lines, the TERM environment variable is set to vt100, or both.

When the IVT window is larger than 24 lines, setting a scrolling region from 1 - 24 means that NO scrolling occurs on lines outside the scrolling region (defined by VT220 emulation rules). Thus, everything displayed there gets hammered on the same line(s), over and over again.

Various solutions:

• Fix the terminfo file on the HP-UX box (requires root privilege). Use "untic vt220 > vt220.tic" to get a text version of the terminfo file, edit the 1;24 out of there, use "tic vt220.tic" to recompile.
• Tell IVT to tell the HP-UX box that it is emulating a vt100 (see TELNET_TTYPE). Note that this lie can cause other trouble, as a vt220 has more keys, so some applications won't work as well as they used to.
• Install the "ivt.tic" file on the HP-UX box, compile it (using tic) and tell the HP-UX machine (using TELNET_TTYPE) that you are an IVT terminal (set "ivt,vt220,vt100" in the TELNET_TTYPE). This also enables a few extra features. You'll find the ivt.tic file in the "Unix" subdirectory of the IVT distribution.
• After logging in, use F3 (setup) and click on "Reset terminal". This resets the session to VT220 start-up defaults, and that also resets the scrolling region.
• Write a little IVT script that intercepts the erroneous command and ignores it. This is only an option if you have many of these HP-UX boxes and none of the above can be used.

  ---

This is an important feature, others are prev/next

4: How to create, close and switch between sessions

IVT can handle multiple, simultaneously active sessions. Sessions behave like completely independent virtual terminals.
F4-S gives an overview of existing sessions and a re-ordering possibility.
Here you can also change the name of the host in the status line and the status comment.
These functions are easily accessed from the session menu bar.

You can create or close a session at any time and hot-key between them.
To CREATE a session you use:

A session can be cloned, which means that the current session is used to find the host, username and protocol and IVT attempts to create an identical session and do auto-login there. It also copies the window size, font, and all other possibly modified settings of the current session.
Cloning uses the ORIGINAL hostname and username, so when you use scripts to modify the hostname and/or username, those scripts will work correctly for the cloned session, too.

Also, see the PRECONNECT statement to execute a script before a connect is made (to redirect connections, for example).
See also the ONCONNECT statement to execute a SCRIPT after successful connect.
The panel can be modified by setting the $HOSTPROMPT variable.

For a SERIAL connection, type a DEVICE (e.g. COM2,9600,n,8,1). Only the port name (COM1, COM2, etc) is required, the baud rate defaults to 19200, the parity to none, data bits to 8, stop bits to 0.

For TCP/IP, type HOST[:port]. HOST can be an IP address, port is optional.
You can, of course, also specify the name of a host. See the RESOLVE statement on ways to configure IVT to use non-standard ways of translating hostnames.

To SWITCH TO an existing session you can use:

To CLOSE a session (after logout) use ALT+F4. Exiting the LAST session will cause IVT to exit. You can also set the NO_RECONNECT feature, this will cause sessions to be closed automatically when the host disconnects.

Using EXPLICIT_EXIT will close all but the last session.

See also NO_GUI_CLOSE, which can force you to do a clean log off instead of forcibly killing sessions.

See also BATCHMODE, to prevent errors under certain circumstances.

Don't use ALT+F4 as the normal way to log off - some hosts or applications get upset when you force a hang-up this way!

F4-S will display a screen that shows all existing sessions. Here you can edit various attributes.
You can also quick-select the F4/S screen by clicking the mouse on the slash in between the current and maximum session numbers.
An even easier way is to use the menu bar.

This is an important feature, others are prev/next

5: IVT and the Windows registry

5.1: Saving IVT setup to the registry

Configuring IVT can be done in two basic ways:

• Traditionally, you configure IVT by editing your IVT.RC file with a text editor, after which you restart IVT so it reads the new file(s). The advantage is that the setup is human-readable and shareable with other users.
  The disadvantage is that you need to use a text-editor and need to learn the syntax of the IVT.RC setup language.
• Alternatively, you can experiment with various setting by using the setup screens accessed via F3 (or using the SETUP menubar). Most settings that you can change in the setup screens only modify the current session (and not other active sessions). When you find a setup you like, you can save the current setup so it becomes the startup default.
  See also PROFILEs, which allow you to have several separate setups.

Saving setup parameters can be done in 2 ways:

• Click on the SETUP menu on the menu bar, and click "Save into Registry".
• Click on the SAVE button in the setup screen.

If there is a current profile in the registry, IVT will ask if you want to overwrite it.
After saving a setup, IVT will make that setup the global default (you do not have to exit and restart IVT).

During start-up, IVT will first read all IVT.RC files in the normal way.
Then, if the NO_REGISTRY keyword has NOT been used, it will attempt to find a saved profile in the registry. When found, the settings from the registry are loaded "on top of" those from the IVT.RC files.

The upshot is that you no longer need to worry about the syntax of IVT.RC files. You experiment in the setup screens until you find a setup that works for you. Then, you save that. That's all.

However, there is a problem with having two different mechanisms to accomplish the same thing. If you modify IVT.RC settings after you have saved your setup to the registry, that would have no effect since the registry overrules the IVT.RC file setup. This can be very confusing.

Therefore, whenever you save the setup to the registry, IVT will also save the result of your IVT.RC commands in the registry. During start-up of IVT, the CURRENT results of your IVT.RC settings are compared with the saved copy in the registry. When a difference is found, you have used BOTH mechanisms (IVT.RC files AND registry) to modify the SAME value. In that case, IVT will warn you with a popup saying that you should either re-save or delete the registry settings to resolve the conflict.

As a consequence it is best to stick to one configuration mechanism.
When you use the NO_REGISTRY directive, the menu bar entries for manipulating the registry will be greyed out, and the buttons in the setup screens for the same functionality are greyed out, too.

5.2: Removing IVT setup from the registry

As described in the previous topic, the setup of IVT can be saved to the Windows registry. This can, however, give conflicts with your IVT.RC files.
As you grow to appreciate the power of IVT's setup files you might want to abandon the simplicity of saving a setup in the registry and write your own configuration files, scripts and so on.

When you click on DELETE in this setup screen, IVT will remove any saved settings from the registry.
It will then use the current IVT.RC settings as the current defaults, and restore those for the current session as well.

In other words, deleting a setup is the exact reverse of saving one, and making that work properly is harder than it sounds :-)

Another way to delete the registry setup is to use the SETUP menu on the menu bar, and select "Delete from registry".

This is an important feature, others are prev/next

6: The IVT keyboard guide

6.1: Summary of special IVT function keys

IVT has a lot of special keys that do the most wonderful things. Many of these things can make life a lot easier. Also, all keys can be programmed.
Last, but not least, the HOST can program keys, see the 'keyp' program.
The complete list of special IVT keys is:

F1              - Hold Screen (but see also F1F4).
F2              - Print Screen. Also usable during a CUT operation.
F3              - Setup. Changes IVT configuration on the fly.
F4              - Help. See also help-on-help.

CTRL+F6         - Obtains a sub shell when not in secure mode.

CTRL+CursUp     - Switch to the previous session.
CTRL+CursLeft   - Switch to the previous session.
CTRL+CursDown   - Switch to the next session.
CTRL+CursRight  - Switch to the next session.
CTRL+SHIFT+Curs - Switch to FIRST (up/left) or LAST (down/right) session.
ALT+1 to ALT+9  - Switch to session 1 - 9.
ALT+0           - Type a (hexa)decimal or octal (unicode) character code.
ALT+t           - Toggles back to previously active session.
ALT+g           - Switch to the next group.

CTRL+PageDown   - Create a new session (auto logon)
                  NOTE: Combine with shift and it CLONES a session.
CTRL+PageUp     - Create a new session (no auto-logon)
                  See also the $HOSTPROMPT variable.

CTRL+SHIFT+END  - Ends learn mode (key programming).

CTRL+BREAK      - Sends a ^C on the session.
CTRL+DELETE     - Sends a DEL character.
CTRL+BACKSPACE  - Sends a DEL character.
CTRL+@          - Sends a NULL character.

ALT+F4          - Session hang-up (immediate abort of session).
SHIFT+ALT+s     - Invoke screensaver immediately.

HOME            - VT220 'FIND' key.      Also CTRL+F7.
INSERT          - VT220 'INSERT' key.    Also CTRL+F8.
DELETE          - VT220 'REMOVE' key.    Also CTRL+F9.
END             - VT220 'SELECT' key.    Also CTRL+F10.
PageUp          - VT220 'PAGE UP' key.   Also ALT+F1.
PageDown        - VT220 'PAGE DOWN' key. Also ALT+F2.

CTRL+F7         - VT220 'FIND' key (if you lack a HOME key).
CTRL+F8         - VT220 'INSERT' key (if you lack an INSERT key).
CTRL+F9         - VT220 'REMOVE' key (if you lack a DELETE key).
CTRL+F10        - VT220 'SELECT' key (if you lack an END key.
ALT+F1          - VT220 'PAGE UP' key (if you lack a PageUp key).
ALT+F2          - VT220 'PAGE DOWN' key (if you lack a PageDown key).

ALT+Enter       - Flip Full screen mode.
ALT+Shift+M     - Maximize/restore window.

ALT+PgUp        - Enter history pager, one page back.
ALT+PgDown      - Enter history pager, one page down.
ALT+CursUp      - Enter history pager, one line up.
ALT+CursDown    - Enter history pager, one line down.
ALT+HOME        - Enter history pager, start of history buffer.
ALT+END         - Enter history pager, end of history buffer.
                  Using the mouse wheel is easier...

ALT+F9          - Invoke IVT file transfer functions.

ALT+a           - Toggle ALERT mode.
ALT+c           - Enter CUT mode.
ALT+L           - Lock keyboard.
ALT+m           - Activate the first menu on the menu bar.
ALT+p           - Paste the default buffer (clipboard).
Shift+Insert    - Same as ALT+p
SHIFT+ALT+p     - Paste a named buffer.

ALT+s           - Slower output. Repeat as necessary.
                  When used from the PAGER or this help system, it saves text
                  to a file on disk.
ALT+q           - Speed up output (Quicker). Repeat as necessary.

6.2: CTRL+F6: Escape to operating system (Sub Shell)

Using CTRL+F6 will give you a shell (command prompt) on the Windows operating system.
The command is only valid when secure mode is off.
It can be that the administrator has disabled access to the command prompt.
See also SHELLEXECUTE script function.

6.3: Application/Numeric keypad mode

A VT220 terminal can operate the numeric keypad in two modes:

• Numeric
• Application

IVT shares this multiple use with Windows, where the extra numeric keypad can be operated in numeric mode and as an alternative for PgUp, PgDown, cursor keys and so on. Further more, the top row of the numeric keypad (the Num Lock, /, * and - keys) can be configured in IVT to be the VT220 PF1 - PF4 keys (not to be confused with F1 - F4). Then there is 7 or 8 bit mode, which further determines what actual codes will be sent.

All of this can be a bit confusing, since there are many different sets of codes emitted by the keys on the numeric keypad:

• When the "Num lock" mode is on, and the IVT setting for the "keypad mode" is "numeric" (default) and "PF1-PF4 on top row numpad" is set to "On" (also default), the numeric keys simply emit the numbers, the extra "+" and "enter" keys emit "+" and "enter". The top row emits the VT220 PF1 to PF4 codes (since a true VT220 has those keys in that position). When that setting is "off" those keys also emit the characters printed on them.
  The "Num lock" mode can be switched without generating the PF1-PF4 keys by using "Shift-Num lock". IVT will ignore that combination, but Windows won't (the status of the "Num lock" light will change).
• When the "Num lock" mode is off, and the IVT setting for the "keypad mode" is "numeric" (default), the keys behave PC-style again, so they are just alternates for Home, PgUp, PgDown, End, Insert, Del and the cursor keys.
• When the "Num lock" mode is on, and the IVT setting for the "keypad mode" is "Application" (default) and "PF1-PF4 on top row numpad" is set to "On" (also default), the keys will behave as VT220 style "application mode" keys. Thus, 0 is "ESC O p", 1 is "ESC O q", to 9 is "ESC O y". Enter sends "ESC O M", the comma sends "ESC O n", the "+" key "ESC O l". This is for 7-bit mode, there is yet another set of codes for 8 bit mode.
• When you switch "Num lock" off, IVT again uses the PC defaults (alternates for the cursor keys, Home, End and so on.
• Last but not least, you can use the macro recorder to overrule all of this, and program the keys on the numeric keypad in all sorts of ways.

Confused? Just experiment with the various settings until you get what you desire. Please note that the current setting in "Setup" CANNOT be saved into the registry, since a VT220 is expected to be in "Numeric" keypad mode by default. When an application requires the "Application" mode, it should set this by means of this escape sequence explicitly.

When absolutely necessary, things can be forced out of kilter by:

ONCONNECT * ForceApplicationMode
Script ForceApplicationMode
   VTECHO "\1B="
END

Add this to your IVT.RC file, and it will make IVT think that every host it connects to sends the string to switch into application mode as the very first thing.
BTW, "\1B>" will switch back into numeric mode.

6.4: ALT+t: Toggle between two sessions

This is one of the handy features of IVT that you quickly become very fond off.  Whenever you switch between sessions, the number of the session you came from is remembered by IVT. When you use ALT+t, IVT switches back to that session (and again remembers where you came from).

This toggling between two sessions is very handy when you have many sessions active but find yourself switching between two of them many times.
For example, having error messages from a compiler on one session and doing something about them on another.

It is also usable as a quick screen-at-a-time DIFF program. When there are small differences between two screens, lean on the ALT+t. IVT will rapidly switch between two sessions, which will make the differences apparent.

6.5: ALT+a: Alert mode (ring bell on activity)

This is a very useful feature of IVT when you have to wait for a long time before the host is going to respond.

Typing an ALT+a will toggle alert-mode. This will cause IVT to ring the bell as soon as a character is received from the host (actually, once for every received network packet).
When the receiving session happens to be in the background, the activity indicator will show a red background and the bell will sound muffled.

Typing another ALT+a will turn the alert-mode off again.
The current setting can be made visible from this setup screen.
There is no way to initialise this setting from an IVT.RC file.
However, using IVTFUNCTION this function is accessible to a script.

6.6: ALT+0: Generate any character.

Most Windows programs allow you to enter a special character by holding down the ALT key and then typing a decimal character code on the numeric keypad.
Even old DOS programs allowed you to do that, and long ago people used to enter diacritical characters in WordPerfect or Word using this technique.

IVT reserves the ALT+number keys for very fast and convenient switching between sessions. To allow you to enter such special characters anyway, the unused ALT+0 is used to bring up a dialog in which you can conveniently enter a decimal, hexadecimal or even octal character code.

When you use a normal codepage, the resulting code must lie between 0 and 255 (inclusive), and is transmitted to the host if you choose OK.
When you use UTF-8, the character code can be any valid Unicode character point.

Note that the simple display of the character is only one of the possible results!  For example, if you send a "3", which is ^C, most Unix hosts will consider this an interrupt. If you send 127, it is a DEL character, usually that will cause either a backspace or an interrupt. Depending on the settings on the host, it may either accept 8-bit characters or reject them, or change them. Even if a character gets displayed, the result depends on the selected CODEPAGE in IVT, and a number of other related settings...

In other words: Your Mileage May Vary.

The important thing is that this allows you to send any character value to the host, just like other programs allow you to do...

When an invalid string is entered, the BELL will sound if you click OK.

6.7: Names of the VT220 programmable keys

In an IVT.RC file, a key can be programmed using the KEYNAME directive.
Valid names for these keys are:

PF1 - PF4       - Normally CTRL+F1 to CTRL+F4, but see F1F4.
PF1 - PF4       - In Windows, top row of numeric keypad.
PF5             - A VT220 lacks this key, but IVT maps the F5 key there.

F6  - F10       - Same as on a PC. You can also use F11 and F12 when available.
F11 - F20       - These are mapped from SHIFT+F1 to SHIFT+F10

FIND            - The HOME     key or CTRL+F7.
INSERT          - The INSERT   key or CRTL+F8.
REMOVE          - The DELETE   key or CTRL+F9.
SELECT          - The END      key or CTRL+F10.     See also the KEYBOARD.
PRVSCR          - The PageUp   key or ALT+F1.
NXTSCR          - The PageDown key or ALT+F2.

The VT220 "DO" key is a fancy name for F16 (so you have to use SHIFT+F6).

So for example:

   NXTSCR "ls -lab\r"

Will program the PageDown and ALT+F2 keys of the PC to the Unix command "ls -lab" followed by a return.
When such a statement occurs inside a script, the key is programmed for the current session only (after normal variable-substitution).

It is also possible to redefine any key using keyboard macros or to start a script when you press a key.
The newer KEYMACRO command is even more powerful.
Last but not least, the keyp program can be used on Unix to reprogram the keyboard.
See also MOUSE_KEY, which allows you to bind scripts to mouse actions.
Since a possible action is the SEND statement, this allows you to send data to the host when you press a mouse button.

This is an important feature, others are prev/next

7: The status line and what it can do for you

7.1: Introduction to the status line

The (optional) status bar of IVT shows lots of information about the current status of the foreground session, plus general information about the other sessions and groups of sessions.

The status bar uses icons to indicate various conditions, such as printer active, keyboard lock, autolog active, security, etc.
The various parts of the status bar can be clicked to perform actions on them (such as editing the hostname and comment parts).
A right-click will display help about any item.

It looks like the example below, click on any part to get more info:

______________________________________________________________________________

M x/y/G       HOSTNAME    HH:MM  123456789 G        Comment          Icons

______________________________________________________________________________

Explanation of the various fields:

All parts of the status line can be clicked with the mouse:

• Left-click allows you to edit the relevant part;
• Right-click gives context-sensitive help for that part.

See also STATUS, STATMIDDLE, STATBORDERS, STATUSCLICKS and PRSTATLINE.

7.2: Status line Modem indicator for serial lines

When the current session is a serial one, the leftmost position of the status line can show the following values:

• "M". This means IVT cannot detect a 'Device Ready' signal on the port.
  Usually, this means there is no modem attached or it is turned off.
• "C". IVT sees a 'Device Ready' signal, but no 'Carrier Detect' signal. The carrier signal is raised when a session with a remote modem is established (actually, this depends on modem configuration and the cable (if any) between modem and PC).
  As soon as the carrier signal is raised, the C will disappear. However, since detection of the carrier-signal depends on the configuration of your modem and the cable, if the red C continues to be displayed during a session, you can use this setup screen to toggle it off or use the NO_CARRIERSTATUS command in an IVT.RC file.
• "B". Break signal. The serial line is currently in BREAK state.
• "O". A red capital O indicates Overruns. Overruns indicate that your computer cannot keep up with the remote end, and characters are lost. The serial setup panel shows how many were lost, looking at this screen will also reset the overrun indicator (and clear the status-line indicator). This way, every time you lose something, you will at least be aware of it. Turning history off sometimes helps. The usual cause is that you have an old-fashioned UART chip that cannot keep up with modern, fast modems.

7.3: The status line indicators and icons.

These icons indicate various important aspects of the current status of IVT.
The following ones can appear:

• Script active (a large red S with a bolt lightning through it).
  When one or more scripts are active on the current session that are not hidden, this icon is displayed. If scripts assist in getting you logged in, it is generally wise to leave them to do their work before you start typing on the session (wait for the icon to disappear).
• Printer icon.
  Indicates a printer is active on this session. You can turn printers on from the setup-screen, or the host can activate a printer. A 'printer' can actually be a file as well. Using F3-F will 'flush' (close) the printer. An automatic TIMEOUT for this can be set when the printer is defined. See also F2 (print screen). See also printing.
• Stop sign icon.
  Hold screen. It means F1 has been pressed and all output to the screen is stopped immediately. If there is no flow control (serial line) this might result in data loss. On a LAN-session, the host will automatically stop transmitting when the buffers are full.
• Recorder icon.
  Learn mode. All keyboard input is remembered and stored under a key. You can turn this on with Learn Mode.
  End with either F3-L or with Shift+Ctrl+End, use the menu bar or click on the icon.
• Notebook icon.
  AUTOLOG is active for the session (logging data to a file). Click on the icon to alter the log settings.
• X-windows icon.
  X forwarding is active for the SSH or Kerberized telnet session.
• Forwarding icon (2 connected PC's).
  Tunnels are active on the SSH or Kerberized telnet session.
• IPv6 icon.
  IVT can create IPv4 or IPv6 sessions for all protocols (like SSH, TELNET, rlogin and so on). When an IPv4 connection is used, no icon is displayed. See the IPVERSION command to configure how IVT chooses between IPv4 and IPv6.
• Keyboard lock warning countdown.
  When a keyboard timer lock is active, 30 seconds before the keyboard is going to be locked, IVT will sound the bell and start a 30-second countdown. Touching a key will abort the countdown. When the grace period expires without keyboard activity, the keyboard will be locked and you will have to type the PASSWORD to unlock it.
  You can change the value from the setup screen, setting it to zero will disable the keyboard lock.
  When you have scripts setup to perform auto-login, it is especially important to crypt your setup files and lock the keyboard to prevent others from using your login-account!
• Keys icon.
  To indicate that the keyboard is LOCKed. You must type the proper password to re-enabled the keyboard. IVT also disables all other ways to control it when the keyboard is locked (menus, mouse, etc).
• Leds 1 - 4.
  The status of the official keyboard LEDs of the VT220 terminal. A real VT220 has four lights, called L1 to L4. A number with a green background displayed in this position means that the host has sent an escape sequence to turn this particular LED on. Not many applications use this feature.
• Padlock icon.
  When Kerberos or SSH is used to make the session private in both directions, a padlock icon will be displayed.
  Whenever the session switches back to plain text in either direction, the icon will disappear.

7.4: Status line hostname

This part of the status line shows the name of the host the session is connected to. Initially, this is whatever was used from either the Create session dialog or the command line.

It can also be edited using the F4-S screen (type an 'E' there) or using a STATUSHOST command from a script.
An easier way is to click on the jost name in the status line, which brings up the ecit dialog immediately.
Yet another way is by rightclicking the tab of the session and choose 'Edit'.

For serial lines, this field will show the name of the COM port, baud-rate and such. In this case, when you use F3-SERIAL to change any of these settings, the host name will be updated automatically.

7.5: Status line clock

Traditionally, the middle part of the status line was used as a simple clock that could be turned on or off using the CLOCK keyword or the setup screen.

Later, functionality was added to show the current cursor position in this place, or to show the current position of the mouse instead. This allows you to measure the exact position or length on the screen of certain objects.
In one of these modes it will show two numbers; the first is the line number, the second the column number.
Finally, the "connected" time of a session can be displayed here.

Changing the display of this middle part of the status line can be accomplished in 3 different ways:

• Use the setup screen to change the current setting. This is for all sessions simultaneously.
• Click with the left mouse button on that part of the status line. Every time you click it will change to the next possibility.
• Use the STATMIDDLE keyword in an IVT.RC file.

7.6: Status line activity indicator

This activity indicator occupies only 9 positions in the middle of the status line, but it reveals a wealth of information about the things going on in background sessions. These are:

• Current activity.
  When data is being received on a background session, a sequence of |, /, - and \ characters is displayed, resulting in a sort of rotating movement that indicates current activity.
• Unseen output.
  When output is received that has not been viewed by the user, the sequence number of the appropriate session is displayed. So when the hosts sends a few lines or screens of data, you will first see the position rotate, then stop and display the session number.
  When activity is detected in sessions having a group code other than the current one, all such sessions are lumped together into a single position of the indicator (the 9th and last). A G (for group) is displayed here. When any of the other-group sessions has a red background indicator, the background of the G will be red, when any of the sessions is in the error state, it will blink.
• Bell received.
  When a BELL character is received in a background session, the sound produced sounds a bit 'under water' like, to identify it as coming from a background session. IVT will then make the BACKGROUND color of that session position on the status line RED (to draw attention to the fact that something probably just went wrong in that session). See also BELL_ABUSE.
• Session error.
  When the (LAN) session is lost, the number of that session will blink. Also, since IVT will print an error-message on that session which is accompanied by a beep, the background will be RED. So, if a host on the LAN goes down, all sessions you have with that host will show a red, blinking number to draw your attention to it, and a BELL will sound for every session, too!
• Green background.
  The background of an activity indicator can be made GREEN by sending the ^[ B (ESC-SPACE-B) sequence). Use this in a Shell-prompt and a background session will show green when it is ready! Use this when you have a long running 'make' command or some such. All output of make (or errors) can later be viewed using the pager, you can monitor progress simply by waiting for the indicator to turn green (cool, huh?) NOTE: The new COLORREADY statement can be used to customize the actual foreground and background colors for the indicator...

7.7: Status line comment

The session comment can be typed in the initial dialog when you create a session.
It can also be set from the host using the ^[ Ctext; escape sequence (ESC-SPACE-CanytextSEMICOLON, see example).
This allows the host to automatically identify the session.

It can be typed directly using F4-S <Edit>.
Also, you can click on the comment in the status line, which allows you to edit it (use ESC to abort the edit).
Alternatively, you can use a rightclick on the tab of the session and choose 'Edit' from the menu that appears.

Use it to describe the purpose of the session. Especially when you have many sessions to the same host, this comment is ideal to tell them apart. The F4-S screen lists all comments, to give you an overview of all your sessions and the possibility to edit the comment, change the order of sessions etc.
Also, the WINDOW menu on the menu bar shows the session comments.

It can be set from a script using the STATUSTXT and STATUSTXTFIX commands.
Any comment longer than the maximum of 40 positions is silently truncated.

See also the TITLEBAR command, which will show this comment in the IVT applications title bar.
See also the  XTERM set window title command.

8: IVT menu bars and panel dialogs

8.1: Introduction

Menu bars and the create dialog are a late addition to IVT. For over 10 years, IVT was a program with many powerful features accessed with the keyboard only.
All those things were described in detail in these manual pages, but these days few people take the time to read all of this, even in spite of Tables of Contents, lists of important topics, FAQs, read-me-firsts and whatever else I tried :-(

After releasing version 11.3 of IVT to the Web in August 1999, I got many questions about IVT that were answered in the manual, the FAQ and read-me files, but were not noticed by the people asking the questions. Thus, many powerful features of IVT went unnoticed by many users - a great pity.
Therefore, I added the menu bars in January 2000. Every important part of IVT now has an optional menu bar on top of the screen (sessions, history pager and this help system).

Since November 2005, this menu bar can now be displayed as a normal Windows menu bar, instead of the original IVT text-mode one.
In june 2008, support for the old text-mode bar was dropped due to a major rewrite to support uTF-8.

The next item was to make creation of sessions easier and more intuitive.
For this, the create session dialog was made which allows you to switch protocols, edit items, click buttons and so on. All the code for this is - like the rest of IVT - home rolled.
Once this was working properly, December 2001 was used to rewrite the setup system entirely, so from version 14.1e onwards the setup is mouse-driven and usable by novices, too.

For more details on using and customizing the menu bars, click here.
For more details on using and customizing the create session dialog, click here.
For setup, see here.

This is an important feature, others are prev/next

8.2: Menu bars

All important functions in IVT have been given an entry in one of the menus that can be pulled down from one of the menu bars.
Menu bars can be enabled and disabled by using the MENUBAR directive in the IVT.RC configuration file.

The menu bar can also be activated by pressing and releasing the ALT key.
The normal Windows way (F10 or ALT+shortcut key) does NOT work, as both these key combinations are reserved by IVT for terminal emulation purposes. The one exception was for the lone ALT key, which would normally do nothing in IVT.

Every menu item also has a context-sensitive help, accessed by typing F1 while that entry is highlighted, or by right-clicking it (even when greyed out).

There is even a customisable entry in the session menu bar. Normally invisible, this entry can be configured from the IVT.RC file. This allows the user to launch IVT scripts and generate keystrokes using the standard menu bar interface.

8.2.1: Using the menu bars

The menu bar can be activated as follows:

• Click with the mouse on one of the words in the bar;
• Press and release the (left) ALT key.
• Uses ALT+Space

When a menu is activated, an item can be chosen by clicking on it with the mouse. The keyboard can be used to navigate the menus as well:

• Type the underlined character to choose an item quickly;
• Cursor keys to go up/down left and right;
• Home to go to the first entry, End to go to the last (text mode only);
• ENTER to choose the currently selected item;
• F1 to display instantaneous help on the currently selected item. A right mouse-click on an item will also display the help.

Most items in the menus also display the associated keyboard shortcut. Use these to quickly access common features.

8.2.2: Setting menu bar colors

MENU_COLORS ...

No longer supported in this version of IVT, this used to set the colors of the text-mode menu bar.

8.2.3: Configuration of the CUSTOM menu

One of the nice features of the session menu bar is that it has a configurable menu. Normally, this menu is empty and invisible. It can be activated from the IVT.RC file by using several MENU statements which have to be called from a SCRIPT. Normally, you would write a "startup" script to do this.

First of all, the menu must be given a name using the TEXT directive.
This string will appear on the menu bar itself.
It is your responsibility to have a properly formatted string here, a very long string, or one containing odd characters will produce a variety of unpleasant effects...
An "&" character can be used to indicate a shortcut character.

Next, the menu must be filled with entries, of which there are 4 different types (detailed below). Every item has a description (the text which will appear in the menu). An '&' in that text can be used to indicate the highlighted shortcut character for that entry (see below for an example).

The different types are:

• CALL.
  This entry will cause a SCRIPT (with optional parameters) to be called when chosen by the user. The script must - of course - be written by the user.
• STRING.
  This entry will "play" a number of simple keystrokes as specified by the user. Only normal data keys can be used.
• KEYS.
  This entry will "play" a number of keystrokes as specified by the user. These keys can do anything the user might do with the keyboard. The interface is slightly more complex (and not implemented yet ;-).
• LINE.
  A separator line is drawn by IVT.

Lastly, the menu must be enabled, which will make it visible. It can also be disabled. The "MENU ENABLE" and "MENU DISABLE" commands accomplish this.

The menu can also be cleared using the RESET command. That way, a script can redefine the menu later.

The order in which the statements are executed determines the order in the resulting menu. Time for an example:

   Script Startup
      MENU RESET                # Clear any previous menu
      MENU TITLE "&Favourites"
      MENU CALL  "Start my favourite &editor"  Start vi
      MENU CALL  "Start &mail program"         Start elm
      MENU LINE
      MENU STRING "Show my &processes" "ps -fu johnb\r"
      MENU ENABLE
   END

The TITLE command will create an entry on the menu bar called "Favourites".
The F will be the shortcut key for that menu (GUI menu bar only).
The first two entries will call the "Start" script (which has to be defined elsewhere). It will be passed one parameter (vi or elm in the example).
The shortcut character will be 'e' and 'm' respectively.
Then, a separating line is drawn.
The next entry will send the "ps" command when chosen (shortcut is 'p').

The idea is that you can create entries for common tasks in your own personalized menu...

8.3: Start-up general help

Welcome to IVT, a powerful multi-session LAN terminal emulator.
This version also supports the SSH Secure Shell protocol.
Click on any of the following links for more information (right-click returns from a link):

• General introduction of IVT
• INTRODUCTION FOR NEW USERS
• Creating & managing sessions
• The create session panel interface
• Password learning and automatic login
• Major features list
• IVT FAQ (Frequently Asked Questions)
• What the users have to say about IVT

There is also Help On Help...

For the slightly more advanced user, the following links may be worth reading:

• Cutting and pasting with the mouse
• Protocols supported by IVT
• IVT keyboard guide
• IVT start-up files (IVT.RC)
• IVT scripting language
• Viewing/managing scroll-back history

8.4: The create session panel interface

IVT used to be a "text-mode only" program until the beginning of 2000.
Mouse mode cut/paste was an early feature, but for the rest you used the keyboard. Creating sessions, scroll-back history, file transfer and hosts of other functions were accessed through ALT and CTRL key-combinations.
My home page even used to say that IVT was meant to be used by people who use a terminal emulator as a primary tool, and that anyone who only used Unix through TELNET once in a while was better off with other products.

After releasing IVT to the Internet in September 1999, I got many requests for features that already were a part of IVT, but were unnoticed because they were hidden behind some obscure key combination.
Menu bars were added as the first thing to give pull-down menus which make most of the significant features available to novice users.

Adding these menus was still not enough to satisfy some users out there (hi Hans!) and they complained about the complexity and unfriendliness of IVT.
So, new in version 12.2 is the create session dialog, a panel interface that should look familiar to Windows users.

All items in the dialog are clickable with the mouse. Input fields can be edited using (mostly) the same way as in any Windows application.
Right-clicking any part of the dialog will bring you to a context sensitive help screen of IVT.

While the create session dialog is active, you can also click on the menu bar and choose SETUP to change all kinds of settings (with the mouse, even).
By clicking on the MORE and LESS buttons you can extend (or limit) the choices IVT displays in the dialog. You can also use the CRDIALOG directive in an IVT.RC file (or from this setup screen) to set the default interface.

8.5: Repeat count

The "Repeat" field in the create-session panel allows you to create a number of identical sessions in one operation.
You will have to select the maximum panel (click on More until it appears).

All sessions are to the same host and will be logged in (when requested) with the same user-id.
When there is room in the comment field of the session, an automatic sequence number will be appended to be able to distinguish between them.

The Automatic Login system will use the $IVT_REPEATNR variable to do the same, too.

See also the R=Count option of the CREATE statement, which allows another way of specifying a number of repeated sessions. These two cannot be combined, a CREATEGRP cannot be created multiple times automatically.
See also MERCY_MODE, to prevent excessive stress on hosts.

8.6: List with previous host & users

The fat down-arrow at the end of the hostname prompt can be used to access a list of recently used and predefined hostnames, usernames and so on.

The list consists of 2 parts. The first part are hostnames, usernames and other data typed into the login dialog by the user. IVT remembers the last 25 typed names (but see MAXTYPEDHOSTS to configure this).
The second part is configurable with the HOSTLIST command in an IVT.RC file, or using the address book editor avaiulable from the "extra" menu.

Double-clicking on an entry in the dialog that opens will select that entry.
You can also single-click followed by <OK>.
You can even select MULTIPLE entries in ONE operation and IVT will create multiple sessions at once!

Entries can be deleted from the list one-by-one or all together.
The resulting list is saved in the registry and thus survives starting and stopping IVT.
The option is enabled only when at least two different hosts and users have been typed by the user. The last entry typed by the user automatically appears in the login dialog.

A more powerful way to automatically start sessions for particular users and hosts is the session group mechanism of IVT.

See also the hostlist filter.

8.7: Host lister filter expression

When you use the address book together with project files, the number of hosts to select from can grow uncomfortably large.
By typing a partial name into the "filter" box, the listing is adjusted to contain only matching hosts. Actually, the value you type here can be a regular expression (see the MATCH function).
The string that is matched is the combination of the hostname and description (comment field) of the address book entries (so you can search on arbitrary parts of the hostname, description, or combination).

Before a selection is shown, IVT will first force an expansion of all groups in the address book (like clicking on "Expand all").

The value in the filter box is not cleared automatically by IVT. If you want to view the complete address book again, you will have to clear it manually.

9: F3: IVT Setup dialogs

9.1: Introduction to setup dialogs

For help on any individual item, use a right-click on that item (or select the item and press F1). Click on the question mark in the title bar of windows to get help on that specific window.

To navigate through the various items, just click on them, or use the following keys:

• Cursor keys to move in the desired direction;
• Tab to move to the "logical next" item;
• Shift-Tab to move to the "logical previous" item;
• Spacebar to "click" on the current item;
• ENTER to perform the default action for the current window.
• F1 for help.

When editing text fields, all normal keys to edit and move inside the field will work as expected (HOME, END, Delete and so on).

The old setup shortcuts of IVT still work:

F3 - Apply changes, end setup;
R  - Reset terminal;
C  - Abort all scripts on this session;
D  - Dump incoming data;
F  - Flush printer;
L  - Start (or end) Learning a macro.

New ones are:

A - Apply changes and exit setup;
P - Printer setup
W - Windows setup
H - Help
? - Help

The <Save to registry> button is enabled only when the REGISTRY setting is in effect (when NOREGISTRY is used, the button is disabled).
When clicked, the current setup is saved into the registry, see here for details.

The <Delete> button will delete any settings from the registry and will make IVT revert to the setup that result from the IVT.RC file settings.
It will ask for confirmation first.
See here for details.

9.2: Setup propagation

The setup dialogs allow you to change the look and feel of the current session, and to save the settings of the current session so all future sessions will have the new look and/or feel. See also SIZE4ALL.
However, up until Tue Aug 16 23:02:42 2005, there was no way to force a change in the setup to all currently existing sessions.
The "Propagate" function uses the current session parameters and copies those to all currently existing sessions. So all sessions get the look and feel of the current session with regards to:

• Colors;
• Font;
• Window size;
• Window position.

and so on and on (everything that you can change in setup). The "propagate" function is available from the main session menu bar (the "setup" menu there) and through the IVTFUNCTION and KEYMACRO functions, which allow you to propagate setup either under script or keyboard control.
There is also a button in Windows Setup.

There are a few reasons why a session will not change its look & feel:

• The session is in scroll back mode;
• The session is in blocked mode (hold screen);
• The session is in an error state (disconnected);
• The session is currently being initiated.

This is for various technical and practical reasons.

Note that if you have not changed any setting, using the "Propagate" function has no visible effect, except that IVT will force a screen resize, font adjustment and so on for every session, which can cause network activity, screen redrawing and so on (even if it ends up looking exactly the same).
In other words, do not use it unnecessarily.

See also SIZE4ALL.

9.3: Protocol setup

This dialog allows you to choose the basic transport and session protocols that IVT is going to use for future sessions.
The transport protocol is the low-level way IVT sends data from A to B, this can be a serial line, TCP/IP or NetBios.
This chooses the basic session protocol.
A session protocol runs "on top of" a transport protocol. It can be TELNET, RLOGIN, VTP or MULTIPLEX.

Transport protocol : [WinSock     ]
Session   protocol : [Telnet   ]

TCP no delay option : [X]
Socket timeout      : [  20]
Trace name resolving: [ ]
<Configure proxy>

9.4: Proxy setup

The Proxy panel allows you to configure IVT to use various types of proxy in order to make its network connections. The settings in this panel affect the primary network connection forming for your SSH, TELNET or RLOGIN session.
Below you'll find more information on each separate topic.

Show proxy debug messages: [ ]
Proxy type               : [None      ]
Proxy host:port          : ........................................
Timeout in seconds       : 15...
Exclude host/IPs         : ........................................
Proxy local connections  : [ ]
DNS lookup at proxy end  : [Auto]
User name                : ruurdb..................................
Password                 : ****....................................
Telnet command           : connect $HOSTNAME_ONLY $PORT\n..........
IVT script name          : ........................................

9.5: Telnet setup

The TELNET setup dialog allows you to modify the settings for future sessions and to inquire the status of the current session.
When no current session exists, or the current session is not of type TELNET, the "inquiry" functions are all greyed out.
Below you will find more information on each option.

Show option negotiation : [ ]
Offer extra options     : [X]
Use New Env (RFC 1592)  : [ ]
Terminal type           : ivt,vt220,vt100.....
Terminal speed          : 38400,38400.........
X Display value         : NL-ARN-L60278:0..............
Send IP-address in Xdisp: [ ]
Keep-alive delay (0=off): 0
<Send AreYouThere      >
<Send break            >
<Send Interrupt Process>
<Force Logoff          >
<Show remote status    >
<Toggle binary mode    > Local=Off Remote=Off
Suppress Go Ahead      : Local=On  Remote=On
Local flow control     : Enabled, Restart XON

9.5.1: Telnet setup: Send Are You There

When you are using a TELNET connection to a host, and the host does not seem to respond to your input anymore, you can click on this button.
This will send a special command called "Are You There" to the remote end of the TELNET connection. A host should respond with something along the lines of "[YES]", or "I AM HERE". Some hosts only ring the bell to avoid corrupting the screen. The idea is that a life sign is given. When no response is received, the problem lies (probably) in the network connection itself.
However, your BELL might have been set to OFF...

9.5.2: Telnet setup: Send break

When a TELNET host is not responding, you might first want to try and send an "Are You There" to see if anything is still alive at the other end of the connection. If there is, and the program you are talking to seems to be dead (or cannot be stopped by normal means for whatever reason), you might try to send a TELNET BREAK. This is a friendly way to ask the program to stop.

Simply click on the appropriate button in the TELNET setup dialog.
A more unfriendly way is the interrupt process, described below.
Not all TELNET host implementations honour this request. Your last recourse is to hit ALT+F4 to kill the session.

9.5.3: Telnet setup: Send Interrupt Process

The TELNET protocol supports an application independent way to terminate processes. Even when your host has disabled all normal ways to interrupt applications, TELNET clients can request an "Interrupt process".
This is the last resort if all else fails.
See also "Send TELNET break".

9.5.4: Telnet setup: Force Logoff

This is a request from IVT to the TELNET host to disconnect the session.
I have not found many hosts that honour this request, most ignore it.
Another way to disconnect forcibly would be to use ALT+F4.
See also "Send TELNET break" and "Send Interrupt process".

9.5.5: Telnet setup: Show remote status

This is a request from IVT to the TELNET host to send its idea of the current status of all TELNET options. All options that are marked DO (the host thinks IVT should do this option) or WILL (the host will do that option) are sent back and displayed (on the normal session screen) by IVT.

Since all these options are negotiated when the session is established, both ends of the connection should have the same idea on the current status. When IVT receives the status from the host, it compares that to its own ideas on the status. When it matches, it is displayed as "Correct". When a mismatch is found a "MISMATCH" message is displayed.
Use this when in doubt on the correct implementation of the telnet host.

9.5.6: Telnet setup: Binary mode

This requests binary transmission on the session. It is used internally by the file transfer functions of IVT but not used much otherwise. Enabling this mode will prevent certain character translations and local flow control.
The setup will show the current status, clicking the button will toggle that setting from on to off and v.v.

9.5.7: Telnet setup: Suppress Go Ahead

This is display only, you cannot change the setting.

A standard TELNET connection is actually half-duplex, when one side of the connection is done transmitting, it should send a message to the other side saying "I'm done, you go ahead now". In these modern days of full duplex connections and applications that can send unsolicited output there is not much use for such a message. Any side that does not want these messages can send a "DO Suppress Go Ahead" message to the other end. IVT will send such a message to a TELNET host during session initialisation. The host might respond with "DONT Suppress Go Ahead" when it actually wants the protocol.
If the host does not want to see any "Go Ahead" messages, it will say "WILL Suppress Go Ahead" and (probably) send a message to IVT which says "DO Suppress Go Ahead" to which IVT will respond "WILL Suppress Go Ahead".

The result of these negotiations will be shown in the TELNET setup dialog.

When the Go Ahead is sent by the host, IVT will ignore it (it can't force you to type something) and when it is required by the host, IVT will send a "Go Ahead" after you finished typing.

9.5.8: Telnet setup: Local flow control

This is display only, you cannot change the setting.

Local flow control is a way to stop the display of characters received by the host, by typing a special character (usually XOFF, generated by typing a CTRL+s key). When local flow control is enabled, typing an XOFF will make IVT stop immediately (normally, the XOFF would be transmitted to the host which would respond eventually, but there might be lots of buffered data in the network which could make XOFF pretty useless).

There are two ways to restart the flow: RESTART_ANY and RESTART_XON.
When the first is enabled, any typed character will resume output.
When the second is enabled, you have to type an XON (Ctrl+Q).
When local flow control is enabled, Ctrl-S and Ctrl-Q are transmitted to the host, and also handled locally. IVT immediately stops displaying output (same as using F1).

9.6: Kerberos setup

This panel allows you to configure the Kerberos features of IVT.

Enable negotiation                : [X]
Automatically forward credentials : [Forwardable]
Reverse lookup of hostnames       : [X]
Automatically negotiate encryption: [X] (to host)
Automatically negotiate decryption: [X] (from host)
Debug Kerberos encryption         : [ ]
Realm                             : ....................
Support for DES CFB64             : [Input/output]
Support for DES OFB64             : [Input/output]
Enable use of PC-DCE .DLL         : [X]
X-Windows port forwarding         : <View/configure>
Encrypt current session           : [X]
Decrypt current session           : [X]
<Show status for the current session>
<Kerberos licence management>

9.7: X-Windows port forwarding

This panel allows you to configure the X-Windows port forwarding protocol and view some statistics about the number of packets and bytes transmitted for the X-Windows protocol over a secure channel. This secure channel can be either SSH or Kerberos, or even both at the same time.

The value of the DISPLAY variable can be changed only BEFORE a session is established, since part of that value is transmitted to the host when the session is established initially. For the same reason the other settings that are used only during session establishment are disabled afterwards.

The statistics shown are global values (all sessions, all X-traffic).

X-display forwarding   : [Auto ]
DISPLAY variable       : :0.0...................
SSH authorization mode : [MIT Magic Cookie 1  ]
XAUTH delay (Ms)       : 750
Number of open channels: 0
Packets from hosts     : 0
Bytes   from hosts     : 0
Packets from X-server  : 0
Bytes   from X-server  : 0

<Refresh>   <Reset>

The Refresh button refreshes the statistics to current values.
The Reset button forces all statistics to zero.

9.8: SSH Setup

This panel allows you to configure the settings for the Secure Shell version 2 protocol. It looks as follows:

Debug SSH protocol negotiation: [ ]
Log SSH packet data to IVT.LOG: [ ]
X-Windows port forwarding     : <View/Configure>
Allow interactive passwords   : [X]
Don't allocate pseudo terminal: [ ]
Enable authentic. forwarding  : [X]
Agent hijack protection       : [X]
Enable compression            : [X]
Allow non-standard use of DES : [ ]
Accept host keys              : [Ask user  ]
Keep-alive delay (0-off)      : 0
Terminal type for SSH         : vt220....................
Data to send to server        : .........................
Private key file for SSH      : .........................
Pathname of PAGEANT executable: .........................
Automatically start PAGEANT   : [X]
<SSH Port Forwarding          >
<Configure SSH Key Exchange   >
<Configure SSH ciphers        >
<Configure SSH bug detection  >
<Manage stored SSH keys       >
<Start KEYGEN (makes key pair)>
<Start PAGEANT now            >

Most of the SSH code was borrowed from PuTTY. Thanks.

9.9: SSH Port Forwarding

This panel allows you to setup SSH port forwarding. It looks like:

Current session only : [X]
Type of forwarding   : [Local  ]
Source [host:]port   : .......................................................
Destination host:port: .......................................................
Accept all hosts     : [ ]

The SSH protocol has the ability to forward arbitrary network connections over your encrypted SSH connection, to avoid the network traffic being sent in the clear. For example, you could use this to connect from your home computer to a POP-3 server on a remote machine without your POP-3 password being visible to network sniffers.

In order to use port forwarding to connect from your local machine to a port on a remote server, you need to:

• Choose a port number on your local machine where IVT should listen for incoming connections. There are likely to be plenty of unused port numbers above 3000 (You can also use a local loop back address here; see below for more details). Let us assume you pick 3030.
• Now, before you start your SSH connection, go to the "SSH Port Forwarding" panel. Choose 'Current session only' and type 'Local'. Enter the local number 3030 into the 'Source port' box. Enter the destination host name and port number into the 'Destination' box, separated by a colon (for example, popserver.example.com:110 to connect to a POP-3 server).
• If you want to use this popserver connection from your PC (the one that runs IVT) only, 'Accept all hosts' checkbox unchecked. IVT will now only accept an incoming connection from the local PC. When checked, anybody who can contact port 3030 on your PC can connect through the tunnel to the remote popserver. Usually, you'd leave this unchecked.
• Now click the 'Add' button. The details of your port forwarding should appear in the list box.

BTW: The above dialog is equivalent to: SSH_FORWARD LOCAL 3030 popserver.example.com:110 in your IVT.RC file.

Now start your session and log in. Port forwarding will not be enabled until after you have logged in; otherwise it would be easy to perform completely anonymous network attacks, and gain access to anyone's virtual private network. To check that IVT has set up the port forwarding correctly, you can turn on 'Debug SSH protocol negotiation' before logging in.
IVT should say something like this:

SSH: Forwarding local port 3030 to popserver.example.com:110

Now, if you connect to port 3030 on your local PC, you should find that it answers you exactly as if it were the service running on the destination machine. So in this example, you could then configure an e-mail client to use localhost:3030 as a POP-3 server instead of popserver.example.com:110. Of course, the forwarding will stop happening when your IVT session closes down.

You can also forward ports in the other direction: arrange for a particular port number on the server machine to be forwarded back to your PC as a connection to a service on your PC or near it. To do this, just select the 'Remote' type instead of the 'Local' one. The 'Source port' box will now specify a port number on the server (note that most servers will not allow you to use port numbers under 1024 for this purpose, unless you are logged in as 'root' there).

An alternative way to forward local connections to remote hosts is to use dynamic SOCKS proxying. For this, you will need to select the 'Dynamic' type instead of 'Local', and then you cannot enter anything into the 'Destination' box (it will be greyed out). This will cause IVT to listen on the port you have specified, and provide a SOCKS proxy service to any program which connects to that port. The SOCKS protocol negotiates the actual destination with the client.

The source port for a forwarded connection usually does not accept connections from any machine except the SSH client or server machine itself (for local and remote forwarding respectively). This can be changed in several ways:

• The 'Accept all hosts' option allows you to set up forwarding (including dynamic port forwarding) in such a way that machines other than your client PC can connect to the forwarded port. When used for a remote connection, the remote host will also accept any incoming connection (so that machines other than the SSH server machine can connect to the forwarded port). Note that not all SSH-2 servers honour it (in OpenSSH, for example, it's usually disabled by default).
  PuTTY has only a single setting for all forwarding. IVT improves on this by allowing you to specify an 'Accept all hosts' per forwarded connection.
• You can also specify an IP address to listen on. Typically a Windows machine can be asked to listen on any single IP address in the 127.*.*.* range, and all of these are loopback addresses available only to the local machine. So if you forward (for example) 127.0.0.5:79 to a remote machine's finger port, then you should be able to run commands such as finger fred@127.0.0.5. This can be useful if the program connecting to the forwarded port doesn't allow you to change the port number it uses. This feature is available for local-to-remote forwarded ports. SSH-2 can support it in theory but servers will not necessarily cooperate.

(Note that if you're using Windows XP Service Pack 2, you may need to obtain a fix from Microsoft in order to use addresses like 127.0.0.5).

See also SSH_FORWARD.
IVT will shown an interchange icon in the status bar when IVT is actively forwarding data. The icon does not appear when channels are set up but not in active use.

9.10: SSH Key-exchange configuration

This panel allows you to configure how IVT handles SSH-2 key exchange.
See also the IVT.RC command SSH_KEX.

Key exchange occurs at the start of an SSH connection (and occasionally thereafter); it establishes a shared secret that is used as the basis for all of SSH's security features. It is therefore very important for the security of the connection that the key exchange is secure.

Key exchange is a cryptographically intensive process; if either the client or the server is a relatively slow machine, the slower methods may take several tens(!) of seconds to complete.

If connection start-up is too slow, or the connection hangs periodically, you may want to try changing these settings. If you don't understand what any of this means, it's safe to leave these settings alone.

IVT supports a variety of SSH-2 key exchange methods, and allows you to choose which one you prefer to use.

IVT currently supports the following varieties of Diffie-Hellman key exchange:

• Group 14: a well-known 2048-bit group.
• Group 1: a well-known 1024-bit group. This is less secure than group 14, but may be faster with slow client or server machines, and may be the only method supported by older server software.
• Group exchange.
  With this method, instead of using a fixed group, IVT requests that the server suggest a group to use for key exchange; the server can avoid groups known to be weak, and possibly invent new ones over time, without any changes required to IVT's configuration. We recommend use of this method, if possible.

If the first algorithm IVT finds is below the 'warn below here' line, you will see a warning message when you make the connection, similar to that for cipher selection.

Repeat key exchange.
If the session key negotiated at connection start-up is used too much or for too long, it may become feasible to mount attacks against the SSH connection.
Therefore, the SSH-2 protocol specifies that a new key exchange should take place every so often; this can be initiated by either the client or the server.

While this renegotiation is taking place, no data can pass through the SSH connection, so it may appear to freeze. Usually the same algorithm is used as at the start of the connection, with a similar overhead.

You can control how often IVT will initiate a repeat key exchange (rekey).
You can also force a key exchange at any by using the Rekey now button.

Max minutes before rekey.
This specifies the amount of time that is allowed to elapse before a rekey is initiated. If this is set to zero, IVT will not rekey due to elapsed time. The SSH-2 protocol specification recommends a timeout of at most 60 minutes.

You might have a need to disable time-based rekeys completely for the same reasons that keep-alives aren't always helpful. If you anticipate suffering a network dropout of several hours in the middle of an SSH connection, but were not actually planning to send data down that connection during those hours, then an attempted rekey in the middle of the dropout will probably cause the connection to be abandoned, whereas if rekeys are disabled then the connection should in principle survive (in the absence of interfering firewalls).
For these purposes, rekeys have much the same properties as keep-alives (except that rekeys have cryptographic value in themselves, so you should bear that in mind when deciding whether to turn them off).
Note, however, the SSH server can still initiate rekeys.

Max data before rekey.
This specifies the amount of data (in megabytes) that is permitted to flow in either direction before a rekey is initiated. If this is set to zero, IVT will not rekey due to transferred data. The SSH-2 protocol specification recommends a limit of at most 1 gigabyte.

Disabling data-based rekeys entirely is a bad idea. The integrity, and to a lesser extent, confidentiality of the SSH-2 protocol depend in part on rekeys occurring before a 32-bit packet sequence number wraps around.
Unlike time-based rekeys, data-based rekeys won't occur when the SSH connection is idle, so they shouldn't cause the same problems.

See also the IVT.RC command SSH_KEX.

9.11: SSH bug configuration

This panel allows you to configure how IVT should detect and avoid bugs in various SSH-2 implementations.

Miscomputes SSH2 HMAC keys             : [Auto detect]
Miscomputes SSH2 encryption keys       : [Auto detect]
Requires padding on SSH2 RSA signatures: [Auto detect]
Misuses the session-ID in PK auth      : [Auto detect]

9.12: Stored SSH host keys

This dialog shows you all received SSH host keys. It is reached from the main setup screen, <SSH settings>, <Manage stored SSH keys>.
Such SSH keys are sent by a host when a connection is made through the SSH protocol. IVT will store the key and its fingerprint in the registry.
The next time a connection is made to the same host, the transmitted key is compared to the stored copy. If it does not match, a warning is issued.

If you have many hosts that come and go, these keys can clutter up your registry. Also, you may want to check the fingerprint of a particular host key. This panel allows you to inspect and delete individual keys. By clicking on <Delete all>, IVT will remove all stored keys from the registry. Mind, no confirmation is asked. Losing your keys is no disaster though, since the next time you connect to a host it will be stored again.
See also the AUTO setting of SSH_ACCEPT.

You can also export the keys to a file with <Export to file>.
Such files can be used through the SSH_HOSTKEYS directive in an IVT.RC file.

Note: PuTTY does not have this functionality :-)

9.13: Serial setup

This panel allows you to configure the settings for serial ports.
Depending on whether the current session is a serial one, you can modify the current port or (when the current session is not connected yet or is not of a serial type), change the global defaults that will affect future serial sessions.

Baud rate          : [19200]
Parity             : [None ]
Data bits          : [ 8 ]
Stop bits          : [ 1 ]
Remote flow control: [X]
Local flow control : [X]
CTS/RTS control    : [X]
DSR send control   : [X]
BELL on phone RING : [X]
Show Carrier Detect: [X]
<Short BREAK (250ms)>
<Long BREAK (1.5 sec)>

Total char overruns   0
Current overruns      0

9.14: RLOGIN setup

RLOGIN is not as popular a protocol as TELNET, but IVT supports it.
This dialog allows you to configure the values that will be used for future sessions of this type.

Local user name : ....................
Remote user name: ....................
Terminal type   : vt220...............

9.15: VT220 (basic) setup

This basic setup dialog manages the main characteristics of the VT220 emulator.

Screen size         : [60x145 (Dflt)]
Allow resize        : [X]  Allow ALT-screen [X]
One size for all    : [X]
History             : [X]
Screens             : [10  ]
7 or 8-bit mode     : [7]
Auto reconnect LAN  : [ ]
Retain sessions     : [ ]
Line wrap           : [X]
LF implies CR       : [ ]
Screen save after   : 10 minutes
Lock keyboard after : 0 minutes
Smooth scroll delay : 0  Ms   Pixels: 1
Keyboard lock passwd: ********
Answerback string   : \06...........................
Terminal speed      : [Turbo ] (see also ALT-S)

9.15.1: VT220 basics: Linefeed implies CR

When this option is turned on, IVT will automatically add a Carriage Return character after every received Linefeed character. This means the next displayed character will be at the start of the next line, rather than at the same column position on the next line. The host can control this with an escape sequence. You cannot set a global default, a VT220 has to have this initialised to OFF. This modification is NOT saved into the registry!

See also CSI 20 h.

A number of users have reported trouble with this setting. Sometimes there are hosts which force this setting to ON and then produce screen corruptions because of that, sometimes they expect it to be turned on but do nothing to actually set it. In such cases, little IVT scripts can be used to force the setting, like so:

   ONCONNECT * SetLfImpCrOn
   Script SetLfImpCrOn
      VTECHO "\1B[20h"
   END

This script will force the setting to ON for every established connection.
The opposite script is more complex:

   ONCONNECT * SetLfImpCrOff
   Script SetLfImpCrOff
      SECRET
      FOREVER
         WAIT "\1B[20h" # Wait for a command to turn it on
         IGNOREESCAPE   # Ignore it.
      NEXT
   END

This script launches a background script for every session, which just sits around monitoring everything received from the host. When a command is seen that turns this setting ON, it ignores it.
The SECRET means there won't be an annoying red S in the status line to show that a script is active.

9.16: VT220 (more) setup

This dialog combines a mishmash of other VT220 terminal characteristics, besides the ones in the VT220 basic setup dialog.

Alert mode          : [ ]
Bell action         : [Sound tune     ]  Bell abuse settings
.WAV file             : ........................... Browse
Flash action        : [Flash screen   ]
.WAV file             : ........................... Browse
Backspace key       : [Backspace  ]
F1-F4 keys          : [Normal     ]
Cursor key mode     : [Normal     ]
Keypad mode         : [Normal     ]
Create sess dialog  : [Medium ]
Monochrome screen   : [ ]
SCO-ANSI compatible : [ ]   Keyboard [ ]
Cursor height       : 16 Blinks: [X] <Color>
Local echo          : [ ]
Screen debug mode   : [Off   ]
Packet bounds trace : [X]

Explicit exit       : [X]
Function keys locked: [ ]
Clock skew          : 0

9.16.1: Setup: Bell abuse settings

This dialog allows you to set the BELL_ABUSE parameters.

Disable bell when overused  : [X]
This many bells             : [5   ]
In this many seconds        : [2   ]
Seconds of silence required : [5   ]

9.16.2: Setup: Local echo mode

A late addition to IVT, this will simply echo everything you type to the screen. If the host is also echoing, you will see everything twice.

If the host is not echoing, you can use this to make the things you type visible. It can be turned on and off from this dialog.

This is also handy if you want to try the effect of some function keys and such within IVT. This feature can also be turned on and off by the host by using the CSI 12 l/h command. When you want to turn on local echo for a session automatically, use a small script such as:

   ONCONNECT * LocalEchoOn
   Script LocalEchoOn
      HIDE
      VTECHO "\1B[12l"  # Send CSI 12 l, turns local echo on.
   END

9.17: Mouse setup

This dialog allows you to configure the actions taken by IVT in response to mouse action.

Mouse mode             : [Cut/Paste]
Cut mode               : [Block]
Hide while typing      : [X]
Copy scroll speed      : 4..
Wheel scroll factor    : 1
Wheel scroll page size : 24
Leave selection visible: [X]
Word/phrase selection  : [IVT (double button) ]
Extend to full line    : [X]
Use strict CUT mode    : [X]

IVT uses the mouse very extensively, please have a look at the special mouse chapter, especially the advanced possibilities.

9.18: Color setup

Colors can be specified multiple ways. Some forms go all the way back to the first MS/DOS version of IVT. The preferred syntax is the 2nd column.

0       Black
1       Blue
2       Green
3       Cyan
4       Red
5       Magenta
6       Brown
7       White
8       Grey
9       Brightblue
10      Brightgreen
11      Brightcyan
12      Brightred
13      Brightmagenta
14      Yellow
15      Brightwhite

Actually, any combination of "bright" with a color is valid, so you can also specify "brightblack" (grey) and "brightbrown" (yellow).

All color statements in IVT.RC can take either the name or the number as a specification of the desired color. See also COLORS.

Note that IVT will swap the selected background color with the VT220 default (black), so that when a program explicitly selects black, IVT will use whatever background you select, and when the application selects your background color, IVT will use black. This will keep color displays readable (and I know of one application that selects black foreground color to hide passwords by making them black-on-black so they would show when the background color of IVT was white...
See also SOFTBLINK.

Current session       : [White  ] [Black  ]  Example
Ready indicator       : [Black  ] [Green  ]  Example
Reverse CUT           : [ ]
Cut colors            : [White  ] [Blue   ]  Example
Help screens          : [White  ] [Blue   ]  Example
Selected hyperlink    : [White  ] [Green  ]  Example
Unselected hyperlink  : [White  ] [Red    ]  Example
Cursor foreground RGB : 0   0   0     <Modify>
Cursor background RGB : 0   255 0     <Modify>
Search foreground RGB : 0   0   0     <Modify>
Search background RGB : 255 255 0     <Modify>
Underl. foreground RGB: 0   0   0 [ ] <Modify>
Underl. background RGB: 255 255 0     <Modify>
Blink foreground RGB  : 0   0   0 [ ] <Modify>
Blink background RGB  : 255 255 0     <Modify>

<Redefine ANSI colors>

9.19: Font and Keyboard

This panel controls the main look & feel options of IVT.

Current font               : Face=Lucida Console,Points=9
Font quality               : Default
Poorman's linedraw         : [ ]
Autom. resize font         : [ ]
8-bit chars displayed      : [Codepage]   [DEC     ]
8-bit commands are         : [Executed]
Received data is in        : [ISO-8859-1:1998 (Latin 1, West Europe) ]
Treat ambiguous CJK as wide: [ ]
National replacement       : [US ASCII       ]
IVT dialogs are in         : [English   ]
Input language             : [Use system default    ]

CAPS lock mode             : [Allowed   ]
[X] CAPS+SHIFT is lower case
[X] PF1-PF4 on top row numpad
[X] Recognize ALT-0/9 on foreign keyboards
[[ ] Key click
[ ] Keyboard debug
[ ] EMACS ALT is META

9.20: Log settings

This dialog controls the creation of log files of session data.
The top of the dialog shows the current logging settings.

Autolog name     : .............................................
Autolog mode     : [Off ]  Suspend   Resume
Timestamp lines  : [X]
Write file header: [X]
Show in status   : [X]
Start mode       : [Ask user   ]

Automatic logging can also be combined with a script, see this example.

9.21: Windows setup

Menu bars             : [X]
Vertical scroll bar   : [X]
Status line           : [X]  Borders   : [X]  Middle:  [Clock]
TABs bar enabled      : [X]  Close icon: [X]  Confirm: [X]
Tab text              : [User@Host]   Adj: 0
Full screen scrollbar : [X]   Menu bar [X]  Statusline [X]
Extra vertical border : 2     Horizontal: 0
Delay before tooltips : 300   Keep for  : 3000
Address book size     : 25
Auto complete hosts   : [Any   ]
Show start-up tips    : [ ]
Window position       : [Last known]
Window coordinates   X: 10    Y: 20   <Copy current>
Always on top         : [ ]
Window transparency   : 0  (0 disables)
IVT title bar displays: [Session comment]
Fixed title bar text  : Test comment.......................
Software blink speed  : 400

<Propagate settings>     <Show IVT splash screen>

9.22: Printer setup

This dialog allows you to add, delete and modify printers. You can also assign a specific printer to the current session, change the default printer and modify the way these manual pages are printed.
If you make changes to Windows printers, these changes can be saved to the registry. When IVT starts up, it will re-apply the changes to those printers.
When printers are removed, the IVT extra settings will be discarded the next time you save the setup.

Printer         : [hp deskjet 930c series (Dflt)  ]
Font            : Facename=Lucida Console,Points=9
Open for        : [Append   ]
Timeout         : 28..    <Properties>
Print mode      : [Off     ]
Auto landscape  : [X]
Font scaling    : [X]
Black/white only: [ ]
Auto Form Feed  : [X]
Prompt if exists: [X]
Controller mode : [Raw  ]
Mode            : [Off       ]
<Make this printer the default>
<Add a printer-to-file>
<Delete this printer  >

Print screen with statusline:  [X]
Confirm print screens       :  [X]
Confirm print selections    :  [X]
Print screen with timestamp :  [X]
Manual prints lines/page    : 61.
Manual prints indents       : 10.

With this, you can control the logical printer for the current session, or add new (logical) printers for the current (and future) sessions.
IVT will show all your Windows printers here, with their normal names. You cannot delete such printers, and you cannot set a page length for them (this depends on the paper size and it automatically determined at print time).
You can click on the FONT line to change the font used for all text output to printers. Click on the <Properties> button to change the default properties for the printer.
All other printers are files, and treated as such.

If you just want to print a Unix file, check out the privt support program! This prints Unix files on your Windows printer!

IVT can manage multiple printers (each 'printer' can be any writable file).
A session can be connected to one of these printers. A printer may be shared by several sessions (output will be intermixed from all sessions). Of course, different sessions may have different printers, which can all be simultaneously active.

A printer is selected in this F3 screen. Logical printers can be added by clicking on this button. A newly created printer becomes the default for the current session only.
By clicking on the <Make this printer the default> button, the selected printer will become the default printer for new sessions.
The PRINTER keyword can be used in an IVT.RC file to define the default printers.

Every printer has an overwrite/append flag that determines how the printer will be opened. When 'overwrite' is selected, any existing file is overwritten.
When 'append' is selected, output is appended to that file. For a true device the setting is (usually) irrelevant.
There is also a timeout associated with each printer. When the specified number of seconds has elapsed without activity for the printer, it will be closed automatically.

A printer is 'opened' by the first session that sends something to that printer. This can be done by:

• Using the F2 (print screen) function key. This will give you a dialog which has to be confirmed or escaped (but see CONFIRM_PRSCREEN). This is the standard Windows printer-selection dialog.
• Using setup and setting 'Printer Mode' from off to either controller (where output goes ONLY to the printer) plain text (lines are printed only when the cursor leaves the line in a normal way) or all text (where every received byte is also sent to the printer (including escape-codes)).
• The host can use VT100-escape sequences to control printing.

When a printer is active for the session, a icon will show in the status line. The printer is not closed until a "FLUSH PRINTER" button is used from the main setup screen, or the specified PRTIMEOUT value elapses without activity.

Closing will cause actual printing to start on spooled (network) printers (this prevents every PrintScreen from becoming a separate spooled print job, thus saving paper, banner-pages and aggravation).

Using the black & white feature will suppress color printing.

Also, you can record an entire session to a printer without generating many individual print jobs every time nothing happens for a few seconds (but see also AUTOLOG for better ways of logging sessions).

See also PRINTER, PRTIMEOUT , AUTOLANDSCAPE, PRINTER_FONT_SCALE and PRBLACKWHITE.

9.23: Keyboard macros

Keyboard macros allow you to program keys manually (learn mode). You choose a key you want to program, and start the recorder. IVT will switch you to the session screen and will start recording every keystroke. You end learn mode (which is indicated in the status line by an icon) by returning to setup and choosing the <Keyboard macro> button again (which will read "END MACRO" in that case). Alternatively, type Shift+Ctrl+End or use the menu bar.
See LEARN for details, or click on any of the links below for detailed help on that particular option.
Macros are saved into the registry when you save your setup settings.

<Choose key to program>

This session only      : [ ]
Match LEFT/RIGHT Shift : [ ]
Match LEFT/RIGHT Ctrl  : [ ]
Match LEFT/RIGHT Alt   : [ ]
Match CAPSLOCK key     : [ ]     <Read/Write macro files>
Match NUMLOCK  key     : [ ]
Match SCROLL LOCK key  : [ ]     <Delete all macros>
Match Scan Code        : [ ]
Recursive expansion    : [X]

Type of programming    : [Keyboard recorder         ]
Fixed string value     : ..............................
Script to invoke       : ..............................
Function to perform    : ALT-0 (any key)...............

<Start recorder> <Delete key>          <Cancel>  <OK>

For a detailed explanation on key macros and their many options, see the special chapter on learn mode.

9.24: Encrypting files

Filename            : .............................................
<Browse for file>
Use default password: [ ]
Password            : ........
Password (retype)   : ........
<Encrypt>    <Decrypt>

This panel allows you to encrypt or decrypt files with either a default key or a password you supply. When a default key is chosen, the file can never be decrypted (!), but can be read by IVT during start-up without prompting for the password. However, see also CRYPTPWD, which allows you to store keys in a file which is encrypted with the default key (so IVT can decrypt that file, learn your passwords, and decrypt other files without prompting for the password).
See Encrypting .RC file for more details.

9.25: ZMODEM setup

Download directory        : C:/tmp/transfer....................
Host has buggy binary     : [ ]
Autodetect ZMODEM transfer: [X]
Maximum &packet size      : [1024]

9.26: Setup: Reset terminal

When you type an F3-R sequence (or click on the "Reset Terminal" button in the main F3 setup panel), the virtual terminal will be reset to default settings. Use this when the session has gotten stuck or in an inoperable state due to (for example) sending a binary file to the terminal (cat-ting an executable is an oft made Unix error that can bring a terminal in such a state). F3-R will do everything that a host initiated reset command does, and will also:

• Cancel any running script (see also F3-C);
• Clear the history buffers.

The last feature is useful if you want to do a simple sort of file transfer. You can first clear the history pager buffers, then start a command sending a lot of output to the terminal, then use ALT+s in pager mode to save the entire buffer contents to a file.

By the way, also look into F3-D for a quick way of getting rid of unwanted output sent by a host.

Note: F3-R resets the current terminal to the terminal defaults. If you have made configuration changes that affect all sessions (like the font, or the extra border size, the title bar setting or the status line settings), they are NOT restored. For that you'll have to change them back or exit IVT and restart.

9.27: Setup: Cancel scripts

The F3-R command resets an entire terminal. One of the results of this is that any running script is cancelled.

The F3-C command (either typed or by clicking on the "Cancel Scripts" button in the main F3 setup panel) is less destructive - it ONLY terminates all scripts and threads that are active for the current session. Use this if a complex chat-script runs into difficulties due to unexpected responses from the host.
Aborting a script also undoes any DISPLAY OFF command, and restores any temporary status text set by a STATUSTXT command.
Any existing WINDOWs are killed.

See also the CANCEL statement, by which a script can protect itself from termination by either F3-R or F3-C. Such a script can only be stopped by a KILL, termination of the session or its own free will.

9.28: Setup: Dump data

Sometimes, a host is given a wrong command and starts sending tons of binary garbage to the terminal. In Unix, cat-ting an executable file is a well-known example of this. Normally, you would interrupt this with ^C, but sometimes the network has accumulated tons of data in buffers that IVT has to wade through because the buffers are not always cleared when you use ^C.
Normally, this is not a problem because IVT is so fast, but binary data can contain a lot of garbage that causes a lot of processing in IVT - the most obvious example is a BELL character which will cause IVT to ring the bell for a substantial fraction of a second. For some unknown reason, there are a lot of BELL characters in the average executable :-)

Whenever a host starts doing this, you can use the F3-D command - IVT will start throwing away everything that arrives on the session without actually looking at the data - it only counts the number of characters discarded this way and displays this counter on the screen. It will keep doing this until:

• Nothing arrives on the session for more than a second;
• You type a key.

In both cases, IVT will then switch back to the session. Afterwards, the F3-R command may be needed to get rid of side effects of the garbage that got processed before you managed to type an F3-D.

9.29: Setup: Flush printer

Printers are usually not attached physically to a Windows PC anymore.
Usually, you will have a network connection to a printer. When the printer is opened, all output is accumulated in a file which gets printed when the printer is closed. This is different from a real VT220, where a physical, noisy printer could be attached to the back of the VT220 terminal, and every line (or character) would get printed immediately.

When IVT opens a printer, a printer icon shows in the status line. The printer stays active until:

• The timeout expires;
• You click on the printer icon on the status bar.
• You click on the <Flush Printer> button (or type F3-F);
• The host sends an ESC<space>p command or you use this in a script via a VTECHO command (the old way);
• You use an IVTFUNCTION with "Flush Printer (F3-F)" argument (the new way).

Only then will your job actually start printing (or the file is closed in case of a (manually added) printer that is actually a file).

See also AUTOLOG.

This is an important feature, others are prev/next

10: F4 - Help & Various functions

10.1: F4-S: Session ordering

Using F4-S(essions) will take you to a panel that shows all existing sessions and their primary attributes. These attributes are:

• Seq.
  Sequence number of the session, shown as the first number on the status line. Automatically assigned and managed by IVT.
• Grp.
  The group code of the session. See below for manual editing and CREATE for automatic assignment of group codes.
• Prt.
  The protocol of the session. TLN=Telnet, RLN=Rlogin, SSH, or SER=Serial.
• Hostname.
  Name of the host or device that the session is connected to. This is also displayed in the status line. It can be set manually in this screen (see below) or using CREATE. From a script, it can be set using the STATUSHOST command.
  See also SESSION_OVERVIEW, which also determines what you see here.
• Comment.
  Descriptive comment that is also displayed in the status line. It can be set from a CREATE statement or (manually) below. From a script, it can be set temporarily with the STATUSTXT command or permanently with the STATUSTXTFIX command. The HOSTLIST command is another source of comments. This field is very useful to describe the purpose of the session. Personally, I find it very handy to have a number of CREATE statements in my IVT.RC file to automatically create a bunch of sessions during start-up of IVT (using the -A command line option and an OPTIONS statement in the ivt.rc file to take care of the rest of the options.

While in this panel, you can perform the following actions:

• Use the "Move UP" and "Move Down" buttons to change the relative order of sessions. This will drag the currently selected session to a new place, and reassign all session-sequence numbers. You can also type a number in the "Move to" box and that will move the currently selected session to the indicated position (or the nearest possible value if the number you give is too high).
• Click on a line in the main window to select that particular session.
• Double-click on a line will select the session and switch to it immediately.

• Click on the "Save as a group" button will use the current set of connected sessions and turn them into a CREATEGRP. Host name, user name, protocol, comment, profile and the order of the sessions are preserved in this group. This means you can re-create these sessions with only a few mouse clicks. The group is created in the registry, which means you can use the sessions group editor to tweak the group and the individual sessions in the group. After clicking on the "Save as a group" button, you will be asked for the name of the group. When a valid (unique) name is given, the group is created and the editor for it is started (so you can add a description and other options and details for the new group). The group can be started as any normal group (by using the group name as if it is a host name, using the "Groups" button in the "Create session" dialog and so on).
• Click on the "Kill session" button will ask for confirmation before forcing a disconnect on that session. For normal TELNET sessions, this implies that any programs running on the host will receive a SIGHUP (hang-up signal), which should terminate them.
  It has the same effect as typing ALT+F4 while in the session screen. When the last session disappears, IVT will exit (but see also the EXPLICIT_EXIT directive to change this).

Click on the "Edit/details" button to view or change the session details. This will bring up a new dialog with the following fields:

• Session (same as the "Seq" field in the previous panel)
• Id. This is the internal identification of the session, shown as part of the 'session established' message. These numbers may show up in network tables of the PC (file descriptors, sockets and so on).
• Protocol, IP version and remote address. The protocol will be something like "SSH" or "TELNET". The IP version will be 'IPv4' for an old-fashioned IP connection and IPv6 for a modern one. The remote address will show the actual address. For an IPv4 session, this will be a dotted-decimal address and port number, for IPv6 it will be the full hexadecimal address and port number. For non-IP sessions (serial, netbios) the TCP/IP fields are omitted.
• Hostname, as it appears in the status line too. You can edit this, which is useful when you rlogin or telnet away from the machine IVT is connected to (so the machine you are working on is no longer the one displayed in the status line). See also this part of the status line.
• Comment. See description above. Free text.
• Tab text. A right-click on the tab of a session takes you straight to this dialog that allows you to set a different text for the tab. The TABSBAR command determines the type of the default text, which can be overruled by the SetTabText function or by manually typing another value here. When you make this field empty, the default is again supplied. The icon of the tab can be set using the SetTabIcon script function.
• Group code. This is a single character or digit. Groups allow you to treat a number of related sessions as if they were the ONLY sessions running in IVT. Having several groups is logically the same as running multiple instances of IVT, but it is much easier to switch between groups then it is to switch between programs. Using Ctrl+Cursor keys will only switch between sessions in the same group, the status line will show the current and total number of sessions for the current group only (but will also show the code of the currently selected group, or a '+' if the current groups is a blank (default) but other groups exist).
  Switching between groups can be accomplished by using ALT+g or from the F4-S screen where ALL existing sessions are displayed. Groups are handy if you have many sessions, some of which are related to each other and you want to treat the group a logical unit of work. The default is to have a 'blank' as the group code, but you can set one using one of the parameters of the CREATE statement automatically. Also, the "More" setting of the "Create session" dialog allows you to enter a group code fo the session you are about to create. When you (multiple) select hosts from the address book, that dialog also allows you to specify the code for all the sessions you are about to create. Finally, you chan change the group code of an existing session by using the F4-S screen, or by right-clicking on the tab and choose "Edit". When activity in groups other than the current one is detected, the status line will show a 'G' code in the last position of the activity indicator.

You can also quick-select the F4-S screen by clicking the mouse on the position of the hostname or comment-parts of the status line.
Yet another way is to select the WINDOW menu on the menu bar.

This is an important feature, others are prev/next

10.2: F4-G: Create a named group of sessions

The CREATEGRP statement can be used in an IVT.RC file to describe a logical group of sessions. The group has a name and a description.
Your setup may have multiple CREATEGRP statements, each group presumably describes a group of sessions you want to create in a single operation.

Such a group of sessions can be created by typing the name of the group at the Ctrl+PgDown prompt, but this screen offers an even easier way.

The F4-G screen shows all such named CREATEGRP groups (name and description).
The standard cursor keys can be used to select an entry, the ENTER key can be used to select the current entry.
Even easier is to simply click on one of the lines.
There is an entry on the menu bar in the SESSIONS menu too.

IVT will immediately create the bunch of sessions that belong to the group.
When you use the password learning and autologin system, all these sessions can log in and perform some task after logging in too! This means you can create a whole bunch of sessions with only a few mouse-clicks that will start your mail, news etc. programs for you on demand.
Using the -A or -agrp command line options allows you to do this from a shortcut on your desktop or your start-up folder.

10.3: F4-X: Managing scripts

Scripts can be written and stored in IVT.RC files. IVT will read these files at start-up. You can also explicitly read files using F4-X-R, which is convenient when you are developing scripts.
A script is parsed and loaded into memory, from where it can be executed by using F4-X, selecting the proper script, and typing ENTER.
Alternatively, you can simply click on the appropriate line.
A script can be removed from memory from the F4-X screen by typing DEL there.

Scripts come in two types: Visible and HIDDEN ones. Visible means that the F4-x screen will show them and the user can invoke them. HIDDEN scripts can only be called by other scripts.
When a script is not hidden, a DESCRIBE statement can be used to describe the purpose of the script. This will be shown in the F4-X screen, too.

When complex series of scripts are developed (such as the modem dialer example) it can be convenient to have them in separate files, which can be INCLUDEd from your main IVT.RC file.

Any of these files can be encrypted, IVT will prompt for the password when none of the passwords it has remembered work.

Scripts can take parameters. The F4-X screen does not offer any interface to pass parameters, however. When required, you will have to write a wrapper script that interactively asks for these parameters (e.g. using KbdLine or PROMPT) and then calls the function actually desired.

10.4: F4-K: Managing macro's

All keys in IVT are programmable in various ways:

• Using F3-L, you can put IVT into learn mode. The new key definitions can be stored in a file using F4-K-W, and can be loaded again at start-up of IVT using the LOAD keyword in an IVT.RC file. These keys can be programmed per session or for all sessions. Use this when you find yourself repeatedly typing the same keys in the same order.
• Using the BIND command, you can cause a SCRIPT to be executed whenever you type a key. This allows for more complex things, since the script can use SEND, WAIT and IF statements to interact with the host. Use this when the interaction with the host fails with learned keyboard macro's because IVT 'types' to fast.
  See also BIND_SYNC.
• Using the KEYMACRO command, which is a newer and more powerful form of the BIND command and accepts any key-combination instead of only the standard VT220 key names of the BIND command.
• Keys can be programmed using the keyp Unix program. This employs a standard vt220 escape sequence to program vt220 keys, and an IVT special sequence to program other keys.
  This can be used to program keys regardless of what emulator you are using. Handy when you do not control the IVT configuration files.
• Standard vt220 keys can be programmed in an IVT.RC file simply by naming it like thus: NXTSCR "ls -lab\r" programs the "NextScreen" key (the PgDown key on a PC) to emit a directory listing command.
  The KEYMACRO is a newer and more powerful command for this.

This is an important feature, others are prev/next

11: Protocols supported by IVT

11.1: Overview of supported protocols

One of the major features of IVT is that it can run several sessions simultaneously, even over different transport (low-level) protocols and several built-in session (higher-level) protocols. See the PROTOCOL IVT.RC statement for a description of how to select these protocols.

IVT supports the transport protocols listed below. However, IVT can be compiled with or without support for any of them. See the PROTOCOL documentation for a list of protocols actually supported by THIS version of IVT:

• SERIAL
  The COM-ports of your computer using either a built-in or external modem or a direct line. An entire chapter is devoted to this protocol.
• NETBIOS
  A LAN interface found on many PC's. Win'95 (and NT) even support the NetBios interface over TCP/IP (to confuse the issue here :-) This protocol was common around 1995, but has faded out of view ever since.
• TCP
  This is on MS/DOS only. IVT uses FTP Inc.'s commercial, proprietary TCP/IP stack to communicate over TCP/IP.
• WinSock
  A way to interface to TCP/IP on Windows machines. All modern PC's use this to communicate over a network.
  This version of IVT supports both IPv4 and IPv6 sessions.

When you use a network protocol, the hostnames you use must match the convention of that protocol. This means that hostnames typed in on the command line, CREATE statements or the CTRL+PgDown prompt depend on the protocol that will be chosen by IVT for the new session. This can be set using either the setup screen or the PROTOCOL statement.
Each section below describes the possible hostnames you may use for that particular protocol.

IVT also supports several session protocols to run on top of the transport protocols. For example, on top of TCP/IP you would have to use either RLOGIN or TELNET to get a login session with a Unix machine. The session protocol determines how to interpret the data sent by the host. Currently, IVT supports:

See the appropriate sections for further details.

11.2: Transport protocols

11.2.1: The NetBios transport protocol

When the NETBIOS protocol is chosen, IVT will check to see if NetBios protocol stacks are available on your computer. The NetBios interface is actually only an API (application program interface) that will usually use NetBeui or TopNetBios or some such protocol as the actual transport. But it is also possible to use another transport (such as TCP/IP) "underneath" a NetBios API.
As a good example, Win'95 provides this by default. As far as IVT is concerned, the Win'95 machine offers several logical NetBios adapters, which (in olden days) were used to connect PC's to several LAN's using several physical network adapters.
On Win'95 (or NT) one of these "adapters" is actually NetBios-over-TCP/IP, allowing IVT to make (limited) use of the TCP/IP protocol, which is now in much wider use than Netbeui.

IVT will check for the presence of logical adapters and broadcast a unique name on each network it finds (a necessary ritual on NetBios networks).
When a connection needs to be established, it will attempt each network in turn. When a successful connection is established, IVT will remember what network it found this host on, and the next session will be attempted at that network first (since a failed attempt can take many seconds and you will usually talk to hosts on one network only).

NetBios hostnames are typically names (just one word), such as "SERV01".
Sometimes, these names end in ".LOGIN", so a typical name might be SERV01.LOGIN. OliNet LAN was the birthplace of IVT, so IVT still appends this .LOGIN as a default to every NetBios hostname unless you tell it not to by using the -L command line option or the OPTIONS statement in an IVT.RC file.

This protocol has fallen out of use ever since 1995 or thereabouts.
WinSock is now the protocol of choice.

11.2.2: The TCP transport protocol

Sorry - this MS/DOS protocol is not in this version of IVT.

The second protocol to be supported by IVT was FTP Inc's TCP/IP implementation for MS/DOS based computers. This commercial package offers a TCP/IP stack together with a package to develop applications on top of this stack.

IVT uses the 'telnet' library offered by this package to enable it to make direct login connections using the telnet protocol.
Actually, this introduces a design problem, since IVT ought to support its own TELNET session-protocol on top of any transport protocol (such as the socket interface also offered by this development package). But time was short and the functionality was important, so the IVT transport "TCP" is actually a transport + session protocol rolled into one.
Later, this was rectified with the introduction of the WINSOCK transport protocol and RLOGIN and TELNET session protocols.

You need to purchase Ftp Inc's DOS stack to be able to use IVT with the TCP protocol. IVT will automatically detect this protocol and use it when no other LAN interfaces (such as NetBios) are detected.

When you specify a hostname to connect to, you must either specify a name that can be resolved by your TCP/IP setup (using the hosts files and/or DNS name services) OR a dotted-address style internet address (like 145.72.248.60).

Optionally, this address can be followed by a : and a port number. The default port number is 23 (telnet), but you can connect to other ports this way (the SMTP port 25 being the most popular one).
This notation can be used in CREATE statements, too.

The current telnet protocol also allows a few special TELNET functions, accessible via this setup screen.

11.2.3: The WINSOCK transport protocol

Adding the WINSOCK interface to IVT was no small feat. IVT was a DOS program, and WINSOCK is a Windows Socket interface (Sockets being a way to interface to TCP/IP networks).

After a brief and disappointing experiment with Winsock for DOS and the DJGPP C-compiler I discovered I could compile large hunks of IVT with the visual C++ environment for Windows. The result was a text-mode Win32 application, which has full access to all the Windows calls without the GUI overhead.
This enabled me to write an IVT WinSock layer, on top of which I wrote a TELNET engine (from scratch).
The other protocols (NetBios and Serial) were also rewritten for Windows.

I had to make many modifications to the video and mouse system, just about rewrote the keyboard handler and many more small modifications to make IVT run happily under Windows 95 and Windows NT.
New commands were added to take advantage of the Windows possibilities.
The color handling is now much nicer, variable window sizes are used, sound files can be played, etc.

We are talking several months of work here!

IVT is now a fast, flexible, native Win32 application.

In the summer of 2002 I decided to make IVT a GUI application. Trouble with the mouse, keyboard, the latest versions of Windows and the clumsy resize of IVT windows, no font support, no scroll bar and so on finally bothered me enough to do something about it. Version 16.1 is a true GUI program, has true underlining, a scroll bar, font support, true double-wide and double-high characters, and so on. Internally, that meant making IVT a multi-threaded application, yet another rewrite of keyboard and mouse handling, and several thousands extra lines of code to deal with the extra possibilities.

Anyway, WinSock is the underlying transport protocol for (in this build):

• TELNET,
• Kerberized TELNET
• SSH
• Rlogin

In the fall of 2010, IPv6 support was added. The code for resolving addresses needed a rewrite for this, and many changes to the code for connecting sessions (when a host has multiple addresses with a mix op IPv6 and IPv4 then IVT will try them in sequence. Port forwarding, proxy support and so on all had to be made IPv6 aware.

11.2.4: The SERIAL transport protocol

Support for serial communications was introduced in version 7.3 of IVT and was the third way to connect to hosts (next to NetBios and TCP/IP).
Serial lines are really very different from LAN-connections. They are much slower, you can have only one connection on them, and the host you connect to depends on where the physical wire goes. A direct connection is used to connect your PC running IVT to a serial port on another computer, or you can use a modem to dial into other computers via the telephone network.
See the dialer example for further info.

When you are a LAN-user of IVT, the slowness and single-naturedness of these connections is something you have to get used to. To overcome the limitations of these serial connections, IVT comes with two extensions:

• Dialer
  You can provide a file which describes telephone numbers and names of systems you can reach over a modem connection. IVT will dial for you and (optionally) do the login for you.
• IVTM
  This is a Unix program that allows you to use the remote Unix computer that you access over a modem, with several sessions simultaneously as if you were sitting on its local LAN. This is very, very powerful and once you get used to it you'll wonder how you ever got along without it.

When the initial connection to a serial "host" is made, IVT only opens the serial port of the local computer. Therefore, the hostname specified on the command line must take the form of:

   COMn[,baud[,parity[,databits[,stopbits]]]]

Where all these fields have the following meaning:

Example: COM2,19200,n,7

Only the port number is compulsory, the rest is optional and defaults to:

        9600,n,8,1

The IVT.RC commands you can use to change the settings of a serial port are:

The status line will reflect the current port selections. The leftmost position is used as modem indicator.
The serial setup screen also allows you to verify and change all serial port settings.

Starting from version 14.1a, you can also send a BREAK signal on a serial line. From this setup screen, you can initiate either a short (250 Ms) or a long (1.5 seconds) break. This puts the connection in a special state that is sometimes used to wake up a remote host or reset the connection.
When you click or enter on the appropriate line, you will be switched back to the session automatically.

This is an important feature, others are prev/next

11.2.5: The multiplex transport protocol

IVT allows multiplexing multiple sessions over a single connection. Very handy when you are using a non-LAN connection (e.g. serial line), though this session protocol is also supported on all other transport protocols.

This mode is entered by running the Unix multiplexer ivtm on the remote end.
The 'normal' session disappears, to be replaced by a new login on a pseudo terminal on the Unix host. This login is necessary to make sure that you get a 'real' new login session that is registered as such in Unix (in the utmp file, for example). The original session is made non-writable because a special protocol is now spoken on it. A message from the sysop (using e.g.
wall) would interfere with this protocol.

New sessions can be created/closed in a normal fashion, the only difference being that you do not start a session to a computer, but must specify a remote command that will be started on a new pseudo-terminal.
The default command is telnet %s, where %s is substituted by whatever you specify as hostname. This default command can be changed using the MLDEFCMD IVT.RC setting (e.g. rlogin %s).

The upshot of all this is that, once ivtm is started on Unix, you can pretend you are on the local LAN of that computer and create sessions to all other machines on that LAN. Everything works the same except for the telnet escape character of the Telnet running on Unix (usually CTRL+] or CTRL+A).
This will give you a telnet prompt which you might not expect.

Logging out from a session will terminate the particular telnet (or rlogin), which will cause ivtm to send a special message to IVT so it can close the session. Depending on the setting of RECONNECT, this will either display a message that the session ended (when RECONNECT is in effect) or will make it quietly disappear (when NO_RECONNECT is in effect).

When the last session started from IVTM terminates, IVTM itself exits. This should cause your 'raw serial' session to reappear, and things are back to the way they were before you started IVTM (a single serial session).

There is another problem that arises when you use a modem dialup to a host on which you want to run ivtm. The binary protocol used by ivtm can confuse hardware between IVT and the Unix host (modems, port selectors, multiplexers and what have you). XON/XOFF characters are notorious, so are NULL characters that sometimes get eaten somewhere along the line.

If you already used TELNET or RLOGIN before reaching the host you run ivtm on, the escape sequences of those programs become special, too.

To avoid these special characters, use the MLFILTER command. Here you can specify a simple list of decimal ASCII codes, which will be escaped on the link (taking 3 bytes rather than 1, so don't overdo it).

Remember that all the sessions used from ivtm have to share a single modem connection with limited speed. Doing a file transfer in one session will have a noticeable effect on performance in the other sessions. Also, consider what has to happen when you use F1 (Hold Screen) on one of these sessions. IVT cannot simply stop reading (like when it is a LAN session) because data intended for that session would block data intended for other sessions.
Therefore, IVT will send a message to ivtm when F1 is pressed, which will cause IVTM to stop sending data for that session.
Another F1 will resume output.
This makes F1 less immediate than usual, but that is a small price to pay.

The last catch has to do with systems that fail, causing the link between IVT and IVTM to be broken (modem that loses a connection, crashing Unix system (rare, but happens :-) or a failure in either IVT or IVTM.
The 'solution' for this is that you can forcibly disconnect sessions by using ALT+F4 in the normal fashion. The FIRST time you do this on a session managed by IVTM, IVT will send a termination message to IVTM. Normally, this will result in a close of the session, which is acknowledged by IVTM, which will result in a normal shutdown of that session.

If IVTM is not responding (for whatever reason), a SECOND ALT+F4 will result in an immediate local abort of that session in IVT. This way, you can clear all sessions that are left behind when the modem connection is lost.

On the IVTM side, all sessions will be killed automatically when the connection to IVT disappears prematurely, and IVTM itself will exit.
Normally, this should free up everything, making the dial-in available again.

Multiplexed sessions can be mixed with 'normal' sessions, so you can have a LAN session between your PC and Unix box at home, while simultaneously dialing out through a modem to a Unix box that runs ivtm.

11.3: The IVTM program

This version of IVT supports the multiplexing protocol.

The multiplexing protocol allows you to run several independent simultaneous sessions over a single connection (such as a serial line). It will also work over other types of connections (such as TELNET or RLOGIN sessions).

The details about using ivtm are explained here. This section explains how to get the ivtm program running on your Unix hosts (which is currently the only environment supported by IVTM).

In your IVT distribution kit you'll find the file 'ivtm.c'.
This file can be compiled on:

• SYSVR4 (STREAMS based PTY's);
• Linux;
• HP-UX.

Ports to other flavours of Unix are possible.

Simply typing:

        make ivtm

to any Unix prompt should result in a 'cc -O ivtm.c -o ivtm', which implies a default compile of the source into an optimised 'ivtm' executable.
Simply starting this executable (no parameters) should be everything you ever need to know about it. When things do NOT work as advertised, you might try:

        ivtm -d

which will create a file called ivtm.debug with (very) detailed debugging info.
Ask for support (at ivtsupport@softwarevoordelig.nl) if you have trouble.

11.3.1: The DUMMY transport protocol

The DUMMY protocol is a late addition to IVT (appeared in version 20.1).
It is a very simple protocol:

• Any connection to any host will immediately succeed;
• The session never sends anything by itself, never fails, never goes into an error state and never disconnects by itself;
• Anything you SEND (or type) on the session is echoed back using VTECHO so you can use all VT220 escape sequences and commands.

The reason for this protocol is that sometimes you just want to use IVT as a batch system that connects dynamically to all sorts of hosts, or even just reads and writes local files.
IVT insists that you have a session context to run scripts in, so you need a connection to "something" before you can call scripts, have variables, and are able to create THREADs or FORK sessions.

Without the DUMMY protocol, you would have to resort to a connection to some localhost port, or a serial connection, or even a real connection to some host you happened to have just to satisfy the session requirement.

All these have serious problems, since a serial port may not be available, or the localhost connection can fail or cause problems (by sending some data you did not expect or want), the remote host can be down or unreachable, etc.

Because a connection to a host using the dummy protocol is a full blown session, you can use the full array of commands and variables IVT has to offer. You can use the actual HOSTNAME variable as a sort of label (it appears in the status bar). You can have as many simultaneous sessions to DUMMY as you require.

You can choose the DUMMY protocol from the command line using the -D option.

11.4: Session protocols

11.4.1: The TELNET session protocol

The WINSOCK transport protocol enables IVT to use the TCP/IP layer of Windows workstations. However, this in itself is useless without a transport protocol such as TELNET or RLOGIN.

TELNET is an old and very widespread protocol. It can be used between very different types of computers because it implements a device called an NVT (Network Virtual Terminal) on both sides of the connection. The NVT must implement a number of basic features and handling the peculiarities of the local operating system and/or hardware is the task of the telnet terminal or telnet host.

Besides the basic features, many options were added to the TELNET protocol.
The basic NVT implements a negotiation protocol for these options.
Every TELNET implementation can request a certain option to take effect and it can reject every option that it does not know about. This allows advanced implementations to work with older and/or less advanced peers.
Every option is described in a separate RFC (Request For Comment). The texts of these RFC's are freely downloadable from the Internet. I've downloaded all of them and implemented a lot of them, which makes IVT one of the most complete TELNET implementations around. I have seen many "modern" hosts reject requests from IVT to enable a TELNET feature that IVT knows about.

When you enable TELNET_TRACE, IVT will show the negotiation process on screen.
For every request the host makes, IVT will show "Received DO <option>". The option is described and the RFC that defines it is named as well.
When IVT can handle the option, it will say 'WILL <option>'. When IVT cannot or will not do the option, it will say 'WONT <option>'.
Usually, the host will start by sending a bunch of options that it wants enabled. When these are all answered, IVT will inspect unrequested ones that it would like to see enabled and give it a try by sending out its own 'DO' commands. Usually, it is rewarded by a bunch of 'WONT' answers because these are the ones the host does not know about.

For some options, when a host receives a 'WILL' from IVT, it means that the host is now allowed more complex commands, such as the 'Terminal Type' option.
When the host wants to know what kind of terminal is being emulated, it will first ask 'DO TERMINAL-TYPE'. When IVT replies 'WILL TERMINAL-TYPE' the host will say 'SUB-OPTION TERMINAL-TYPE SEND' which means: "Please be so kind to send me the type of terminal, which you can, because you said 'WILL'".
You can use the TELNET_TTYPE command in an IVT.RC file to specify the value that IVT will transmit to the host (defaults to vt220).

At the end of all the negotiations, the host will usually display the login prompt.

Below you find the full list of options for the TELNET protocol. The ones that appear bold are the ones implemented by IVT. The other ones are either not applicable for a TELNET client such as IVT, or I have not found the time yet to implement them. Stay tuned!

11.4.2: The RLOGIN session protocol

RLOGIN is a session-protocol that was added in version 8.v of IVT in May 1997.
It is designed to run on top op the WINSOCK protocol (but will run on top of any other protocol, too). RLOGIN is a Unix protocol that allows remote users to login without necessarily supplying a password.

An alternative is TELNET, a more well known protocol to do the same.
RLOGIN is based on a rather simple 'trust' system, where the host can allow users from particular systems to login using the same user name. When the system is configured to trust the remote system (or user), that particular user on that particular system does not have to supply a password when logging in. Other Unix commands, such as RCP and RSH also work without passwords in this case.
If the remote user is NOT authorized to log in, these utilities will prompt for a password.
Another titbit of information that can be transmitted to the host is the type of terminal your are using (the Unix TERM environment variable).

IVT can use the RLOGIN protocol with a configurable local user name, remote user name and terminal type. The terminal type defaults to 'vt220', the usernames default to none (empty strings). These defaults can be altered either from this setup screen or with the IVT.RC commands:

RLOGIN_LOCALUSER        : To set the local username
RLOGIN_REMOTEUSER       : To set the username to use on the host
RLOGIN_TERM             : To set the terminal type.

The information is simply passed to the remote host just after the session has been established. If the host does not trust the IP-address that you are calling from, or does not trust the particular user-id that you claim, it may either disconnect or prompt for a password.

Note that the Unix machine tests the originating TCP/IP port (must be a privileged port). On Unix, you have to be 'root' (super user) to get such a port for your outgoing session. The remote host will disconnect any session from an 'untrusted' port immediately. On Unix, the RLOGIN program is privileged. It will also send the actual username of the invoking user to the remote end.

However, on a PC anybody can do anything, so IVT can get a 'privileged' port without any trouble, and it cannot know the username of the user since it does not know LanManager from Banyan from Novell from whatever. So the username it sends to remote is whatever you set it to. If the host chooses to believe all that, that is up to the host.

11.4.3: Secure Shell (SSH-2)

As of version 17.0 (august 2003), IVT supports Secure Shell version 2, also known as SSH2. The code for this was largely borrowed from PuTTY, and I would once again like to thank the authors of the excellent program for making the source available.

Secure shell is a widely used protocol to encrypt the session between IVT and the target host. The prevents the sniffing of passwords from the LAN (a simple technique that makes TELNET really insecure).
The Kerberos protocol in IVT allows similar protection. SSH and Kerberos solve the same problem in different ways. The major differences are:

• Identification of host computers.
  Any SSH client can connect to any server. The user cannot know if the server is actually the one it claims to be. The public key of the server is stored by IVT and compared the next time, so you will at least know you are connecting to the SAME server every time. Kerberos will work only when the host computer proves its identity to IVT, just as IVT must prove the identity of the user to the server. This is more secure, but the price is that all users and servers must be administered centrally.
• Integration.
  Kerberos integrates with Windows to support Single Sign On. SSH requires passwords on the host or key files, which are difficult to manage if you have many hosts.
• Encryption.
  SSH supports modern ciphers such as AES - Kerberos/IVT not quite yet. The modern ciphers are considered stronger.
• Elegance.
  Kerberized TELNET uses the extendibility of the TELNET protocol to add the authentication and encryption. SSH comes in two flavours (SSH-1 and SSH-2). These versions are fundamentally different and both do not use the TELNET terminal model (and so have their own sets of commands to handle the size of the window, keyboard and screen stuff, X-windows and so on). Personally, I think it is a pity that SSH re-invents all of that.

The SSH layer of IVT currently supports SSH-2 only. The SSH-1 protocol is deprecated and therefore not supported.
The SSH X-window port forwarding code in IVT is shared between the Kerberos style and SSH style modes.

See the following links for more details:

SSH_CIPHERS             - Specify order of ciphers
SSH_ACCEPT              - Automatically accept/reject host keys
SSH_BUGS                - Detect SSH server bugs
SSH_COMPRESSION         - Data compression in SSH
SSH_DATA                - Sending commands
SSH_DEBUG               - Getting debug information
SSH_INTERACT_PWD        - Enabling keyboard interactive login
SSH_KEEPALIVE           - Send No-Operation packets regularly.
SSH_KEYFILE             - Specifying a private key file
SSH_LOGDATA             - Packet-level debugging
SSH_PSEUDO_TERM         - Allocating a PTY
SSH_TERM                - Specifying terminal type
SSH_XAUTH               - Method of X-windows authentication
FORWARD_X               - X11-port forwarding
XAUTH_DELAY             - XAUTH problem handling.
SSH_FORWARD             - Generic port forwarding
SSH_KEX                 - Key exchange options.

SSH_BUGS                - Detection and handling of bugs

12: Syntax of IVT.RC setup files

12.1: Introduction to IVT.RC files and Table Of Contents

When IVT is started, it looks in several places for a file called IVT.RC.
When such a file is found it is read and processed. To be specific, it tries the following names:

• If the "-c" command line option is used (config file) it reads ONLY the file specified on the command line and does not try to find any other file. This is intended to be used when IVT is used to script interactions with a host and you want complete control over the environment (and not some unexpected ONCONNECT script from a private user file taking control).
• $IVTDIR/IVT.RC
  In whatever directory IVT.EXE finds itself. This file is intended to configure global settings for all users (only significant when there are multiple users sharing IVT on a network install). This file is part of the IVT distribution and can be overwritten by a future upgrade. If you make modifications to this file, be sure to save a copy of your work somewhere. The file provides various hooks to other setup files, using INCLUDE_OPT commands (optional includes).
• %HOME%/IVT.RC
  Home directory of the user (when HOME environment variable exists). This step can be supressed using NO_PRIVATE_RC_FILES. The file is intended to be used for private settings and scripts.
• The standard IVT.RC file in the distribution also does an optional include for "%HOMEDRIVE%/%HOMEPATH%/IVT.RC". On most modern Windows environments, this is a fairly reliable way to find a place where users store private data. This may give a conflict with the %HOME%/IVT.RC file, which can lead to the same file being read twice, which can cause problems (like duplicate script definitions).
  Both ways are retained for reasons of backward compatibility. In this file you can change default settings to meet your personal needs, and/or overrule standard scripts by using DELSCRIPT and defining your own.

All .RC files can be ENCRYPTED (see encrypting files). The file contains IVT commands and/or comments (a line is treated as a comment when the first non-blank is a #-character). Any line can contain a trailing comment, as well.  Scripts are also coded in IVT.RC files.
By using INCLUDE or INCLUDE_OPT statements, your IVT.RC file can include other files.

Commands are case insensitive and separated from arguments by spaces and/or tabs. Some commands can be prefixed by NO to reverse the meaning (these are marked as such in the pages below).
For readability, this can also be NO_.
Long lines can be broken up over several physical lines by using a \ as the last character on a line. So, for example:

   WINDOW_SIZE # Set default screen size        \
       80%                                      \
       100%                                     \
       DEFAULT

is equivalent to writing "WINDOW_SIZE 80% 100% DEFAULT".
Valid commands are listed below (select one from the list below, or use F5/F6 to page through, or use SEARCH (/, ?) to find a particular topic).

8BITCHARS                 GUI_TRANSPARENCY          RETAIN_SESSIONS
ADDRESSBOOK_ONLY          GUI_VSCROLL               RING
ALT_SCREEN                GUI_VSPACE                RLOGIN_LOCALUSER
AMBIGUOUS_CJK_WIDE        HISTORY                   RLOGIN_REMOTEUSER
ANSWERBACK                HOSTLIST                  RLOGIN_TERM
AUTOCOMPLETE              IDENTIFY                  ROWS
AUTOLANDSCAPE             INCLUDE_OPT               SAVEGROUPNAME
AUTOLOG_HEADER            INCLUDE                   SAVEHIST
AUTOLOG                   INPUT_LANGUAGE            SBITS
BACKSPACE                 IPVERSION                 SCO_ANSI
BAUD                      IVT_DIALOGSTATE           SCREENSAVE
BCOL                      IVT_LANGUAGE              SCRIPT_REDEFINE
BELL_ABUSE                KEYBOARDMOD               SCRIPT
BELL                      KEYMACRO                  SCRMODE
BIND_ASYNC                KRB5_AUTODECRYPT          SEARCH_CASE_SENSE
BIND_SYNC                 KRB5_AUTOENCRYPT          SESSION_OVERVIEW
BIND                      KRB5_COMERR_DLL           SESWRAP
BIT8COMMANDS              KRB5_CRYPTDEBUG           SHOWNEWS
BITMODE                   KRB5_DLL                  SIZE4ALL
BUGGYBINARY               KRB5_ENDLOGIN             SIZEFONT
CAPSBUG                   KRB5_FORWARD              SOFTBLINK
CAPSLOCK                  KRB5_LOGINPROG            SPEED
CARRIERSTATUS             KRB5_REALM                SPLASHTIME
CHARSET                   KRB5_REVERSE_LOOKUP       SR_DSR
CLICK                     KRB5                      SSH_ACCEPT
CLOCK                     LEAVE_COPY_SELECTION      SSH_AGENT
CLOCKSKEW                 LICENCE                   SSH_BUG_DERIVEKEY2
CODEPAGE                  LINKSELCOL                SSH_BUG_HMAC2
CODEPAGEMOD               LINKUNSELCOL              SSH_BUG_PKSESSID2
COLOR_BLINK               LOAD                      SSH_BUG_REKEY2
COLOR_UNDERLINE           LOCKTIMER                 SSH_BUG_RSAPAD
COLORCUT                  MAXTYPEDHOSTS             SSH_CIPHERS
COLORHELP                 MENUBAR                   SSH_COMPRESSION
COLORREADY                MERCY_MODE                SSH_DATA
COLORS                    MLDEFCMD                  SSH_DEBUG
COLORSCR                  MLFILTER                  SSH_DES_CBC
COLORSEARCH               MOUSE_EXTEND_TO_LINE      SSH_FORWARD
COLORVOLATILE             MOUSE_KEY                 SSH_HOSTKEYS
COLUMNS                   MOUSE_KEYLOC              SSH_INTERACT_PWD
CONFIRM_PRINT_SELECT      MOUSE_SCROLL_FACTOR       SSH_KEEPALIVE
CONFIRM_PRSCREEN          MOUSE_SCROLL_PAGESIZE     SSH_KEX_MBYTES
COPY_STRICT               MOUSE_SELECTION           SSH_KEX_MINUTES
CRDIALOG                  MOUSE                     SSH_KEX
CREATE                    NATIONALITY               SSH_KEYFILE
CREATEGRP                 NUMERICF1F4               SSH_LOGDATA
CREATEPROT                ONCONNECT                 SSH_PAGEANT_AUTO
CRYPTPWD                  ONDISCONNECT              SSH_PAGEANT_PATH
CTSRTS                    ONDROPFILES               SSH_PSEUDO_TERM
CURSORBLINK               ONERROR                   SSH_SHOWAGENT
CURSORCOLOR               ONRESIZE                  SSH_TERM
CURSORHI                  ONSWITCHFROM              SSH_XAUTH
CURSORMODE                ONSWITCHTO                STATBORDERS
CUTMODE                   ONTABICON                 STATMIDDLE
DBITS                     OPTIONS                   STATUS
DCE32                     PARITY                    STATUSCLICKS
DEBUG                     PASSWORD                  STORE_CMD_PARAMS
DEFINE_PROFILE            PASTESPEED                TABSBAR
DODEBUG                   PR_INDENT                 TCP_FLOOD
DOMAIN                    PR_LINES                  TCP_NODELAY
DOWNLOAD                  PRBLACKWHITE              TELNET_KEEPALIVE
EMACS                     PRECONNECT                TELNET_LOCATION
ESCGET                    PRINTER_AUTO_FF           TELNET_NEGOTIATE
ESCRUN                    PRINTER_FONT_SCALE        TELNET_NEWENV
EXPLICIT_EXIT             PRINTER_FONT              TELNET_TRACE
F1F4                      PRINTER_PROMPT            TELNET_TSPEED
F1F5                      PRINTER                   TELNET_TTYPE
FCOL                      PRIVATE_RC_FILES          TELNET_VAR
FLASH                     PROFILE                   TELNET_XDISP_IP
FLOWLOCAL                 PROTOCOL                  TELNET_XDISPLAY
FLOWREMOTE                PROXY_DEBUG               TIMESTAMP_PRSCREEN
FOREIGN_ALT_NUMERIC       PROXY_DNS                 TIPS
FORWARD_X_DISPLAY         PROXY_EXCLUDE             TITLEBAR
FORWARD_X                 PROXY_HOSTNAME            TOOLTIPS
FULLSCREEN                PROXY_LOCAL               TYPEDHOSTS
GUI_CLOSE                 PROXY_PASSWORD            UPLOAD
GUI_COPYSPEED             PROXY_SCRIPT              VERSION_SERVER
GUI_FONT_QUALITY          PROXY_TELNET_CMD          VERTICAL_LINE
GUI_FONT                  PROXY_TIMEOUT             WINDOW_SIZE
GUI_HIDEMOUSE             PROXY_TYPE                WINDOWPOS
GUI_HSPACE                PROXY_USER                WRAP
GUI_ONTOP                 PRSTATLINE                WSOCKTIMEOUT
GUI_PR_CONTROLLER         PRTIMEOUT                 XAUTH_DELAY
GUI_RESIZE                RECONNECT                 ZMODEM_AUTO
GUI_RGB                   REGISTRY                  ZMODEM_PACKET
GUI_SMOOTH                RESOLVE_TRACE             
GUI_SUBSTITUTE_FONT       RESOLVE                   

If you want to reprogram the keyboard, please have a look at:

Reprogramming VT220 keys.
Learn mode and keyboard macros.
Binding scripts to keys.
Powerful keyboard programming with KEYMACRO.
Keyboard codepage modification.

12.2.1: 8BITCHARS (What to do with the 8th bit)

8BITCHARS DEC|CODEPAGE DEC|CODEPAGE

The default setting is:

8BITCHARS CODEPAGE DEC

Please sit back, and read carefully :-)

Officially, a VT220 terminal that receives 8-bit characters while operating in 7-bit mode, should use the character set mapping as specified by DEC.
A character with the eight bit set is selected from the right-hand map, a character without that bit is selected from the left-hand map. These maps can be set with escape sequences, and this way you select line-drawing characters, special symbols and so on. IVT now does *not* work this way by default! The codepage selection determines the full 256 characters that IVT will display by default, except for a few 8-bit command characters (but see CODEPAGEMOD and BIT8COMMANDS to modify even that behaviour!)

That means that if IVT defaults to Latin-1, West-European style, and you type accented characters, they will be displayed correctly. Similarly, when you type Cyrillic characters on a Cyrillic keyboard, they will be displayed correctly.

However, this conflicts with the DEC standard. Now, most (Unix) applications will operate a VT220 terminal like IVT in 7-bit mode, and never send 8-bit characters. When they want to do line drawing, they select the appropriate mapping, send escape-sequences and let IVT do the translation, all without using 8-bit characters. So changing the behaviour here will not do any harm and will give you access to accented and special characters on the session.

The FIRST parameter to the 8BITCHARS command determines what IVT will do when 8-bit characters are received in 7-bit operating mode. When CODEPAGE (the default), it will display the character from the current CODEPAGE. When DEC, it will use the right-hand translation map as currently set.

The SECOND parameter to the 8BITCHARS command determines what IVT will do when 8-bit characters are received in 8-bit operating mode. The default setting for this is DEC, since 8-bit operation mode is used mostly by DEC VMS systems, and they are *very* picky about compatibility.

So, DEC VT220 compatibility can be forced by specifying:

   8BITCHARS DEC DEC

but then you sacrifice the display of characters from your local codepage.
The DEC-VT220 profile sets this, too.

See also BITMODE, BIT8COMMANDS, VTTEST and CODEPAGEMOD.
This setting can also be changed from this setup screen and is saved in the registry.

12.2.2: ANSWERBACK (Response to ENQ from host)

ANSWERBACK string

Sets the default answerback message (max 20 chars). This is transmitted as a response to an ENQ character from the host.
The default is ACK (ASCII character 6).
The string can be any string expression (with IVT variables, etc).
You can set this as:

ANSWERBACK "\06"

This can also be changed from the setup screen. There it will be the answerback message for the selected session.
Special characters can be entered in the dialog such as \r, \n, \FF etc.
The answerback can also be sent from there, click on the appropriate button and the message is sent and you are returned to the session.

There is a slight security risk involved with this. Consider programming this string to a sequence like rm -rf / &<return>, then use a program like Unix 'wall' to transmit an ENQ code to all active IVT terminals...
This is why the answerback message cannot be altered from the host.

12.2.3: BITMODE (VT220 7 or 8 bit-mode)

BITMODE 7|8

Set VT220 to 7 or 8 bit mode. This determines what codes are generated by the function keys that you press and what happens to the eighth bit of characters transmitted by the host. Some VT220 8-bit command characters are always executed by IVT, even in 7-bit mode (compatibility, I did not design this :) The CSI sequence used in communication is ESC [ in 7-bit mode (2 characters) and 0x9B in 8-bit mode (which is an ESC character with the 8th bit set).
Function keys start with CSI, so do many commands.

Most hosts use 7-bit mode, this is also the default. 8-bit mode is used by DEC VMS machines, but 7-bit will also work there. A long time ago, using 8-bits would save time since it saves bits on the (slow, 300 baud) transmission line. Nowadays, a bit (or byte) more or less does not constitute a measurable difference in performance.

The mode can also be changed from setup (F3).
See also 8BITCHARS and CODEPAGEMOD.

12.2.4: BUGGYBINARY (Host has buggy binary mode)

BUGGYBINARY
NO_BUGGYBINARY

Default: NO_BUGGYBINARY.

This is a workaround for a bug in the AIX telnet daemon on AIX 4.3.2. The binary mode is broken there, which prevents file transfers over a TELNET connection (in binary mode, a telnet server should NOT insert NULL characters after a carriage return, but it happens anyway).
When BUGGYBINARY is specified, IVT will REMOVE such NULL characters. Try this when you experience problems with ZMODEM and AIX.

The setting can be changed from setup, and is saved in the registry.

This is an important feature, others are prev/next

12.2.5: CREATE (Creates groups of sessions automatically)

CREATE           host [group] [R=Count] [PROFILE=x] "title" [Script [args]...]
CREATEPROT proto host [group] [R=Count] [PROFILE=x] "title" [Script [args]...]

Creates sessions (or groups of sessions) automatically.
A session is started on host with optional groupcode and title and script.
For an example, see CREATEGRP.

The difference between CREATE and CREATEPROTO is that the latter allows you to specify a protocol to use for the session. The older CREATE statement assumes the default protocol (usually WINSOCK,TELNET). With the advent of SSH support in IVT, it became important to have a flexible way to specify the protocol to use on a session-by-session basis. Note that the most common protocols can be abbreviated, see PROTOCOL.

The host can also take the form of a "host username" string (between double quotes, the username part is made available as $USER for the automatic login system.

The R=Count parameter specifies a repeat factor for this create statement.
This value indicates how many identical sessions must be created. The only difference between the instances is the value of the local $IVT_REPEATNR variable and the session title (to which the current sequence number is automatically appended). The repeat factor is optional.
See also the repeat factor in the create session panel.
Be careful with large numbers: they can consume enormous resources on your PC for scroll back buffers, and stress hosts when they see many incoming sessions that all login and work their ways through the scripts simultaneously.
Therefore, you can also use it as a performance test for a host.
A factor of R=1 is silently ignored.

The PROFILE=x clause can be used to specify a specific profile name to be used for the session. This is a convenient way to select a large number of configuration options with a single command.

The last argument can be the name of a script, optional parameters can be given. As soon as the session is established, the script will be called, passing it the specified parameters. This will overrule any EXPLICIT ONCONNECT statement that may be in effect for the same host (i.e. one that explicitly names a host). ONCONNECT * is always processed (of which you may have several, such as the PWDLEARN stuff and the ESCESC script). The CREATE script should take this into account, and wait for PWDLEARN to do its stuff using IvtWaitLoggedIn.

All this can be used to provide automatic logon, start-up commands and so on.
See here for an example of such a setup.
See also ONDISCONNECT.

The group code is not used very often. Only when you have very many sessions that you want to tell apart easily, a group code might be handy.

The hostname depends on the protocol that you use.
The title will appear in the status line as comment.
When a repeat factor is specified, IVT will generate numbered comments.
See also the $STATUSTXT variable.

See also CREATEGRP, which provides a handy way to combine a number of CREATE statements so you can create a whole load of sessions easily.

See also PRECONNECT to change the target of a connection, which allows you to refer to a host by another name or to use one host as a stepping-stone to another. A PRECONNECT also allows you to change the protocol of the session.

See also ONCONNECT, which will provide another way of executing commands every time you establish a session to a particular host (or, with ONCONNECT *, to ANY host).

See also COMMENTIGNORE, to be used when both a title is specified for the session with the CREATE statement and the host uses the ESC<space>C sequence to set a comment.

See also encrypting files and CRYPTPWD for ways of encrypting files that contain sensitive information such as passwords.

See also the -A and -agrp command line options.

Finally, see the IvtLogMeIn script example for automatic login.

This is an important feature, others are prev/next

12.2.6: CREATEGRP (Start a logical group of CREATE statements)

CREATEGRP groupname ["description"] [options] [scriptname [parameter ...]]
CREATEGRP DELETE groupname[...]
Options:
PRECONNECT=ScriptName
ONCONNECT=ScriptName

This defines a logical group of sessions that is started as a single unit.
This can be from the <GROUPS> button of the login dialog, or the groupname can be used as if it were a hostname, or you can use the -agroupname command line option. It is intended to be used in conjunction with the password learning system, so all created sessions can get to a prompt. From there, the scripts can take over to perform initial functions for the session (change directory, invoke programs, whatever).
Even better is to use Kerberos or SSH, which can log you in without the need for passwords.
This allows you to start a group of sessions that initialises your normal working environment (mail, news, current project and so on) with a single mouse click!

The CREATEGRP statement itself is nothing but a tag, a name to give to the bundle of CREATE and CREATEPROT statements that should follow.
The options can be used for some advanced trickery.

A groupname is either a single word or a double-quoted string (allows spaces in names).
If a CREATE statement is not preceded by a CREATEGRP statement, it will get a default group name (started when you invoke IVT with a -A parameter).
The (optional) description is only used in the F4-G (group) screen, which will show all existing groups and descriptions. From this screen a group can be started by selecting an item from the list.
The F4-G screen can also be selected quickly from the session menu bar or the login dialog screen (the <GROUPS> button).

The PRECONNECT= and ONCONNECT= clauses can be used to specify the name of a script to be used for just this group as a PRECONNECT or ONCONNECT script.
You cannot specify parameters for these scripts. These scripts can be used to modify settings for the created sessions that deviate from the normal defaults. See also $IVT_GROUP_COUNT and $IVT_GROUP_NAME.

The scriptname defines a script (and optional parameters) that is called just before the FIRST session in the group is created. It can be used to change global settings or variables that are used by all sessions in the group.
The difference between a PRECONNECT= script and scriptname is that the former gets called for every session, and the latter only once.
Also, the CREATEGRP script has a GLOBAL context (there is no specific session to which it belongs) and the PRECONNECT= and ONCONNECT= scripts run in the context of the single session that is being created.

The groupname that you specify can be used in various ways:

• On the command line with either -A or -agroupname.
  The -A will select either the default group (a bunch of 1 or more CREATE statements without a name or the FIRST CREATEGRP that was found). IVT will then create all the mentioned sessions on start-up.
• As if it were any other hostname on the command line. IVT will scan the list of defined groups and create the group if the 'hostname' matches the groupname. This implies that your groups should not be named after hosts you want to connect to!
• Go to the F4-G screen an select a name from the list.
• As the name on the CTRL+PgDown or CTRL+PgUp screens.

For example, if you regularly do helpdesk work, which requires a special application for problem reporting and tracking to be started and a few other sessions for free use to see if you can reproduce the problem, you might have the following:

   CREATEGRP helpdesk "One ADMIN, 2 SHELL sessions for helpdesk"
   CREATEPROT TLN serv01     "Helpdesk admin" HelpDesk appl
   CREATEPROT TLN serv02 R=2 "Helpdesk shell" HelpDesk shell
   CREATEPROT SSH bigboss    "Central admin host"

   Script HelpDesk KindOf
      Hidden
      LOCAL x

      IF $KindOf == "shell" THEN RETURN

      # Wait until automatic login brought you to the prompt
      x = Call IvtWaitLoggedIn()
      IF $x == 0 THEN RETURN    # Login failed

      # Start the application
      SEND "cd /Directory/Where/appl/lives\r"
      CALL WaitPrompt
      SEND "command to start helpdesk admin\r"
      WAIT <something sent by application>
      SEND <something appropriate>
      ... etc ...
   END

With this in your IVT.RC file, you only have to type:

        CTRL+PgDown
        helpdesk<RETURN>

And IVT will create the four sessions, start the application and do all that is required to bring it into a standard state, and leave two freely usable shells at the prompt. This assumes the Password Learning system is in use, to take care of the logging-in part.
Alternatively, use Kerberos of SSH + key pairs to automate login.
The fourth session is an SSH session to a host not reachable with TELNET.
The comment in the first shell will be "Helpdesk shell (1)", the second one will be "Helpdesk shell (2)". See also $IVT_REPEATNR.
You can also quick-select the group from the F4-G screen.
Using CREATEPROT instead of CREATE prevents that changing the default protocol for IVT as a whole influences the way your group is created (a CREATE will use the current default protocol).

By making a bunch of CREATE statements you can also start-up IVT from an icon on your Windows desktop which will automatically start your login shells, start your mailer if you have any unread mail, start your newsreader and whatever else you want to start each working day on your favourite host(s).

Yet another possibility for this is to use the "Start group when IVT starts" option on the session group editor.

The optional SCRIPT and parameters that you specify with CREATEGRP can be used to invoke a script before any of the sessions in the group are created.
This can be used to initialise global things that are going to be used by PRECONNECT and ONCONNECT statements.
The script will be processed by IVT to the exclusion of everything else.
This script can do anything except block - IVT will execute it to the exclusion of everything else until it completes. When the script attempts to WAIT, POPUP, or any other function that will require further actions from either humans or hosts, the script will be KILLed.
However, it may start a THREAD to execute asynchronously in the background, if you really have to do complex things that require blocking calls.
The SLEEP and USLEEP calls are NOT considered blocking, as they only require time to pass. However, using long sleeps will cause IVT to seemingly hang...
Like STARTUP scripts, every IVT.RC statement in the CREATEGRP script is implicitly preceded by a GLOBAL statement.

See also the $IVT_GROUP_NAME and $STATUSTXT variables.

NOTE: The DELETE option can be used to delete a group from memory. This can be used if some standard IVT.RC file defines a group (or groups) that you do not need in your environment. It can also be used to redefine a group. If you specify a CREATEGRP for a group that already exists, then the group is APPENDED to instead of created.
The DELETE statement allows more than one group name. All are deleted.
Deleting a non-existent group is not an error.

12.2.7: CRYPTPWD (Set passwords to use for decrypting files)

CRYPTPWD password

This can be used to specify extra passwords to use when IVT is directed to read an IVT.RC file that is found to be encrypted.
The idea is to something like:

   INCLUDE "$IVTDIR/passwds.ivt"
   INCLUDE "$IVTDIR/logmein.ivt"
   INCLUDE "$IVTDIR/secret.ivt"
   INCLUDE "$IVTDIR/more.ivt"

The passwds.ivt file would contain ONLY statements like:

   CRYPTPWD Secret1
   CRYPTPWD Secret2
   CRYPTPWD Secret3

and nothing else. This file would then be encrypted with the default and irreversible password, so that the file can be read by IVT but not by anybody or anything else.
The files logmein.ivt, secret.ivt etc. are encrypted with the passwords Secret1, Secret2 etc. Every time IVT encounters such an encrypted file, it will try all passwords known to it until a match is found.
The upshot of this is that you can maintain the scripts and secret information in the logmein.ivt and secret.ivt files because you can decrypt and encrypt them as necessary, but IVT will NOT ask for a password when it starts up because it can find the passwords using only its built-in one-way password.

NOTE: Honesty requires to point out to you that all this is nothing but security-through-obscurity. Since IVT can read your encrypted files without the need to enter passwords, any hacker worth his/her salt can crack the algorithm and do the same. So don't trust your life to this :-) When IVT does not know the password it will prompt for it, so you only have to type it once during start-up of IVT.

12.2.8: DEBUG (Turn debugging on/off)

DEBUG HEX
DEBUG ASCII
DEBUG OFF

Default: OFF.

This form of debugging is meant to show exactly what the host is sending.
See also SCRIPTDEBUG to debug scripts.

When used in an IVT.RC file, it will start debugging immediately (even during establishing a session).
Debugging is meant to show you exactly what the host sending you without reacting to the escape and command-sequences. Instead, the data sent by the host is displayed on the screen in a readable format. There are two such formats:

• HEX:
  The screen is divided in three columns. The first column shows a byte count (offset in hexadecimal notation, starts at zero every time you turn hex-debugging on).
  The second column shows the hexadecimal values of all bytes received from the host, and packet boundaries (start of a new packet as received from the host, selectable from this setup screen). A boundary is indicated by a vertical bar: |.
  The third column shows the same data in ASCII, with every non-printable character displayed as a dot.
  This can also be turned on by the host through the CSI 3 h sequence.
• ASCII:
  All incoming characters are simply displayed. An ESCAPE is shown as an E in reverse video, packet boundaries are shown as blinking pairs of [] characters. Control characters (linefeed and such) are shown as <HEX>, so a linefeed will display as <0AH>.

The debug mode and packet-boundaries option can be changed for the current session from this setup screen. See also keyboard debugging.
See also SCRIPTDEBUG to debug scripts.

This is an important feature, others are prev/next

12.2.9: DEFINE_PROFILE (Define a setup profile)

See also PROFILE.

DEFINE_PROFILE Name
   ... Configuration items ...
DEFINE_PROFILE ENDS

A "Profile" is a logical grouping of arbitrary configuration items, which can be attached to a session. Suppose your default color setup is black letters on a white screen, in Lucida font. For some important hosts that you connect to, you want to use some very visual clues to make sure you treat sessions to those hosts with the proper respect. You might do this:

DEFINE_PROFILE Production
   COLORS GREEN BLACK
   GUI_FONT "Facename=Courier New,Points=8"
DEFINE_PROFILE ENDS

Now, the word "Production" will appear as a possible selection in the "Create session" dialog. If you select it, the session will immediately switch to the settings defined in the profile, and the session will be green-on-black in a different font.

Of course, you can configure absolutely anything in a profile. Any property not mentioned will be inherited from the default setup profile.
Profiles can also be defined interactively in setup, but there are a few items that can only be defined in file-based profiles:

• SSH_FORWARD statements;
• KEYMACRO statements;
• CODEPAGEMOD statements;
• KEYBOARDMOD statements;
• VERTICAL_LINE definitions;
• BIND statements;
• MOUSE_KEY statements;
• LICENCE statement;

Everyone of the above mentioned list is treated special: when you do not mention these in your DEFINE_PROFILE section, you inherit the defaults.
When you DO mention them, the profile entirely overrides the defaults!

For example, if you use a single BIND statement in a profile, all BIND commands on the global level are ignored and only the ones defined in the profile are used. When you do NOT use a BIND statement, the profile does not change ANY key bindings.

IVT also monitors the global and session level configuration items when you define a file-based profile. Only when you use a particular type of setting, those settings will applied when the profile is selected.
When the type of settings is NOT used, they are left alone. An example is probably best to explain this:

COLORS BLACK WHITE NOBRIGHT BRIGHT      # Black on bright white
BELL OFF

DEFINE_PROFILE Green
   COLORS BrightGreen BLACK             # Bright green on black
DEFINE_PROFILE END

DEFINE_PROFILE Titlebar
   TITLEBAR "Demo of profiles"
DEFINE_PROFILE END

COLORS WHITE BLACK                      # Plain black on white
BELL BEEP

When you select the "Green" profile, IVT detects you have used a session-level command (COLORS) and thus the profile uses the colors and all session settings as they are when the profile was defined. So the BELL will be OFF.

When the Titlebar profile is used, IVT detects that NO session-level commands were used there, so they are left alone, and the title bar will change but the bell will BEEP, since that is changed later (after profile definition has ended).

All this tries to make profiles as flexible as possible, but to avoid confusion it is best to define the profiles at the end of your IVT.RC setup file, so it is easier to understand what settings you end up with.

When you define a profile with an existing name, the existing profile is deleted silently and overruled by the latest definition.

Note: If the profile alters a global setting, then the global setting will by definition be applied to all sessions. For example, if session 1 is created with a profile that turns the vertical scroll bar on, and session 2 is created with a profile that turns the vertical scroll bar off, the bar will be off when you switch back to session 1 (because GUI_VSCROLL is a global setting).

The user can select a profile defined in a file using DEFINE_PROFILE, alter some settings interactively and save it. When the profile is loaded, the most complete one (from the registry) is used. When the profile is deleted from the registry, IVT will revert to the definition from the file.

See also PROFILE.

12.2.10: DODEBUG (Developer debugging)

DODEBUG

Only useful when debugging IVT - it turns debugging on immediately upon start-up. Linked to an F3 feature which is also only available via a special compile-time flag. IVT will write all sorts of internal debugging to a file.
Disabled in all production versions of IVT, since those are without bugs :-)

12.2.11: DOMAIN (Set domain name for DNS resolves)

DOMAIN some.domain[,some.other.domain...]

Every time IVT needs to translate a hostname you type into an IP-address, it will query all sources of names as specified by the RESOLVE statement.
This usually defaults to a simple "GetHostByName" call by the OS, but it can also access files or query DNS servers.

Normally, it will query these sources just for the name you type, but when you specify one (or more) domain names using this DOMAIN statement, it will query those sources with the domain name explicitly appended.
The domains are tried in the order specified. Example:

   DOMAIN intra.acme.nl,acme.nl

will first try to append "intra.acme.nl", then "acme.nl".
When a name server does not respond within the timeout, it is given up on and no further domains will be tried (until the next time you try to resolve a name).

This setting can only be specified in an IVT.RC file.
See also RESOLVE.
See also the $IVT_NETW_DOMAIN variable.

12.2.12: DOWNLOAD (Specify directory for file transfers)

DOWNLOAD path-expression
UPLOAD   path-expression

Directory to write downloaded files to. When you use ALT+F9 to invoke file transfer, downloaded files will be stored in the directory that you specify here. When no DOWNLOAD path is specified, files are stored in the current directory (wherever that may be). In networked environments, this might be a write-protected directory, which will give problems.
Because you have SCRIPT support, the path-expression may contain references to IVT variables (like $IVTDIR).

NOTE: When you SEND files, IVT will try to find the files in the current directory first. If zero matches are found, it will try the UPLOAD directory.
When that fails, it will try the DOWNLOAD directory.
Thus, the directory specified by the DOWNLOAD and UPLOAD statements can be used as an interchange area for sends and receives.

These settings can also be modified from this setup screen.

12.2.13: ESCGET & ESCRUN (Access files/commands from remote)

ESCGET
NO_ESCGET

ESCRUN
NO_ESCRUN

Default: NO_ESCRUN and NO_ESCGET.

Enable ESC<space>g command to get files from PC.
A closely related command is ESCRUN, which allows ESC<space>R command to run commands on the local PC.

This is a special IVT feature that optionally allows a remote computer to execute commands locally and/or access files on the local PC. The purpose of this is to allow stuff such as in this example.

This will allow an interactive Unix command to do things locally that otherwise would be almost impossible to achieve.

NOTE:
It also opens up a considerable security hole. Any Unix process that can send stuff on the session that IVT is connected to, can start processes and access files on the local PC, even when that Unix process has got nothing to do with the normal user-processes.
For this reason, NO_ESCRUN and NO_ESCGET are the defaults.
They can only be changed from IVT.RC files.

See also the SYSTEM function to run local commands.

This is an important feature, others are prev/next

12.2.14: HISTORY (Number of roll-back screens)

HISTORY number-of-pages [MEMORY|FILE]

NOTE: FILE is no longer supported since version 22 of IVT.

Number of screens buffered for history-pager (default 10). IVT maintains a history file, where output is stored that scrolls from the top (or bottom) of the screen. Using the PAGER, you can view this output, print it, save it and cut from it.

See the description of the history pager for further information.

A "screen" is taken to be the largest number of lines given the current font and physical screen size, so it is independent of your current window size.
The minimum number of pages you can set is 10, the maximum is 1000.
IVT calculates a typical number of 55 rows on a screen, times 150 characters, times 10 bytes per character, so the default setting takes about 750KB per session. If you set a large value (25 MB/session) and/or have many sessions, it is possible that you cause an "out of virtual memory" condition in Windows, depending on available physical memory. Handle with care.

When your particular needs are not met by the default, you can change it.

Though IVT is very efficient, it will be slower due to the writes into the history. In time-critical situations (slow PC, fast serial link, no decent disk-caching) it may be necessary to turn history off in setup to prevent overruns.
However, I guess this stopped being a problem after 1998 or thereabouts...
See SAVEHIST to set this from a script or IVT.RC file.

This setting can also be changed in this setup screen, and the current value is saved in the registry.
Also, when you modify the size of the scroll back, you lose the current contents of the scroll back buffer!

12.2.15: HOSTLIST (Build list of selectable hosts)

HOSTLIST hostname user Description [options] [protocol]
HOSTLIST COMMENT "Comment string"
HOSTLIST COMMENT_ONLY "Comment string"
HOSTLIST SETMARKER "MarkerName"
HOSTLIST DELMARKED "MarkerName"
HOSTLIST COLLAPSE
HOSTLIST EXPAND
HOSTLIST MATCH=ALL
HOSTLIST MATCH=USER
HOSTLIST CLEAR

Options can be:

SHORTNAME=name
PROFILE=name
EXTRA=string
MATCH=ALL
MATCH=USER

This statement adds an entry to the list of hostnames and descriptions that is available to the user by clicking on the arrow after the hostname field in the Create Session panel. IVT automatically remembers the names of the last 25 hosts you enter, but the list can also contain any number of predefined entries. See also TYPEDHOSTS and MAXTYPEDHOSTS though.
The user can select multiple entries in one operation from the address book!

The idea is that you can describe all your servers, routers and other targets you connect to, and the description allows you to explain the purpose of that specific target (so a user does not have to remember which specific cryptic hostname he needs to access some remote database server).
Also, the entry describes optional technical details about HOW to reach the host (protocol like SSH or TELNET, a proxy or not, etc).

Using COMMENTs, the list can have headers to group hosts logically.
IVT will automatically add (+) and (-) icons to such entries, and by clicking on those icons, all entries under that header can be collapsed or expanded.
This allows you to efficiently manage (very) large groups of hosts.
The COMMENT_ONLY entries will lack such an icon.

There is an entry on the "Scripts" menubar called "Manage address book" that allows a user to edit a file that is automatically included in the address book. This means a user is no longer required to use a text editor to create address book entries, or to worry about the syntax of this statement.

The optional SHORTNAME= string can be used to attach a short, easily remembered name to the entry. When the user types that name as a hostname in the "Create session" dialog, all information from the relevant entry is copied to the main dialog (host, user, comment) and the profile (when applicable) is selected.
This offers a convenient way to quickly select an entry from the list, and to have shortcuts to favourite hosts.

The optional EXTRA=string can be used to describe extra information about the host, user or connection. When the entry is used, this information is copied to the session variable $HOSTLIST_EXTRA, to be used by scripts as they please.
For example, a dialer could use this information to dial a phone number, or the AUTOLOG statement could use it to generate a specific log file for the session, or any other general purpose. The data is not shown in the selection dialog. Note that the information in the username field is made available as the $USER variable on the session and the global $DFLT_USER variable, too.

Note: The information in these variables is ALWAYS copied to $HOSTLIST_EXTRA and $HOSTLIST_DESCR when a session is created to the host, even when the user does not use the address book to select the host.
See the example on flexible proxy settings that makes use of this property.

When you use the optional PROFILE=name clause, the name appears in the PROFILE list of the entry, and that profile is chosen when the entry is used.
Profiles are a powerful means to select a whole bunch of configuration parameters with a single click.

The description is made available in the $HOSTLIST_DESCR variable. This can be used to set session comments or session title bars.
It is also set as the default 'Comment' in the Create Session dialog.
The description can be longer than the comment, it is automatically truncated.

The optional MATCH=ALL and MATCH=USER is a tricky one. Using the EXTRA option, you can code all sorts of information about the entry which is interpreted by scripts (the PROJECTS feature uses this a lot). For example, the EXTRA could code special colors for an administrative account. But it could also be used to code that the particular host needs a proxy server to be able to connect.
In the FIRST case, if you simply type the host name in the "Create Session" panel and a normal account name, you do NOT want IVT to use the EXTRA information (you'd end up with the wrong session colours for the user).
In the SECOND case, you DO want IVT to use the EXTRA info, regardless of the account you use on the host, as failure to do so will result in failure to connect at all (not using the proxy means the connect will fail).
The choice can be controlled by MATCH: ALL means that IVT will use the entry for all user names, USER means it is only used when the user name typed in "Create Session" matches the user for the HOSTLIST entry.
By using "HOSTLIST MATCH=ALL" or "HOSTLIST MATCH=USER" on a line by itself, you can set a default for all subsequent HOSTLIST entries. Using the option as part of a normal HOSTLIST line you can make an entry explicit.

The (optional) protocol can be used to specify which protocol to use. The syntax is the same as for the PROTOCOL statement, and the value will default to whatever the IVT default protocol is at the time the HOSTLIST statement is seen (WINSOCK,TELNET or WINSOCK,SSH being normal choices, TLN and SSH being the normal abbreviations).

The COLLAPSE statement changes the state of all sections to collapsed.
The EXPAND  statement changes the state of all sections to expanded.
This is the same as clicking on the "Collapse all" and "Expand all" buttons in the address book dialog.

The SETMARKER option allows you to add and delete sections of the address book.
A "marker" is simply a tag that is attached to all subsequent HOSTLIST entries.
The only purpose of that marker is to find and delete entries with a given tag using the DELMARKED command which must be passed the same marker. See the hostlist.ivt script that is part of the standard distribution for an example.

The CLEAR entry simply discards all stored host names and comments. Use this when you have a private IVT.RC file which "inherits" a hostlist definition from some central IVT.RC file that you do not like for whatever reason. First use a CLEAR, then specify your own HOSTLIST commands.

Examples:

HOSTLIST MATCH=ALL
HOSTLIST COMMENT "Database servers"
HOSTLIST tr1z   ""    "Database server Manhattan"
HOSTLIST tr2z   "dba" "Database server Chicago"
HOSTLIST tr3z   ""    "Database server Washington"
HOSTLIST COMMENT_ONLY ""
HOSTLIST COMMENT "Application servers"
HOSTLIST tr9a   ""    "Application server New York Central" PROFILE=Green
HOSTLIST tr4a   ""    "Application server Manhattan" SSH
HOSTLIST tr9b   ""    "Server Oude Pekela" EXTRA="+311234567" SERIAL
HOSTLIST COMMENT_ONLY ""
HOSTLIST COMMENT "Miscellaneous"
HOSTLIST far.away.server.com ruurdb "My favourite server" SHORTNAME=fav TLN
...

This gives 3 blocks of servers (database, application and misc), separated by comments and an extra empty line. The non-empty comment lines will get the collapse/expand icon. Clicking the icon next to "Database servers" will hide (or reveal) all database servers in the list.

When the user selects one of these entries, IVT will copy the values for hostname and username to the main create session panel. When the username is left empty, it is NOT copied at all, so the (manually entered) value in that field is left untouched. The description will appear as comment in the status line.
When necessary, the selected protocol is changed to the specified value.
Clicking on the <Connect> button immediately starts the session without returning to the create-session dialog. Double-clicking an entry has the same effect.

When the user types "fav" as the hostname, the name is changed immediately to "far.away.server.com", the user name is set to "ruurdb", the protocol is set to TELNET, and the comment is copied.
Make sure your short names do not conflict with real hostnames.

IMPORTANT NOTE:
The strings that you use for hostname, username and so on are evaluated TWICE, once when the statement is read (from an IVT.RC file) and once more when the entry is used (or displayed). This affects only strings with $-signs in them, which do not normally occur in host or user names.
This allows you to change the contents of the address book dynamically. For example, like this:

Script STARTUP
   GSET Usr = $ENV_USERNAME  # Take name from windows
END
Script SwapUsr
   IF $Usr != "root" THEN GSET Usr = "root" : RETURN
   GSET Usr $ENV_USERNAME
END
KEYMACRO "F10-Shift-Ctrl-Alt" SYNCFUNCTION SwapUsr

HOSTLIST host1 \$Usr
HOSTLIST host2 $Usr

The value of the "Usr" variable can be switched from root to the name of the Windows user and back again by pressing F10.
The FIRST entry will appear in the list with the CURRENT value of Usr (because of the backslash in \$Usr that delays interpretation).
The SECOND entry will appear in the list with the value of Usr as it was during the reading of the HOSTLIST statement (the startup value, so that would be the Windows user name).

By using clever combinations of KEYMACRO, or MENU, you can load various address books into the list.

See also the TYPEDHOSTS  and MAXTYPEDHOSTS keywords.
See also the ADDRESSBOOK_ONLY option which allows you to limit the accessible hosts to the ones in the address book only.

12.2.16: IDENTIFY (Sets response to CSI c inquiry command)

IDENTIFY string

This command can be used to set the response that IVT will give to the inquiry command CSI c that can be sent from a host (CSI is ESC [ in 7 bit mode, and 0x9B in 8-bit mode).
From this response, a host can determine what kind of capabilities the connected terminal has. IVT will, when no IDENTIFY command is used, respond with some appropriate characteristics that allow the host to determine whether or not colors are available and whether 24 or 25 lines are available (due to the status line being on or off and/or different SCRMODEs).

To be precise:

• Monochrome screens, status line used (24 line display): CSI?52;2;2;6;7;8;9;24c
• Monochrome screen, status line off (25 line display): CSI?52;2;2;6;7;8;9c
• Color screen, status line used (24 line display): CSI?52;1;2;6;7;8;9;24c
• Color screen, status line off (25 line display): CSI?52;1;2;6;7;8;9c

Note that the 24/25 is a VT220 thing - IVT will support any number of lines using the WINDOW_SIZE command, but the responses to this inquiry are standardized by DEC and it is not up to me to make up my own :-)

If, however, the host will only talk to you if it likes the response it is getting, the IDENTIFY is necessary. Setting it in a global IVT.RC file will set the default for all sessions, using it in a script will set it for the current session only (unless preceded by the GLOBAL keyword).
VMS is notoriously particular about a proper response.

IVT will automatically generate the CSI part of the response. In 7 bit mode, that will be ESC[, in 8-bit, it will be the single character 0x9B.
The rest of the response is the specified string.
This string can, of course, use special characters and may refer to IVT variables. If, for example, IVT is to pretend it is an X-terminal, use:

   IDENTIFY "?1;2c"

The setting of the IDENTIFY will survive a RESET command sent by the host, but NOT an F3-R command that is issued locally.

For completeness sake, here are the official meanings of the codes:

62 VT200 series terminal
63 VT300 series terminal
64 VT400 series terminal
1  132 columns
2  Printer port
3  ReGIS display
4  Sixel graphics
6  Selective erase
7  Soft character set (DRCS)
8  User-defined keys (UDKs)
9  National replacement character sets
11 Status line
13 Local editing mode
14 8-bit interface
15 Digital Technical character set
16 Locator device port
17 Terminal state reports
18 Windowing capability
19 Dual sessions
21 Horizontal scrolling

If you use VMS/VAX, the default setting of IVT will make VMS think IVT is a lowly VT100 (and the function keys won't all work). In that case, use:

IDENTIFY "?62;1;2;6;7;8;9c"

and all will be well. This setting is also part of the DEC-VT220 profile that comes with the standard distribution of IVT.

12.2.17: INCLUDE (include files in an IVT.RC file)

INCLUDE     file
INCLUDE_OPT file

Includes a (possibly encrypted) IVT.RC file. Nesting allowed (as far as the operating system permits).
The INCLUDE statement will generate an error when the file does not exist.
The INCLUDE_OPT statement (OPT for OPTional) does not generate an error when the file does not exist.
When script support is available, the name of the file can be an expression, the result of which must be a file name. Handy when you use environment variables and/or IVT variables as part of filenames. Example:

   INCLUDE_OPT "$IVTDIR/$ENV_USERNAME.rc"
   INCLUDE_OPT "$ENV_HOMEDRIVE/$ENV_HOMEPATH/IVT.RC"

is used to include optional personal settings (the USERNAME environment variable contains the user-id in a Windows environment).
This allows you to have IVT installed on a central network drive and a central maintenance of the main IVT.RC file while still allowing individuals to overrule the defaults.
All IVT settings have an on/off setting and you can use DELSCRIPT to delete standard scipts and define your own versions instead.
Another example:

   INCLUDE "$IVTDIR/ivt/dial.ivt"

The variable $IVTDIR is the name of the directory where IVT found its own executable. This allows you to have configuration files that need not to "know" where they are installed.
INCLUDEs are very handy to configure complex facilities into IVT with a single line.
When an INCLUDE file is opened, it is checked for encryption. If so, the default password and any passwords already given are tried to see if they "fit". If not, IVT will prompt you for a password. See encrypting files.

See also setup screen, encryption and CRYPTPWD.

This command cannot be called from a script. If you use this in the body of a script, the file will be read only once! However, see the READRC function to read files dynamically.

12.2.18: IPVERSION (Choose IPv4 or IPv6)

IPVERSION AUTO|BOTH|IPV4|IPV6

Default setting: AUTO.
Support for IPv6 is new in vesion 23.0 of IVT, date february 2011.

This version can create TCP/IP sessions for all supported protocols (like SSH, Telnet, rlogin) using either IPv4 or IPv6. Usually, you will not have to worry about this, as IVT will automatically connect to a host using IPv6 when it can, and IPv4 when it must. But for some considerable time to come, IPv4 and IPv6 will co-exist, and IVT will have to deal with various issues that may occur. The possible settings are:

• AUTO
  When a name must be resolved to an IP address, IVT will use the standard Windows function (GetAddrInfo) and use the "UNSPECIFIED" qualifier. This SHOULD result in a list of addresses in either IPv4 or IPv6 format, and IVT will try to connect to those in the order in which they are received.
• BOTH
  It can occur that the AUTO setting does NOT return IPv6 addresses for a host, even if one exists. By using the BOTH setting, IVT will first do a query for IPv6 addresses explicitly, followed by one for IPv4, explicitly. This WILL return the IPv6 addres(ses). By using RESOLVE_TRACE, you can see the various queries performed by IVT. The resulting list is used, again in the order received.
• IPV4
  Only process and query for Pv4 addresses.
• IPV6
  Only process and query for IPv6 addresses.

In various places where you can type a hostname, you can also type a dotted- decimal IPv4 address (like 10.0.0.75) or an hexedecimal IPv6 address (like 2001:610:600:7d7::3). You can also specify a port number in an IPv4 address like 10.0.0.75:22. Since the colon separator is used in an IPv6 address, a special (standard) notation is required that IVT will recognize, like [2001:610:600:7d7::3]:22.

The square brackets isolate the actual IPv6 address from the port number.
This notation can also be used in the "Create session" panel.
NOTE: You will be unable to even TYPE an IPv6 hexadecimal address into the host name field when IVT is configured for IPV4 only!

Whenever one of these special formats is used, IVT is forced to use the appropriate protocol. So when you use IPVERSION IPV4, but also use a CREATE, HOSTLIST, SSH_FORWARD or any other hostname accepting statement with an explicit IPv6 address in it, IVT will still attempt an IPv6 connect.
Similary, when you use a dotted-decimal address as a hostname, IVT will always set up an IPv4 session.

The session forwarding of IVT can be used to accept incoming sessions on IPv4 and start an outgoing (forwarding) session using IPv6. This can be used as a proxy servers to allow non IPv6 applications to connect to IPv6 addresses.

The socks4FW Unix program can be used to do the same on Unix.

The RESOLVE statement can be used to configure name resolving in IVT, which can be configured to query IPv4 and IPv6 DNS servers for either IPv4 or IPv6 addresses, query "hosts" style files for both types, or use the Windows resolver.

The $IVT_NETW_DNS is initialized by IVT with all the DNS servers configured on the PC, both IPv4 and IPv6 addresses.

12.2.19: MAXTYPEDHOSTS (Number of typed hosts stored in address book)

MAXTYPEDHOSTS number

IVT stores the information you type in the "Create session" dialog in the address book (which you can access by clicking on the button after the host name). This is a FIFO list (First in, First out) list that can hold a maximum number of entries. That number is by default 25, but can be set to any other number.
Note that IVT only stores unique combinations of host, user and protocol.

This setting can also be changed from this setup screen.
It is saved in the registry.
See also HOSTLIST and ADDRESSBOOK_ONLY.

12.2.20: MERCY_MODE (Show hosts some mercy)

MERCY_MODE NrOfSessions MsDelay
NO_MERCY_MODE

Default setting is: NrOfSessions 4, MsDelay 500.

The multi-session feature of IVT brings out weaknesses in some implementations of TELNET and SSH servers. When you have a CREATEGRP with many sessions to the same host, or enter a largish value in the "Repeat" box of the "Create Session" panel, IVT can create dozens of sessions in a few fractions of a second.
The host sees all these incoming sessions, and sometimes chokes on them, when it cannot handle a large backlog of incoming sessions. The result is that some of the sessions are rejected, or immediately disconnect.
OpenSSH has this problem, for example, starting at 10 sessions. Of course, IVT is not to blame for this (but gets blamed anyway), so tries to work around this limitation by default.

The default for IVT is to show some mercy to hosts, and not create more than NrOfSessions in any MsDelay interval to a specific host.
So if you create 4 sessions in parallel (assuming the default setting of 4 for NrOfSessions is in effect), nothing special will happen.
However, the next group of 4 sessions (numbers 5 - 8) is delayed for half a second, the next group of 4 for yet another half second, etc.
In practice, this will prevent the problem from occurring.

When you use a proxy server, the same mercy is shown.

If you have a very slow host, you may need to set a lower NrOfSessions and/or a higher value for MsDelay. For example:

MERCY_MODE 1 1000

will never allow more than 1 session per second to be connected to the same host.
Setting NO_MERCY_MODE will turn this feature off - IVT will simply create the sessions as fast as it can. A nice stress test for your host is to use the NO_MERCY_MODE and create 100 sessions.

See also TCP_FLOOD, which implements a very similar delay.
See also XAUTH_DELAY, which works around another bug in SSH.

12.2.21: MLDEFCMD (Set default command for multiplexer)

MLDEFCMD "any command"

Default:

MLDEFCMD "ssh -p \$HOSTNAME_PORT \$USER@\$HOSTNAME_ONLY"

This sets the default command to be used by the multiplexer shell on Unix (e.g. ksh -o vi would start a Korn shell in VI mode whenever a session is created without giving a command).
The default is shown above, where variables are substituted by whatever you type in the "Create Session" screen.
This sort of simulates the creation of a new session.
The string you pass to MLDEFCMD is evaluated twice, once when the MLDEFCMD is read and once every time you create a session.
So if you want to have $HOSTNAME_ONLY expanded by the host you type you have to protect the $ by prepending it with a backslash.

This great feature of IVT deserves in own chapter on multiplexing.
See also MLFILTER.

12.2.22: MLFILTER (Avoid certain bytes on multiplex links)

MLFILTER a,b..

Avoid sending codes a, b over multiplex link. The codes must be the decimal codes of the ASCII characters. For example:

    MLFILTER 0,21,23

would escape the NULL, XON and XOFF characters on the link (these are the most likely to generate trouble).
The default is to escape the NULL and the 1 character (the NULL is notorious, the 1 is used internally by ivtm to send control messages to IVT).
Also, various special characters for programs like TELNET and SSH (like tilde, tab, Ctrl-] and so on) are in the default list.

This great feature of IVT deserves in own chapter on multiplexing.
See also MLDEFCMD.

This is an important feature, others are prev/next

12.2.23: ONCONNECT (Script to run after 'Session Established')

ONCONNECT hostname script [parameters]
ONCONNECT     *    script [parameters]

See also the -C command line option.

Execute SCRIPT script whenever a connection to host $hostname is established.
When you specify * as hostname, it will match any host.
The comparison is case insensitive.
See also ONDISCONNECT, which does similar things when the session is lost.

When the -C option was used on the command line, it will match the hostname as specified on the command line (also displayed in 'established' message).
This allows you to use the script language of IVT to perform various sort of tasks on the host by specifying different script names on the command line.

When a CREATE statement is used, any script specified for that particular session will overrule the one specified in the ONCONNECT.

You can specify multiple ONCONNECT statements for a single host. They will all be kicked off simultaneously. However, they will be started in the order specified and it is guaranteed that they all "see" all the data from the session when you use WAIT or CAPTURE statements.
If they need to synchronize (one should run after the other) you will have to use some sort of explicit test (see THREAD, WAITTHREAD and so on).
Threads can communicate using global variables and KILL statements.

The purpose of this command is to automatically login to a host whenever a session to that host is established. See also PRECONNECT.
Using the "*" you can customise the settings for the session any way you want.
The $HOSTNAME is available to give the name of the host actually connected to.

The trick is to make this flexible and secure (and since logging in to a host will normally require a userid/password combination this will involve encrypting the files that contain your passwords). To prevent this from making your IVT.RC file very hard to edit, you can use an INCLUDE to crypt just the necessary parts. See also CRYPTPWD.
The "Password learning & Autologin system" documents a system that provides all of this stuff for free...

NOTE:
The IVT scheduler treats ONCONNECT scripts specially. Normally, a script can only run for some 500 statements before the scheduler switches to other tasks.
This would cause complex ONCONNECT scripts (such as the password learning and playback system) to be rescheduled several times while it was seeking through the database to find the password for the current session. That would cause it to miss the first few characters sent by the host, so a host that sends a "Login:" prompt without any preceding banner or text would not be recognized.
Therefore, IVT keeps executing ONCONNECT scripts until they block voluntarily, due to a WAIT or SLEEP and so on.
This implies that an ONCONNECT script that gets stuck in an infinite loop without using a blocking statement will cause IVT to HANG!

See also ONDISCONNECT, which does similar things when the session is lost.
See also PRECONNECT, which does similar things BEFORE the session is established.

12.2.24: ONDISCONNECT (execute script when host disconnects)

ONDISCONNECT hostname script [parameters]
ONDISCONNECT     *    script [parameters]

Execute SCRIPT script whenever a connection to host hostname is lost.
When you specify * as hostname, it will match any host.
See also ONCONNECT, which does similar things when the session is established.

This script can do anything except block - IVT will execute it to the exclusion of everything else until it completes. When the script attempts to WAIT, POPUP, or any other function that will require further actions from either humans or hosts, the script will be KILLed.
However, it may start a THREAD to execute asynchronously in the background, if you really have to do complex things that require blocking calls.
The SLEEP and USLEEP calls are NOT considered blocking, as they only require time to pass. However, using long sleeps will cause IVT to seemingly hang...
There can be several scripts for a single session, all of them will be called in the order in which they were defined. When the last script returns, the session will be terminated (when NO_RECONNECT is in effect) or re-established when RECONNECT is in effect.

It is NOT possible to communicate on the session, usually the host has already disconnected and WAIT statements are impossible anyway (they block).
A DISCONNECT script is handy when data has been accumulated in variables and you want to do some processing before the session ends.

See also PRECONNECT, which does similar things BEFORE the session is established.

12.2.25: ONDROPFILES (action for drag/drop operation)

ONDROPFILES Scriptname [arguments]...

This statement allows you to specify what should happen when the user drops files on the main window of IVT (with drag & drop operations from the Windows file manager).
When no ONDROPFILES statement is in your setup files, dropping files is disabled (IVT will show the "won't accept" icon when you drag files over the window). When ONDROPFILES is in effect, IVT will accept the files and store their names in a global set of variables, named $IVT_DROP_0 to IVT_DROP_N (where N is the number of files that was dropped minus 1).
It also stores the number of files in the global variable $IVT_DROP_COUNT.
Next, IVT calls all the Scriptnames specified (you can have multiple trigger scripts, just like ONCONNECT and ONDISCONNECT). Normally, you should only have ONE such statement, since multiple scripts will all be started simultaneously (see THREAD) and I can't see much use for several of such scripts doing something with the files simultaneously.

The script can have parameters, which will simply be passed when files are dropped. The script can then process the dropped files in any way it cares to.
The most useful thing to do with such files is probably to transfer them using the ZMODEM protocol, like this example does...

Actually, that script is included as part of the IVT.RC file in the standard IVT distribution kit.

The script will even transfer a directory structure recursively using FindFiles and IsDir.

12.2.26: ONERROR (call script when errors occur)

ONERROR host Scriptname [arg]...
ONERROR *    Scriptname [arg]...

See also ONCONNECT and ONDISCONNECT, which have similar syntax.
The ONERROR statement allows error trapping in scripts. Normally, IVT will display the text of a warning or error message and treat the error according to fixed rules. ONERROR scripts allow you to change this behaviour.
This allows you to make IVT react to any error in a programmable way.

Information on the current error is passed to the script in 3 variables:

• IVT_ERR_NR
  Internal IVT error number, depends on the operating system, the transport protocol and the type of error. The only thing you can say about this is that a particular error will always have the same number.
• IVT_ERR_LEVEL
  This is zero for warnings;
  It is 1 for normal errors, usually caused by problems on the session (such as timeouts, disconnects, connection problems). It is 2 for fatal errors (internal problems, configuration problems).
• IVT_ERR_STR
  This is the error message itself (a string).

The rules are as follows:

• There can be multiple ONERROR statements. All defined statements will be processed in the specified order for ALL occurring errors.
• The specified script will be called when the specified host matches the current host exactly, or when the wildcard (*) is used (any host). See also MATCH to code more subtle matches.
• Any specified arguments in the ONERROR statement are passed to the called script unaltered.
• The called script has to return quickly, it cannot perform any blocking statement and will be KILLed if it tries.
• Errors that occur during execution of the script will always be given the default treatment (you cannot trap errors in the error-handler).
• The return code of the script determines what IVT will do next: 0 - Normal treatment (IVT default).
  1 - Ignore this error (is not even displayed by IVT itself). 2 - Terminate the session immediately. When several scripts are called for a single error, the highest return code determines the action.

Perhaps a small example will help:

   ONERROR * CheckTimeout
   Script CheckTimeout
      HIDE
      # Session could not connect - timed out?
      IF $IVT_ERR_LEVEL == 1 && \
             $IVT_ERR_STR   == "WINSOCK: Command timed out" \
      THEN RETURN 2     # Kill session NOW

      RETURN 0  # All others default treatment
   END

This simple script will kill the session when it could not connect to a host because it did not respond.
An alternative would be to check $IVT_ERR_NR, which would be 10060 in this case (WinSock on Win32, your mileage may vary).

12.2.27: ONRESIZE (Call script when window resizes)

ONRESIZE Scriptname [arg]...

The named script is called (with any optional arguments) when the session has just changed size. This is when either the size of the window or the number of rows and/or columns has changed (see SIZEFONT).

The script can use the $COLS and $ROWS variables to find the new size of the session. It can, for example, use the TITLEBAR and STATUSTXT commands to show the new size.

It can use QUERYSETTING to query the new font or the current size of the session window.

See also GUI_RESIZE, SIZE4ALL and QUERYSETTING.

12.2.28: ONSWITCHFROM/TO (Call script when session switch occurs)

ONSWITCHTO   Scriptname [params]
ONSWITCHFROM Scriptname [params]

This causes a script to be executed when IVT switch between sessions.
The session that becomes the foreground one will get ONSWITCHTO scripts executed. The session that loses the foreground will get the ONSWITCHFROM scripts executed. There can be multiple ONSWITCH scripts.

Such a script can be used to change global settings that depend on the current session - a rare case since you usually can handle this with normal per-session settings. But an example might be the custom menu bar entry.

NOTE: The script is started and IVT does not wait for it to finish.
If the script takes a long time to execute and the user switches rapidly between sessions, it could happen that multiple instances of the TO and FROM scripts are started. Make sure you protect against this by using SHAREMODE.

See also PRECONNECT, ONCONNECT, ONDISCONNECT, ONRESIZE, ONERROR, ONDROPFILES.

12.2.29: ONTABICON/TO (Call script when user clicks tab bar icon)

ONTABICON Scriptname [params]

The TABSBAR command can be used to enable a tab for every session that contains a customisable text and am optional icon.
The default icon that IVT can supply is a close icon, but you can use the SetTabIcon() function to supply a different icon.
When the user clicks the icon, this ONTABICON statement can be used to start a script on the session to handle the click.

When no ONTABICON is specified and the user clicks on the CLOSE icon in the tab, IVT will immediately terminate the session.

When an ONTABICON script is specified, ALL handling of ALL clicks becomes the responsibility of the script. This allows you to associate arbitrary icons with arbitrary sessions that cause arbitrary things to happen when the user clicks on them.

You can query the name of the icon associated with a tab using the QuerySetting function with "ICONTAB" as a parameter.

12.2.30: OPTIONS (Specify command line options in IVT.RC file)

OPTIONS options

The OPTIONS keyword can be used to set/unset command-line options. This is useful if you always want certain options to be in effect regardless of how IVT is invoked. The options takes the same form as on the command line. Use a preceding hyphen (-) to turn an option on, and a preceding plus (+) to reverse the meaning. Examples:

OPTIONS -ns       (acts as if 'IVT -ns ...' was used)
OPTIONS +n +s -B  (space separated, multiple options allowed)
OPTIONS +ns       (acts as if 'IVT +ns ...' was used)
OPTIONS -s        (forces security on)
OPTIONS +s        (forces security off)
OPTIONS "+s"      (forces security off, quotes are optional)

Another way to specify options to IVT without typing them every time is to define an environment variable called IVTRC. You could, for example, say:

   SET IVTRC=+ns

And that would have the same effect as an OPTIONS statement.
If you use a -B (no banner) option, IVT will remove the splash screen when it is currently displayed as soon as it sees the option.

12.2.31: PRIVATE_RC_FILES (Allow/deny private configuration)

PRIVATE_RC_FILES
NO_PRIVATE_RC_FILES

When IVT starts up, it will usually attempt to read an IVT.RC file on the private HOME directory of the user (as indicated by the HOME environment variable of Windows). Sometimes this is undesirable, for example when you have a special IVT configuration in some network directory, where the IVT.RC file is used to configure some specific application.
In that case, the NO_PRIVATE_RC_FILES command will prevent the processing of those private files.

The default is, of course, PRIVATE_RC_FILES.

However, see also the "-c" command line option.

This is an important feature, others are prev/next

12.2.32: PROFILE (Load configuration)

PROFILE "name"

See also DEFINE_PROFILE.

Older versions of IVT could only save ONE setup configuration.
This version of IVT can use multiple setup-configurations called PROFILES.

A profile defines the entire look and feel and all configurable options of IVT under a simple name. When a session is created, the name of a profile is associated with that session, and all the settings in the profile are applied before the session is actually created.
Profiles can be created in two ways:

• Interactively in setup.
  You simply alter whatever part of setup you want, then use the "Save as" button at the bottom of the main setup panel. This will show a profile management dialog. Type a name for the new profile and click "Save as". These profiles are stored in the registry, so they belong to the current user profile (of Windows).
• In the IVT.RC file.
  Use the DEFINE_PROFILE directive to instruct IVT that a new profile is going to be defined. All settings up until the DEFINE_PROFILE ENDS are made part of the named profile. Such profiles can contain items that cannot be configured interactively, such as KEYMACRO, printer definitions and many others. See DEFINE_PROFILE for details

IVT defines one default profile. This appears in the "Create session" dialog as the first choice. Initially, this profile is the result of the IVT.RC file setup (or, lacking such a file, from the built-in defaults of IVT).
You can overwrite the default profile as you like, changing the look and feel with which IVT starts up.
The default distribution kit of IVT adds another profile: DEC-VT220, which configures IVT to be as close as possible to a true VT220 terminal.

A profile can be attached to a session in many ways:

• Interactively from the "Create session" dialog, which contains a drop-down box that allows you to choose one of the known profiles.
• By using a global PROFILE command in the IVT.RC setup files. For example, the initial configuration script of IVT can set the DEC-VT220 profile as the default. Instead of "Default" being the default profile, DEC-VT220 assumes that role.
• Using the PROFILE command in a script. Usually you would use a PRECONNECT or ONCONNECT script for this. A single command will load the entire setup, either from an interactively defined profile or from a DEFINE_PROFILE. You can use this to change arbitrary setup items for particular hosts, users or whatever other condition you can think of. If you want to use a different profile for ALL your sessions, use a PRECONNECT statement that sets a different profile. If you want to leave the user a choice for his own profiles, use:

  
  PRECONNECT * ChangeProfile
  Script ChangeProfile
  # Only modify profile when current setting is default
  IF LOWER(QUERYSETTING("PROFILE")) == "default" \
  THEN PROFILE "MyProfile"
  END
  

  
  This uses the QUERYSETTING function to inquire the current profile. When not default, it will modify it. This prevents the ChangeProfile function overruling a setting from HOSTLIST, CREATE and so on.
• The PROFILE= clause in a CREATE statement.
• The HOSTLIST command has been extended to allow the definition of a profile for fixed address book listings. This allows yet another way to offer easy predefined choices to the user. When the host is picked from the list, the associated profile is applied.

There a few rules governing profiles:

• Deleting the default profile (from the registry) is allowed, this restores IVT to the setup that results from its configuration files.
• Older versions of IVT did NOT allow this, but starting in version 22 you can load any profile, modify it interactively, and save it under the same name. For example, this allows you to load the DEC-VT220 profile (which is defined in the IVT.RC file), modify it, and save it to the registry under the same name (DEC-VT220). When the profile is loaded, IVT will check for such an overloaded profile name.
• A profile can contain items that are not session-specific. An example is the language of IVT itself, or the look of the title bar (there are many others). It is not wise to define various profiles with different global settings, as the last one that is applied will be used, which can be confusing to the user. However, it can be very powerful to have the entire look & feel of IVT switched over by choosing a different profile, therefore it is allowed and supported. Use with care.
• Profiles can be based on other profiles. If you create a prof1 profile, laod it, modify it and save it as prof2, IVT will only store the modifications (relative to prof1). When prof2 is loaded, IVT will first load prof1, then apply the prof2 modifications. This can be nested to an arbitrary depth. It does imply that when you modify prof1, prof2 will inherit those modifications. Again, best to keep it simple here.
• When you use the name of a non-existent profile in your IVT.RC files, it is treated as if you said "Default".
• The "Default" profile can be specified in either English or your native language, when you have selected that. The QUERYSETTING function always returns "Default" (in English).

12.2.33: PROTOCOL (Specify the type of protocol to be used)

PROTOCOL transport[,session]

NOTE: This statement can also be used in a PRECONNECT script to change the protocol of a session that is about to be created.

This version of IVT supports the following transport protocols (which is a subset of all existing protocols):

• NETBIOS
  NetBios protocol (can also be NetBios-over-TCP/IP). IVT was originally designed for this protocol.
• SERIAL
  RS-232 over serial lines (modems and such). This is useful if you want to use IVT from home rather than on a LAN. Also when you connect to special hardware that requires a serial connection.
• MULTIPLEX
  This version of IVT also supports multiplexing. On a LAN, this is not really necessary, but on serial lines it gives you the possibility to run several sessions on the remote (Unix) host you login to, using the IVTM support program.
• WINSOCK
  The Windows way of doing TCP/IP. This is by far the most common protocol nowadays.
• DUMMY
  This protocol allows you to have a "session" to a dummy host, which always connects immediately, never sends anything except echoing back what you send it. This is useful if you want to have an IVT script batch procedure that just needs a session context to "something".

In addition to these transport protocols, you can "push" one of the following session protocols on top of this:

• TELNET. The IVT built-in TELNET protocol.
• SSH. The Secure Shell version 2 protocol.
• RLOGIN
  The (Unix) RLOGIN protocol, designed for use over TCP/IP.

For your convenience, IVT recognizes a number of handy abbreviations for common combinations. These are:

NET - NETBIOS
VTP - Vtp hack.
TLN - WINSOCK,TELNET
SSH - WINSOCK,SSH
RLN - WINSOCK,RLOGIN
SER - SERIAL
DUM - DUMMY

Examples:

        PROTOCOL SERIAL
        PROTOCOL NETBIOS,VTP
        PROTOCOL WINSOCK,RLOGIN
        PROTOCOL WINSOCK,TELNET

When no protocol statement is used to force IVT, it will determine which protocols are compiled in and available at runtime, and use one that seems 'logical'. Use the command line or a PROTOCOL statement to force the choice.
You can, of course, also use the setup screen to change both the transport and session protocols.
The setup-screen allows you to change the protocol for the NEXT session you are going to create.

A script can query the current effective protocol by using the $PROTOCOL and $PROTOCOL_SESSION.

12.2.34: REGISTRY (Load start-up config from registry yes/no)

REGISTRY
NO_REGISTRY

Default: REGISTRY.

When the setup screens are used to change the configuration of IVT, the resulting configuration can be saved into the Windows registry using setup.
See "IVT and the Windows registry" for details.

If, for some reason, you want to ignore the current contents of the registry without deleting it, you can specify NO_REGISTRY in your IVT.RC file.
IVT will then not attempt to read the registry during start-up.
Also, the button to save the setup to the registry will be disabled, so users are unable to make permanent changes to the IVT setup.

See also secure mode and IVT_DIALOGSTATE.
See also the IVT registry functions REGCREATEKEY, REGDELETEKEY, REGDELETEVALUE, REGQUERYENUM, REGQUERYSTR, REGQUERYDWORD, REGSETVALUEDWORD and REGSETVALUESTR.

12.2.35: RESOLVE (Set name resolution options)

RESOLVE "NameSource[,...]"
NO_RESOLVE

Resolving is the process of translating hostnames into IP numbers (the numbers that identify a host on a TCP/IP network).
In this version of IVT, this can be an IPv4 or IPv6 address.

This option is only used for the TCP/IP (WinSock) transport protocol.
See also the DOMAIN statement, to specify a number of domain names to append to the hostname. The default domain of the PC you run IVT on is used automatically.

NameSource can be one of:

• Filename of a HOSTS style file;
• IP address of DNS server with optional timeout and port number;
• The word HOSTBYNAME.

For example, the name of a host (like www.ibm.com) must be resolved to an IP address (like 129.42.58.212) before a session can be established.
The translation of names into numbers can be achieved in a number of ways:

1) Using a HOSTS type file (containing numbers and their names).
2) Using DNS (Domain Name Server).
3) Using WINS (a Microsoft way of doing DNS).

A HOSTS file contains lines with IP numbers and one or more names for that address. For example, you could have a file called C:/WINDOWS/HOSTS that contains lines like:

193.79.171.11   atf.cmg.nl mailgate
2001:200:dff:fff1:216:3eff:feb1:44d7 www.kame.net kame
fe80::a00:27ff:fe8d:54f2 moria-u

the IPv4 line gives two names for one address. Either can be used as the name when you establish a session. Fields on a line are separated by white space (spaces or tabs). Lines can be empty or end in a comment.
A comment is introduced with the # sign.
The lines with all the colons in them are IPv6 hexadecimal addresses, which this version of IVT understands as well.

A DNS server (Domain Name Service) is a computer on the network that resolves names into IP numbers.
IVT has to know the IP-address of one (or more) of such servers to be able to query them. Normally, the server can be reached on the well-known DNS port (number 53), but you can specify another port.
The DNS IP-address can be an IPv4 or IPv6 address, IVT can query both typeso of servers.
See also the DOMAIN statement.

IVT can also use the standard "gethostbyname" function, which will simply use the configuration of your PC to translate the name into the desired address.
This can use files, query DNS or WINS servers or whatever.
From IVT version 22.2 onward, DNS calls are no longer synchronous (which would block IVT if the DNS server was slow), but asynchronous (handled in the background). This solves a number of annoying issues.

The RESOLVE statement takes a list of sources to query.
Each source is either:

• The IP-address of a DNS server (IPv4 or IPv6 style).
• A filename (with lines according to a HOSTS file format);
• The literal word HOSTBYNAME or GETADDR (same meaning);
• An AVOID:ip-address construction instructs IVT to NOT use a certain DNS server (see below).

The sources are queried in the order you specify them.

A filename is simply the (full) pathname of the file.

A DNS server must be the dotted-decimal address of a nameserver, optionally followed by a / and a decimal timeout in seconds, optionally followed by a second slash and a port number.
IVT will wait for the specified number of seconds for an answer from the DNS server. When no reply is received, the next name source is tried.
The timeout defaults to 20 seconds. The port number to 53 (DNS).
During the timeout, IVT WILL respond to input from other sessions, the keyboard, scripts, etc. since the built-in DNS resolver is home-rolled and asynchronous. See also the DOMAIN statement, to try to resolve the name in a number of different domains.

When you specify the literal HOSTBYNAME, IVT will use that function (the asynchronous, non-blocking Windows version of it).

When you do not use a RESOLVE statement in your IVT.RC files, IVT will default to scanning the HOSTS file in your OS directory, followed by a HOSTBYNAME.

The AVOID:IP-address is a little used option that can be used to try and correct bad DNS setups. When a queried  DNS server sends a "redirect" to IVT, this normally causes IVT to re-send the query to the specified address.
When such a redirect address is specified in an AVOID clause, IVT will simply give up on that specific redirect and try the next alternative.
This can be used when a DNS server redirects you to a server on the Internet, but you are behind a firewall which blocks the query, causing long timeouts.

Example:

   RESOLVE "C:/Windows/HOSTS,193.79.171.11/3/53,193.79.171.100,HOSTBYNAME"

This would first look in your local HOSTS file, then query a nearby DNS server which is unreliable (often down, hence the timeout of only 3 seconds), then resort to another, slower but more reliable server (default timeout, thus 20 seconds). The default port of 53 is specified explicitly as an example, it may be omitted,
If all queries fail, IVT will do a call to the OS with "gethostbyname".

If a name cannot be resolved, session establishment will fail with a "Host unknown" error message (see also ONERROR).

You might use the file to configure the IP-addresses of servers that you use often if you are plagued by unreliable DNS-servers. If not, it is best to leave ALL resolving to a DNS server because when servers change their address the DNS-server will know about it, where your local file does not.

The NO_RESOLVE statement (no parameters) will delete any previous list of remembered resolvers. This can be used to forget settings from other configuration files, or force things back to their defaults.

Note: Version 21.1c of IVT adds a local cache to the name resolver, where resolved entries are kept for a short while (30 seconds). This is intended to prevent floods of queries for the same hostnames when you have a group of sessions to the same (or a small set) of hosts, or proxy server. For example, a group of 30 sessions all using the same (named) proxy server would cause 30 identical DNS queries to be performed without this local caching of answers.
The cache is cleared when the RESOLVE statement is used to alter resolving.

See also the RESOLVE_TRACE command to print debugging output.
See also the DOMAIN statement to search a number of domains.
See also the $IVT_NETW_DOMAIN variable.
See also the $IVT_IP_CANON variable.
See also the RESOLVENAME function.
See also Winsock, TELNET, SSH and RLOGIN.

12.2.36: RESOLVE_TRACE (Show name resolution and DNS debugging)

RESOLVE_TRACE
NO_RESOLVE_TRACE

Default: NO_RESOLVE_TRACE.

This command can be used to make IVT print out information about attempts to resolve a hostname into an IP-address. This assumes the WinSock protocol and that the RESOLVE statement has been used to configure DNS (Domain Name Server) addresses.

Whenever a DNS NameServer is queried or a HOSTS type file is searched, IVT will show some details on the screen concerning the query and the result.

This might be helpful when you receive 'Host unknown' errors.
This option can also be changed from this setup panel, which works only for the current session (so you must set this before you initiate the session by choosing "setup" from the create session dialog).

12.2.37: RLOGIN_LOCALUSER (Name of local user for RLOGINs)

RLOGIN_LOCALUSER stringexpression

This is only for use with the RLOGIN protocol (and ignored otherwise).
This sets the name that will be transmitted to the remote (Unix) host and which identifies the user on the local PC. Since IVT has no way to determine who you really are, it will send whatever you tell it to.
A reasonable value might be:

   RLOGIN_LOCALUSER $ENV_USERNAME

which will set it to your Windows username (if any).

The Unix machine will use this name to see if the user is 'trusted'. It can be configured along the lines of 'User john on system X is equivalent to user johnb on THIS system'. This is not very secure.

See also RLOGIN_REMOTEUSER and RLOGIN_TERM.

12.2.38: RLOGIN_REMOTEUSER (Name of remote user for RLOGIN)

RLOGIN_REMOTEUSER stringexpression

This is only for use with the RLOGIN protocol (and ignored otherwise).

This sets the name that will be transmitted to the remote (Unix) host and which identifies the user you want to login as on that host. When the host decides to trust you, it will log you in without prompting for a password. If not, it will either disconnect or simply ask you to prove your claim by asking for a password.

When you do not specify this value, IVT will use whatever you have entered in the create session dialog in the "User name" field.
If you do not specify a user there, but have specified a value for the RLOGIN_REMOTEUSER, that latter value is also assigned to the $USER variable.

See also RLOGIN_LOCALUSER and RLOGIN_TERM.
See also the password learning and automatic login system.

12.2.39: RLOGIN_TERM (Terminal type for RLOGIN sessions)

RLOGIN_TERM stringexpression

This is only for use with the RLOGIN protocol (and ignored otherwise).

It sets the type of terminal you claim to use (it will end up in the Unix TERM environment variable). The default is "vt220", which IVT emulates. You can set it to anything else. When you use the special TIC (Terminal Information Compiler) on the IVT.TIC file delivered with IVT the host will know a terminal type "ivt", which