RSU 1.4 Copyright (C) 1993 Burkhard Daniel & Hans-Georg Michna






                           RSU 1.4





      Remote Software Update for Networks - Documentation










  Copyright (C) 1992, 1993, 1994 Burkhard Daniel & Hans-Georg
                           Michna
                              


                      Table of Contents


         Licensing and Support                    3
         Introduction                             4
         How RSU Works                            5
         Installing RSU                           5
            RSU Server Preparation                5
            Workstation Preparation               6
         The RSU Development Cycle                6
            Steps in the RSU Development Cycle    6
            Prepare an RSU Test Workstation       7
            Create and Test the New Module        7
            Protect Users From Your Tests         7
            Upload the New Module to the RSU Server 8
            Adapt the RSU Program                 8
            Test the New RSU Program              8
            Activate the New RSU Program          8
         Programming RSU                          9
            General Rules                         9
            Sample RSU Program                    9
            Execution Sequence                    10
         Alphabetical List of Commands            10
            General Command Syntax and Semantics  10
            Sections                              11
            Environment Variables                 12
            DOS Commands                          12
            Echo                                  13
            Goto                                  13
            If                                    13
            IniAddLine                            15
            IniChangeLine                         15
            IniCopyLine                           16
            IniCopySection                        16
            IniDeleteLine                         16
            IniDeleteSection                      17
            SynchronizeDir                        17
            SynchronizeDir (Old Syntax)           19
         Brief Command Overview                   21
         
         

                   RSU.DOC [57] 18.10.94
                              


Licensing and Support

RSU including its documentation files is Copyright (C) 1992,
1993, 1994 Burkhard Daniel and Hans-Georg Michna. It is
distributed under the Shareware concept. Its use on isolated
PCs, for example to change settings in WIN.INI through batch
files without the involvement of any network file server is
free, even if the computer is connected to a network. As soon
as RSU is used to copy files from a network file server to a
user's local storage or to copy any parts of files of the
Windows INI type from a network file server, however, its
free use is restricted to a 30 day trial period. After that
the shareware fee has to be paid, if the program is still
used.

Since the combinations of file servers and workstations can
be rather involved, some specifications are in order. If RSU
is used to manipulate shared files on other file servers (for
example several slave servers being updated from one master
server), then each target file server being updated counts
only as one user, as long as no individual workstation files
are modified on it. In other words, user workstations do not
count if RSU is not used to alter their individual files like
CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, PROGMAN.INI,
PROTOCOL.INI or NET.CFG. A special case is that each
workstation has its individual files in a workstation
specific directory on a file server and RSU is used to update
the workstations' individual files on that file server
(example: diskless workstations). In this case, each
workstation should be counted as one user, since RSU is doing
exactly the same amount of work as if the workstation
specific files were on local workstation disks.

The shareware fee for RSU 1.x is US $50.00 or DM 85 (German
Mark) for each group of up to 100 users. In other words, if
the program is used for 1 to 100 users, the fee is US $50.00
or DM 85.00. If it is used for 101 to 200 users, the fee is
US $100.00 or DM 170.00, for 201 to 300 users US $150.00 or
DM 255.00 and so on. The DM (German Mark) price may change in
a future version, if the exchange rate changes considerably.
Future enhanced versions of RSU may be more expensive.

The program contains no technical means to enforce payment
other than noting the requirement on screen when an
unregistered copy of RSU is started.

To pay the fee through CompuServe log on to CompuServe and
enter the command: GO SWREG. Search for the keyword RSU and
register according to the choices you get on screen. Each
single registration copy is good for up to 100 users.

Alternatively, send a check to one of the following
addresses.

USA:   A.C.I. Micro, Mark Jordan, 45 Roland, Winchester, MO
       63021

Europe:A.C.I. Micro, Hans-Georg Michna, Notingerweg 42, D-
       85521 Ottobrunn

       In Europe use a Eurocheque for DM 85 or equivalent 
       per 100 users.

The program may be freely distributed as long as the files
stay together unaltered and packed in one file using an
archiving program like PKZIP, LHA or similar. It is not
allowed to add any other files other than minor additions
that do not exceed the size of the original files. It is not
allowed to distribute RSU as part of another program or
package because we fear that this might look as if RSU may no
longer require its shareware fee payment which it always does
according to the rules outlined above.

Through CompuServe Mail you can reach Hans-Georg Michna
74776,2361 or Burkhard Daniel 100342,2050, if you have
questions, remarks or proposals for future enhancements of
RSU. You can also reach them through Internet mail:
74776.2361@compuserve.com and 100342.2050@compuserve.com

Disclaimer: At the present state of software technology it is
not possible to create error-free software. RSU may contain
errors. Anybody using it should take precautions like
creating safety backups in case a defect causes damage to any
computer or data. The authors of RSU can under no
circumstances be held responsible for any damage.

Microsoft(TM) is a trademark of Microsoft, Inc.


Introduction

RSU (Remote Software Update) is a program that updates the
software on many individual workstation1 PCs connected to a
file server. The file server, when equipped with RSU, becomes
an RSU server.

The RSU program does not run on the RSU server, however. It
runs only on the workstations. The RSU server consists only
of subdirectories and files on the file server.

                          {picture}     
                   Sample RSU installation

The fundamental idea is that all workstation configurations
are stored on the RSU server. RSU then copies the appropriate
modules to each workstation while retaining individual
settings or individual software on the workstations.

The file server used for RSU does not have to be the same
file server that is used for normal work. It is necessary, of
course, that users log in to the RSU server from time to time
to get the topical remote software update.

Since the file server does not usually run DOS a separate RSU
test workstation is needed to develop and test the
configurations. If testing on different hardware is needed
then one RSU test workstation is needed for each hardware
setup. RSU test workstations can be used for other work when
they are not being used for RSU development. Their RSU
related configuration has to be totally reset, however,
before it is used for testing. RSU can

* copy predetermined files from the RSU server to the
 workstations,

