This chapter outlines several alternative options for installing and using SoftWindows on a Unix network.
It also discusses the factors affecting the performance of SoftWindows and tells you how to tune them effectively.
For information on how to install SoftWindows, Microsoft Windows, and Windows and MS-DOS applications in various configurations, refer to the following sections of the SoftWindows documentation.
SoftWindows – see Chapter 3, “Installing SoftWindows”.
Microsoft Windows – see Chapter 5, “Windows configuration”.
Microsoft Windows applications – see “Using Windows” in the SoftWindows 2.0 for Unix User's Guide.
MS-DOS applications – see “Using MS-DOS” in the SoftWindows 2.0 for Unix User's Guide.
Install SoftWindows on the local workstation.
Install applications on the local workstation.
Run SoftWindows on the local workstation.
This option provides the best SoftWindows performance since the user's network does not play a major role. However, one of the disadvantages is that SoftWindows can take up a significant amount of total hard disk space since each user needs to have SoftWindows, Microsoft Windows, and MS–DOS applications installed on the local hard disks.
The best SoftWindows performance because all files are accessed from the local hard disk, and there are no network load issues involved in running SoftWindows files.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Complete control over environment.
Stand-alone operation – do not have to rely on the operation of the network.
Install SoftWindows on the local workstation.
Install applications on an NFS server.
Run SoftWindows on local workstation.
This option generally provides lower performance than Option 1 because SoftWindows has to access the network when running each application. However, this allows the user to have one installation of each application, thereby saving hard disk space. Furthermore, upgrading an application only needs to be carried out once on the NFS server instead of on each local workstation as in Option 1.
Fast SoftWindows performance.
If the NFS mount is fast, this option could be as fast as Option 1.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Requires less local hard disk space than Option 1.
Application and user files can be centrally managed and upgraded from the NFS server.
Install SoftWindows on the local workstation.
Install applications on a PC LAN file server.
Run SoftWindows on the local workstation.
This option generally provides lower performance than Option 1 because SoftWindows has to access the network when running each application. However, this allows the user to have one installation of each application, thereby saving hard disk space. Furthermore, upgrading an application only needs to be carried out once on the PC LAN file server instead of on each local workstation as in Option 1.
Generally good SoftWindows performance.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Requires less local hard disk space than Option 1.
Application and user files can be centrally managed and upgraded from the PC LAN server.
Applications can be shared with the users using real PCs and SoftWindows PCs on the PC LAN server.
Typically slower than Option 1 or Option 2.
Requires up to 75 Mbytes of hard disk space on each local workstation.
The SoftWindows software updates have to be applied to each local workstation.
Accessing application and user files from a typical PC LAN via PC networking software is generally slower than accessing the same files from a typical NFS server.
Only one local SoftWindows instance at a time can use the applications on the PC LAN file server; that is, multiple SoftWindows instances and/or processes on the same workstation cannot simultaneously access the PC LAN file server.
Install SoftWindows on an NFS server.
Install applications on an NFS server.
Run SoftWindows on the local workstation via NFS.
Create SoftWindows C: drive for each user on the NFS server.
This differs from Option 1 in that all of the SoftWindows files are installed on the NFS server instead of on the local workstation.
Saves local workstation hard disk space since only the server needs to have a copy of the SoftWindows and application files.
If the NFS server access is at least as fast as local hard drive access, this option could be nearly as fast as Option 1.
SoftWindows and application updates need only be applied to the server.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Local workstations may be diskless.
Accessing SoftWindows and application files from an NFS server is generally slower than accessing them from a local hard disk.
There is read-only access to SoftWindows hard disk files for all users except the first.
This can be avoided by creating separate hard disk files for each user on the server or local workstation.
Possible problems with NFS and SUID bit permissions.
SoftWindows files are split between the local workstation and an NFS server.
Install applications on an NFS server.
Run SoftWindows on the local workstation via NFS.
Typically used when local workstation hard disk space is valuable, but performance is a major consideration. This option is the same as Option 4, but with some possible performance improvements as a result of having some key SoftWindows files installed on the local workstation.
The size of the SoftWindows footprint on the local workstation's hard disk can range from 5 Mbytes to 20 Mbytes, depending upon how SoftWindows is split.
Optimization of the smallest local workstation footprint with the best performance.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Accessing SoftWindows and application files from an NFS server is generally slower than accessing them from a local hard drive.
After the first user launches SoftWindows other users have read-only access to the SoftWindows hard disk files.
This can be avoided by creating separate hard disk files for each user on the server or local workstation.
Possible problems with NFS and SUID bit permissions.
All of the local workstation's SoftWindows files must be updated when software updates are applied to SoftWindows on the NFS server.
Install SoftWindows on a remote Unix workstation.
Install applications on a remote Unix workstation.
Remotely run SoftWindows on the remote Unix workstation, but display it on the local workstation via an X Server.
This option enables X terminals and Unix workstations with X Windows to run SoftWindows via an X server display. SoftWindows and the applications are installed on the remote Unix workstation, and multiple instances of SoftWindows are run on the remote Unix workstation and displayed via an X server on the local workstation or X terminal.
Can be used with X terminals.
Does not use any local workstation space for SoftWindows or application files.
SoftWindows and application updates need only be applied to the remote Unix workstation.
The performance of the local workstation is impacted only by the X server display operations and not the SoftWindows or application executables.
The performance with an X server display may be significantly better than with the other options on the same workstation.
The performance seen on the local X server display is a function of the performance of the remote Unix workstation running SoftWindows, the network performance, and the local workstation's load in handling X server functions.
Accessing SoftWindows files over the network may be slow.
Running multiple copies of SoftWindows on a single remote Unix workstation can quickly reduce the performance of each of the local workstations on their local X server displays.
Only one instance of SoftWindows can access PC networking (via SoftNode) at a time on a single workstation. This means that when there is more than one instance of SoftWindows running, only one instance can use the PC networking.
One possible solution to this SoftNode limitation would be to store any data or applications files on an NFS server or on the remote workstation, and then use FSA drives to concurrently access the files from multiple instances of SoftWindows running on the same or multiple Unix workstations.
SoftWindows will typically only see the remote Unix workstation's devices and therefore cannot directly use the local workstation devices, such as floppy drives, CD-ROM drives, and comms ports.
Only one user can access a server device at a time.
After the first user launches SoftWindows other users have read-only access to the SoftWindows hard disk files.
This can be avoided by creating separate hard disk files for each user on the server or local workstation.
The recommended amount of memory for workstations running SoftWindows is 64 Mbytes. It will run on 32 Mbyte machines but performance will be suboptimal.
The recommended SoftWindows session size is 8Mbytes. The Unix process size will be approximately 25 Mbytes, leaving the Unix kernel and X server with 7 Mbytes of real memory. This is unlikely to be sufficient, and swapping will result leading to a degradation in performance of both SoftWindows and other processes running on that machine.
To run Windows applications under SoftWindows the recommended amount of PC memory is 8 Mbytes, as on a real PC.
Certain resource-intensive applications, such as Microsoft Word 6 and Excel 5, require 8 Mbytes of PC memory for optimum performance.
Allocating too much PC memory can reduce performance in some circumstances, depending on the amount of physical memory in the machine, and the other processes running on the machine, since swapping may result. We recommend that you increase the PC memory gradually until any resulting increase in performance levels off. Adding more PC memory after this point could reduce performance.
SoftWindows uses host memory to support the 486 emulation in addition to the memory used to emulate PC memory. It is possible that adjusting the amount of host memory dedicated to the 486 emulation can improve performance. By default, the 486 emulation is allocated the maximum value of 8 Mbytes, or 1024 code buffers. You can change this by setting the environment variable Soft486Buffers.
LIM is supported within SoftWindows via a LIM emulator which makes use of PC memory. For performance reasons, we recommend that you do not configure SoftWindows to use LIM unless your application requires it to run because using LIM entails a performance overhead. Refer to Chapter 4, “Setting up memory”, for information on how to configure LIM if required.
The 80486 supports paging, allowing pages of data from memory to be swapped to secondary storage. If your host machine has limited memory and you know that you are going to have to endure a certain amount of swapping, you have the choice of either getting Microsoft Windows to handle its own swapping or allocating enough memory to SoftWindows to alleviate this. In the second case, the host machine handles the swapping.
Although a diskless node has its own memory, it uses the server for its operating system. Also, because the node's disk is shared with the server, paging is carried out by the server, not by the diskless node. This will have a compounded effect if a user tries to run more than two versions of SoftWindows at a time. Refer to “Physical memory” for more information.
The configuration of the user's network also affects the use of SoftWindows on a diskless node since SoftWindows will need to access the network for everything; this could cause a degradation in performance, particularly if the network is slow and unreliable.
When SoftWindows is actively running a PC or Windows application it will attempt to use 100% of the Unix host's available CPU – just as the application uses 100% of a real PC's 80486 CPU cycles.
If you run several SoftWindows sessions concurrently on the same machine, they will share the host's CPU resource. For example, if two SoftWindows sessions are running simultaneously on the same machine, each will use at most 50% of the host CPU resource; they will therefore run at half speed when they are both active.
The performance of SoftWindows is reduced when it is displayed remotely because display data and input from the keyboard and mouse has to be transferred over the network.
A 256-color bitmap can be quite sizeable in terms of the amount of data which must be transmitted. A remote display may also affect the networking (SoftNode) component of SoftWindows since, for particular protocols on particular platforms, SoftNode sees all the packets that the host machine sends, including any packets resulting from having a remote X display.
For best performance use an 8-bit graphics card. A 24-bit card can degrade performance, unless the card is very fast.
There may also be an issue when using Microsoft Windows with 256 or 16 colors. There have been some instances of a graphics card having a problem with one color setting while working fine with the other. An example of this is the Sparc ZX card. In tests, SoftWindows ran slower when in 16-color mode than in 256-color mode. It should be noted that the results were very host-specific.
Another option which produces a performance improvement is the use of the -backing_store option with SoftWindows. This option makes use of the backing store facility if it exists on the user's machine.
If, while using the -backing_store option, SoftWindows suddenly stops refreshing the screen, then the problem may be the X server. If the server runs out of memory, the backing store facility simply disappears. If SoftWindows has not refreshed the windows since you launched it, you may have to restart your X server with an option enabling the backing store feature.
Whether you are using SoftWindows in MS-DOS only or within Windows, the larger the SoftWindows screen size selected, the slower SoftWindows will tend to run.
If the application displays larger bitmaps as a result of a larger screen size, this results in much more data being sent to the X server which can degrade performance.
If the Window is too small, the application does its own clipping within the emulation. For example, too small a Window size can cause Windows scroll bars to be displayed. This can also impact performance.
You may wish to select various screen sizes to see which best suits your application. Beware of having screen sizes which occupy the entire X display or even are partially off screen, since this is known to severely degrade performance with certain window managers because of the extra clipping work required on each X request.
SoftWindows can be run on an X terminal connected to a Unix server. Note, however, that the areas of concern highlighted in the Local Display versus Remote Display and Physical Memory sections apply to the use of SoftWindows on an X terminal.
Running an application on an X terminal uses up some of the resources of the Unix server to which it is connected.
Also note that Microsoft Windows performs numerous offscreen bitmap operations which SoftWindows delegates to the X server, and this uses the local X terminal memory. The amount of physical memory an X terminal has can impact these types of operations. With the X server using some of this memory as well, you may need to add more physical memory to the X terminal. The amount each terminal requires is very host-specific, and also depends upon the X server being used.
For HFX drives where the user knows that all files are DOS/Windows files in standard 8.3 format, HFX file access can be improved in certain circumstances. For example, if you are accessing an OS/2 file system, use the NET USE /CS command to disable the filename mapping facility, since it would be unnecessary on an 8.3 file system. For more information refer to Chapter 11, “NET USE”.
If SoftWindows is being run on a multiprocessor host, a performance improvement may be seen by ensuring that SoftWindows runs on a different processor than the X server. If the host is to run multiple SoftWindows sessions, it would be best to run each session on a different processor if sufficient processors are available.
Due to the mechanism used by SoftWindows to provide PC LAN connectivity, users may experience a slight degradation of SoftWindows network performance on busy networks. Where possible, SoftWindows PC networking drivers are passed only the network packets required by the PC network client software. However, if the SoftWindows user requires Unix connectivity using TCP/IP, the SoftWindows networking drivers will also receive the host's own TCP/IP traffic which must be rejected. This extra filtering can cause a slight increase in workload on the PC emulation.
It is recommended that when SoftWindows-based TCP/IP client software is used, the SoftWindows session should not be displayed on a remote display. Displaying remotely increases the overall network load on the PC-based TCP/IP stack.
In general, the SoftWindows networking drivers are passed the same amount of information as would be passed to a real networked PC and are subject to the same environmental conditions. Extra CPU resources or memory will not solve problems caused by a poorly structured, badly designed, or incorrectly routed local area network.
SmartDrive causes a performance degradation of 2%–5%. If you have moved SmartDrive to the Startup program group, it is recommended that you disable it in SoftWindows by moving the SmartDrive icon out of the Startup program group.
The SmartCopy utility can cause a delay when switching to the SoftWindows window from another X application after selecting a large amount of data due to the time taken to copy the data selected in the X application to the Microsoft Windows clipboard. Depending on the amount of data involved, this can take a second or two.
Microsoft Windows applications that pause between tasks can activate the SoftWindows WinIdle utility, causing SoftWindows to go idle, seemingly reducing performance and slowing down the application. If this causes problems, remove WinIdle from the Windows Startup folder.
If you wish to run only MS-DOS (non-Windows) real mode applications under SoftWindows, configure the minimum amount of PC memory, 1 Mbyte. This will ensure that SoftWindows uses the minimum amount of the system resources and gives the best performance of the system as a whole.
When using the SoftWindows LIM expanded memory emulator, configure the corresponding amount of extra PC memory.
If you want to make SoftWindows available to additional workstations, either install SoftWindows on each workstation or remotely mount the original SoftWindows installation on each workstation.
In either case you need a license for each copy of SoftWindows you want to run concurrently.
To mount a copy of SoftWindows on a second workstation, proceed as follows:
Mount or link the remote $SWIN2HOME to a local $SWIN2HOME.
For example, using an NFS mount type the following commands as root at the Unix prompt on the second host:
mkdir install mount sourcemachine:install install
where sourcemachine is the name of the workstation where SoftWindows was physically installed, and install is the SoftWindows installation directory.
Alternatively, you can use automounter, assuming the following line has been included in the automounter mapping file on the second host:
/net -hosts
by typing the following command at the Unix prompt on the second host:
ln -s /net/sourcemachine/install install
where sourcemachine is the name of the workstation from which you are installing and install is the SoftWindows installation directory.
Run SoftWindows in the usual way by typing, for example:
install/bin/swin2
To install SoftWindows on a second workstation proceed as follows:
Install SoftWindows as normal, but remove the $SWIN2HOME/FLEXlm/license.dat file if present.
Either:
Edit the user's “.cshrc”, “.login”, or “.profile” file to include a line that specifies a valid license file in the network.
For example, in the C shell, add the following single line to “.cshrc:”
setenv LM_LICENSE_FILE /hosts/machine/usr/lib/SoftWindows2/FLEXlm/license.dat
Or:
Link the primary license file to the secondary installation. When a link is created, new licenses can be generated from SoftWindows without having to copy the license file around the network.
For example, enter the following command (all on one line):
ln -s /hosts/machine/usr/lib/SoftWindows2/FLEXlm/license.dat install/FLEXlm/license.dat
SoftWindows can be configured to run in a secure mode, which is designed to allow the system administrator to configure an installation so that users have access only to specific PC applications and cannot change the configuration of SoftWindows itself.
Secure mode provides the following features:
Users run a standard configuration of SoftWindows and cannot modify that configuration.
SoftWindows is prevented from booting from a floppy disk in drive A:. If configured, drive A: can still be used for normal file storage operations by MS-DOS and Windows programs.
The MS-DOS boot modifier keys, 5, 8, and S are disabled so that users cannot modify the boot sequence.
The MS-DOS control key combinations, Ctrl-C, Ctrl-B, and Ctrl-alt-del are disabled so that users cannot exit from application programs.
SoftWindows can be set up so that SoftWindows terminates when the user exits from an application.
This section describes the recommended procedure for setting up a user to run in the secure mode.
Log in as the user, and start SoftWindows to set up a hard disk file and any required FSA drives to run the required PC application.
Add the following command to the user's AUTOEXEC.BAT file:
C:\INSIGNIA\SECURITY.COM Exit from SoftWindows and save the configuration.
Log in as root and use a text editor, such as vi, to edit the SoftWindows system configuration file install/sys.swin2config to use the hard disk containing the PC application as set up by the first step, and with any other configuration settings required (communications port, floppy device, display size, and so on).
After editing sys.swin2config, ensure that it is owned by root and has the SUID bit set. If necessary, log in as root and cd to the SoftWindows installation directory. Then enter the commands:
chown root sys.swin2config chmod 4444 sys.swin2config
You may find it useful to refer to the configuration previously saved to the user's configuration file, $HOME/.swin2config.
You cannot simply copy the user's configuration file over the system configuration file, because the system configuration includes some additional lines.
For more information about the system configuration file refer to Chapter 7, “Configuring SoftWindows”.
Carry out any further configuration of the Unix system which is required to run the PC application securely.
This may involve changing ownership or permissions of files or directories in the user's environment or which are used through FSA drives.
For security purposes you may wish to restrict access to user files run during the Unix login process and configure the user's account to use a restricted shell.
Ensure that there is not a “.swin2config file” in the user's home directory, and that SWIN2HOME and other environment variables are set appropriately to use SoftWindows when the user logs in.
Log in as the user, and check that the PC application runs as required.
When SoftWindows boots, it will notify you that the user does not have a configuration file. At this stage the SoftWindows menus are still enabled, so you can check the configuration. Make a note of any configuration changes that are required so that they can be added to the system configuration file.
Edit the SoftWindows system configuration file $SWIN2HOME/sys.swin2config, and change the configuration entry SECURE from No to Yes.
Ensure that $SWIN2HOME/sys.swin2config is owned by root and has the SUID bit set.
This is necessary because editing the file manually may clear the SUID bit. If necessary, log in as root, and from the $SWIN2HOME directory enter the commands:
chown root sys.swin2config chmod 4444 sys.swin2config
The user will now only be able to run SoftWindows in secure mode.
For maximum security, it is recommended that SoftWindows be installed on the workstation on which it is to be executed. Running SoftWindows across an NFS mount to another workstation may not be as secure in some situations as in others.
If the PC application you are using can be exited by the user, you may find it useful to run it from a batch file that includes a reference to the utility C:\INSIGNIA\EXITSWIN.COM, which causes SoftWindows to exit.
For maximum security, it is also recommended that configuration entries in $SWIN2HOME/sys.swin2config should not use environment variables (such as $HOME) to locate hard disk files, FSA directories, and so on. Otherwise the user could set the environment variable to use an alternate directory.
If you wish to prevent users from writing to hard disk files, it may be useful to make the hard disk read-only, and to set the configuration option, RO_DISK_PANEL_DISABLE, in install/sys.swin2config.