Winsock RSHD/NT (Remote Shell Daemon) is a service for Windows NT that services the standard rsh and rcp commands. It accepts requests for program execution from the rsh command and file transfers from the rcp command from other hosts on the network via TCP/IP and executes them on the system running Winsock RSHD/NT. It runs under Microsoft Windows NT 3.51 or higher.

Winsock RSHD/NT is similar to the Unix rshd, but provides some special functionality for the Windows environment, such as:

• Capturing of standard output/standard error output of NT Console and MS-DOS programs

• Sending keystrokes to GUI programs started with rsh

• Optional automatic conversion of text files between Unix and NT format with rcp copies

Command requests can come from clients running other operating systems such as Unix or from other Windows systems running Windows NT, Windows 95, or Windows 3.x. You can use the rsh utility that comes with your TCP/IP package or the rsh command in Denicomp Systems’ Winsock RCP/RSH/REXEC package (a separate product). Unix and Windows NT both have their own rsh commands; Windows 95 and Windows 3.x do not. Some third party TCP/IP packages include rsh.

Files can be copied to the system or from the system running Winsock RSHD/NT using the standard TCP/IP rcp command. This includes the rcp command available with Unix or Windows NT or a third party rcp command such as the one found in Denicomp Systems’ Winsock RCP/RSH/REXEC package. Windows 95 and Windows 3.x do not include the rcp command.

Winsock RSHD/NT requires a Intel x86-based system or DEC Alpha based system running Windows NT 3.51 or higher and a network.

Winsock RSHD/NT does not run under Windows 95. There is a version specifically written for Windows 95 called Winsock RSHD/95. Contact Denicomp Systems for more information.

The purpose of a Remote Shell Daemon is to service the standard rsh and rcp commands. These commands were designed to be used on a network where users and systems were generally trusted and convenience was more desirable than security.

Since rsh and rcp do not require users to supply passwords before being granted access, there is the risk of unauthorized users being granted access to your system when running Winsock RSHD/NT (or any Remote Shell Daemon, for that matter). This risk is greatly increased if the system running Winsock RSHD/NT is connected to the Internet. Winsock RSHD/NT provides mechanisms for you to determine which hosts and users are granted access to your system. Firewalls can also help to reduce this risk. But the risk of unauthorized access still remains even when these are used because of the lack of password validation.

By installing Winsock RSHD/NT, you are taking this risk of unauthorized access upon yourself. By installing Winsock RSHD/NT, you are agreeing that you will not hold Denicomp Systems responsible for any damage caused by unauthorized access to your system through the standard rsh and rcp commands. Denicomp Systems did not design the rsh and rcp protocols; RSHD/NT simply implements the standard originally designed for Unix systems.

Please review the license agreement included with Winsock RSHD/NT and do not continue with the installation or with using it if you do not accept its terms.

As will be explained later, you can install Winsock RSHD/NT as a Windows NT service or as a Windows NT application. A service is a special Windows NT program that automatically starts in the background when Windows NT starts. It runs even when no one is logged on to the NT console. An application is simply a standard Windows NT program that you execute from the Start menu (or Program Manager) or from the NT Command Prompt. Applications only run when someone is logged in to the NT console; when you log out, NT will stop the application.

Normally, you will want to install Winsock RSHD/NT as a service. The only times you would not want to install RSHD/NT as a service would be if you either only wanted to have RSHD/NT running occasionally when you manually start it or you only want to experiment with it and you do not have permission to install it as a service.

If you are going to install RSHD/NT as a service, you must be logged in as a user who has permission to create services. Normally, you will want to do this while logged in as Administrator.

If you received a diskette, insert the Winsock RSHD/NT diskette into your diskette drive. If you are using Windows NT 4.0 or higher, click on Start, then Run. If you are using Windows NT 3.51, from the Windows NT Program Manager menu, select File, then Run. Then type the name of your diskette drive followed by "SETUP". For example, if the diskette is in the A: drive, type "A:SETUP". Then press the Enter key. (This can also be done from a Command Prompt if you prefer).

If you have downloaded a .ZIP file, you probably have already unzipped the file into a directory. From that directory, execute SETUP.EXE. You must not install the software into the same directory where you unzipped the files.

The Winsock RSHD/NT Installation window will then appear. Verify that the drive letter or directory shown in the Source field is correct. If it is not, specify the proper drive or directory.

Specify the directory in which you would like Winsock RSHD/NT to be installed in the Destination field. This will default to the \WRSHDNT directory on the drive where Windows NT is installed. You may change it if you wish. However, if you are installing RSHD/NT as a service, you must install RSHD/NT on a local hard drive, not a network drive. The NT Service Controller cannot access network drives.

If you do not want Winsock RSHD/NT to be installed as a Windows NT Service, uncheck the Install as Service option and it will not be added to the list of Windows NT Services. Winsock RSHD/NT can be run as an application instead of a service if you wish (details on how to do this are provided later).

Press the Install button to begin the installation. Press Cancel if you wish to exit.

Files will be copied to the destination directory. When all files have been copied, if you chose to install RSHD/NT as a service, the installation will ask you whether or not you want Windows NT to start the Winsock RSHD/NT service each time Windows NT starts. Click Yes to start it automatically each time Windows NT starts or No if you want to start the service manually. The Winsock RSHD/NT service will then be installed in Windows NT’s list of services and it will be started.

See the section on Winsock RSHD/NT Utilities for instructions on how to manually start and stop the Winsock RSHD/NT service.

To remove Winsock RSHD/NT, use the Add/Remove Programs applet in the Windows NT Control Panel. Find Winsock RSHD/NT in the list of installed programs, click on it once, then click on the Add/Remove button. Verify that the directory shown is the directory where RSHD/NT is installed and click on the Uninstall button to proceed or Cancel to abort. This will completely remove Winsock RSHD/NT from your system.

