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 customizable 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.

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://ivtssh.nl/downloads

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

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.4.1: Copyright for Open Source parts of IVT

For the HIGHLIGHT and history search functions that use regular expressions, IVT uses the PCRE library (Perl Compatible Regular Expressions), details of which can be found at http://www.pcre.org.
As the website says: "The PCRE library is free, even for building proprietary software", and thank you very much for providing this excellent package.

The documentation for the Perl expressions can be found at: http://perldoc.perl.org/perlre.html

The PCRE library is released under the BSD license, which reads:

THE "BSD" LICENCE
-----------------

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of the University of Cambridge nor the name of Google Inc. nor the names of their contributors may be used to endorse or promote products derived from this software without specific prior written permission.

End of quote.

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-2025 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
           Use +A to disable automatic creation of sessions on startup.
-agrp   : Automatic startup, use group code 'grp'.
           This option can be repeated to start multiple groups.
           Note: No space is allowed between the -a and the group name.
-B      : Suppress display of graphic introduction (banner) screen.
           See also SPLASHTIME.
           The banner is always suppressed if there is a "nosplash" file in
           the current directory.
-C<scr> : Call script scr when connection to host established (see ONCONNECT).
-c<file>: Use 'file' as the ONLY IVT.RC file.
           Note: No space is allowed between the -c and the file name.
-h      : Enter hypertext manual of IVT (complete on-line documentation!)
-I      : Ignore Windows startup mode (MAXIMIZED/MINIMIZED)
           See also IVT_SHOWNORMAL environment variable.
-n      : No attempt to do autologin.
-p      : Secure mode - No sub-processes started ever
-s      : Secure mode - No multiple sessions, no sub shell
-T      : Turn startup Tips off.
-Q      : Do NOT start the "Start group on startup" groups.
-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
-P<prof>: Select prof as startup PROFILE.
           Note: No space is allowed between the -P and the profile name.
-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
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 BUILDNR 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 IVTMUX 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 Chrome, Firefox or IE).
A browser can follow a link of type:

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

The code you need in the HTML would be something like:

   <A href="ivt://somehost">Login to somehost with IVT</A>

This will cause IVT to be executed, passing it the URL with a preceding "-u" option. This new instance of IVT will not create a window or a session, but 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. The "hostname" can even be the name of an IVT session group, in which case all the sessions described in that group are created.

Additional information can be passed in the URL.
As an example:

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

Would cause IVT to behave as if those commands were read as part of a script, so the protocol will be DUMMY and resizing will be disabled.
There is no limit to the number of statements that can be passed this way.
All statements have 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%20DUM;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 privileges, 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.

1.13: Integration with password managers (like SecretServer)

Programs such as SecretServer manage secrets (like passwords) and often have a method of starting an external program to open a session to a certain host.
The password manager will then start that external program, passing it the name of the desired host, the user to login as, and the password.

When IVT is configured as the external program, you do NOT want a separate instance of IVT started for every session, but rather a new tab should appear for such a session. IVT can already do this using a URL, to integrate with a password manager is a matter of translating the command to start a session into a URL command. IVT has the "-u" command line option for that. For example, when "$h" is the host, "$u" is the user and "$p" is the password as provided by SecretServer, starting IVT like this will open a new tab to that host, log in as that user and will use that password when the host prompts for it:

   C:\path\IVT.exe -B2 -u ivt://$h;SecretUser=$u;SecretPasswd=$p

The "path" must be the full path to IVT, normally like:

   "C:\Program Files\BearStar Software\IVT Secure Access\ivt.exe"

A little scripting in the standard util.ivt module of IVT will intercept this command and make the proper arrangements for the tab to open.

This is an important feature, others are prev/next

2: Several useful facilities of IVT

2.1: The scrollback 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-viewing 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 may 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 COLOR_SEARCH 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 'Edit' menu or from the pager menu bar. Normally, a search uses regular expressions. If you are not familiar with those, or you need to search for a string that contains special characters, you can use the 'search plain text' option, which will search for the literal string instead of a regular expression.

Incoming data on a session is blocked while you are viewing history.
You can also 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 three items to manipulate the scroll back buffer:

• Search scrollback buffer.
  This is a quick way to enter history mode and start a search.
• Clear scrollback buffer.
  This simply deletes the contents of the scrollback buffer.
• Copy all to clipboard.
  This places the entire contents of the scrollback 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.

