Winsock REXECD/95 (Remote Exec Daemon) is a service for Windows 95 and Windows 98 that services the standard rexec command, which allows remote program execution. It accepts requests from the rexec command from other hosts on the network via TCP/IP and executes them on the system running Winsock REXECD/95. It runs under Microsoft Windows 95 or Windows 98. It does not run under Windows NT; use our Winsock REXECD/NT for Windows NT.

The rexecd service differs from the similar rshd (Remote Shell Daemon) service in that rexecd requires you to supply a valid password before access is allowed. The rshd service does not require a password and enforces security in a different (and less secure) method.

Since Windows 95/98 does not provide its own consistent password validation facility, Winsock REXECD/95 provides its own. You must set up users and passwords using the Winsock REXECD/95 Control Panel applet before it can service rexec commands.

Also, Windows 95/98 does not allow multiple simultaneous login sessions, so any programs executed or files accessed through REXECD/95 will use the same access permissions as the user currently logged in to Windows 95/98. Even though a different user might be specified in the rexec command, that user will only be used to determine the correct password; it does not affect the programs or files that may be accessed. Use Windows NT if you need that type of security.

Winsock REXECD/95 is similar to the Unix rexecd, but provides some special functionality for the Windows environment, such as:

· Supports a non-standard version of the rcp command for copying files using the rexec protocol

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 rexec utility that comes with your TCP/IP package or the rexec command in Denicomp Systems’ Winsock RCP/RSH/REXEC package (a separate product). Unix and Windows NT both have their own rexec commands; Windows 95/98 and Windows 3.x do not. Some third party TCP/IP packages include rexec.

Files can also be copied to or from the Windows system running Winsock REXECD/95 using a non-standard TCP/IP rcp command. The standard rcp command uses the rsh protocol to initiate the connection to the host. Winsock REXECD/95 supports rcp copies from an rcp command that initiates the connection using the rexec protocol instead. This is referred to as "RCP/X" in this documentation. Denicomp Systems has a version of the rcp command in its Winsock RCP/RSH/REXEC for Win32 package that supports the rexec protocol. This software works on Windows 95/98 and Windows NT systems only. For other operating systems, such as Unix, you would need to obtain source code for the rcp command and modify it to support rcp copies through rexec, so this capability may be of limited usefulness in that environment.

Winsock REXECD/95 requires a computer running Windows 95 or Windows 98, the TCP/IP protocol, and a network. It does not work under Windows NT - use our Winsock REXECD/NT under Windows NT.

The purpose of a Remote Exec Daemon is to service the standard rexec command. Although rexec requires users to supply passwords before being granted access, there is the risk of unauthorized users being granted access to your system when running Winsock REXECD/95 (or any Remote Exec Daemon, for that matter). This risk is greatly increased if the system running Winsock REXECD/95 is connected to the Internet. Winsock REXECD/95 provides additional mechanisms besides password validation 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.

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

Please review the license agreement included with Winsock REXECD/95 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 REXECD/95 as a Windows service or as a Windows application. A service is a special Windows program that automatically starts in the background when Windows starts. It runs even when no one is logged on to Windows. An application is simply a standard Windows program that you execute from the Start menu or from the command prompt. Applications only run when someone is logged in to Windows; when you log out to log in as another user, Windows will stop the application.

Normally, you will want to install Winsock REXECD/95 as a service. The only time you would not want to install REXECD/95 as a service would be if you only wanted to have REXECD/95 running occasionally when you manually start it.

If you received a diskette, insert the Winsock REXECD/95 diskette into your diskette drive. Click on Start, then Run. Then type the drive letter 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 DOS 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 REXECD/95 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 REXECD/95 to be installed in the Destination field. This will default to the \WREXEC95 directory on the drive where Windows is installed. You may change it if you wish. However, if you are installing REXECD/95 as a service, you must install REXECD/95 on a local hard drive, not a network drive. Windows may not have access to the network drive when it starts services.

If you do not want Winsock REXECD/95 to be installed as a Windows Service, uncheck the Install as Service option and it will not be added to the list of Windows Services. Winsock REXECD/95 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.

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