If you wish to remove Winsock RSHD/NT manually, you must first stop the Winsock RSHD/NT service, then remove the service from Windows NT’s list of services before deleting the files. From the Windows NT Control Panel, double-click on the RSHD icon. Then, from the Winsock RSHD/NT Control Panel, click on the Service Control button.

From the Winsock RSHD/NT Control menu, first select Stop the Winsock RSHD/NT Service. Then select Remove the Winsock RSHD/NT Service. Removing the service does not actually delete any files. It only removes RSHD/NT from NT’s list of services. You can then delete the Winsock RSHD/NT directory. You should also delete the files WRSHDNT.CPL in the Windows NT System directory (\WINNT\SYSTEM32 for example). This is the Control Panel applet for Winsock RSHD/NT.

You should then also delete the Winsock RSHD/NT registry entries using regedit. The Winsock RSHD/NT registry entries are stored under the registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\DenicompSystems\WRSHDNT

You can optionally run Winsock RSHD/NT as a Windows NT application instead of a service. This requires that someone log in to Windows NT so that Winsock RSHD/NT starts.

To start Winsock RSHD/NT as an application, execute the following command:

If you are executing this command from the Windows NT Command Prompt, you should use the command:

If you do not use the start command, you will not have access to that Command Prompt window until Winsock RSHD/NT is stopped. Be sure that you do not already have Winsock RSHD/NT running as a service.

When Winsock RSHD/NT is started, it will display a window where messages about the status of Winsock RSHD/NT will display. The number and type of messages that display depends on the Message Level option in the Winsock RSHD/NT Configuration.

To stop Winsock RSHD/NT, simply close the window or activate the window and press Control-C.

Winsock RSHD/NT will work properly using its default configuration. You only need to configure Winsock RSHD/NT if you wish to change any of the available options, enable security, or use the logging capabilities. By default, no security is enforced and no logging is done

You configure Winsock RSHD/NT by using the Windows NT Control Panel. In the Control Panel, double-click on the RSHD icon to configure Winsock RSHD/NT. In the RSHD/NT applet, you can press <F1> at any time to display help information about the options available.

After changing most Winsock RSHD/NT Configuration options, you do not need to stop and restart Winsock RSHD/NT. It will recognize the change, unless you disable the monitoring of the registry (see below).

NOTE: Each of the log files may refer to the same file name if you wish. They will not overwrite each other. Each message is appended to the end of the file. You should be sure to periodically delete the log file(s) because they can get large over time on an active system.

• The Minimized or Hidden options are useful when the system running RSHD/NT is actively used and is not a standalone server. With the Normal or Maximized options, the person using the system will see a window appear each time a command is executed through rsh.
• You cannot send keystrokes to commands that are minimized or hidden. Therefore, if you select the minimized or hidden option as the default, RSHD/NT will automatically run any program in a normal window when keystrokes are specified in the rsh command, overriding this setting.
• Using the Hidden option can cause administrative problems. When a program’s window is hidden, it does not appear in the Task List, so there is not an easy way to stop a hidden program or to tell if any are running. There are utilities that allow you to see the hidden programs (such as the PView program that comes with Microsoft Visual C/C++).

• Never - Copy all files as binary

• Always - Convert all files

• Convert based on list of file extensions

• Convert based on contents of first block

With Unix, security is enforced on remote command execution using a combination of the password file (/etc/passwd), the hosts file (/etc/hosts),and the host equivalency files (/etc/hosts.equiv and $HOME/.rhosts).

Winsock RSHD/NT enforces security through the Security File. The name of this file is specified in the Winsock RSHD/NT Configuration in the Security File entry.

If you specify a Security File name and the file does not exist or the file is completely empty, all hosts and users are denied access.

Conversely, if you do not specify a Security File, all hosts and users are granted access. So if you do not wish to enforce any security, do not specify a Security File name in the configuration file.

Additionally, you can configure Winsock RSHD/NT to ensure that user names on remote hosts are valid on this system. You should only enable this security option if you use consistent user names across all of the systems on your network.

You create the Security File using a text editor. If you are using the Winsock RSHD/NT Control Panel applet, you can click on the Edit Security button to run the Windows Notepad editor to edit the Security File specified in the Security File configuration option.

The Security File consists of lines that specify who may or may not access the system using Winsock RSHD/NT. The following are the options available:

When specifying the host on the lines in the Security File, you may use either a host name or an IP address (in dotted-decimal format). If you use a host name, that name must be resolvable by TCP/IP, either through the hosts file or through DNS.

You may use wildcard characters when specifying the user and/or host name in the Security File. The wildcard characters that can be used are:

If the request is coming from a Unix system, the user name is the login name of the user. If the request is coming from a Windows PC or non-Unix operating system, the method of specifying the user name is determined by the implementation of the rsh or rcp command you are using.

Keep in mind that the standard rsh command allows you to override the user login name with the -l option and the standard rcp command allows you to use "user@" before the host name to override the user login name. When the user login is overridden using these methods, the standard Unix rsh and rcp implementations send both the actual login name and the override name specified on the command line. If you are specifying user names in the Security File, keep this in mind.

To effectively use the Security File, you must first understand how it is viewed by Winsock RSHD/NT.

When Winsock RSHD/NT receives a request, it sequentially processes the lines in the Security File to determine whether or not the host and user are granted or denied access. It looks at each line in the Security File until it determines that either the host or the user is specifically denied permission.

Winsock RSHD/NT begins by assuming that permission is denied for the request. It then examines the lines in the Security File to see if any of the lines pertain to this request.

Once Winsock RSHD/NT finds a line that denies access to either the user or the host, it stops looking and denies permission.

If it finds a line that grants permission to the user and/or host, permission is tentatively granted, but it continues to process the lines in the Security File.

If it processes the entire Security File and does not find a line that grants permission to the user and/or the host, permission is denied. If security was tentatively granted at some point and not denied subsequently, permission is granted.

For example, let's say that the following is the contents of the Security File:

In this example, if any user on the host "jetty" makes a request, permission will be granted, unless the user is "jackie", since "jackie" is denied access from all hosts (-jackie).

If "jackie@jetty" makes a request, Winsock RSHD/NT reads through the Security File and finds the host name "jetty", and tentatively grants permission. However, it continues and finds that the user "jackie" is denied from all hosts, so permission is denied.

Also, if any user on the host "booey" makes a request, they are granted permission unless the user is "gary", since "gary@booey" is specifically denied permission (-gary@booey). All other users on the host "booey" are granted permission except "jackie" (-jackie).

The user "fred" on the host "mars" is granted permission because of the line "+fred@mars". However, since the host "mars" does not appear on a line by itself, no other users on the host "mars" are granted permission except the user "robin", who is granted permission from any host (+robin).

Finally, all users making requests from systems whose host names end in ".netcom.com" are granted permission, unless the user is "jackie", since "jackie" is denied permission from all systems.

If you think you have properly set up the Security File, but you are being denied access when you think you should be granted access, the following provides some tips on determining the cause of the problem:

• Be sure that you have correctly specified the Security File name in the RSHD/NT Control Panel applet and that it actually exists.
• Be sure that you have saved the Security File as an ASCII text file. From a NT Command Prompt, use the TYPE command to view the contents of the Security File.
• If the editor used automatically appends an extension to filenames (such as Notepad, which appends a .txt), be sure that you have specified this extension on the filename specified in the Security File field.
• Be sure that the Security File is stored on a local hard drive, not a network drive.
• If you are running the RSHD/NT service as a non-LocalSystem user, be sure that the user has permission to read the Security File.
• If you have specified host names in the Security File, be sure that your system can resolve the names, either through DNS or through the HOSTS file. Try using the ping command to verify access to the host names specified in the Security File.

If these tips do not help, enter a filename in the Message File field and a 4 in the Message Level field in the RSHD/NT Control Panel applet. Then execute rsh or rcp from a system that should be given access, then examine the Message File. It will contain a trace of the steps RSHD/NT is using to validate the remote user and host.

Under Unix, the Remote Shell Daemon process (rshd) implements security through user equivalence. That is, it is assumed that when an rcp or rsh command is executed by the user "john" on a client system, the user "john" exists on the host system and has the appropriate privileges.

Under Unix, the Remote Shell Daemon process (rshd) runs as the super-user, root. Unix has a feature known as "set user id" or "setuid". When you execute an rsh or rcp, the Unix rshd effectively "becomes" the user passed to it by rcp or rsh.. Any process spawned (rsh ) or file accessed/created (rcp) are done so as if that user were logged on to the system, taking on the security attributes of that user.

Windows NT has a similar capability (called "impersonation" in NT). However, there is a basic, but important difference. In order for a process like RSHD/NT to "become" another user, that user’s password must be supplied. This is incompatible with rcp and rsh - they cannot ask for a password. So it is not possible for RSHD/NT to mirror this feature of Unix’s rshd.

When RSHD/NT is installed by its SETUP program, an NT service is created and is set up to run RSHD/NT as the user System (also known as LocalSystem), which is a privileged account. Any files accessed by RSHD/NT will be accessed as the user System and any programs spawned will be done so as the user System. This means that programs run through rsh will have unrestricted access to the NT system and rcp will have unrestricted access to the files on the NT system.

Although the default System account is privileged (meaning it has access to all resources on the NT system where RSHD/NT is running), the System account does not have access to any network resources, such as shared drives or printers. This is a Windows NT security feature. If you attempt to run a program through rsh that needs to access a network resource, such as a shared drive, or you need to rcp a file on a shared drive and the service is running as System, you will receive errors.

If you need to restrict access through RSHD/NT or you need to have access to network resources, you have two options.

Option 1:

Option 2:

The downside to the second option is that only the System user has access to the Windows NT desktop. So if you run RSHD/NT as any other user, NT executes the programs on an invisible desktop so you will not see any windows of programs executed through RSHD/NT and you will not be able to use the special "send keys" option of the rsh command. The rsh command will continue to function properly in all other cases, however. Option 1 does not have this problem because the service still runs as System, but the programs will run in the context of the user specified.

In both cases, you can specify the account name of an existing user. However, this can cause problems because you must also specify that user’s password. If that user’s password expires or changes, you must remember to manually change it in the setup at that time or RSHD/NT will not start. NT will not update the Service setup automatically.

An alternative is to set up a new account specifically for the purpose of running RSHD/NT. Specify that the account’s password does not expire so it will not be forced to change. You can then set up the security attributes of that user and they will be inherited by all rsh and rcp commands serviced by RSHD/NT. (This is similar to the way NT’s FTP Server implements security for anonymous users.)

This will then allow you to restrict the files accessible by users using rcp and rsh . It is not totally ideal because all users will be given the same access rights. But it is a necessary compromise because of the basic differences between NT and Unix.

If you need to access a network resource (such as a shared drive or printer on another system) through RSHD/NT, you must follow the steps in the previous section RSHD/NT and NT Security so rsh or rcp executes in the security context of a user who has access to those resources. By default, RSHD/NT runs as the System user, who does not have access to any network resources.

If you follow the steps in that section, you will then be able to access network resources using their UNC (Universal Naming Convention) names. For example, if there is a directory shared as "CDRIVE" on the system named "SERVER2", you can access it using the path name \\SERVER2\CDRIVE. You do not need to map a drive letter to it; you can access it directly (assuming proper permissions) using its UNC name. For example, to get a directory listing of that directory, you could use:

This command would access \\SERVER2\CDRIVE (case is not significant) through RSHD/NT running on the system "winnt3".

Ideally, you should always use UNC path names, but there may be times when it is necessary for you to map a drive letter or LPT port to a network resource through RSHD/NT. If mapped drives or printers are required, there are a few special considerations involved.