Also note that AUTOLOG is normally on and everything that is displayed on the session is also logged to a file. The file can be accessed by clicking the notebook icon in the status line (on the far right).

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.
• Use a highlight marker to mark text on screen.
• 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 behavior).
At the start of the CUT, you have a select window (the colors of which can be set with the COLOR_CUT 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 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 behavior.
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 copying 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.
• F3: Mark the text with a highlight marker color.
• 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 behavior 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.

Note: You can configure various levels of Putty compatibility using the MOUSE_PUTTY_WORDS and MOUSE_PUTTY_SELECT options.

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 behavior 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 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.2.11: Store text on clipboard from a script

The IVTFUNCTION "Copy String to Clipboard" takes a string parameter.
The contents of that string are stored on the Windows clipboard.
This allows a script to control the contents of the clipboard: use with care.

Passing an empty string will clear the clipboard.

Example:

IVTFUNCTION("Copy String to Clipboard","WAIT", "My Example string");

2.2.12: Kill all session but this one

The IVTFUNCTION "Kill all sessions but this" can be used to perform the same function that the context menu of the session tab provides: Close all sessions except the current one.
Handle with care, as all other sessions are forcefully closed.

2.2.13: Show session events

This menu option in the 'Sessions' menu can be used to view the SSH or Telnet debug after a session has been established.
When something fails during session establishment, you can use the SSH_DEBUG or TELNET_TRACE options to view the details of the protocol. But if that is too late, the 'Show session events' menu option can be used to save the details to a text file and invoke the standard editor of the system on that file so you can study the details at your leisure.
This option can be used on any existing SSH or Telnet session.

The (temporary) work file with the log is removed when IVT exits.

Putty has the 'Show events' option in the menu for this, IVT was lacking that feature and that just wouldn't do :-)

2.3: Themes (manage color themes)

Themes are a new feature in IVT 26.1 (July 2018).
IVT is now shipped with 50 different color themes, which have been borrowed from Putty. Choosing and activating a color theme in Putty requires manually loading a bunch of settings into the registry and it has no preview of a theme.

In IVT, working with these themes is much easier:

• Choose from the menu bar: Setup->Themes: Color.
• A dialog appears that shows the names of all the available themes.
• If you have an active session, IVT can demo the theme by selecting an entry from the list. It will show all available color combinations and how they look on your hardware.
  When you have no session active, the demo is unavailable (but you can still select a particular theme).
• Choose "Activate".
  When you have a session active, you will be returned to it with the selected scheme active.
  If you are still in "Create session" mode, the scheme is activated and you are returned to the "Create Session" Dialog.
• If you decide you like the theme and want it to become the default, treat it like any other setting: Go into setup (F3), use the "Save As" button and save the current settings as the default profile.

That is all.
Note: The "Solarized Light" and "Solarized Dark" themes are particularly attractive.

Under the hood, a theme is an IVT script that can be called like any other.
So you can have custom scripts that can activate themes as they see fit, for example, in a default setup file:

   Script STARTUP
      Call THEME_COLOR_Solarized_Dark()
      NO_COLOR_FOR BOLD FOREGROUND      # But overrule the bold color
      BOLD_STYLE SHADOW                 # I like boldness
   END

will activate the "Solarized Dark" theme, but with a tweak. Most themes will arrange for bold characters to be shown using a color, and the Solarized theme uses a color that is almost the same as the default foreground (so you can hardly distinguish bold text from normal text). Personally, I like it better when bold is truly bold, so I disable the color-for-bold, and change bold display to a shadowed font. Likewise, any setting set by the theme can be tweaked or overruled by subsequent commands.

All themes are coded in a new plugin, see the "Plugins" directory of IVT for the details.

If you find a Putty theme that you want to use and is not part of IVT: In the "Support Programs" directory of IVT is the Perl script that I have made to convert the cryptic Putty registry names into IVT themes.
The script is meant to be self-explanatory.

2.4: 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.5: 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.
In release 23 the option was added to have MULTIPLE menus.

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

• Key broadcasting.
• Project file loading.
• A script to manage a local address book.
• Configuring the Ex-AutoPrompt system.
• Various other powerful scripts that could otherwise be overlooked.
• 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 mouse clicks, 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 and alter other settings of IVT.
The scripts menu bar contains an entry to start NOTEPAD on that file.

See the stock IVT.RC file for more examples, and the MENU keyword.
See also DELSCRIPT to delete a loaded script from memory so you can load a new version, convenient for development.

2.6: 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 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. Projects can also add custom menu to the menu bar.
Connecting to a host will use 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 "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 is 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 this example file for suggestions.
• Optionally, a file with the same base name 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 base name 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. Alternatively, use SSH_ACCEPT AUTO.

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 base name 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 scripts itself to better suit your needs.

See also the example script to provide a context menu per host, that demonstrates a real-life project example.

One of the things the project scrip arranges is the management of the special $HOSTLIST_EXTRA variable. You can use this to assign a bunch of attributes to a specific host (and the attribute vocabulary is easily extended). The standard script has support for:

• MENU=Name
  Will arrange for a script name "menu_$Name" to be called whenever the user switches sessions. This can be used for a host-specific menu on the IVT menu bar, which can be used to configure common commands for that host which can then be started by a simple menu-choice.
• SCRIPT=Name
  The named script will be called before a session is initiated.
• THREAD=Name
  The named script will be started as a background thread before a session is initiated.
• SET=Name=Value
  Will set the session variable called Name to the given Value.
• GSET=Name=Value
  Will set the global variable called Name to the given Value.
• THEME=Name
  Will choose the given color theme for the session.
• DIR=Directory
  IVT will send a change-dir command to the host after logging in to go to the given directory.
• LINUX
  Designates the host as type Linux, and that will cause UTF-8 as codepage.
• TERM=Name
  Will set the TERM environment variable on an SSH or TELNET session to the given Name.
• EVAL=string
  Will invoke the IvtEval function on the given string, which allows arbitrary commands to be executed before a session is initiated.

As an example, consider this:

   HOSTLIST bamboo root "My favourite" EXTRA="TERM=ivt\nDIR=/tmp" SSH

When a session is established to the "bamboo" host, it will login as root and set the TERM variable to "ivt" and change directory to /tmp after login.

For more details, study the "projects.ivt" file in the IVT distribution.

NOTE: Set the global variable PROJECTS_DEBUG to 1 if you want to see what the system is actually doing below the covers. Very convenient for troubleshooting complex projects setups.

This is an important feature, others are prev/next

2.7: The session groups editor

A major new feature was introduced in version 16.1a of IVT - the group editor.
Before, the very powerful CREATEGROUP 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, CREATEGROUP 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 CREATEGROUP manual page.

A group 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 (unless you start IVT with the +A option, which suppresses this).
Multiple groups can have this option set, all of them will be created when IVT starts up. Similarly, the "-a" command line option can be used multiple times to start multiple groups.
Use the -Q option to suppress the starting of these special groups, in case you have misbehaving groups or need to edit the definition of a complex group.

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. If you want to choose a host from your address book, you can type the short name of the host if you want to.
• 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.
• Tab text.
  When set, the given text will appear in the tab of this session. This overrides any default that IVT arranges otherwise.
• 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
   LOCAL x
   DESCR "Use this in a session create, params are Dir and Command"

   # 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
   }

   WAIT_ONCONNECT("SetUnixEnv");
   WAIT_ONCONNECT("AutoPromptSetPrompt");

   # Highlight with edit-in-tab does this...
   WAIT_ONCONNECT("StartEditOnConnect");
   
   # When we get to this point, all known scripts that want to change the
   # working environment of the shell have done their thing.

   # When CMD is a Clearcase Setview that must PRECEDE the cd.
   LOCAL CmdDone = 0;
   if (substr($cmd,0,17) == "cleartool setview") THEN {
      send "$cmd\r"
      Call WaitPrompt();
      CmdDone = 1;
   }

   # 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 (and not done yet)
   IF $CmdDone == 0 && $cmd != "" THEN Send "$cmd\r"

   # If an IVT scriptname is given (3rd param), 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.8: Fixing broken groups

As explained in the previous chapter, a CREATEGROUP 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 CREATEGROUP 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.9: 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 this 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 tabs bar, 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 tabs bar 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".
• Check "Save size".
• 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). For each profile, make sure you size and position the window where you want it, and use the 'Copy current' button to obtain the proper coordinates. Save those coordinates and size as part of all the profiles.

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.
All other attributes in the CREATE can be used as well: Host name, user name, scripts, parameters and so on.

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.
When you start an IVT with the name of your group on the command line, or start IVT and just type the name of the group in the host name field, IVT will create all the other instances and the 'empty shell' that is left behind will terminate automatically.

Note that all your profiles are based on the default profile. So, if you change a setting in the default profile which is not explicitly 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 way, a whole array of windows can popup with a single mouse click, every window can have 1 or more sessions, every session can connect to a host and start programs there.

This is an important feature, others are prev/next

2.10: 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.
Before using the interactive key macro feature, you might want to have a look at KEYMACRO, which allows you to write keyboard macro's in the form of a script, which is more easy to view and alter.
Interactive setup mode is easier to use, though.

Learn mode is entered through this setup screen (choose the button labelled <Keyboard macros>) in setup.

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 the 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).
• VT220 key only.
  When selected, the keymacro is only recognized in plain session mode. This can be convenient for keys that are used by IVT internally as well (such as PgUp/PgDown, cursor keys and so on). For example, if PgUp is programmed to send something to the host, it is advisable to turn this option on or you will not be able to use the PgUp key in the history pager or the help system, or during copy operations using the keyboard. See also BIND.
• 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 / Windows key recorder.
  You must record the keys once (after pressing <Start recorder>). IVT will remember everything you type until you end the recorder (by clicking on the recorder icon on the status bar, or by pressing Ctrl+Shift+End, or by using the menu bar). When the key is typed, playback is at maximum speed. The difference between the "Keyboard recorder" and the "Windows key recorder" is that the former (and older) one, is only capable of recording keys that actually generate data. The newer Windows recorder can also record keys like a lone ALT, CTRL or SHIFT key (and combinations thereof). This allows you to have a macro that activates the menu bar (type a lone ALT), switch sessions using keys, etc.