To remote Winsock REXECD/95, use the Add/Remove Programs icon in the Control Panel. Find Winsock REXECD/95 in the list of programs installed, click on it, then click on the Remove button. This will remove REXECD/95 from your system.

If for some reason this does not work, you can remove Winsock REXECD/95 manually. You must first stop the Winsock REXECD/95 service, then remove the service from the list of services before deleting the files. From the Windows Control Panel, double-click on the REXECD icon. Then, from the Winsock REXECD/95 Control Panel, click on the Service Control button.

From the Winsock REXECD/95 Control menu, first select Stop the Winsock REXECD/95 Service. Then select Remove the Winsock REXECD/95 Service.

Removing the service does not actually delete any files. It only removes REXECD/95 from the list of services.

You can then delete the Winsock REXECD/95 directory. You should also delete the files WREXEC95.CPL in the Windows System directory (\WINDOWS\SYSTEM for example). This is the Control Panel applet for Winsock REXECD/95.

You can also remove the REXECD/95 registry entries using REGEDIT. Delete the registry key:

You can optionally run Winsock REXECD/95 as a Windows application instead of a service. This requires that someone log in to Windows and start Winsock REXECD/95 (unless you add it to the StartUp folder; then it will start automatically after logging in).

To start Winsock REXECD/95 as an application, execute the following command:

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

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

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

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

Windows 95 and Windows 98 do not have a consistent password validation facility. Depending on the type of network you use, passwords are either validated locally (a peer-to-peer network), on a Windows NT server, on a Novell server, or on a Unix server (using Samba for instance).

Since REXECD/95 must validate passwords, it provides a method for you to define users and passwords. Only those users and passwords you set up will be permitted to issue rexec commands to this system. These users and passwords are set up using the Winsock REXECD/95 Control Panel applet.

The REXECD/95 Control Panel applet also allows you to change many other options that affect the way REXECD/95 operates. Winsock REXECD/95 will work properly using its default configuration. Other than setting up users and passwords, you only need to configure Winsock REXECD/95 if you wish to change any of the available options, enable security, or use the logging capabilities.

To set up users and passwords or change other configuration options, in the Windows Control Panel, double-click on the REXECD icon to configure Winsock REXECD/95. In the REXECD/95 applet, you can press <F1> at any time to display help information about the options available.

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

In order to use Winsock REXEC/95, you must set up a least one user and password. User and password information is stored on your hard drive in an encrypted file named rexecpwd.dat in your Winsock REXECD/95 installation directory. The file is hidden and read-only, so you will not normally see it listed and you will not be able to delete it unless you change the read-only attribute.

When setting up users, you can use three different formats when specifying the user login name:

User - give user access from any host with the specified password

User@host - give user access only from host with the specified password

User@ipaddr - give user access only from the IP address ipaddr with the specified password

You can use a mix the various formats if you wish. However, if you specify a user without a host or IP address and the same user with a host or IP address, only the user/password without the host or IP address will be used and the others will be ignored. So, while you can use a mix of the formats for different users, you cannot mix them with the same user.

To add a new user, enter the user's login name and password and click on the Add button.

To change an existing user, find that user in the user list and click on it once. Then click in the field you wish to update (the login name and/or the password) and make the necessary changes. Then click on the Update button to save your changes.

To delete a user, find that user in the user list and click on it once. Then click on the Delete button.

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 REXECD/95 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 rexec.
• You cannot send keystrokes to commands that are minimized or hidden. Therefore, if you select the minimized or hidden option as the default, REXECD/95 will automatically run any program in a normal window when keystrokes are specified in the rexec 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++).

These options only affect rcp using the rexec protocol (the non-standard rcp command supported by REXECD/95). If you are running a Remote Shell Daemon (rshd) also, it does not affect those rcp commands.

• Never - Copy all files as binary

No end-of-line conversion will be done. All files will be transferred or received unmodified.

• Always - Convert all files

Convert the end-of-line characters on every file copied from or to this system through REXECD/95.

• Convert based on list of file extentions

Only convert end-of-line characters in files ending with the specified list of file extensions; any file not ending in the specified extensions will be copied without modification. You must then enter the list of file extensions. Separate each file extension by a comma. Do not include any spaces. You must include the "dot" (.). For example: .TXT,.C,.H,.PRN,.MAK