• Initially RSHD/NT will not know of any drive or printer mappings. When a service starts or logs in as another user (i.e. the RSH User or RCP User), Windows NT does not execute any login scripts or restore any persistent drive mappings.

• Drive mappings are global on a Windows NT system, but are accessible only by the login session that created them. This is very important to understand. Although Windows NT functions as a network server, it is not a multi-user operating system. If the interactive user (logged in using the keyboard attached to the NT system) maps the drive letter F: to a network share, F: will only be accessible from that keyboard by that user. Other processes (such as those created through RSHD/NT or any other service) will see that F: is a mapped drive, but F: will not be usable from those processes; Windows NT will give an Access Denied error if you try to use it. You also cannot map F: to another network drive while it is in use by the interactive user (or another process).

• You cannot use rsh to issue single NET USE commands to map drive letters. If you try to do so, you will orphan the drive letter and it will be unusable by any process until you reboot the system. Windows NT tracks drive mappings by logon session. When you issue an rsh command, RSHD/NT creates a new individual logon session for each command. If you use rsh to execute a NET USE command to map a drive letter, the map will be created for that login session (which exists only for the duration of that command) When the command finishes, the login session will be ended but the drive will remain mapped. Since the login session that created it no longer exists, the drive letter will become unusable. Also, because the login session no longer exists, the map cannot be deleted because only the session that created it can delete it. So it becomes an "orphan" and unusable until you reboot.

You can use NET USE commands in batch files executed through RSHD/NT as long as you remember to delete the map(s) at the end of the batch file. For example:

REM MYTEST.BAT

DIR F:

NET USE F: /DELETE

This is OK because it creates the map, uses it, then deletes it. Since the batch file is executed with a single rsh command, it is executed within a single logon session so the drive letter will be usable throughout the batch file. But if you omitted the NET USE F: /DELETE command, F: would become orphaned and unusable when the batch file ended. The next time you ran the batch file, it would fail.

NOTE: The above batch file could also fail for two other reasons:

• The interactive user on the NT system mapped drive F: to some network resource (even the same resource as above). Again, since the interactive logon session "owns" F:, it cannot be used in another logon session.
• Two (or more) rsh commands were executed simultaneously to execute this batch file or some other batch file that mapped F:. The first one executed would succeed, but the others would fail because the first execution would "own" the F: drive until it deleted the map.

If you must use drive letters and LPT ports to access network resources through RSHD/NT and you cannot use UNC path names, your only options are:

• Do so in a batch file. At the beginning of the batch file, issue the necessary NET USE commands to map the drives/printers, execute the command(s), then issue NET USE commands to delete the maps. This can be inconvenient because you would need to create a batch file for every different command you wanted to execute.
• Use the RSHD/NT AUTOMAP.INI file, explained in this section.

The AUTOMAP.INI file allows you to set up drive and printer mappings for use in RSHD/NT. For each rsh and rcp command, RSHD/NT will read this file and map the specified drives and printers, execute the command, then automatically unmap the drives/printers for you so they are usable by the next command and so they do not become orphaned.

The AUTOMAP.INI file is a text file that you can create with a text editor (such as Notepad or EDIT). It must be stored in the RSHD/NT Installation Directory (usually C:\WRSHDNT - check the RSHD Control Panel applet to be sure; look on the Advanced tab).

In the AUTOMAP.INI file, you can specify NET USE commands to establish drive and printer mappings. The syntax of the NET USE command allowed in AUTOMAP.INI file is:

Where:

This syntax is the basically the same as the standard NET USE syntax, except:

• you may omit the password parameter when using /USER: if the password is not necessary
• the password can be placed after /USER: instead of before it if you wish

So, if you placed the following lines in AUTOMAP.INI:

NET USE M: \\WESTCOAST\ACCT clancy2 /USER:tom

For every rsh and rcp command, RSHD/NT would map F: to \\SERVER2\CDRIVE, M: to \\WESTCOAST\ACCT (using the user "tom" and the password "clancy2"), and LPT4 : to \\PRSERVER\PRT1. It would then execute the command, then unmap the drives and printers automatically. It will do this regardless of whether the command actually uses the mapped drives or printers, since RSHD/NT has no way of knowing whether it will or not.

RSHD/NT will not report a failure if it cannot create any of the maps. Your command may fail because the map is unavailable or inaccessible and that may cause an error to be reported back to you, but the mapping failure itself will not generate an error.

Again, the map would fail if another process already has the drive letter or printer port name in use.

You can also create "sections" in AUTOMAP.INI that allows you to specify different mapping schemes for different users and hosts. Any maps that appear at the beginning of the file that are not under a section heading get mapped for every user from every host.

You can specify sections in the AUTOMAP.INI file for specific users, specific hosts (clients), or specific users on a certain host. You do this by enclosing the specification in square brackets ([ ]) and including the maps under it. The options are:

[+user] - The maps in this section are only executed for "user"

[host] - The maps in this section are only executed for rsh/rcp commands from "host"

The "user" referred to above is the user received from the client in the rsh/rcp command. This may be the logged on user on the client or it may be overridden with the -l option in rsh or the user@host: specification in the rcp command.

You may use wildcard characters (*, ?) if necessary and you may use IP addresses instead of the host name if you wish. Some examples:

[+john]

[myhost.com]

[10.0.1.*]

[alice@brady.com]

You can specify comments in the AUTOMAP.INI file by using "rem", "#", or ";" at the beginning of a line.

The following is an example of a slightly more complex AUTOMAP.INI file:

# These maps are for all users

[10.0.1.*]

# These maps are only for users with local IP addresses

[honcho@oursys]

# Only the head honcho can access this

NET USE M: \\MGMT\DATA

NOTE: Although the NET USE command is a standard NT command, please realize that AUTOMAP.INI is not a batch file. The NET USE syntax is only used for the purpose of familiarity. RSHD/NT is reading and interpreting lines in the AUTOMAP.INI file - it is not actually executing NET USE commands per se. So you cannot include any other commands besides NET USE in AUTOMAP.INI and you cannot use any other options to NET USE other than those shown here. If you try, the lines will be ignored.