• 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. If you need longer delays, you probably need a script to handle some complex interaction with the host.
• 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 enter here and evaluate it as a string expression. The result should be the name of a valid script. The rest of the string you enter is seen as a list of expressions that are passed as parameters to the script. The field can be much longer than 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. See SHAREMODE to do something about this. 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 (and 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.11: 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).
F3 also works (just like many Windows programs).

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 than 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.12: Hypertext help keyboard commands

2.13: 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.14: 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.15: 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.16: 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.17: 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 support@ivtssh.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?
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 CREATEGROUP 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 mouse wheel 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.
Go to FAQ start page.

3.5: 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.6: 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 WINDOW_POS 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.7: 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.8: 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.9: 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 analyze 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.10: 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.11: 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.12: 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.13: 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 PR_CONTROLLER (for all printers) or in this setup-screen for individual printers.

Go to FAQ start page.

3.14: 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 (initialization 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.
See also WAIT_ONCONNECT to synchronize multiple ONCONNECT scripts.
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 menu bar). 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".

5.3: Exporting/importing IVT configurations

When IVT saves setup in the registry, that data is more or less invisible to the average user. The data grows over time:

• Typed host names and users;
• Saved host keys of hosts you SSH into;
• All settings modified in setup;
• All preferences configured in the plugins;
• Etc.

Besides the data in the registry, there are files with saved passwords, configuration, private settings and so on.

When a new PC is going to be used, it would be nice if all that accumulated data could be transferred to the new PC, and that is what the export/import functions in the 'Setup' menu are for.

• Use the 'export' function to create a ZIP file with the IVT data in it.
• Transfer the '.ZIP' file to the new environment.
• Use the import function on the new PC to import the file.

The import function will check the validity of the file before using it. When it seems okay, it will replace any current configuration data in the IVT registry with the contents of the file and overwrite any files with the data from the ZIP file.

So use this with care!

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+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, SYSTEM and COMMANDOUTPUT script functions.

6.3: 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.4: 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.5: 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.6: 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 NNxYY 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 of 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 accounts!
• Keys icon.
  To indicate that the keyboard is LOCKed. You must type the proper password to re-enable 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 host name in the status line, which brings up the edit dialog immediately.
Yet another way is by right-clicking 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 size indicator.

This shows the current session size in rows and columns.
When the window is too narrow, this field is omitted to make room for the other fields on the status line.
Currently, the field is display only.

When you interactively resize the screen, the indicator shows the resulting size. Note that the title bar does the same, but many people overlooked that.

7.7: Status line activity indicator

IVT supports two kinds of activity indicators. Such an activity indicator is intended to alert you to a status change of a background session (a session you are not currently looking at). The two forms are:

• One position in the tab of the session, which uses a rotating hands of a clock to show activity, checkmarks for readiness, colors for errors. This is the default.
• A field in the status bar that can show the activity for the first 9 sessions. A number showing there indicates that the indicated session had activity, a rotating movement to show activity, and colors for errors.

The default in newer versions of IVT is to use the tab for this, but if you liked the status line indicator it can be turned on using TABSBAR NO_ACTIVITY configuration option.

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.
  In the tab, this is indicated by the moving hands on a clock face.
• 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.
  In the tab, this is indicated byu a checkmark.
• 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.
  In the tab, the checkmark or clock will turn red in this case.
• Session error.
  When the (LAN) session is lost, the indicator 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 indicator 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 COLOR_READY statement can be used to customize the actual foreground and background colors for the indicator... In the tab, the checkmark will turn green when this happens.

7.8: 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 right-click 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 60 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.

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 set of customizable entries in the session menu bar.
Normally invisible, these 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 of Windows.

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 menus

One of the nice features of the session menu bar is that it has configurable menus. Normally, these menus are empty and invisible. They 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.
There can be up to 10 custom menus on the menu bar, number 0 to 9.
Number 0 is reserved by IVT, it is used for the 'Scripts' menu entry.
You select a menu by using "MENU SELECT x", where x is a single digit (0 - 9).

Note: These menus can support multiple languages, just like the rest of IVT.
See the ONLANGUAGE statement and NLS() function for details.

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. If you do not assign a shortcut, IVT will assign a unique one for you (if possible).

Next, the menu must be filled with entries, of which there are 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).
Again, these shortcuts will be chosen automatically if you omit them.

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.
• 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 (for example when switching to a different national language).

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

   Script Startup
      MENU SELECT 1             # Choose a private menu
      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.
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
• Viewing/managing scroll-back history
• IVT keyboard guide
• IVT start-up files (IVT.RC)
• IVT scripting language
• Protocols supported by IVT

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 many 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.
Afterwards, it was rewritten to be a normal Window GUI 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.

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 CREATEGROUP cannot be created multiple times automatically.
See also MERCY_MODE, to prevent excessive stress on hosts.

8.6: List with previous host & users

The address book icon at the end of the hostname prompt in the "Create Session" panel can be used to access a list of recently used and predefined hostnames, user names, profiles 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 available 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 host list filter.

8.7: Host list 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). The search is case insensitive.

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, click on the "Clear" button.

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 and drag the icon to any line to get help on that specific item.
Right-click anywhere in the blank area of the dialog to get help on the panel itself.

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.

The old setup shortcuts of IVT also 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 NO_REGISTRY 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.

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 also chooses the basic session protocol.
A session protocol runs "on top of" a transport protocol. It can be TELNET, SSH, RLOGIN, VTP or MULTIPLEX.

Transport protocol  : [WinSock     ]
Session   protocol  : [Telnet   ]
IP version          :[Both     ]
TCP no delay option  : [X]
TCP keep alive option: [X] [15] [10] [3]
Socket timeout       : [  20]
Trace name resolving : [ ]
Search domains       : [acme.com           ]
<Configure proxy >
<Configure delays>

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.
In case you are unfamiliar with proxy servers: it is a server that connects to a host on behalf of IVT because your PC cannot reach that host directly.
IVT connects to the proxy server and asks it to connect to the destination host. After the connection is established, the connection is transparent.

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

9.5: Configure delays

The Delays panel allows you to configure various delays that IVT will perform on purpose to prevent overloading hosts and networks.
Click on any of the links below for more information.

Mercy mode after #sessions : [4    ]
Mercy mode delay           : [500  ]

TCP flood protect #sessions: [10   ]
TCP flood protect delay    : [1500 ]

Paste maximum lines        : [3    ]
Paste maximum bytes        : [10000]
Maximum wait for response  : [10   ]
Send CR separately         : [ ]

9.6: IVT Tunnel setup

The ivttunnel program can be used to traverse firewalls and so on. This dialog allows you to configure the tunnels and various supporting details.
This dialog can be reached from Setup->Protocol->Configure IVT tunnels, or from the dialog: Setup->SSH setup->Configure IVT tunnels.
This is because these tunnels can be over any sort of connection, even serial ones.

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

Tunnel program      : .........................
Debug file          : .........................
Config file         : .........................
Start minimized     : [X]

See ivt tunnels for details.

9.7: Telnet setup

The TELNET setup dialog allows you to modify the settings for future sessions and to inquire the status of the current TELNET 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)  : [ ]
Send NUL after CR       : [X]
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.7.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 also have been set to OFF...

9.7.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 honor this request. Your last recourse is to hit ALT+F4 to kill the session (or use the TABSBAR close icon).

9.7.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.7.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 honor this request, most ignore it.
Another way to disconnect forcibly would be to use ALT+F4 or use the TABSBAR close icon.
See also "Send TELNET break" and "Send Interrupt process".

9.7.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.7.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 back again.

9.7.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 initialization. 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.7.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.8: Kerberos setup