* change the contents of subdirectories, even whole
 subdirectory trees, on the workstation PCs such that they
 become equal to their parents on the RSU server, by adding,
 deleting or overwriting files on the target PC,

* exclude certain subdirectories and files from directory
 replication,

* report all changes when synchronizing directories,

* add, change, copy or delete certain sections or certain
 lines in INI files like WIN.INI and SYSTEM.INI,

* copy or delete sections in text files like AUTOEXEC.BAT and
 CONFIG.SYS,

* find out whether each workstation is already up to date and
 skip the updating process,

* detect BIOS signatures of certain hardware and, for
 example, automatically install the appropriate drivers.


How RSU Works

Since the file server or any program running on any
workstation has normally no access to any local disks the
main RSU program has to run on each workstation to work its
magic. The most convenient way to achieve this is to run it
each time any user logs in to the RSU server.2

This can be achieved in different ways on different operating
systems. On a Novell network, for example, a command can be
called up after the system login script finishes, by using
the Novell EXIT "<command>" syntax or by calling it in the
middle of the login script with the # syntax. See the manual
of your network for details. RSU can be called from a DOS
batch file. It has one command line parameter which is the
path of the RSU program file. Example:

    f:\rsu\rsu.exe  f:\rsu\rsu.prg
    
RSU.EXE will execute the RSU program file. Files are
typically copied from the RSU server to the local disk or
modified on the local disk. Instead of the local disk the
individual user storage space may also be on a file server.
In this case each user's private storage should be mapped to
a drive like U:, such that each user sees his private storage
area when he refers to U:.


Installing RSU

RSU Server Preparation

Each file server can be a RSU server. The basic method is to
keep a mirror image of a workstation in a RSU server
directory, for example in F:\RSU\WSIMAGE. There can be
several such directories for several different
configurations. The configurations have to be created and
tested on test workstations, then copied to the RSU server.
In addition the RSU server needs one other directory with
read-only access for RSU.EXE and the RSU program file
(example: RSU.PRG, example of RSU read-only directory:
F:\RSU).

The management of more than one workstation configuration can
easily achieved by creating small signal files on the
different workstations which indicate the configuration type.
The existence of any of these signal files can then be
queried by a simple "If Exist" command. Another method is the
BIOS scan, using RSU's BIOS function. Thus the BIOS version
of the computer or, for example, of the display adapter can
be determined automatically and the appropriate configuration
installed without any manual intervention.


Workstation Preparation

Before installing RSU you have to make sure that all
workstations connected to the RSU server have a valid minimal
installation. The absolute minimum would be an installed DOS
and the minimal network drivers to be able to connect to the
server.

It is recommended that you have an initial workstation setup
procedure to erase all RSU related directories and files from
a workstation and recreate the whole minimal setup from
scratch. This could be done with a batch file like
INSTALL.BAT on the RSU server. This will be very useful for
users if they have somehow destroyed vital files on their
workstation. They will then have a way to get up and running
again if everything else fails and no service person is
available.

It is also conceivable to use RSU to such an extent that each
and every file on the workstation is covered by RSU. This
would have the advantage that every workstation would recover
from any loss or mutilation of files automatically when
logging on to the RSU server. But this will often not be
practicable for performance or other reasons.

RSU will run inside Windows and Windows NT. Note, however,
that Windows or Windows NT may keep certain files open, such
that these files themselves cannot be copied or updated. On
Windows NT, RSU, like many other DOS programs, requires read
and write access to the file CMOS.RAM in the SYSTEM32
directory. RSU, like any DOS or 16 bit Windows program,
cannot use long file names, but it will use the automatic
substitutes generated by Windows NT.


The RSU Development Cycle

Steps in the RSU Development Cycle

The RSU development cycle is the process of developing a new
configuration. Frequently this will just be a small change in
an existing configuration, but it could also be an entirely
new configuration for a new type of workstation, for example.
Development proceeds in these steps:

1.     Prepare a RSU test workstation by making it equivalent
 to the topical RSU update level.

2.     Create and test a new configuration or modify the
 existing one on a test workstation.

3.     Temporarily protect users from your RSU server
 changes.

4.     Upload (copy) the new workstation configuration to the
 RSU server or modify the existing one on the RSU server.

5.     If necessary, adapt the RSU program file (example:
 RSU.PRG).

6.     Test the new RSU setup on a test workstation.

7.     Activate the new setup, such that it gets installed on
 all target workstation PCs (undo step 3).

In many cases this development cycle can be shortened by
skipping certain actions if their effect is minimal or if the
number of workstations is low enough such that some risk can
be taken.

The following sections describe these actions in detail.


Prepare an RSU Test Workstation

First you have to make sure that your RSU test workstation is
equal to a topical workstation elsewhere in the network. If
the test workstation has not been used for anything that
might have altered the files and directories concerned then
it can be used right away. If not, and whenever there are any
doubts, the test workstation should be installed fresh from
the RSU server. It is a good precaution to log in once after
installation and obtain the latest changes from the RSU
server to make sure they are included in the workstation
image on the RSU server.

The RSU update level information can be stored in any file
for each workstation. You only have to edit this file or
touch it such that the file date or time is changed to force
an update.

Start the RSU program, normally by logging in to the RSU
server. The test workstation should automatically be updated
to the topical update level. After the test workstation is up
to the present standard you can now make the desired changes.


Create and Test the New Module

Now you can make the desired modification on the test machine
only. Test thoroughly, since all your users who use that
module will depend on your conscientiousness.


Protect Users From Your Tests

As soon as you touch the RSU server all users who happen to
use the server will receive any modification. Therefore you
have to make sure that this does not happen.

There are several ways to protect users:

1.     Deactivate the whole RSU server until you are done
 with all changes. One way is to rename the RSU program.
 Without it RSU will not be able to do anything. Another is
 to activate a jump over the RSU part of the controlling
 batch file.

2.     Leave the RSU server running and create a second RSU
 server at least for the module you intend to work on. This
 is not quite so difficult as it sounds. It may be necessary
 for bigger changes that require some time to work out.