Keep in mind that this is not a complete solution to the problem of using mappings. You still must somehow deal with the fact that Windows NT is not a multi-user system and if another process uses a drive letter, it will not be usable by any other process until the process that created it deletes the map. There is nothing that RSHD/NT can do about this - it is the way Windows NT works.

With Unix, the rsh utility executes the specified program on a remote host and returns the standard output and the standard error output to the rsh command. You can then see the output of the programs on your screen.

When you execute NT console or MS-DOS programs using rsh, you will also see the standard output and standard error output of those programs. NT console and MS-DOS programs are character-based and write output to the standard output/error, which RSHD/NT can capture and return to the remote system.

For example, the following command would display a directory of the C: drive’s root directory on your screen (assuming RSHD/NT’s default configuration is being used):

Note the double backslashes (\\). If this rsh command is being issued from a Unix system, Unix uses the backslash as an "escape" character. To send a single backslash to RSHD/NT, you must specify two.

With Windows graphical programs, there is no such thing as "standard output" and "standard error". Programs execute in graphical windows, so there is no way to return any output using rsh. (There are also some NT console and MS-DOS programs that write directly to the screen and their output cannot be returned either.)

Therefore, when using rsh to initiate programs on a Windows NT system, you will not see any output of graphical programs on your screen (where the rsh command was used). It will display on the Windows NT system that received the request.

For example, if you used the following command:

This would start Excel on the NT system named "winnt3" (assuming "excel.exe" was in the PATH). You would see nothing on your screen as a result of starting Excel. Excel would be running on the screen of the NT system named "winnt3".

If you attempt to execute a program that does not exist or Windows returns an error trying to load the program, you will receive a descriptive error message on your screen from Winsock RSHD/NT to tell you that the program was not successfully executed.

Important Note: Winsock RSHD/NT uses the PATH and other environment variables specified in the System Control Panel for the entire system, not for a specific user. If you are trying to execute a program that Winsock RSHD/NT cannot find, check the System environment variables. You can also use an Environment Variable File to change the PATH; see the section on configuring RSHD/NT for more details.

Some commands that you can execute at Windows NT’s Command Prompt are not actually programs; they are internally recognized by the command interpreter CMD.EXE. One example of this is the DIR command. If you look in the directory where Windows NT is installed, there will be no DIR.EXE. It is part of CMD.EXE.

In previous versions of Winsock RSHD/NT, you had to prefix these internal commands with "cmd /c". Winsock RSHD/NT now recognizes internal commands and will execute them through the NT command interpreter. Prefixing the commands with "cmd /c" is no longer necessary, although it will still work if you do.

If you are using an alternate command shell, you can specify this shell and its internal commands in the RSHD/NT Control Panel applet. RSHD/NT will then recognize them and prefix them with your command shell.

You can optionally capture the standard output and standard error output of Windows NT Console or MS-DOS programs through Winsock RSHD/NT with the rsh command. This allows you to display the output of these programs that output to the standard output or standard error on another screen or capture it to a file on another system. It also allows you to send the standard input from rsh to the remote program. This is known as redirection.

By default, Winsock RSHD/NT automatically attempts redirection on every program executed using rsh, to capture the standard output and standard error and send it back to the rsh command, and receive standard input sent to it by the rsh command and provide it to the program executed.

If you mostly execute NT Console or MS-DOS programs through RSHD/NT, this default behavior of automatic redirection is the most useful. However, it does have some downsides when you want to execute graphical programs through RSHD/NT (which do not have standard input/output/error) or you simply do not need redirection even for console or DOS programs.

The downsides to automatic redirection are:

• When executing graphical programs, there is some additional overhead in starting the programs because RSHD/NT tries to redirect the standard I/O, even though there is none.
• When executing graphical or console/DOS programs with automatic redirection, RSHD/NT does not return control to the rsh command until the program executed completes. The rsh command will not end until the remote program ends.

You can control this in two ways, if necessary:

Option 1. If you only occasionally need to use rsh to execute graphical programs or console/DOS programs where you do not want rsh to wait until they complete, you can add the special "<[WIN]>" option in the rsh command. This tells RSHD/NT that it should not attempt redirection on this program only. For example:

This will start Excel on the system named "winnt" and RSHD/NT will not attempt any redirection. The rsh command will end immediately after Excel starts; it will not wait until Excel exits. Without the "<[WIN]>", the rsh command would not end until you closed Excel.

Option 2. If you mostly execute graphical programs or you usually do not want to do redirection on console/DOS programs because you do not care about the output, you should uncheck the option labeled Attempt Redirection on Every Command in the RSHD/NT Control Panel applet. If you uncheck this option, RSHD/NT will not automatically attempt redirection, unless you specify the special "<[CON]>" option in the rsh command. This tells RSHD/NT that it should attempt redirection on this program only. For example:

This will run the "net view" command on "winnt" and display the output on your screen. The "net view" command displays information on the standard output.

If you have unchecked the RSHD/NT Control Panel option labeled Attempt Redirection on Every Command, programs executed through rsh will return control back to rsh immediately after the program begins. It will not wait until it completes.

If you want the rsh command to wait until the program finishes executing, you can use the special "<[WAIT]>" option in the rsh command. For example, to execute the command "bkgprint" and wait for it to finish, use:

Winsock RSHD/NT provides the ability for you to send keystrokes to a graphical Windows application you initiate using the rsh command. It also allows you to specify how the window is to be displayed (i.e., normal, minimized, maximized, or hidden). This provides you with some "remote control" over what the program you run does once it starts.

If you are running the RSHD/NT service as a user other than the default System account, you will not be able to use this function. This is a feature of Windows NT’s security system – only the System user has access to the NT desktop (screen). When the RSHD/NT service is run as a non-System user, NT puts the windows on an invisible desktop and they cannot receive keystrokes. A better option is to use the Execute All RSH Commands as User option in the RSHD/NT Control Panel applet and continue running the service in the System account. This will allow you to use keystrokes.