• Convert based on contents of first block

REXECD/95 will examine the contents of the first block of the file to be sent or received and determine whether or not an end-of-line conversion is necessary. If the first block contains only text characters (letters, numbers, spaces, tabs, carriage returns, newlines, backspaces, escapes, and form feeds), REXECD/95 will perform an end-of-line conversion on the file. If the first block contains any other non-text data, it will be copied without modification.

The size of the first block is specified in the RCP Block Size field.

This is the directory where Winsock REXECD/95 is installed. This will be filled in by the REXECD/95 installation program. If you move REXECD/95 to another location, you must update this.

With Unix, security is enforced on remote command execution using rexec by validating the user and password.

In addition to user and password validation, Winsock REXECD/95 enforces security through the Security File. The name of this file is specified in the Winsock REXECD/95 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 if a valid user and password is supplied.

You create the Security File using a text editor. If you are using the Winsock REXECD/95 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 REXECD/95. 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 rexec or rcp command you are using.

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

When Winsock REXECD/95 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 REXECD/95 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 REXECD/95 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 REXECD/95 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 REXECD/95 Control Panel applet and that it actually exists.
• Be sure that you have saved the Security File as an ASCII text file. From a DOS 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 spceified in the Security File field.
• Be sure that the Security File is stored on a local hard drive, not a network drive.
• 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 REXECD/95 Control Panel applet. Then execute rexec or rcp from a system that should be given access, then examine the Message File. It will contain a trace of the steps REXECD/95 is using to validate the remote user and host.

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

When you execute console or MS-DOS programs using rexec, you will also see the standard output and standard error output of those programs. Console and MS-DOS programs are character-based and write output to the standard output/error, which REXECD/95 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 REXECD/95’s default configuration is being used):

Note the double backslashes (\\). If this rexec command is being issued from a Unix system, Unix uses the backslash as an "escape" character. To send a single backslash to REXECD/95, 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 rexec. (There are also some console and MS-DOS programs that write directly to the screen and their output cannot be returned either.)

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

For example, if you used the following command:

This would start Excel on the Windows system named "win95" (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 Windows system named "win95".

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 REXECD/95 to tell you that the program was not successfully executed.

Important Note: Winsock REXECD/95 uses the PATH and other environment variables specified in AUTOEXEC.BAT. If you are trying to execute a program that Winsock REXECD/95 cannot find, check the environment variables. You can also use an Environment Variable File to change the PATH; see the section on configuring REXECD/95 for more details.

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

Winsock REXECD/95 recognizes internal commands and will execute them through the command interpreter. Prefixing the internal commands with "command.com /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 REXECD/95 Control Panel applet. REXECD/95 will then recognize them and prefix them with your command shell.

You can optionally capture the standard output and standard error output of Windows Console or MS-DOS programs through Winsock REXECD/95 with the rexec 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 rexec to the remote program. This is known as redirection.

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

If you mostly execute Console or MS-DOS programs through REXECD/95, this default behavior of automatic redirection is the most useful. However, it does have some downsides when you want to execute graphical programs through REXECD/95 (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 REXECD/95 tries to redirect the standard I/O, even though there is none.
• When executing graphical or console/DOS programs with automatic redirection, REXECD/95 does not return control to the rexec command until the program executed completes. The rexec 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 rexec to execute graphical programs or console/DOS programs where you do not want rexec to wait until they complete, you can add the special "<[WIN]>" option in the rexec command. This tells REXECD/95 that it should not attempt redirection on this program only. For example:

This will start Excel on the system named "win95" and REXECD/95 will not attempt any redirection. The rexec command will end immediately after Excel starts; it will not wait until Excel exits. Without the "<[WIN]>", the rexec 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 REXECD/95 Control Panel applet. If you uncheck this option, REXECD/95 will not automatically attempt redirection, unless you specify the special "<[CON]>" option in the rexec command. This tells REXECD/95 that it should attempt redirection on this program only. For example:

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

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

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

Winsock REXECD/95 provides the ability for you to send keystrokes to a graphical Windows application you initiate using the rexec 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.

You cannot send keystrokes to an application started through Winsock REXECD/95 if there is no one logged in to Windows. The program will be executed, but it will not receive the keystrokes. When Windows is at a login window, other programs cannot receive keystrokes because Windows is waiting for you to log in.

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 rexec command is:

This will execute "command" on the host "hostname". Winsock REXECD/95 allows a slight modification of the rexec syntax to send keystrokes. This is compatible with all rexec 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 "win95" and type "This is a test" on the first line, the command would be:

If you looked at the win95'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 REXECD/95 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:

rexec win95 "<%FO\\docs\\invoice.doc~%FP~%FX>" word

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 rexec 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 rexec 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 rexec command line.

You will most likely need to specify a full pathname of the keystroke file on the system running Winsock REXECD/95, unless you know the working directory of Winsock REXECD/95 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 REXECD/95, you could use it with this command:

This would run "excel" on win95 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 rexec 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 rexec 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 win95. 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 rexec command line since the tif1.mac has ended. Then it continues by sending the keystrokes in the file \kb\tif2.mac. That is:

Winsock REXECD/95 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 REXECD/95 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).

REXECD/95 internally understands two special commands that allow you to remotely shutdown and reboot the Windows system through the rexec 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.

Winsock REXECD/95 also provides Remote Copy (RCP) Server capability. This allows you to copy files to and from a PC running Winsock REXECD/95 using a non-standard rcp command.

The standard rcp command uses the rsh protocol to initiate the connection to the host. Winsock REXECD/95 supports rcp copies from an rcp command that initiates the connection using the rexec protocol instead. This is

referred to as "RCP/X" in this documentation. Denicomp Systems has a version of the rcp command in its Winsock RCP/RSH/REXEC for Win32 package that supports the rexec protocol. This software works on Windows 95 and Windows NT systems only. For other operating systems, such as Unix, you would need to obtain source code for the rcp command and modify it to support rcp copies through rexec, so this capability may be of limited usefulness in that environment.

The difference between the standard rcp and "RCP/X" is that "RCP/X" will ask for a password; the standard rcp does not.

The following gives a few examples of how RCP/X is used, using Denicomp Systems' Winsock RCP/RSH/REXEC for Win32 package.

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

NOTE: The "-x" is a non-standard extension supported by Denicomp Systems' rcp command that tells rcp to use the rexec protocol instead of rsh.

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 REXECD/95 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 REXECD/95 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 REXECD/95 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 systems use carriage return (ASCII 13) and newline pairs for line delimiters.

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

Winsock REXECD/95 includes two utilities that allow you to control the operation of the Winsock REXECD/95 service.

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

To start it without using the Control Panel, use Start/Run, then type the name of the REXECD/95 installation directory (usually C:\WREXEC95), a backslash (\), then "wrexectl" (e.g. "C:\WREXEC95\WREXECTL"). Or you can get to a Windows DOS Prompt. Change to the directory where Winsock REXECD/95 is installed using the CD command, then type "wrexectl".

You can then do the following:

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 REXECD/95 Control Panel applet, REXECD/95 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:\windows\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 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 the Windows TCP/IP implementation. Often, your first rexec will be fast, then subsequent commands will be delayed by a few seconds. This delay is not caused by REXECD/95. It takes Windows a few seconds at times to notify REXECD/95 that there is a connection waiting. REXECD/95 processes the request very quickly once it is notified.

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

The root of this problem can be explained somewhat, although technical. After you issue the first rexec, 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 Windows system after you do an rexec to it.

As long as there are closed sockets in the TIME_WAIT state which were created by REXECD/95, 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 rexec 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 Windows 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 rexecd (or rshd).

The Windows 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 REXECD/95, so there is no work-around that we can employ to resolve it. It would require a change to the Windows TCP/IP stack.

Since it only occurs on subsequent rexec commands during the TIME_WAIT interval, which is four (4) minutes by default under Windows, as long as there are at least four minutes between each rexec from the same client, the delay will not occur.

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

Internet: support@denicomp.com

WWW: http://www.denicomp.com

Compuserve: 71612,2333