This panel allows you to configure the Kerberos features of IVT.
Kerberos is a security protocol that allows TELNET connections to be secure in both authentication and data transport. SSH is more common, but Kerberos has a few powerful properties like a central point of administration and mutual authentication.

Enable negotiation                : [X]
Automatically forward credentials : [Forwardable]
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.9: 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.10: 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: [ ]   Use timestamps: [ ]
Log SSH packet data to IVT.LOG: [ ]
X-Windows port forwarding     : <View/Configure>
IVT tunnels                   : <View/Configure>
Kerberos/GSSAPI               : <View/Configure>
Allow interactive passwords   : [X]
Don't allocate pseudo terminal: [ ]
Allow use of Pageant          : [X]
Enable authentic. forwarding  : [X]
Agent hijack protection       : [X]
Enable compression            : [X]
Show SSH debug messages       : [X]
Allow non-standard use of DES : [ ]
Accept host keys              : [Ask user  ]
Trivial authentication        : [Disconnect]
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 core SSH code was borrowed from PuTTY. Thanks!

9.11: SSH Port Forwarding

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

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

   [ Add ]   [ Remove ]

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, set 'Accept all hosts' checkbox to 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 honor 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 show 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.12: 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.13: SSH bug detection

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]
Handles SSH-2 key re-exchange badly    : [Auto detect]
Only supports pre-RFC4419 GEX          : [Auto detect]
Ignores SSH-2 maximum packet size      : [Auto detect]
Replies to requests on closed channels : [Auto detect]

Normally, IVT will attempt to detect the bug automatically, based on the name and version number of the remote SSH server. When a bug is present in a server IVT does not know about and the bug causes problems, you can set it to "Force on". When IVT thinks there is a bug when there in fact is none, you can set this to "Force off".

9.14: 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.
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 (because this may be a host that pretends to be somebody else).

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, to limit IVT's connections to known hosts only.

Note: PuTTY does not have this functionality :-)

9.14.1: GSSAPI Authentication over SSH connections

This setup screen configures Kerberos authentication over SSH, using the GSSAPI protocol. This feature was introduced in IVT 24.0 in 2014.

Attempt GSSAPI authentication: [X]
Prefer GSSAPI over others    : [X]
Allow credential delegation  : [ ]
Use OS user as default login : [X]
Reverse lookup of host names : [X]

Preference order for GSSAPI libraries:
   MIT Kerberos GSSAPI          <  Up  >
   User specified GSSAPI.DLL    < Down >
   Microsoft SSPI SECUR32.DLL

User-supplied GSSAPI DLL     : [               ] <Browse>

9.15: 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 ]
CTS output control     : [X]
DSR output control     : [ ]
DSR input sensitivity  : [ ]
DTR control            : [ Enable    ]
RTS control            : [ Handshake ]
XON/XOFF output control: [X]
XON/XOFF input control : [X]
XON limit              : [128  ]
XOFF limit             : [0    ]
BELL on phone RING     : [X]
Show Carrier Detect    : [X]
Write timeout          : [0    ]
<Short BREAK (250ms)>
<Long BREAK (1.5 sec)>

Total char overruns   0
Current overruns      0

There are a number of buttons in the "Preset" section which will select logical combinations for flow-control. By clicking them, the relevant options will automatically be updated.
When you use an IVTFUNCTION to access this (using "Serial preset" as a parameter), you must specify a 3rd parameter that specifies which button must be simulated:

RTSCTS: Select Request-to-send/Clear-to-send flow control DTRDSR: Select Data-terminal-ready/Data-set-Ready flow control.
XONXOF: Selects XON/XOFF flow control in both directions.
NONE:   Turns off all forms of flow control.

9.16: 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.
Be warned: RLOGIN transmits passwords in clear text over the network.

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

9.17: VT220 (basic) setup

This basic setup dialog manages the main characteristics of the VT220 emulator. Click on any of the links for more information.

Screen size         : [60x145 (Dflt)]
Allow resize        : [X]
Allow ALT-screen    : [X] Separate scrollback[ ] <Swap Now>
One size for all    : [X]
History             : [X]
Screens             : [10  ]
Timeout             : [0   ]
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)
Highlight strings   : <View/Configure>

9.17.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.

NOTE:
Older versions of IVT refused to save this setting, since it causes an incompatibility with a true VT220 when you do. Starting with version 23.1, it is the users' responsibility to make sure of the setting: IVT saves it when you save setup, along with the all other settings. when the host alters the setting using an escape sequence, it is marked as VOLATILE and will not be saved accidentally, which was the original reason to skip saving this option.

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 that case, just set it to ON and save it.
In the former case, a little IVT script can be used to force the setting, like so:

   ONCONNECT * SetLfImpCrOff
   Script SetLfImpCrOff
      SECRET
      FOREVER
         WAIT "\1B[20h" # Wait for a command to turn it on
         IGNORE_ESCAPE  # 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.
Note that this is a hack: the host is just plain wrong in sending the command and then still assuming it is off. instead of working around the problem in IVT, it is better to fix the host.

9.18: 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 ]
SCO-ANSI compatible : [ ]   Keyboard [ ]
Cursor height       : 16 Blinks: [X] <Color>
Local echo          : [ ]
Screen debug mode   : [Off   ]
Packet bounds trace : [ ]

Explicit exit       : [X]
Function keys locked: [ ]
Session switch wraps: [X]

9.18.1: Setup: Bell abuse settings

This dialog allows you to set the BELL_ABUSE parameters.
This is a way to prevent excessive noise when the host sends many BELL characters or a binary file to the screen.

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

9.18.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.19: Mouse setup

This dialog allows you to configure the actions taken by IVT in response to various mouse actions in the sessions screen and history pager.

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) ]
Putty-separators             : [ ]  <View/Configure>
Extend to full line          : [X]
Copy to clipboard in RTF, too: [X]
Use strict CUT mode          : [X]
Paste trailing newline       : [X]
Trim trailing spaces         : [X]
Unicode smart paste          : [X]
Show usage in status         : [X]
XTERM2 same as XTERM         : [ ]
Bracketed paste support      : [X]

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

9.20: 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      YellowZe
--      Default

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

The special 'Default' is used when you use the COLORATTRIBUTE function to code a color to be used in a DIALOG. The default will select either the default dialog foreground or background color, whatever that is.

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.

Session foreground RGB  :   0   0   0     <Modify>
Session background RGB  : 255 255 255     <Modify>
Cursor foreground RGB   :   0   0   0     <Modify>
Cursor background RGB   :   0   255 0     <Modify>
Reverse CUT             : [ ]
Cut foreground RGB      : 255 255 255
Cut background RGB      :   0   0 255     <Modify>
Search foreground RGB   :   0   0   0     <Modify>
Search background RGB   : 255 255   0     <Modify>
Tooltip foreground RGB  :   0   0   0     <Modify>
Tooltip background RGB  : 255 255   0     <Modify>
Marker foreground RGB   :   0   0   0     <Modify>
Marker background RGB   : 255 255   0     <Modify>
Automatic color contrast: [ ]
Xterm 256 color mode    : [X]
Monochrome screen       : [ ]

Help screens            : [White  ] [Blue   ]  Example
Selected hyperlink      : [White  ] [Green  ]  Example
Unselected hyperlink    : [White  ] [Red    ]  Example
Ready indicator         : [Black  ] [Green  ]  Example