Also, due to a limitation in Windows NT, you cannot send keystrokes to an application started through Winsock RSHD/NT if there is no one logged in to Windows NT. The program will be executed, but it will not receive the keystrokes. This is again due to NT’s security system. When NT is at a login, the login window is displayed on a special desktop and no other program can gain access to it. NT does this so no other program can attempt to capture your password as you type it.

If you are familiar with Microsoft Visual Basic or the Visual Basic for Applications (VBA) macro language, sending keystrokes s is very similar to the SendKeys capability of those programming languages.

The standard syntax of the rsh command is:

This will execute "command" on the host "hostname". Winsock RSHD/NT allows a slight modification of the rsh syntax to send keystrokes. This is compatible with all rsh commands. The alternative syntax for sending keystrokes is:

If the first parameter after the host name begins with a less-than sign (<), that parameter is interpreted as keystrokes to be sent to the command specified in the next parameter. The keystrokes must end with a greater-than sign (>). You must also enclose the entire parameter in quotes so special characters and spaces are not interpreted by the operating system.

For example, if you wanted to run the Windows Notepad on the system named "winnt" and type "This is a test" on the first line, the command would be:

If you looked at the winnt's screen, you would see the Windows Notepad with "This is a test" on the first line.

You cannot send keystrokes to all applications. This is beyond Denicomp Systems control. Most applications will allow you to send them keystrokes, but there are a few that will not.

Winsock RSHD/NT also allows you to specify special keys in the keystrokes parameter that cannot normally be typed on a command line, such as embedded Enter keys, function keys, ALT keys, etc.

Keystrokes are sent sequentially as they appear between the "<" and ">". To send a single character, use the character itself. For example, to send the letter "X", use the letter "X". To send the word "hello", just specify those letters.

To specify keys combined with any combination of Shift, Ctrl, and Alt keys, prefix the regular key code to one or more of the following codes:

For example, to send the Alt-F keystroke, specify "%F". To send Ctrl-Alt-D, specify "^%D".

To send the Enter key, use the tilde (~).

To specify that the Shift, Ctrl, and/or Alt keys should be held down while several other keys are pressed, enclose the key codes in parentheses ( ). For example, to have the Alt key held down while X and D are pressed, use "%(XD)". You could also use "%X%D", but if the Shift, Ctrl, and/or Alt keys need to be held down for a number of keystrokes, the parentheses can make the string shorter. Also, you would want to use the parentheses if the application detects the release of the Shift, Ctrl, and/or Alt keys and that is not desired.

The following characters have special meaning in the keystroke parameter, so they must be enclosed inside braces ({ }). Some of these special characters have not been explained yet.

To send characters that are not normally displayed when you press a key (such as Enter or Tab) and keys that represent actions rather than characters, use the following special codes:

You can also specify that a key is to repeat itself a certain number of times, without repeating the key itself in the string. To repeat a keystroke, use the format:

Where "keystroke" is the key to repeat, followed by a single space, then the number of times to repeat the key.

For example, to press the down arrow key eight times, use "{DOWN 8}".

To type thirty asterisks (*), use "{* 30}".

Under some circumstances, it may be necessary to pause for a specific time before sending keystrokes to allow a program operation to complete. This is usually necessary when a program ignores keystrokes that have been queued while a long operation takes place (perhaps generating print output, rewinding a tape, performing a complex calculation, etc.).