3.     If you are making a very small change and you are
 absolutely sure that even a mistake can do no harm you may
 risk to work on the hot system. But be careful! Depending
 on the number of workstations and likelihood of a login you
 should be able to make the change within seconds. This
 might be viable if you just want to change a few files, for
 example. Again do not forget to change the date and time of
 the RSU update level file afterwards, so all users get a
 new update when they log in.


Upload the New Module to the RSU Server

After you have tested the new configuration thoroughly on
your test machine you can now copy the modifications to the
RSU server (for example to the F:\RSU\WSIMAGE directory and
its subdirectories). It is useful to have a program that can
detect the difference between files on two drives like the
Norton CommanderT with its "Compare directories" command. In
any case be sure to copy all changes from the test machine to
the RSU server.


Adapt the RSU Program

Now change the RSU program (example: F:\RSU\RSU.PRG) if
necessary. The modified RSU program should be able to copy
all modifications from the RSU server area to any workstation
PC.

If you make changes to files by means of direct manipulation
by the RSU program, for example with IniChangeLine, be sure
to make those changes on the original files on the RSU server
as well, such that users who do an install from scratch also
get them immediately before they receive the next RSU update.


Test the New RSU Program

After the update is entirely in place but not yet activated
you should test it before releasing it to all users. For this
you either need a second test machine or you have to reset
the first one to the previous configuration which is still
standard for all other users.

Then you have to make sure that the new update affects only
the test machine but not yet all the other users. There are
several ways to achieve this. The easiest is to modify the
RSU program file such that only the testing user gets the
update. Example:

    ...
    
    If %USER% <> SUPERVISOR Then
       Goto Not_yet
    End If
    
    rem   Here enter the RSU commands to be tested.
    
    Not_yet:
    
    ...
    
This sample batch file fragment presumes that the network
user name was written into the environment variable USER, for
example with the Novell Netware login script command:

    DOS SET USER="%USER_ID".
    
Check whether the update is correct. You may have to test
each configuration separately if there are several.


Activate the New RSU Program

Finally, after you have convinced yourself that the new
update works correctly, you can release it to all users by
removing any blocking commands you might have inserted. From
that very moment all users who log on will receive the
update.


Programming RSU

General Rules

RSU is an interpreter for the RSU control language which
strongly resembles BASIC and, to some extent, DOS batch
files. The RSU program is the file which controls all RSU
operations. It should reside on the RSU server, for example
as F:\RSU\RSU.PRG. All users should have read-only access to
it.

RSU is started from DOS with either of the following
commands:

    RSU <program file name>
    
    RSU.EXE <program file name>
    
    RSU <program file name> /debug
    
    RSU.EXE <program file name> /debug
    
The /debug switch produces a display of all commands, as they
are executed.

As long as the program is unregistered, it always displays a
shareware registration screen first. Apart from this,
however, the program is fully functional and may be tested
with all functions for 30 days. After that time the program
must be registered for further legal use, although the
program would technically still function properly.


Sample RSU Program

This is an example of an RSU.PRG file:

    rem   RSU.PRG file
    
    rem   First determine whether the user already has the
      latest version:
    
    If c:\rsu\version.txt Equal f:\rsu\version.txt Then
       echo Your workstation has the latest update level.
       Goto Finish
    End If
    
    rem   Let user know what's going to happen to his
      computer:
    
    type f:\rsu\version.txt
    pause
    
    rem   Modifications to WIN.INI:
    
    IniCopySection f:\rsu\wsimage\win31\win.ini
      c:\win31\win.ini [fonts]
    IniCopySection f:\rsu\wsimage\win31\win.ini
      c:\win31\win.ini [devices]
    IniDeleteSection c:\win31\win.ini [ObscureOldProgram]
    IniCopyLine f:\rsu\wsimage\win31\win.ini
      c:\win31\win.ini [windows] load
    IniDeleteLine c:\win31\win.ini [fonts] Swiss=
    IniChangeLine c:\win31\win.ini [mail] mailbox=%USER%
    
    rem   Modifications to SYSTEM.INI:
    
    IniAddLine c:\win31\system.ini [display] svgamode=98
    
    rem   Synchronization of user files:
    
    SynchronizeDir
      From f:\rsu\wsimage\win31
      To   c:\win31Add
    End SynchronizeDir
    
    SynchronizeDir
      From f:\rsu\wsimage\util
      To   c:\util
      Add
      Overwrite
      Delete
      Subdirectories
    End SynchronizeDir
    
    rem   Users with HappyVGA adapters get a new driver and
      support
    rem   utilities. This requires that such users have a
      signal file
    rem   c:\rsu\happyvga.sig:
    
    If Exist c:\rsu\happyvga.sig Then
       SynchronizeDir
         From f:\rsu\wsimage\happyvga
         To   c:\happyvga
         Add
         Overwrite
         Delete
         Subdirectories
       End SynchronizeDir
    End If
    
    rem   Now install version text file to make sure that
      this
    rem   user doesn't get the same update again:
    
    copy f:\rsu\version.txt c:\rsu
    
    Finish:
    
    rem   End Of File
    
    
Execution Sequence

RSU is a pure and simple interpreter. This has consequences
especially when using the Goto command in connection with If,
Then, Else constructs. RSU takes these commands exactly in
the sequence they are processed. This means that a Goto jump
into an If structure can cause unexpected results if the
programmer isn't aware of the actual processing sequence.
Therefore it is not advisable to jump into an If command.
Jumping out of an If command doesn't hurt. The If construct
is simply never completed. But if it is done many times, for
example in a loop, it will eventually cause a memory
overflow. You should therefore try to use the Goto command
sparingly and prudently. Ghastly mistakes can happen if the
interpreter encounters, for example, an Else command after
jumping out of an If construct, because the interpreter would
assume that the Else belongs to the last encountered If
command.


Alphabetical List of Commands

General Command Syntax and Semantics

All control files are text files in which each line is
followed by a carriage return/line feed pair (13dec and
10dec).