Blink Color Foreground  : [ ]   Background  [ ] Default only
Underl. Color Foreground: [ ]   Background  [ ]
Inverse Color Foreground: [ ]   Background  [ ]
Bold Color Foreground   : [ ]   Background  [ ]

<Redefine ANSI colors>
<Redefine attribute colors>

When you want to use colors instead of true underlining, use the checkbox on the "Underline" items (just before the "Modify" button) to enable this feature. Similarly for colors instead of true blinking.

9.21: Font and Keyboard

This panel controls the main look & feel options of IVT, the font, code page and the way the keyboard behaves.
Also, bi-directional text is configured using the button here.
Also, the language of IVT itself can be configured here.

Current font               : Face=Lucida Console,Points=9
Font quality               : Default
Poorman's linedraw         : [ ]
Display zero               : [Normal   ]
Bold style                 : [Auto     ]
Autom font resize          : [ ]
8-bit char display         : [Codepage]   [DEC     ]
8-bit command mode         : [Executed]
Received data character set: [ISO-8859-1:1998 (Latin 1, West Europe) ]
Treat ambiguous CJK as wide: [ ]
Bi-directional text        : <View/Configure>
National replacement       : [US ASCII       ]
IVT language               : [English   ]
Input language             : [Use system default    ]

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

9.22: Keyboard map exceptions

This panel allows you to configure how certain IVT reserved key strokes are handled when the keyboard is in XTERM mode (which conflicts with those IVT reserved keys).
You can reach this setup panel from: Font/Keyboard, Keyboard map exceptions.

[ ] Alt-Cursor switches sessions
[X] Alt-Cursor enters pager
[X] Alt-T toggles sessions
[X] Alt-Digit switches sessions
[X] Ctrl-PgUp/Down creates sessions

9.23: BIDI Settings

This panel allows you to configure the bi-directional text features of IVT.
By default, IVT will handle scripts like Arabic and Hebrew that go from left- to-right on the screen (LTR) instead of right-to-left (RTL).
Various options can be turned on or off, including automatic switching of the Windows keyboard input language when the host sends an explicit RTL command.

Bi-directional text        : [X]
Arabic text shaping        : [X]
Enable ESC%0 and ESC%1     : [X]
Input language for RTL     : [Use system default]
Input language for LTR     : [Use system default]

9.24: Log settings

This dialog controls the creation of log files of session data.
The top of the dialog shows the current logging settings.
Auto logging is a powerful feature of IVT that allows you to configure an automatic log file for all your sessions to a unique name, optionally organized in directories per day, or per host, or any other scheme you can think of. An icon in the status bar allows control over logging.

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.25: Windows setup

This panel allows you to configure many of the look and feel options of IVT, all sorts of screen furniture like status bar, tabs bar, scroll bar and so on can be turned on or off, sized and configured.

Advanced user interface : [X]
Menu bars               : [X]
Vertical scroll bar     : [X]
Status line             : [X]  Borders   : [X]  Middle:  [Clock]
TABs bar                : [View/Configure]
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   ] Name list: [All hosts] Sort: [X]
Import PuTTY hosts      : [X]
Show start-up tips      : [ ]
Window position         : [Last known]
Window coordinates   X  : 10    Y: 20   <Copy current>
Always on top           : [ ]
Confirm URL click       : [ ]
Alt+Enter is full screen: [X]
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.26: 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 the 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.

Not all items below are visible for all printers. There are two different types of printers:

• Real Windows printers
• Printers that are treated as a plain file.

The first type is detected automatically, the second is added using the button below (Add a printer-to-file-).

Printer         : [hp deskjet 930c series (Dflt)  ]
Font            : Facename=Lucida Console,Points=9
Open for        : [Append   ]
Timeout         : [10 ]    <Properties>
Print mode      : [Off     ]
Auto landscape  : [X]
Auto Form Feed  : [X]
Font scaling    : [X]
Black/white only: [ ]
Prompt if exists: [X]
Controller mode : [Raw  ]
print 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 setup 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 all new sessions.
The PRINTER keyword can be used in an IVT.RC file to define the default printer.

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. A click on the icon also closes the printer.

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.27: 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      : [ ]
VT220 key 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         ]
Bracketed paste        : [Auto]
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.28: 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.29: ZMODEM setup

IVT supports file transfer. The easiest way to send a file to the host is to install "rz" on Unix and drop a file on the IVT window: transfer will be automatic. Typing "sz file" on Unix will send the file to your download directory which you can configure here.

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

9.30: 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 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.

See also CANCEL, to protect scripts against being aborted.

9.31: 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.
All 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

See also the IVTFUNCTION with argument "Restore config". That will reset all private session configuration data to the startup defaults, but will leave the history and current screen untouched, will not alter VOLATILE settings and so on. This can be used, for example, to reset all theme settings.

a KILL, termination of the session or its own free will.

9.32: 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.33: Setup: Flush printer

Printers are usually not attached physically to a Windows PC anymore.
Instead, 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.

9.34: Setup: Highlight strings on the session

This screen is reached from either the 'Extra' menu or from the VT220 settings panel in setup.

This setup screen allows you maintain a list of regular expressions that will be highlighted on the session screen when data appears that matches those expressions. There is an overview screen that shows the most important characteristics of the current setup, with an ADD, REMOVE and VIEW buttons and a 'disable all' option.
The ADD and VIEW buttons will bring you to the maintenance panel for a single HIGHLIGHT item that will show all the details of a single entry:

Enabled               : [X]
Current session only  : [ ]
Regular expression    : [IVT is great            ]
Exclude expression    : [                        ]
Description           : [A simple truth          ]
Case insensitive      : [X]
Trim spaces on right  : [ ]
Blink                 : [ ]
Underline             : [ ]
On default colors only: [ ]
Tooltip text          : [Get it now!             ]
Script on button 1    : [                        ]
Script on button 2    : [                        ]
Script on button 3    : [                        ]
Automatic script call : [                        ]
Predefined action     : [None                    ]
Foreground RGB        : [255] [255] [255]  Default: [ ]
Background RGB        : [  0] [  0] [255]  Default: [ ]

9.35: Setup: TABS bar properties

This setup screen is reached from Setup->Windows setup->View/Configure tabs bar. It can be used to configure the appearance of the TABSBAR.

TABs bar enabled              [X]
Tabs in full screen           [X]
Show '+' tab                  [X]
Enable multiple TAB lines     [X]
Close icon per tab            [X]
Confirm close                 [X]
Sequence number               [X]
Tab contains                  [User@Host  ]
Font                          [Facename=System,Points=9]
Extra pixels under tabs       [2   ]
Extensions (color, animation) [X]
Activity indicator            [X]
Tab base color                [240] [240] [240]
Selected tab foreground       [0  ] [0  ] [0  ]
Selected tab background       [255] [255] [255]
Deselected tab foreground     [0  ] [0  ] [0  ]
Deselected tab background     [181] [181] [181]
Error tab foreground          [255] [255] [255]
Error tab background          [255] [0  ] [0  ]

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.
• User name.
  When known, the account used to log on to the session.
• 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 CREATEGROUP. 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). Setting the "Start group when IVT starts up" will even create all the sessions in the group when IVT starts.
• 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 for 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 can 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 CREATEGROUP 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 CREATEGROUP 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 CREATEGROUP 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 thousand 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 of 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.

11.2.5: The multiplex transport protocol