Within the keystroke list, you can specify pauses by using the special {PAUSE #} keystroke.

This is not actually a keystroke, in that it does not press any key, but it can be included anywhere within the keystroke list. It will pause the specified number of seconds.

For example, the following keystroke list will press Alt-F, P, wait 10 seconds, then press Alt-F, X:

You can specify multiple pauses in the keystroke list if necessary.

The following example, will start Microsoft Word, load a file, print it, then exit.

The keystrokes are:

Note that if this example were being run from a Unix system, you would have to use two backslashes (\\) for every one desired backslash because the Unix shells interpret the backslashes as special characters. The command would then be:

If your keystroke strings get rather long or complex, you can store them in a keystroke macro file so you do not have to specify all of them each time you use the rsh command.

To create a keystroke macro file, you must use a text editor (or a word processor, but be sure to save as an ASCII file). Enter the keystrokes as you would on the rsh command line, with the following exceptions/reminders:

To use a keystroke macro file, enter the at-sign (@) followed by the filename in braces ({ }) where you would normally specify keystrokes on the rsh command line.

You will most likely need to specify a full pathname of the keystroke file on the system running Winsock RSHD/NT, unless you know the working directory of Winsock RSHD/NT on the system running it and the keystroke macro resides in that directory. You may use forward slashes (/) instead of backslashes if you wish; this makes life easier for Unix users because the shell interprets the backslash characters.

For example, if you had a macro in the directory \kbmac\printss.mac on the system running Winsock RSHD/NT, you could use it with this command:

This would run "excel" on winnt2 and send the keystrokes stored in the file \kbmac\printss.mac to it.

You can intermix command line keystrokes and macro file keystrokes. That is, you can specify some of the keystrokes on the command line and use some from a macro file. You can also use multiple macro files.

For example, let's say we want to print a file using rsh through a Windows application called "wintiff". We want to store the keystrokes in a macro file, but do not want to store the filename in the macro file because it can change.

To do this you can store the first set of keystrokes in one macro file, specify the filename on the rsh command line, then store the remaining keystrokes in a second file.

For example, let's say the file is "mypic.tif":

This example copies the file "mypic.tif" to the \tmp directory on winnt2. Then it runs "wintiff" and first sends the keystrokes from the file \kb\tif1.mac. That macro ends when "wintiff" requires a filename. The keystrokes to "type" the filename come from the rsh command line since the tif1.mac has ended. Then it continues by sending the keystrokes in the file \kb\tif2.mac. That is:

Winsock RSHD/NT also allows you to specify the window type of the application being run. Normally, the application is run based on the Default Window Type specified in the RSHD/NT Control Panel applet.

If you want to specify a different method of displaying the application's window, you can specify this inside the keystroke parameter by enclosing the method in square brackets ([ ]).

There are two methods of setting the window type. You can use one of the words shown below or you can use a number. The options are:

Other numeric values may be used - they correspond to the Windows' ShowWindow API call (for all you programmers).

For example, if you want to run the Windows Notepad maximized, viewing the file "heyyou.txt", you would type:

This runs the Notepad maximized, then "presses" Alt-F-O (File Open) and types the filename "heyyou.txt" and presses Enter to load it.

If you wanted to run some application that does some task and exits, you could run it minimized using:

Note that Windows does not allow you to send keystrokes to a minimized or hidden application. Therefore, "[MINIMIZE]", "[HIDE]", "[0]", or "[2]" should always appear alone between the "<" and ">". If you specify other keystrokes, the application will not receive them (Windows will beep at you for each keystroke).

RSHD/NT internally understands two special commands that allow you to remotely shutdown and reboot the NT system through the rsh command. These commands require the special <[INTERNAL]> or <[INT]> indicators. The commands have the following syntax:

The [#] are optional. You can specify a number of seconds to delay the shutdown or reboot in this parameter. If you do not specify a number of seconds, it is immediate.

If you are running the RSHD/NT service as a user other than System or you have specified a user in the Execute All RSH Commands as User field,, that user must have permission to shutdown or reboot the system.

Winsock RSHD/NT also provides Remote Copy (RCP) Server capability. This allows you to copy files to and from a system running Winsock RSHD/NT using the rcp command.

The rcp command is commonly found on Unix systems, Windows NT systems, and in some TCP/IP packages for Windows and DOS. If your TCP/IP package does not provide the rcp command, you can use Winsock RCP/RSH/REXEC from Denicomp Systems.

The rcp command is described in more detail in your TCP/IP package manual or with the manual that comes with Winsock RCP/RSH/REXEC. However, here are a few examples of its use.

Important Note: Unlike the standard Unix rcp command and Denicomp Systems’ rcp command (found in the Winsock RCP/RSH/REXEC package), the Windows NT rcp command copies all files with ASCII end-of-line conversion by default. Binary files must be copied using the -b option of NT’s rcp command. If you do not use the -b option on binary files, the contents of the file will be altered on the destination system.

To copy a file from the host named "srvpc" to your PC or Unix system, use:

The file "yourfile" is copied from the host named "srvpc" to the file on your PC named "myfile". The host "srvpc" could be running either Windows and Winsock RSHD/NT or Unix.

To copy a file from your PC or Unix system to the system named "srvpc", use:

The file \lists\xmas.doc is copied from your system to the file xmas.doc in the directory \word\lists on the system named "srvpc".

To send the entire directory tree from your PC or Unix system to "srvpc", use:

All of the files and subdirectories in the directory \share are copied to the system named "srvpc". It will create a \share directory in the root directory (\) of srvpc.

If the \share directory contained any subdirectories, they would be created on the other system and all the files in them would also be copied.

To copy all of the files ending with ".xls" from "srvpc" to your PC, use:

This copies all of the files ending with ".xls" in the directory \sheets on "srvpc" to the current directory (.) on your PC.

You can use drive letters if necessary. For example, to copy a file from the A: drive on the "srvpc" to your PC:

This will copy "file.txt" from the A: drive on "srvpc" to the file "file.txt" on your system.

NOTE: Winsock RSHD/NT allows you to use both slashes (/) and backslashes (\) for directory separators. It will adjust appropriately. This is especially important for Unix users, since backslashes are interpreted by the shell and must be escaped by using two backslashes for every one backslash. Use slashes instead.

Winsock RSHD/NT provides a method for you to have end-of-line characters automatically converted in files copied with rcp. Unix systems use a single newline (ASCII 10) character as a line delimiter. Windows NT systems use carriage return (ASCII 13) and newline pairs for line delimiters.

When end-of-line conversion is enabled, RSHD/NT will convert all carriage return/newline pairs to single newlines when files are copied from the NT system. It will add a carriage return to every newline character when files are copied to the NT system.

RSHD/NT can automatically convert end-of-line characters in the following ways:

• Convert all files. You would use this option if you only copy ASCII files with rcp
• Convert based on a list of file extensions that you supply. For example, you can convert only files ending with .txt.
• Convert based on the contents of the first block of data in the file. RSHD/NT looks at the data in the first block of the file and if it contains only printable ASCII characters, it will convert the file. If it finds any non-printable characters, it will not convert the file.

By default, RSHD/NT does no end-of-line conversion. The data in files sent or received using rcp is not modified.

To perform end-of-line conversions through RSHD/NT, see the section titled Winsock RSHD/NT Configuration for the RCP Option labeled Automatic End-of-Line Conversion.

Winsock RSHD/NT includes two utilities that allow you to control the operation of the Winsock RSHD/NT service.

The first utility is wrshdctl. This can be run in two ways. First, you can use the Service Control button in the Winsock RSHD/NT Control Panel applet. Or you can run it from the RSHD/NT installation directory.

To start it without using the Control Panel, use Start/Run (or File/Run for Windows NT 3.51), then type the name of the RSHD/NT installation directory (usually C:\WRSHDNT), a backslash (\), then "wrshdctl". For example, "C:\WRSHDNT\WRSHDCTL". Or you can get to a Windows NT Command Prompt. Change to the directory where Winsock RSHD/NT is installed using the CD command, then type "wrshdctl".

You can then do the following:

There is another utility included with Winsock RSHD/NT that performs the same operations as wrshdctl, but is a command line oriented utility. It is called ctrlrshd.

This command can be executed from the Windows NT Command Prompt while you are in the Winsock RSHD/NT directory (\WRSHDNT), unless you have included that directory in your path. Its syntax is:

The install option installs the Winsock RSHD/NT service in Windows NT’s list of services. It does not start Winsock RSHD/NT. You can optionally specify whether you want Winsock RSHD/NT to start automatically each time Windows NT is booted (auto) or if you want to start Winsock RSHD/NT manually when necessary (manual). If you do not specify either, auto is assumed. The directory option is used when you are using the install option and Winsock RSHD/NT is not installed in the current working directory. If it is not, specify the directory name as the third parameter. Note that if you specify a directory, then you must also specify auto or manual.

The start option starts the Winsock RSHD/NT service. Winsock RSHD/NT will begin accepting requests.

The stop option stops the Winsock RSHD/NT service. It will no longer accept requests. This does not remove it from Windows NT’s list of services; it only stops it until you decide to restart it using the start option.

The remove option removes Winsock RSHD/NT from Windows NT’s list of services. It will no longer accept requests and will no longer be available to start or stop. Note that you must first use the stop option if Winsock RSHD/NT is running before removing it.

The remove option does not delete any files; it only removes Winsock RSHD/NT from the list of available services. You can later add it back to the list using the install option.

This occurs because RSHD/NT runs all programs in the security context of the user specified in the RSHD/NT Service setup or in the security context of the user specified in the RSHD/NT Control Panel option labeled Execute All RSH Commands as User/Password.. It does not run the programs as the logged in user on the system from which the rsh command was issued. This is due to differences in the way NT and Unix operate.

By default, RSHD/NT runs all programs as the NT user SYSTEM (also called LocalSystem). This is a special NT user that has access to the NT desktop (screen) regardless of who is logged in. Windows NT does not allow this user to have access to any network resources.

If you need to access network resources, such as networked drives, you will either need to specify a user and password in the RSHD/NT Control Panel option labeled Execute All RSH Commands as User/Password or you need to run the RSHD/NT service as a user other than SYSTEM.

See the section on RSHD/NT and NT Security for additional details.

There could be three possible reasons for this to occur:

This could be due to one of two things. First, it could be due to a slow or inaccessible DNS server if you are using DNS. If you enter a filename in the Security File, Message Log, Request Log, Deny Log, or Error Log fields in the RSHD/NT Control Panel applet, RSHD/NT will attempt to obtain a hostname for the client based on its IP address. If you have specified DNS server(s) in your TCP/IP setup, it will attempt to use them to obtain the hostname. Otherwise, it will use the HOSTS file (e.g. c:\winnt\system32\drivers\etc\hosts).

If the DNS server is down, inaccessible, or simply does not know a hostname for the client's IP address, there could be a long delay before this is determined. If this is the case, there are a few things you can do to resolve the problem:

• Correct the problem with the DNS server.
• Enter hostnames and IP addresses of the client systems in the NT HOSTS file
• Clear the filenames in the Security File, Message Log, Request Log, Deny Log, and Error Log fields
• If you need the Security File and logs, create the following registry entry using REGEDIT:

The second possible cause is not as simple to explain. It is due to a missing "feature" in NT's TCP/IP implementation. Often, your first rsh/rcp will be fast, then subsequent commands will be delayed by a few seconds. This delay is not caused by RSHD/NT. It takes NT a few seconds at times to notify RSHD/NT that there is a connection waiting. RSHD/NT processes the request very quickly once it is notified.

To illustrate this, restart your NT system, then issue an rsh command from another system to the NT system. It will be quick. Then immediately issue another rsh; it will be delayed by a few seconds.

The root of this problem can be explained somewhat, although technical. After you issue the first rsh, the TCP/IP connection (a "socket") is closed and it goes into the TIME_WAIT state, which is normal. You can see this by typing the netstat command on the NT system after you do an rsh to it.

As long as there are closed sockets in the TIME_WAIT state which were created by RSHD/NT, you will experience the delay. It takes up to four minutes (a TCP/IP constant) for them to go out of the TIME_WAIT state. Once they do, the next rsh from the same client will be quick. Then the cycle repeats; you need to wait another four minutes for it to be quick again.

The reason for this is that the NT TCP/IP stack is strictly RFC compliant regarding the TIME_WAIT socket state. Most UNIX TCP/IP stacks, which are derived from BSD, have a non-standard-extension dealing with the TIME_WAIT state and new connections.

BSD-derived stacks allow a new connection request to arrive for a connection that is in the TIME_WAIT state if the new sequence number is greater than the final sequence number from the previous incarnation of the connection. Usually the sequence number for the new incarnation is set to the final sequence number from the previous incarnation plus 128,000.

This feature allows a client and server continually reuse the same port number at each end for successive incarnations of the same connection, but only if the server does the active close, which is always the case with an rshd (or rexecd).

NT's TCP/IP stack does not support this feature and this causes the delay sometimes experienced. The delay is at the TCP/IP stack level and not in Winsock RSHD/NT, so there is no work-around that we can employ to resolve it. It would require a change to NT's TCP/IP stack.

Since it only occurs on subsequent rsh/rcp commands during the TIME_WAIT interval, which is four (4) minutes by default under NT, as long as there are at least four minutes between each rsh/rcp from the same client, the delay will not occur. You can also lessen its effect by changing an NT registry option that allows you to reduce the TIME_WAIT interval from the standard four minutes down to 30 seconds. This registry entry is:

Create this entry as a new DWORD item (or edit if it already exists). Set it to any value between 30 and 300, which represents the number of seconds. The default is 240 (4 minutes). The smallest value allowed is 30 (seconds). You must restart Windows NT after adding/changing this entry for it to take effect.

So, if you set this entry to 30, as long as there are at least 30 seconds between each rsh/rexec from the same client, you will not experience the delay.

Support is available via e-mail through the Internet or Compuserve.

Internet: support@denicomp.com

WWW: http://www.denicomp.com

Compuserve: 71612,2333