Spaces and tab characters in the beginning of any line are
totally ignored. In effect it is as if those characters were
removed before executing the RSU.PRG program.

Lines beginning with "REM  " or ";" (a semicolon) are treated
as comments and not otherwise executed.

Upper and lower case are functionally equivalent. However,
the case is retained when information is forwarded into
another file.

Command parameters are separated by spaces, with the
exception of section headers (section name in brackets) and
INI lines after a section header. If a parameter itself
contains one or more spaces, it has to be enclosed in double
quotes (character no. 34 in the ASCII/ANSI alphabet), so it
is not mistaken for several separate parameters. If a quote
character itself is to be included, two adjacent quote
characters have to be written, but this is possible only
within another pair of quotes.

Examples:

    If Bios(C000-C080) = "ATI GRAPHICS" Then
       ...
    End If
    
    If %COMPUTER_TYPE% = "Label ""Taiwan""" Then
       ...
    End If
    
The second example compares the environment variable
COMPUTER_TYPE with the following text, including the two
quotes:   Label "Taiwan"

If the first word in any line is a valid RSU command then it
is executed. If not the line is deemed to be a DOS command
and is forwarded to the DOS command processor. Note, however,
that not every DOS command can be used. For example, the DOS
command SET has no effect because it is running under a
secondary command processor that has no access to the primary
environment.

In the syntax definitions below, a few special characters and
words are used that have a special meaning.

A word enclosed in angle brackets is a placeholder for a user
defined, variable entry:

    < >
    
The following placeholder stands for any valid RSU command:

    <command>
    
An ellipsis stands for "more of the same":

    ...
    
Braces and vertical bars are used to define a user choice of
one out of several units. Only one can and must be chosen:

    { <choice 1> | <choice 2> | <choice 3> }
    
    
Sections

Several commands work on sections in .INI files. A section is
recognized by its header. It ends before the next section
header. A section header consists of a section name in
brackets. Examples:

    [windows]
    
    [HPPCL5A,LPT1:]
    
    [Microsoft Word]
    
The section header must begin in cloumn 1, i.e. in the
leftmost position of a line. Technically spoken, the opening
bracket must immediately follow the carriage return, line
feed pair that ends the previous line, or it must be the
first byte of the whole file. All lines following the section
header belong to this section until another section header
follows.

Note that section headers can contain spaces. RSU still
recognizes the section header by the enclosing brackets. You
don't need double quotes when referring to a section header
in an RSU command.

To facilitate manipulation of sections in files like
AUTOEXEC.BAT or CONFIG.SYS, a second, alternative form of
section header is also recognized, which consists of the
abbreviation REM in upper, lower or mixed case, followed by
exactly one space, followed by a section header as described
above. The R in REM must be in the leftmost column. Examples:

    REM [drives]

    Rem [NETWORK DRIVERS]

    rem [User Specific Settings]
    
Warning:                                           Never use
       the alternative REM syntax inside an RSU command
       file. All RSU commands work without containing the
       word REM, even if the target files contain it.