Sorry - not in this version of IVT.

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 ivtmux 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 ivtmux 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 ivtmux 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 IVTMUX terminates, it itself exits. This should cause your underlying session to reappear, and things are back to the way they were before you started IVTMUX (a single session).

There is another problem that arises when you use a modem dialup to a host on which you want to run ivtmux. The binary protocol used by ivtmux 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 ivtmux 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 ivtmux 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 ivtmux when F1 is pressed, which will cause it 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 IVTMUX to be broken (modem that loses a connection, crashing Unix system (rare, but happens :-) or a failure in either IVT or IVTMUX.
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 IVTMUX, IVT will send a termination message to IVTMUX. Normally, this will result in a close of the session, which is acknowledged by IVTMUX, which will result in a normal shutdown of that session.

If IVTMUX 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 original connection is lost.

On the IVTMUX side, all sessions will be killed automatically when the connection to IVT disappears prematurely, and IVTMUX itself will exit.
Normally, this should free up everything, making the session 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 ivtmux.

11.3: The IVTMUX program

This version of IVT does not support 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 ivtmux are explained here. This section explains how to get the ivtmiux program running on your Unix hosts (which is currently the only environment supported by IVTMUX).

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

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

Ports to other flavors of Unix are possible.

Simply typing:

        make ivtmux

to any Unix prompt should result in a 'cc -O ivtmux.c -o ivtmux', which implies a default compile of the source into an optimized '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:

        ivtmux -d

which will create a file called ivtmux.debug with (very) detailed debugging.
Ask for support (at support@ivtssh.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 of 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 tidbit of information that can be transmitted to the host is the type of terminal you 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 sends a user name to the who as whatever you set it to. If the host chooses to believe all that, that is up to the host.

Nowadays, SSH or Kerberized Telnet are much better alternatives.

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 flavors (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_HOSTKEY_ALGS                - Host key algorithms

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 suppressed 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.

Note: Settings come in 2 flavors:

• Global setting.
  This is a configuration option that affects IVT as a whole. A typical example is TABSBAR, which turns the tabs on or off, so every session will have a tab.
  If such a setting is changed, it immediately affects all active sessions.
• Per session setting.
  This is a configuration option that can be changed per session. A typical example is COLORS, which specifies the default background and foreground colors of a session. If such a setting is changed, it usually affects only the current session.

IVT maintains a set of defaults for all per-session settings. These defaults are stored in an IVT.RC configuration file, or the registry. If you have a STARTUP script that changes a per-session setting, it will change those defaults (since there is no session yet at startup time). Any session created in the future will start out with those defaults.
When you use a script (or interactive setup) later, only the current session is affected by the change. When you save a PROFILE after altering a per-session setting, that profile can later be used to create sessions with the same settings.
See also the GLOBAL keyword that can be used to explicitly change the global default of a per-session setting in a script.
See also VOLATILE for special handling of changes to settings.

Every chapter in this manual that describes a configuration option will state the type: Global setting or per-session.

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                IDENTIFY                 SCREENSAVE
ADDRESSBOOK_ONLY         INCLUDE_OPT              SCRIPT_REDEFINE
ADVANCED_MODE            INCLUDE                  SCRIPT
ALT_ENTER                INPUT_LANGUAGE           SCRMODE
ALT_IS_MENU              IPVERSION                SEARCH_CASE_SENSE
ALT_SCREEN               IVT_DIALOGSTATE          SESSION_OVERVIEW
AMBIGUOUS_CJK_WIDE       IVT_LANGUAGE             SESWRAP
ANSWERBACK               KEYBOARD_MAP             SHOWLICENCE
ARABIC_SHAPING           KEYBOARDMOD              SHOWNEWS
AUTOCOMPLETE             KEYMACRO                 SIZE4ALL
AUTOCONTRAST             KEYPADMODE               SIZEFONT
AUTOLANDSCAPE            KRB5_AUTODECRYPT         SMART_PASTE
AUTOLOG_HEADER           KRB5_AUTOENCRYPT         SMOOTH
AUTOLOG                  KRB5_COMERR_DLL          SOFTBLINK
BACKSPACE                KRB5_CRYPTDEBUG          SPEED
BAUD                     KRB5_DLL                 SPLASHTIME
BELL_ABUSE               KRB5_ENDLOGIN            SR_DSR_INPUT
BELL                     KRB5_FORWARD             SR_DSR
BIDI_ESC_RTL             KRB5_LOGINPROG           SR_DTR_CTRL
BIDI_LTR_LANGUAGE        KRB5_REALM               SR_RTS_CTRL
BIDI_RTL_LANGUAGE        KRB5                     SR_WRITETIMEOUT
BIDI_TYPE                LANGUAGE_FILES           SR_XOFF_LIMIT
BIDI                     LAST_POSITION            SR_XON_LIMIT
BIND_ASYNC               LAST_PROTOCOL            SR_XONOFF_IN
BIND_SYNC                LEAVE_COPY_SELECTION     SR_XONOFF_OUT
BIND                     LF_IMP_CR                SSH_ACCEPT
BIT8COMMANDS             LICENCE                  SSH_AGENT
BITMODE                  LICENSE                  SSH_BUG_DERIVEKEY2
BOLD_STYLE               LINKSELCOL               SSH_BUG_HMAC2
BRACKETED_PASTE          LINKUNSELCOL             SSH_BUG_LATE_REPLY
BUGGYBINARY              LOAD                     SSH_BUG_MAXPKT
CAPSBUG                  LOCKTIMER                SSH_BUG_OLDGEX
CAPSLOCK                 MAXTYPEDHOSTS            SSH_BUG_PKSESSID2
CARRIERSTATUS            MENUBAR                  SSH_BUG_REKEY2
CHARSET                  MERCY_MODE               SSH_BUG_RSAPAD
CLICK                    MOUSE_EXTEND_TO_LINE     SSH_CIPHERS
CLOCK                    MOUSE_KEY                SSH_COMPRESSION
CODEPAGE                 MOUSE_KEYLOC             SSH_DATA
CODEPAGEMOD              MOUSE_NOXTERM2           SSH_DEBUG
COLOR_ATTRIBUTE          MOUSE_PUTTY_SELECT       SSH_DES_CBC
COLOR_BLINK              MOUSE_PUTTY_WORDS        SSH_FORWARD
COLOR_CURSOR             MOUSE_SCROLL_FACTOR      SSH_GSSAPI_AUTHENTICATE
COLOR_CUT                MOUSE_SCROLL_PAGESIZE    SSH_GSSAPI_DELEGATE
COLOR_FOR                MOUSE_SELECTION          SSH_GSSAPI_ORDER
COLOR_HELP               MOUSE_USAGE              SSH_GSSAPI_PREFERRED
COLOR_MARKER             MOUSE                    SSH_GSSAPI_REVERSELOOKUP
COLOR_READY              NATIONALITY              SSH_GSSAPI_SYSTEMUSER
COLOR_SEARCH             NUMERICF1F4              SSH_GSSAPI_USERDLL
COLOR_TAB_BASE           NUMLOCK_CORRECTION       SSH_HOSTKEY_ALGS
COLOR_TAB_DESELECT       OBJECT_ID                SSH_HOSTKEYS
COLOR_TAB_ERROR          ONCONNECT                SSH_INTERACT_PWD
COLOR_TAB_SELECT         ONDISCONNECT             SSH_KEEPALIVE
COLOR_TIPS               ONDROPFILES              SSH_KEX_MBYTES
COLOR_UNDERLINE          ONERROR                  SSH_KEX_MINUTES
COLOR_VOLATILE           ONLANGUAGE               SSH_KEX
COLORS                   ONMINIMIZE               SSH_KEYFILE
COLORSCR                 ONRESIZE                 SSH_LOGDATA
COLUMNS                  ONRESTORE                SSH_PAGEANT_ALLOW
CONFIRM_PRINT_SELECT     ONSWITCHFROM             SSH_PAGEANT_AUTO
CONFIRM_PRSCREEN         ONSWITCHTO               SSH_PAGEANT_PATH
CONFIRM_URL_CLICK        ONTABICON                SSH_PSEUDO_TERM
COPY_RICH_TEXT           OPTIONS                  SSH_SENDENV
COPY_STRICT              PACKAGE                  SSH_SHOW_AGENT
COPY_TRIM                PARITY                   SSH_SHOW_DEBUG
COPYSPEED                PASSWORD                 SSH_TERM
CRDIALOG                 PASTE_LAST_NL            SSH_TRIVIAL_AUTH
CREATE                   PASTESPEED               SSH_XAUTH
CREATEGROUP              PR_CONTROLLER            STATBORDERS
CREATEGRP                PR_INDENT                STATMIDDLE
CREATEPROT               PR_LINES                 STATUS
CRYPTPWD                 PRBLACKWHITE             STATUSCLICKS
CTSRTS                   PRECONNECT               STORE_CMD_PARAMS
CURSOR_BLINK             PRINTER_AUTO_FF          STRICT_CHECK
CURSOR_HEIGHT            PRINTER_FONT_SCALE       SUBSTITUTE_FONT
CURSORMODE               PRINTER_FONT             TABSBAR
CUTMODE                  PRINTER_PROMPT           TCP_FLOOD
DBITS                    PRINTER                  TCP_KEEPALIVE
DCE32                    PRIVATE_RC_FILES         TCP_NODELAY
DEBUG_TIMESTAMP          PROFILE                  TELNET_KEEPALIVE
DEBUG                    PROTOCOL                 TELNET_LOCATION
DEFINE_PROFILE           PROXY_DEBUG              TELNET_NEGOTIATE
DODEBUG                  PROXY_DNS                TELNET_NEWENV
DOMAIN                   PROXY_EXCLUDE            TELNET_NUL_AFTER_CR
DOWNLOAD                 PROXY_HOSTNAME           TELNET_TRACE
EMACS                    PROXY_IPV6               TELNET_TSPEED
ESCGET                   PROXY_LOCAL              TELNET_TTYPE
ESCRUN                   PROXY_PASSWORD           TELNET_VAR
EXPLICIT_EXIT            PROXY_SCRIPT             TELNET_XDISP_IP
EXTRA_PANEL_ROOM         PROXY_TELNET_CMD         TELNET_XDISPLAY
F1F4                     PROXY_TIMEOUT            TIMESTAMP_PRSCREEN
F1F5                     PROXY_TYPE               TIPS
FLASH                    PROXY_USER               TITLEBAR
FLOWLOCAL                PRSTATLINE               TOOLTIPS
FLOWREMOTE               PRTIMEOUT                TRANSPARENCY
FONT_DISPLAY_0           PUBLIC                   TUNNEL
FONT_QUALITY             PUTTY_IMPORT             TYPEDHOSTS
FONT                     RECONNECT                UPLOAD
FOREIGN_ALT_NUMERIC      REGISTRY                 VERSION_SERVER
FORWARD_X_DISPLAY        RESOLVE_TRACE            VERTICAL_LINE
FORWARD_X                RESOLVE                  VSCROLL
FULLSCREEN               RETAIN_SESSIONS          VSPACE
GUI_CLOSE                RGB                      WINDOW_POS
GUI_ONTOP                RING                     WINDOW_SIZE
GUI_RESIZE               RLOGIN_LOCALUSER         WRAP
HIDEMOUSE                RLOGIN_REMOTEUSER        WSOCKTIMEOUT
HIGHLIGHT_MODE           RLOGIN_TERM              XAUTH_DELAY
HIGHLIGHT                ROWS                     XTERM_256
HISTORY_TIMEOUT          SAVEGROUPNAME            ZMODEM_AUTO
HISTORY                  SAVEHIST                 ZMODEM_PACKET
HOSTLIST                 SBITS                    
HSPACE                   SCO_ANSI                 

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 on 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 behavior!)

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 behavior 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

Default BITMODE 7
This is a per-session setting.

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 per-session setting.

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] [options] "title" [Script [args]...]
CREATEPROT proto host [group] [options] "title" [Script [args]...]

Options are:

• R=Count
• PROFILE=name
• TABTEXT=string
• NEWWIN
• TITLE=string

Default: None.
This is a global setting.

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

The difference between CREATE and CREATEPROT 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 (like TLN or SSH), 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 NEWWIN option is described here.

The TABTEXT will set an explicit text for the tab of the session.
This overrides any default that would otherwise be chosen.

The "title" will end up in the status bar as the status comment.
For clarity this can also be specified as "TITLE=string", since it may not be immediately obvious what it is for.

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.
See also WAIT_ONCONNECT.

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 CREATEGROUP, 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) and WAIT_ONCONNECT to synchronize such things.

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: CREATEGROUP (Start a logical group of CREATE statements)

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

Default: None.
This is a global setting.
Note: CREATEGRP is a deprecated alias for CREATEGROUP.

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 CREATEGROUP statement itself is mostly just 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 CREATEGROUP 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 CREATEGROUP 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 session that happens to be active when the group is 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 CREATEGROUP 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:

   CREATEGROUP 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 CREATEGROUP 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 CREATEGROUP script is implicitly preceded by a GLOBAL statement.

See also the $IVT_GROUP_NAME and $STATUSTXT variables.
See also the WAIT_ONCONNECT function.

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 CREATEGROUP 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

Default: None.
This is a global setting.

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 is a per-session setting.

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.

12.2.9: DEBUG_TIMESTAMP (show elapsed times for protocol debuggers)

DEBUG_TIMESTAMP
NO_DEBUG_TIMESTAMP

Default: NO_DEBUG_TIMESTAMP
This is a per-session setting.

Various options like SSH_DEBUG, TELNET_DEBUG or PROXY_DEBUG result in various diagnostics when those parts of IVT are used.
Sometimes it is handy to know how much time elapses between the various messages. By turning DEBUG_TIMESTAMP on, every diagnostic will contain a time stamp indicating how many hours, minutes, seconds and milliseconds have passed since the start of the session.
This can be used, for example, for debugging delays in logging in to know which component is causing the delay.

This setting can also be changed from various setup screens (telnet, ssh, etc) and is saved in the registry.

This is an important feature, others are prev/next

12.2.10: DEFINE_PROFILE (Define a setup profile)

See also PROFILE.

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

Default: None.
This is a global setting.

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
   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;

Every one 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 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.11: DODEBUG (Developer debugging)

DODEBUG

Default: off.
This is a global setting.

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.12: DOMAIN (Set domain name for DNS resolves)

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

Default: Dynamically determined name of the current DNS domain.
This is a global setting.

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).
IVT will, at startup, try to find the name of the DNS domain your PC belongs to, and set that as the default DOMAIN value. This value is also saved in the $IVT_NETW_DOMAIN variable.