Hint:  If you want to turn such REM lines into real comments
       rather than RSU section headers, insert at least a
       second space or any other characters between REM and
       [.

Hint:  While all RSU commands will recognize and accept this
       alternative syntax and work on it and in the sections
       thus designated, only the command IniCopySection can
       put such a section header into a file.


Environment Variables

Environment variables can be inserted in any command with the
syntax:

    %<environment variable>%
    
Example:
    IniChangeLine C:\WIN31\WIN.INI [mail] mailbox=%USER%
    
This example will take the name from the USER= entry in the
environment and substitute it for %USER% before executing the
IniChangeLine command. For example, if the environment
contains an entry reading:

    USER=DANIEL
    
then the command above will be changed to:

    IniChangeLine C:\WIN31\WIN.INI [mail] mailbox=DANIEL
    
which is useful for example to save users the separate
logging in to Microsoft Mail.

The substitution happens before any quote characters are
processed, i.e. environment variables can be used inside
quotes. To use a percent character (%) for other purposes,
you have to write two adjacent percent characters (%%).
However, RSU cannot use environment variable names that
contain percent characters. You can use the double-percent
feature only outside environment variable names.

Environment variable names may contain spaces (example: %DEPT
NAME%). It is not necessary to enclose them in quotes because
of these spaces-RSU already recognizes the percent signs and
processes them before spaces are considered. But superfluous
quotes outside the variable name don't do any harm either.

Hint:  Novell Netware 3.11 can place essential system
       information entries into the environment with the SET
       <variable>="<text>" syntax of its login scripts.
       Example of a command in a Netware login script:

            SET USER="%USER_ID"
            
            
DOS Commands

Any command found in an RSU program file that is not a valid
RSU command is deemed to be a DOS command. A secondary
command processor (COMMAND.COM) is loaded and the command
forwarded to it and executed.

There is no error checking and no logging with DOS commands,
so be careful to test and use them properly.


Echo

This command simply echoes some text on the screen. It works
like the DOS command with the same name. It was incorporated
only to increase speed and to avoid unnecessary empty lines
on screen.

Syntax:
    Echo <text>
    
Example:
    Echo RSU is now installing new video drivers...
    
    
Goto

This command continues execution of the RSU program file at
the point after the label. The label can be anywhere else in
the program file but has to be in its own line, i.e. no other
command can follow in the line that contains the label.

A label must be at least two characters long, not counting
the colon. The reason for this is that c: means change to
drive C:, rather than a label C. Labels may contain letters,
digits and the underscore _. They may not contain spaces,
umlauts or any other special characters.

Syntax:
    Goto <label>
    ...
    <label>:
    
Example:
    Goto Finish
    ...
    Finish:
    
    
If

This command executes the other commands embedded between If
and End If only if the condition after the If is met.

In addition, an Else clause can be inserted. The commands
after the Else and before the final End If are only executed
if the condition after the If is not met.

The comparison operators  <  <=  =  >=  >  <>  determine
whether the character string to the left is less than, less
or equal, equal, greater or equal, greater than, unequal to
the string on the right of the operator, ignoring upper or
lower case. Thus  a  =  A  would count as true.

The operator "Exist" followed by a filename determines
whether the following file exists, similar to the equivalent
DOS batch command.

The operator "Equal" between two filenames determines whether
the two files are exactly equal in size, date and time.

A special form is the BIOS search. This allows to search a
certain range of memory addresses within the first megabyte
for a word. The syntax of the If clause is:

    If Bios(<hexadr>-<hexadr>) = <text> Then
    
Example:
    If Bios(F000-F100) = AMI Then
       Echo This computer has an AMI Bios.
    End If
    
The BIOS search allows only the equal operator = and cannot
be written with the search word on the left side of the equal
sign. The search is case insensitive. Note also that you have
to use double quotes if you want to search for more than one
word, because the present syntax uses the space as a
delimiter if not enclosed in double quotes. You may write:

    If Bios(C000-C080) = "ati graphics ultra" Then
       Echo ATi Graphics Ultra found.
    End If
    
Note that after the If and between any other elements on the
line one or more spaces are needed. Thus it would be wrong to
write:

    If %USER%=DANIEL Then
    
The correct form is:

    If %USER% = DANIEL Then
    
If any of the variables contains spaces, it must be enclosed
in double quotes. Apart from that, an If command with a
comparison operator must have exactly 5 words in the line.

Syntax (4 different forms):
    
    If <condition> Then
       <command>
       ...
    End If
    
    If <condition> Then
       <command>
       ...
    Else
       <command>
       ...
    End If
    
    If Not <condition> Then
       <command>
       ...
    End If
    
    If Not <condition> Then
       <command>
       ...
    Else
       <command>
       ...
    End If
    
    <condition> = { <text 1> <comparison operator> <text 2>
      | Exist <filename> | <filename 1> Equal <filename 2> }
      | Bios(<hexadr>-<hexadr>) = <text>

    <comparison operator> = { < | <= | = | >= | > | <> }

    <hexadr> = 0 .. FFFF
    
Examples:
    If Not %USER% = SUPERVISOR Then
       Goto Finish
    End If
    ...
    Finish:
    
    If Not c:\rsu\version.txt Equal f:\rsu\version.txt Then
       copy f:\rsu\version.txt c:\rsu
       ...
    Else
       echo You already have the latest version. No update
      necessary.
    EndIf
    
    If Not Exist c:\windows\win.ini Then
       echo Your disk is not properly installed. Please
      follow
       echo the instructions to perform the base
      installation,
       echo then log on again.
       Goto Get_Out
    End If
    
    If Bios(F000-F200) = Dell Then
       c:\dell\keyb.com gr,,c:\dos\keyboard.sys
    Else
       c:\dos\keyb.com gr,,c:\dos\keyboard.sys
    End If
    
Hint:  End If can be written with or without a space between
       End and If, i.e. either "End  If" or "EndIf". The
       preferred form is: "End  If".

Warning:                                           Between
       each of two keywords, operators and operands one
       space is required.

Warning:                                           Do not use
       the Goto command to jump into an If - End If
       structure. Do not use the Goto command to jump out of
       an If - End If structure many times, for example in a
       loop with more than a few repetitions.


IniAddLine

This command is used to add a line where several lines have
the same variable name, like for example the device= lines in
SYSTEM.INI. It appends one further line to the section. If
the section does not exist it is newly created and appended
to the .INI file first.

The only exception occurs if the exact line, variable name
and text, exists in the file already. In this particular case
the command has no effect. In other words, the command does
not produce exact duplicates of whole lines like:

    device=VSHARE.386
    device=VSHARE.386
    
Syntax:
    IniAddLine <ini file> [<section name>] <variable
      name>=<text>
    
Example:
    IniAddLine C:\WIN31\SYSTEM.INI 386Enh device=VSHARE.386
    
    
IniChangeLine

This command changes the text after the equals sign (=) in a
certain section and a certain line in an .INI file. If the
section does not exist it is newly created and appended to
the .INI file first. If the line does not exist it is newly
created and appended at the end of the section. If several
lines with the same variable name exist in the section then
this command is probably not appropriate and should not be
used since it would change only one of the lines.

Syntax:
    IniChangeLine <ini file> [<section name>]
      <variable>=<text>
    
Example:
    IniChangeLine C:\WIN31\WIN.INI [windows]
      load=NWPOPUP.EXE
    
Note that there is presently no command to change only part
of a line. If something like this is desired one possible
workaround is to use EDLIN in batch mode.


IniCopyLine

This command finds a certain line within a section in an .INI
file and copies it into another .INI file. If a line with the
same variable name to the left of the equals sign (=) already
exists it is replaced with the new line. If several lines
with the same variable name exist in the section then this
command is probably not appropriate. It will work on the
first occurrence of the variable. If the section does not
exist in the target .INI file, it is newly created and
appended to the .INI file first.

Syntax:
    IniCopyLine <source ini file> <target ini file>
      [<section name>] <variable>
    
Examples:
    IniCopyLine F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [windows] load
    IniCopyLine F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [windows] load=
    
Both example lines do the same thing. Each one would search
the file F:\RSU\WSIMAGE\WIN31\WIN.INI for the section
[windows]. Within the section it would locate the line
beginning with load= and copy it into the line with the same
section and variable name in the file C:\WIN31\WIN.INI.


IniCopySection

This command works similar to the previous one but copies a
whole section. If a section with the same name already exists
in the target file, it is deleted and the new section copied
and inserted in its place. IniCopySection also inserts an
empty line before and after the section if there was none, to
make the file easier to read and conform with the usual
practice in Windows .INI files.

Syntax:
    IniCopySection <source ini file> <target ini file>
      [<section name>]
    
Example:
    IniCopySection F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [HPPCL5A,LPT1:]
    
This example would copy the whole section [HPPCL5A,LPT1:]
from F:\RSU\WSIMAGE\WIN31\WIN.INI to C:\WIN31\WIN.INI. If
there was a section with that name before it will be
overwritten and all information lost entirely. If the
previous section contained more or other lines than the new
those old lines will be lost.


IniDeleteLine

This command deletes a line in an .INI file.

Syntax:
    IniDeleteLine <ini file> [<section name>] <variable>
    IniDeleteLine <ini file> [<section name>] <variable>=
    IniDeleteLine <ini file> [<section name>]
      <variable>=<value>
    
Examples:
    IniDeleteLine C:\WIN31\WIN.INI [mail] Polling
    IniDeleteLine C:\WIN31\WIN.INI [mail] Polling=
    IniDeleteLine C:\WIN31\SYSTEM.INI [386Enh]
      device=comm.drv
    
This example will search C:\WIN31\WIN.INI for the section
[mail] and in this section for the line beginning with
Polling=. This line will be deleted from WIN.INI. It will
then search C:\WIN31\SYSTEM.INI, section [386Enh] and delete
the line device=comm.drv. Note that, with this syntax, other
device= lines are not affected. This makes it possible to
change particular lines when the same variable occurs more
than once, as usual with the device= lines in SYSTEM.INI.


IniDeleteSection

Syntax:
    IniDeleteSection <ini file> [<section name>]
    
Example:
    IniDeleteSection C:\WIN31\WIN.INI [Microsoft Word]
    
This example will search C:\WIN31\WIN.INI for the section
[Microsoft Word]. The entire section will be deleted from
WIN.INI.


SynchronizeDir

Makes the target directory equal to the source directory
including all files, including files that have a read-only,
hidden or system attribute.

SynchronizeDir handles all files regardless of their
attributes. Attributes are copied with each file only if the
Preserve subcommand is used. Without it the archive attribute
is set and all other attributes are reset in the target file.

SynchronizeDir is a multi-line command and requires several
subcommands to control its operation. Each subcommand has to
be in one line. Empty lines and comment lines can also be
used freely. The following subcommands can be used, and at
least To and From and one other of them has to be used,
otherwise SynchronizeDir will not do anything:

From   Write the source directory after this subcommand.

To                                                Write the
       target directory after this subcommand.

Delete Delete files from the target directory if they don't
       exist in the source directory.

Add    Add files to the target directory if they are not
       there already.

Overwrite                                          Overwrite
       files in the target directory if they also exist in
       the source directory but are different (have
       different size, date or time). This subcommand may
       not be used together with the Conflict subcommand.

Conflict                                           Conflict
       management. This subcommand may not be used together
       with the Overwrite subcommand. If a file name exists
       in both source and target directories but with
       different size, date or time, then this is considered
       a conflict and the following actions are taken:

       1.   Both files are put into the target directory and
          the older one gets a new name like !SYNnnnn.xxx
          where nnnn is a number between 0001 and 9999 and
          xxx is the original extension of the file.
       
       2.   A line is appended to the file !SYN0000.TXT in
          the target directory containing the date, time and
          conflicting file information separated by
          semicolons (;), ready for import into a conflict
          database.
    
       One possible purpose of this function is to allow
       users with portable PCs to copy their network user
       directories home with them and later reconciliate
       their local user directories with those on the
       network if both can have changed.
    
Subdirectories                                     Process
       subdirectories. All subdirectories of the directory
       to be synchronized are also processed.

Preserve                                           Preserve
       attributes. With this subcommand the hidden, system
       and read-only attributes are copied from each source
       file to each destination file. Without this
       subcommand, these attributes are reset in the target
       file.

       Warning:   The Preserve subcommand affects only files
               that are copied for other reasons. It does
               not mean that existing equal files will now
               get their attributes copied if these are
               different. Keep in mind that the attributes
               are not used to determine whether two files
               are equal.
       
Report Write the report file name (complete with path, if
       desired) after this subcommand. Report all changes to
       a report text file. If the report text file already
       exists, the new records/lines are appended.

       The report text file consists of one line for each
       reported file, followed by one carriage return and
       one line feed character. Each line contains the
       following 9 fields, separated by tab characters
       (character no. 9 in the ASCII/ANSI alphabet):
       
       1.   Transaction date in the format: YYYY-MM-DD
          Example: 1994-07-21
       
       2.   Transaction time in the 24 h format: HH:MM:SS
          Example: 23:59:30
       
       3.   Operation: ADD, DELETE, OV-ADD, OV-DEL, REN-ADD,
          REN-DEL. Since each line reports only one file,
          overwrite and rename operations (which work on two
          files) are reported in two lines, as if the file
          were first deleted, then added. The first contains
          OV-DEL or REN-DEL and reports the disappearing
          file. The next contains OV-ADD or REN-ADD and
          reports the new file.
       
       4.   File or directory: FILE, DIR
       
       5.   Path and file name (if file). Examples:
          C:\SUBDIR\FILE.EXT, C:\SUBDIR
       
       6.   File/dir date in the format: YYYY-MM-DD
          Example: 1994-06-15
       
       7.   File/dir time in the 24 h format: HH:MM:SS
          Example: 13:35:50
       
       8.   File size in bytes (empty for directories).
          Example: 1735024
       
       9.   File attributes in the format: HSRA with minus
          signs in the place of attributes that are not set.
          Example for a file with read-only and archive
          attributes, but no hidden or system attributes: -
          - RA
       
ReportOnly                                         Requires
       the presence of the Report subcommand (see above). No
       changes are actually made to directories or files.
       Only the report file is written (appended) as if the
       changes had been made. This can be used for testing
       or if the report file is evaluated by other means.

ExcludeDir                                         Protect
       this directory and all its subdirectories from
       synchronization, i.e. do not read, compare, copy,
       change or delete it and do not synchronize it with
       anything. The directory can be given with full path
       and even the drive specified. If it is given without
       a full path, i.e. with neither a drive designator nor
       a backslash (\) at the beginning, then all
       directories with this name and all their
       subdirectories are excluded from synchronization if
       several occur within the directory tree. The
       ExcludeDir subcommand can occur several times with
       different subdirectories. It is useful only when the
       Subdirectories subcommand is also present.

ExcludeFile                                        Protect
       this file from synchronization, i.e. do not read,
       compare, copy, change or delete it and do not
       synchronize it with anything. The file can be given
       with full path and even with the drive specified. If
       it is given without a full path, i.e. with neither a
       drive designator nor a backslash (\) at the
       beginning, then all files with this name are excluded
       from synchronization if several occur within the
       directory, or within the whole directory tree. The
       file name can contain the wildcard characters * and ?
       which have the same function as in DOS. The
       ExcludeFile subcommand can occur several times with
       different files.

End SynchronizeDir   This ends the complete SynchronizeDir
       command. Exactly one space has to be between "End"
       and "SynchronizeDir". This subcommand is always
       required after all others.

Warning:
       SynchronizeDir will overwrite or erase files with any
       attributes in the target directory and, with the
       Subdirectories subcommand, any of its subdirectories,
       even if they are read-only, hidden or system files.

Syntax:
    SynchronizeDir
      From <source directory>
      To <target directory>
      [Delete]
      [Add]
      [{ Overwrite | Conflict }]
      [Subdirectories]
      [Preserve]
      [Report <report text file path and name>
      [ReportOnly]]
      [ExcludeDir <directory>]
      ...
      [ExcludeFile <file name with or without path and * or
      ? characters>]
      ...
    End SynchronizeDir
    
Examples:
    SynchronizeDir
      From F:\RSU\WSIMAGE\U
      To C:\U
      Delete
      Overwrite
      Add
      Subdirectories
      ExcludeDir F:\RSU\WSIMAGE\U\ADMIN
      ExcludeFile *.BAK
      Report C:\SETUP\SYNCREP.TXT
      Preserve
    End SynchronizeDir
    
    SynchronizeDir
      From F:\RSU\WSIMAGE\DOS
      To C:\DOS
      Overwrite
      Add
    End SynchronizeDir
    
The first example would make the directory C:\U and all of
its subdirectories exactly equal to the directory
F:\RSU\WSIMAGE\U and all of its subdirectories, except for
the directory F:\RSU\WSIMAGE\U\ADMIN, which is entirely
skipped. If a target directory C:\U\ADMIN exists, it is not
touched either. All files with the extension .BAK are
skipped. If files with the extension .BAK exist in the target
directory, they also remain untouched. If files are copied,
their file attributes are copied with them. A report text
file C:\SETUP\SYNCREP.TXT is written, containing a list of
all file changes.

The second would overwrite any files in C:\DOS that are
different from their namesakes in F:\RSU\WSIMAGE\DOS. It
would also add files that are missing in C:\DOS, but it would
not delete or otherwise touch any additional files the user
may have added to his DOS directory. It would also not touch
any subdirectories of C:\DOS.


SynchronizeDir (Old Syntax)

This one-line version of the SynchronizeDir command is
retained only for compatibility purposes and will be dropped
from a future version of RSU. Please don't use it any more.

Note that the newer exclude subcommands and the ReportOnly
subcommand are not available in this old syntax.

Makes the target directory equal to the source directory
including all files, including files that have a read-only,
hidden or system attribute.

SynchronizeDir handles all files regardless of their
attributes. Attributes are copied with each file only if the
/P switch is used. Without that switch the archive attribute
is set and all other attributes are reset in the target file.

The SynchronizeDir command requires switches to control its
operation. The following switches can be used, and at least
one of them has to be used, otherwise SyncDir will not do
anything:

/D                                                Delete
       files from the target directory if they don't exist
       in the source directory.

/A                                                Add files
       to the target directory if they are not there
       already.

/O                                                Overwrite
       files in the target directory if they also exist in
       the source directory but are different (have
       different size, date or time). This switch may not be
       used together with the /C switch.

/C                                                Conflict
       management. This switch may not be used together with
       the /O switch. If a file name exists in both source
       and target directories but with different size, date
       or time, then this is considered a conflict and the
       following actions are taken:

       1.   Both files are put into the target directory and
          the older one gets a new name like !SYNnnnn.xxx
          where nnnn is a number between 0001 and 9999 and
          xxx is the original extension of the file.
       
       2.   A line is appended to the file !SYN0000.TXT in
          the target directory containing the date, time and
          conflicting file information separated by
          semicolons (;), ready for import into a conflict
          database.
       
      One possible purpose of this function is to allow
       users with portable PCs to copy their network user
       directories home with them and later reconciliate
       their local user directories with those on the
       network if both can have changed.
    
/S                                                Process
       subdirectories. All subdirectories of the directory
       to be synchronized are also processed.

/R                                                Report all
       changes to a report text file. The filename
       (including path if desired) has to follow the /R
       switch either with or without an intervening space.
       If the report text file already exists, the new
       records/lines are appended.

       The report text file consists of one line for each
       reported file, followed by one carriage return and
       one line feed character. Each line contains the
       following 9 fields, separated by tab characters
       (character no. 9 in the ASCII/ANSI alphabet):
       
       1.   Transaction date in the format: YYYY-MM-DD
          Example: 1994-07-21
       
       2.   Transaction time in the 24 h format: HH:MM:SS
          Example: 23:59:30
       
       3.   Operation: ADD, DELETE, OV-ADD, OV-DEL, REN-ADD,
          REN-DEL. Since each line reports only one file,
          overwrite and rename operations (which work on two
          files) are reported in two lines, as if the file
          were first deleted, then added. The first contains
          OV-DEL or REN-DEL and reports the disappearing
          file. The next contains OV-ADD or REN-ADD and
          reports the new file.
       
       4.   File or directory: FILE, DIR
       
       5.   Path and file name (if file). Examples:
          C:\SUBDIR\FILE.EXT, C:\SUBDIR
       
       6.   File/dir date in the format: YYYY-MM-DD
          Example: 1994-06-15
       
       7.   File/dir time in the 24 h format: HH:MM:SS
          Example: 13:35:50
       
       8.   File size in bytes (empty for directories).
          Example: 1735024
       
       9.   File attributes in the format: HSRA with minus
          signs in the place of attributes that are not set.
          Example for a file with read-only and archive
          attributes, but no hidden or system attributes: -
          - RA
       
/P                                                Preserve
       attributes. With this switch the hidden, system and
       read-only attributes are copied from each source file
       to each destination file. Without this switch, these
       attributes are reset in the target file.

Warning:                                           The /P
       parameter affects only files that are copied for
       other reasons. It does not mean that existing equal
       files will now get their attributes copied if these
       are different. Keep in mind that the attributes are
       not used to determine whether two files are equal.

Warning:
       SynchronizeDir will overwrite or erase files with any
       attributes in the target directory and, with the /S
       switch, any of its subdirectories, even if they are
       read-only, hidden or system files.

Syntax:
    SynchronizeDir <source directory> <target directory>
      [/D] [< /O | /C >] [/A] [/S] [/R <report text file
      path and name>] [/P]
    
Examples:
    SynchronizeDir F:\RSU\WSIMAGE\U C:\U /D /O /A /S /R
      C:\SETUP\SYNCREP.TXT /P
    SynchronizeDir F:\RSU\WSIMAGE\DOS C:\DOS /O /A
    
The first line would make the directory C:\U and all of its
subdirectories exactly equal to the directory
F:\RSU\WSIMAGE\U and all of its subdirectories. If files are
copied, their file attributes are copied with them. A report
text file C:\SETUP\SYNCREP.TXT containing all file changes is
written.

The second would overwrite any files in C:\DOS that are
different from their namesakes in F:\RSU\WSIMAGE\DOS. It
would also add files that are missing in C:\DOS, but it would
not delete or otherwise touch any additional files the user
may have added to his DOS directory. It would also not touch
any subdirectories of C:\DOS.


Brief Command Overview

In the following text each group of syntax lines is followed
by one or more example lines which are indented.

RSU <program file name>
RSU.EXE <program file name>
RSU <program file name> /debug
RSU.EXE <program file name> /debug
    f:
    cd \rsu
    rsu rsu.prg

Echo <text>
    Echo RSU is now installing new video drivers...

Goto <label>
    Goto Finish

<label>:
    Finish:
    
If [Not] <condition> Then
   <command>
   ...
[Else
   <command>
   ...]
End If

If [Not] <condition> Then
   <command>
   ...
[Else
   <command>
   ...]
EndIf

<condition> = { <text 1> <comparison operator> <text 2> |
    Exist <filename> | <filename 1> Equal <filename 2> } |
    Bios(<hexadr>-<hexadr>) = <text>

<comparison operator> = { < | <= | = | >= | > | <> }

<hexadr> = 0 .. FFFF

    If Bios(F000-F100) = AMI Then
       Echo This computer has an AMI Bios.
    End If
    
    If Not %USER% = SUPERVISOR Then
       Goto Finish
    End If
    ...
    Finish:
    
    (The example above also shows how to insert an
    environment variable.)

IniAddLine <ini file> [<section name>] <variable name>=<text>
    IniAddLine C:\WIN31\SYSTEM.INI 386Enh device=VSHARE.386
    IniAddLine C:\WIN31\SYSTEM.INI 386Enh device=NETWARE.386
    
IniChangeLine <ini file> [<section name>] <variable>=<text>
    IniChangeLine C:\WIN31\WIN.INI [windows]
      load=NWPOPUP.EXE
    IniChangeLine C:\WIN31\WIN.INI [mail] mailbox=%USER%
    
    (The second example above also shows how to insert an
    environment variable.)

IniCopyLine <source ini file> <target ini file> [<section
    name>] <variable>
    IniCopyLine F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [windows] load
    IniCopyLine F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [windows] load=

IniCopySection <source ini file> <target ini file> [<section
    name>]
    IniCopySection F:\RSU\WSIMAGE\WIN31\WIN.INI
      C:\WIN31\WIN.INI [HPPCL5A,LPT1:]

IniDeleteLine <ini file> [<section name>] <variable>
IniDeleteLine <ini file> [<section name>] <variable>=
IniDeleteLine <ini file> [<section name>] <variable>=<value>
    IniDeleteLine C:\WIN31\WIN.INI [mail] Polling
    IniDeleteLine C:\WIN31\WIN.INI [mail] Polling=
    IniDeleteLine C:\WIN31\SYSTEM.INI [386Enh]
      device=comm.drv

IniDeleteSection <ini file> [<section name>]
    IniDeleteSection C:\WIN31\WIN.INI [Microsoft Word]

SynchronizeDir
  From <source directory>
  To <target directory>
  [Delete]
  [{ Overwrite | Conflict }]
  [Add]
  [Subdirectories]
  [Report <report text file path and name>]
  [Preserve]
End SynchronizeDir
    SynchronizeDir
      From F:\RSU\WSIMAGE\U
      To C:\U
      Delete
      Overwrite
      Add
      Subdirectories
      ExcludeDir F:\RSU\WSIMAGE\U\ADMIN
      ExcludeFile *.BAK
      Report C:\SETUP\SYNCREP.TXT
      Preserve
    End SynchronizeDir
    
    SynchronizeDir
      From F:\RSU\WSIMAGE\DOS
      To C:\DOS
      Overwrite
      Add
    End SynchronizeDir
    
Other features:

       %<environment variable>% is replaced by the contents
       of the environment variable.
       
       %% is replaced by %
       
       "<any text containing spaces>" is taken as one
       parameter.
       
       "" is replaced by "

___________________________
1 The term "workstation" is used here for all user PC's
connected to the network, using DOS, not for engineering
workstations running Unix or the like.

2 Another method is to run it each time the workstation is
started, from the AUTOEXEC.BAT file. Since users have few
rights on the file server at that time it would be necessary
to adjust those rights such that all users have reading
rights to all RSU data without being logged in. This may or
may not be possible on different network operating systems.