The CLEAR keyword can be used to clear the list (no explicit or implicit domains are left, so you probably want to set an explicit list soon after, or the user will have to type fully qualified names for all hosts all the time).

This setting can also be specified in this setup screen and is saved in the registry.

See also RESOLVE.
See also the $IVT_NETW_DOMAIN variable.

12.2.13: DOWNLOAD (Specify directory for file transfers)

DOWNLOAD path-expression
UPLOAD   path-expression

Default: The current user's Windows download directory.
This is a global setting.

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.14: ESCGET & ESCRUN (Access files/commands from remote)

ESCGET
NO_ESCGET

ESCRUN
NO_ESCRUN

Default: NO_ESCRUN and NO_ESCGET.
This is a per-session setting.

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.
See also the COMMANDOUTPUT function to run local commands.
See also the SHELLEXECUTE function to run local commands.

This is an important feature, others are prev/next

12.2.15: HISTORY (Number of roll-back screens)

HISTORY number-of-pages [MEMORY|FILE]

Default: 10.
This is a per-session setting.
NOTE: FILE is no longer supported since version 22 of IVT.

Number of screens buffered for history-pager (default 10). IVT maintains a history buffer, 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 copy 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 27 bytes per character, so the default setting takes about 2 MB per session.
This 64-bit build of IVT can handle huge amounts of memory, so you will not be likely to crash IVT by specifying a large amount of scroll back memory.
The 32-bit version of IVT could generate an "out of virtual memory" that way.

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 stop saving scroll back 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!
See also HISTORY_TIMEOUT.

12.2.16: HISTORY_TIMEOUT (Quit pager after inactivity)

HISTORY_TIMEOUT n

Default: HISTORY_TIMEOUT 0 (off)
This is a per-session setting.

This value specifies a number of minutes.

When you use the history pager to view scroll back memory, IVT stops reading data on the session. Other programs will automatically "snap back" to the session when the hosts sends something, which IMHO is bad, as it makes it very hard to view some error message that you just saw scrolling off the screen.
The disadvantage of the IVT approach is that if you leave a session in the scroll back mode, the host will also not receive any response to requests it sends, and this can cause a session to disconnect because a "keep alive" is not answered.
If you experience this, set the HISTORY_TIMEOUT to a couple of minutes. When the scroll back viewer remains activated and unused for the specified number of minutes, it will automatically quit the viewer and return to the session, thus processing queued-up data and - hopefully - prevent a disconnect.

The minimum value for this option is 0 (off). IVT will not timeout.
The maximum is 180 (3 hours).

This setting can also be changed from this setup screen and the current value is saved in the registry.

12.2.17: HOSTLIST (Manage the address book of IVT)

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

Options can be:

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

HOSTLIST adds entries to the address book of IVT. This list of predefined hosts with optional descriptions and various extra information can be accessed by the user by clicking on the icon 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 type 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).

There is an entry on the "Scripts" menu bar 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 various special features are:

COMMENT and COMMENT_ONLY:
   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, they can be used to
   add empty lines and other separators to the list to make it more
   readable.
   The COLLAPSE/EXPAND options can be used to set the default state of all
   sections in the address book.

SHORTNAME:
   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 string can actually be a list of (comma-separated) names, each name is
   recognized as a short name (so you can have multiple aliases for the same
   host). The used value is stored in $HOSTLIST_SHORTNAME.

EXTRA:
   The optional EXTRA=string can be used to describe extra information
   about the host, user or connection. When the entry is selected by
   the user, this EXTRA 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 explicitly use the address book
   to select the host.
   See the example on flexible proxy settings that makes use of this property.

   There are various ways to set the EXTRA information.
   When you use one or more separate EXTRA lines, these are concatenated, and
   every HOSTLIST entry that follows will get a copy of the resulting value.
   An EXTRA clause on a HOSTLIST entry get concatenated, too.
   Example:

     HOSTLIST EXTRA "Part 1\n"
     HOSTLIST EXTRA "Part 2\n"
     HOSTLIST somehost1 someuser1 "This is SOME host1" SSH
     HOSTLIST somehost2 someuser2 "This is SOME host2" EXTRA="Part 3\n" SSH
     HOSTLIST EXTRA CLEAR
     HOSTLIST somehost3 someuser3 "This is SOME host3" SSH
     HOSTLIST somehost4 someuser4 "This is SOME host4" EXTRA="abc\n" SSH

   Here, the first 2 lines set up a default of "Part 1\nPart 2\n". Somehost1
   gets this value. Host somehost2 ends up with a value of:
   "Part 1\nPart 2\nPart 3\n" (combination of the default plus host-specific
   value).
   The CLEAR resets the default to nothing, so somehost3 will not have an
   EXTRA attribute set. Somehost4 ends up with just "abc\n".

PROFILE clause:
   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.

Description:
   This value is made available in the $HOSTLIST_DESCR variable.
   This can be used to set session comments or session title bars.
   The default pwdlearn script does this, actually.
   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. It can be used to describe the host, or provide any sort of
   extra info to the user.
   Note: The description MUST be enclosed in double quotes!

Matching specific users or all users:
   The optional MATCH=ALL and MATCH=USER is a tricky one.
   Using the EXTRA options, you can code all sorts of information about the
   entry which is interpreted by scripts (the PROJECTS feature uses this a
   lot, and see also the context-menu example).
   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 colors 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
   (overrides any default).
   The default setting for this is HOSTLIST MATCH=ALL.
   As a late extra, MATCH=FORCE was added for IVT 27.0.
   That simply means that all of the attributes are used when a match is
   found. A manually typed user name or comment is overridden by the values
   in the address book.

Using protocol specified in entries:
   This feature can be turned on using HOSTLIST USE_PROTOCOL or turned off by
   using HOSTLIST NO_USE_PROTOCOL.
   When on (which it is by default), and the user types a hostname that is
   also listed in the address book, IVT will silently use the protocol
   specified in the entry. So, if your default protocol is SSH, but the
   address book specifies TELNET for that host, typing the hostname will
   result in a TELNET session. When you explicitly click on SSH or select
   some other protocol, that will be used, of course.
   Older versions of IVT did not do this, if you want to restore that
   behavior, use the HOSTLIST NO_USE_PROTOCOL directive in a configuration
   file somewhere. Currently, there is no interactive setup item for this
   setting.

Protocol:
   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).
   It is good practice to always specify the protocol, so things keep working
   properly when you gradually switch from an old protocol (like TELNET) to a
   new one (like SSH).

Address book state:
   The address book has a (+) or (-) icon for every section (which are created
   by using the COMMENT entries). When you have a small address book, it is
   convenient to have all entries immediately visible when the user opens the
   address book. When you have a (very) large list, it is more convenient to
   have everything collapsed, so the user sees only the section headers.
   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.

Markers (manage parts of the address book):
   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. Every time you save the address book contents,
   the previous entries are deleted (using DELMARKED) and the new version
   is loaded (using the READRC function).
   Use SETMARKER without a tag to reset the feature (subsequent HOSTLIST
   entries will not be tagged).

   Note: A session remembers that it was created from a HOSTLIST entry, so when
   you clone a session it can use the exact same entry. That association
   is removed when the host list is (partially) cleared, so a clone-operation
   then tries to find an entry based on the host and user name in the then-
   current address book, but in complex situations this may yield an
   unexpected result.

Clearing the address book:
   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.
   See also the SETMARKER option and DELMARKED to delete marked parts of the
   address book.
   See also this note.

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
...