|
|
Working in the NeTraverse Merge environment
Each session under NeTraverse Merge runs in its own separate, protected virtual machine and cannot interfere with the operation of other NeTraverse Merge sessions or the UNIX operating system.
The NeTraverse Merge sessions do share file systems and system resources with each other and with the UNIX operating system. You might be the only person using your UNIX system, or you might be sharing it with others. For these reasons, you may notice some differences between the DOS or Windows environment under NeTraverse Merge and DOS or Windows on a conventional personal computer.
This chapter describes those differences.
NeTraverse Merge automatically makes the following devices available to DOS or Windows sessions:
For your Windows sessions, there is by default no drive D already set up. We suggest that you set up drive D to be a directory of you own where you keep your Data and Document files.
Note: Because the UNIX file system can often be much larger than a typical file system on a DOS or Windows machine, using a drive to access the entire UNIX file system can cause complications. One problem is that some applications search the entire file system, which does not take very long on a small PC, but can take a long time on a large or networked UNIX file system. For this reason, only the default configuration for DOS is set up with drive D providing access to the whole UNIX file system; the default configuration for Windows is to not have such a drive.
Drive J: The shared drive
Drive J is designated as the shared drive.
NeTraverse Merge system files and other shared files are located on this drive.
(E.g. The Windows files loaded from the Windows installation CD are
in the "J:\wincabs" directory.)
It also has some directories where you can easily share files with
other users.
These are subdirectories J:\share and J:\tmp.
Typically "J:\tmp" is the same directory as UNIX "/var/tmp".
Note that files might be automatically and periodically
deleted from /var/tmp, so only temporary files should
be placed in "J:\tmp".
Drive N: The CD-ROM drive
For Windows sessions (but not DOS sessions),
by default the first CD-ROM drive is
automatically (in most situations) set up to be accessible as drive N.
If you have more than one CD-ROM drive then you can set up other drive
letters to access them.
(Note: A DOS session can only access one CD-ROM drive.)
Ejecting the CD from the drive
NeTraverse Merge sessions access the CD-ROM drive via the UNIX CD-ROM driver.
Some UNIX CD-ROM drivers work more smoothly than others with NeTraverse Merge.
In particular, the way to remove a CD from the drive varies from the
effortless convenience typical of DOS and Windows systems (where just
pressing the eject button at any time ejects the CD) to the traditional
UNIX way of making you type in commands to allow the CD to be removed.
So if you are having trouble ejecting your CD while it is in use by a NeTraverse Merge session, here are is what is going on: The problem is that the UNIX CD-ROM driver is disabling the eject button when you first access the CD-ROM drive. By default NeTraverse Merge automatically closes the the CD-ROM device when 18 seconds elapse without any disk access, which re-enables the eject button.
So if you wait long enough you will be able to eject the CD. (You can change the timeout if you want by setting the environment variable "MERGE_CD_RELEASE_SECONDS" to the desired number of seconds. The default setting is in the file "/etc/default/merge". You can update the setting there to change it for all users.
You can also eject the CD before the timeout expires by first 'releasing' the drive and then pushing the eject button on the CD drive.
The startup directory
When you boot DOS on a conventional stand-alone personal
computer, your working directory is at the top or
root of the file system tree, and you own all files in the file system.
With NeTraverse Merge, your DOS sessions start on drive D: with the initial directory configured to be the same as your current UNIX directory at the time you start the session.
Your Windows sessions start with the initial directory configured to be at the root of your personal drive (normally drive C).
You can change these defaults by running the WinSetup utility in the Desktop environment and using the Start on personal drive option in the Drives and Filesystem view of the Personal Session Configuration window.
Alternatively, you can change your initial location
by using the "r" option from the UNIX command line.
For example, "dos +r" starts your DOS session with the
initial directory at the root of the personal drive, while
win -r starts your Windows session with the initial
directory configured to be the same as your current UNIX directory
(given that you have a UNIX drive available in your Windows
configuration that provides access to this directory, which it
probably does NOT with the default configuration).
File name issues
You can access any file or directory in the UNIX file system from
a NeTraverse Merge session, whether it is created with DOS, with Windows, or with the
UNIX system (provided that you have permission). In general, Windows applications
support long file names, so long UNIX file names can be used as is, but older
Windows and DOS applications are limited to short file names.
To deal with this problem on a regular Windows system, Windows provides a mapping of long file names to short names for those older applications. (This file name mapping is also known as "file name mangling.") NeTraverse Merge provides a similar file name mapping for those older applications. By default the mapping done on each user's private drive C is a standard Windows mapping. The mapping of file names on other parts of the UNIX filesystem is slightly different, but the difference should not concern most people.
Refer to Appendix C, "Filename mapping" for more detailed information about this subject.
Printing in the NeTraverse Merge environment
During installation, NeTraverse Merge creates a printer definition with the name default, which provides for printing to the default UNIX printer. (For this to work, there must be a default printer set up on your UNIX system.)
You can also create other printer definitions for other printers or to use special UNIX printer options. See ``Printer view -- Printer device definition'' in Chapter 5 for more information.
You use these named printer definitions to configure your Windows or DOS session to have a connection to the UNIX printing system.
Printing from a Windows session
To print from a Windows session, you first need to set up Windows for your printer as you would on a standard Windows PC. All the printer definitions automatically show up as selections in the "Add Printer" utility. In detail here are the steps to take:
(In many cases, if the exact model of your printer is not already listed in the selection models that Windows presents to you, you can select a similar model from the list, and it will work fine. You might even want to try this first before trying to track down the drivers disk that came with your printer.)
If you are having problems with printing, you can check the Trouble Shooting Guide's Problems with Printers help page.
Printing from a DOS session
Setting up for printing from a DOS session is not as easy as setting up
for printing from Windows.
To print from DOS to the UNIX printing system, you have print via
a "redirected LPT port".
You set this up in your WinSetup Personal Session
"dos" configuration.
In the "Devices" view there is a "DOS Printer" control that lets
you select a printer definition to have the output
of each DOS LPT port redirected to.
NeTraverse Merge stores printer output to any of the DOS LPT ports in a temporary file. It prints this output when more than 15 seconds have elapsed since the application sent a character to be printed. The timeout is needed because when DOS applications print to the LPT port there is no standard indication as to when the application has finished printing. If an application has normal delays of more than 15 seconds, then your printout can get split up or otherwise not print correctly. You can use the "DOS Printer" control to change that timeout to make it longer or shorter as needed.
Direct printing
You can also bypass the UNIX printing system if there is a special
need to do so.
This involves printing "directly" to the printer via the parallel port.
To do this requires that you "directly" attach the parallel port.
The WinSetup "Personal Session configuration" contains the setting for attaching parallel ports. It is in the "Devices" view "Other Devices" control. All the possible direct attach parallel ports are listed. Note that you might not be able to use some or any of the listed devices. To check, click on the "Detail" button. This brings up the "Custom Devices Detail Viewer". All the possible devices are listed in the top window. When you click on a device name in the top frame, the definition information is printed in the lower frame. In this case, you want to check for the "Access" setting. If is is "Root Only", then you do not have permission to attach to that device. (By default when NeTraverse Merge is installed, all the definitions have the access set to "Root Only".)
To change the access permission, you have to log in as root, and use the WinSetup System-Wide Administration "View/Create/Modify Device Definitions" utility. Refer to chapter 5 for information about using this utility.
Once the parallel port has been made available to a running Windows session, there are some things that can still prevent you from using the port:
If you are still having problems with printing, you can check the Trouble Shooting Guide's Problems with Printers help page.
Using networking under Windows
NeTraverse Merge supports two styles of networking under Windows: Winsock
and VNET.
Winsock style networking under NeTraverse Merge
NeTraverse Merge supports Windows applications that access the
network using the Windows Sockets Interface (WinSock Version 1.1).
Most modern networking applications, such as e-mail and news readers,
Internet browsers and file transfer applications use this
interface.
NeTraverse Merge provides its own WinSock libraries (WINSOCK.DLL and WSOCK32.DLL) which implement Windows networking functions by routing them through the underlying UNIX networking. Therefore, NeTraverse Merge does not require Windows networking components (such as TCP/IP) to be installed in order to support the applications.
To run WinSock applications under Windows, simply install them and start using them. If during installation you are given an option to install the WinSock libraries or TCP/IP, make sure you DO NOT install them, as they will overwrite equivalent NeTraverse Merge libraries.
The Windows Control Panel will show that no networking components are installed. This is as it should be because the low-level support is implemented by UNIX. (Of course, your UNIX system has to be configured to use the network.)
Because NeTraverse Merge must share the space of well-known networking ports with UNIX, and UNIX servers are always "listening" on these ports, NeTraverse Merge supports only WinSock client applications; it does not support WinSock server applications. For example, the Netscape browser is supported under NeTraverse Merge, while the Netscape server is not.
This virtual network interface is connected by NeTraverse Merge to your real network adapter in such a way that the host UNIX system does NOT need to be configured to make it work.
VNET networking does require that you provide a unique IP address to identify each installation of Windows. The network mask, gateway address, domain name, and Microsoft network configuration information must also be specified, just as you would have to do with real Windows machine on your network.
This provides access to "Network Neighborhood" style of browsing, file, and printer sharing over TCP/IP network connections.
Applications requiring Winsock 2 functionality are also supported under VNET. This increase in functionality comes at the expense of increased complexity of configuration and system overhead. If you do not require the increased functionality, it is recommend you use the default Winsock style of networking.
NOTE:
This release of VNET networking requires all services to be implemented
over TCP/IP.
Because of this, IPX/SPX is not supported.
This release of VNET networking also requires that each
simultaneously used Windows session have a unique IP address.
These IP addresses cannot be dynamic because DHCP is not supported.
At Windows installation time you have to select either Winsock or VNET networking. You can later upgrade from Winsock to VNET type networking. Refer to Upgrading to VNET Networking.
(Note: VNET networking is only available with the OpenServer version of NeTraverse Merge.)
Installing applications
In general, you can install most applications under NeTraverse Merge
simply by following the application
manufacturer's instructions for installing on a fixed disk.
The main exception is with Windows VxD drivers.
Installing an application or device driver that includes a VxD
might cause the Windows session to hang or abort every time it is started.
If you have installed a VxD driver that is not supported, you can try to recover by using the following procedure. (This example assumes that your C drive directory is located at $HOME/win".)
cd $HOME/win/windows/system ls -lctr | grep -i 'vxd' cd vmm32 ls -lctr | grep -i 'vxd'Take note of the most recently added VxD files.
mv fancydev.vxd fancydev.vxd.bad
You will probably get a message about a needed VxD that is missing, but you should be able to press <Enter> and continue.
You might have to move the VxD file back to its original name before doing this in order for the package removal to work correctly.
Start a NeTraverse Merge DOS session with the Windows session configuration:
dos +w &
Edit the file cur.reg, which has an ASCII (editable) version of your Windows Registry.
C> regedit /e cur.reg
Search for the entries associated with the suspect VxD and delete them. Save the file and quit the DOS session.
Then, rebuild the registry with:
dos +w &
C> regedit /c cur.reg
You should now be able to start Windows successfully.
Cutting and pasting between Windows and X applications only works when the X Cut & Paste feature is enabled.
By default, your Windows session starts with the X Cut & Paste option turned off, since it does consume system resources. You can turn this option on and off using the X Cut & Paste option from the Options menu. To change your NeTraverse Merge configuration so that cutting and pasting between X and Windows applications is available when you start Windows, see `` X Cut & Paste'' in Chapter 4.
When you want to copy from a Windows application to an X application, make sure the X Cut & Paste option is turned on and use the Cut or Copy mechanism provided by your Windows application. NeTraverse Merge makes this information available to your X application for pasting.
When you want to copy information from an X application to a Windows application, use the mechanism the X application provides for cutting or copying. NeTraverse Merge supports either X cut buffers or the X clipboard selection. NeTraverse Merge passes your information to the Windows Clipboard, where it is available for pasting into your Windows application using the standard Paste mechanism.
NeTraverse Merge also supports the sharing of X text, bitmap, or pixmap formats and Windows text, bitmap, DIB, and OEMTEXT formats.
Depending on system performance, system load, and the amount of data you copy, you may need to wait a few seconds before your information appears in the target clipboard. A status bar at the bottom of your window tells you when the information is complete.
When the X Cut & Paste option is turned on, more CPU and memory resources are used than normal. So, you typically should only have this option turned on when you are actively cutting and pasting between Windows and an X application. Also, you may have memory resource limitations with your X server when copying large items, so copying in smaller chunks may work better in some situations.
Whether or not you can inspect or modify other users' files depends on how UNIX permission modes are set on your system. All files and directories you create or access via UNIX file system drives are protected by these permission assignments. See the umask(1) and chmod(1) commands for more information.
Normally, you should not allow other users to access the files or directories on your personal drive. Some of the optimizations that NeTraverse Merge uses to run Windows efficiently depend on only you having access to your personal drive.
If you have data files you want to share with everyone on your UNIX system, you should put them in the share directory on the shared drive J. You can create subdirectories there if you want to organize the shared files. You can also set the UNIX access permissions so that only certain groups of users can access these directories.
To share access to files that are not or cannot be put under the share directory, you can update your drive configuration to have a drive letter for accessing any directory of your choice on the UNIX file system (if the directory permissions allow it). Each NeTraverse Merge user can do the same so that all can use the same drive letter to access the same location.
NOTE: You should not create drive letter aliases that allow
users to get to your personal (C:) directory. Shared files should be in a
directory outside the scope of your or anyone else's personal drive.
File and record locking
Many current applications, especially network versions,
use DOS file- and record-locking facilities.
NeTraverse Merge supports the standard DOS file- and record-
locking conventions.
An application that uses DOS file-locking opens files in such a way that other applications cannot access the file until it is closed. This prevents the file from being modified by more than one user at a time. Similarly, an application using record-locking opens files in such a way that no one else can access a particular record in that file while you are working on it.
Attempts to simultaneously access a file that is locked by another application may result in the following type of message:
Sharing violation reading drive D:
Some applications' executable files can be shared only if they are read-only. Use the DOS attrib or UNIX chmod command to set the file permissions for these executables to read-only when you want multiple users or processes to be able to read the file at the same time or to execute the application at the same time.
Note: Doing file and record locking on a drive that accesses files
via NFS is generally Not A Good Thing.
This is because often NFS is not configured to enable locking because
when locking is enabled performance can really suffer.
In addition to enabling NFS file locking, to have your NeTraverse Merge
session able to file and record locking on such a drive, you need to enable
"Unix file locking". (Refer to chapter 4 section
Unix file locking options
for info about enabling this setting for a drive.
Increasing record-locking table sizes
A Windows sharing violation can occur if NeTraverse Merge runs out of internal
record-locking table space. NeTraverse Merge attempts to
warn you with a message indicating whether the File Table, the Open-File Table,
or the Lock Table has run out of space.
To increase the table size:
Table Type Parameter Name Default Value ---------- -------------- ------------- File Table MERGE_RLOCK_FILETABLE_SIZE 512 Open-File Table MERGE_RLOCK_OPENTABLE_SIZE 768 Lock Table MERGE_RLOCK_LOCKTABLE_SIZE 1024
Doubling the existing value for the table that is out of space is generally more than sufficient.
File creation error that does not clearly indicate the
nature of the problem.
Where to install network applications
To share the application only with users on the local UNIX system,
you can install the application in a subdirectory of J:\share
because this location is available to all NeTraverse Merge users on
the local UNIX system.
You can also install it in any other directory
on the local UNIX file system to which you have access,
or even on a remote file server to which
the UNIX system has access.
When you do this, you should change your personal NeTraverse Merge session
configuration to have a drive letter assigned to access the directory
where you want to install the application.
Then, each user that wants to use the application can change his or her
configuration in the same way in order to use the application.
File permission issues
Many network applications, once installed, do not create or update
files in the location where they are installed.
When you have such an application, for security purposes, you should
make the directory where the application is installed and all its
subdirectories and files read-only.
Generally, the application's executable files
(e.g., those file with the extension .exe or .dll)
should not be writeable.
Typically, the application's installation program automatically
does this, but some installation programs do not.
So, if more than one user cannot use the application at one time,
or if users get sharing errors, you should make sure
that the application's executable files are read-only.
Limiting access to public applications
You can limit who is allowed to use shared applications by using
the group permission concept that the UNIX file system uses.
Refer to the documentation on the UNIX
chmod(1)
command for more information.
About autoexec.bat and config.sys files
DOS interprets the commands in two special files
automatically every time you start a DOS or Windows session.
These files are autoexec.bat and config.sys.
Because different users may want to include different commands in their autoexec.bat or config.sys files, NeTraverse Merge provides for the following:
The config.sys files contain information about your computer's configuration that the system needs to know every time you run DOS. In addition to the system-wide config.sys file, you might want a personal config.sys file that identifies device drivers required by applications that only you use. And, if there are device drivers that you want to load only when you run certain applications, you might want to include them in a specialized config.sys file that you use only in that application environment.
In general, NeTraverse Merge interprets the commands in a config.sys file
just as a conventional DOS system does.
Refer to
the following section
for a list of commands that cannot be used in a config.sys file.
Restricted DOS commands
Nearly all standard DOS commands operate in the NeTraverse Merge
environment just as they do on a conventional
stand-alone DOS computer.
Some DOS commands, however, are either not usable in the
NeTraverse Merge environment or operate differently than they do on a
stand-alone DOS computer.
NeTraverse Merge emulates DOS file systems while preserving the underlying UNIX file system structure, which is completely different. Some DOS commands do not work on emulated file systems.
If you issue a DOS command that does not work in the NeTraverse Merge environment, DOS displays an error message. This does not harm your computer in any way or destroy any data.
You cannot use the following DOS command with NeTraverse Merge:
Do not use the following commands on UNIX file system drives. You may use them on true DOS file systems such as your diskette drives or DOS file system drives:The following commands affect only the current DOS or Windows session:
The following commands are ignored when they appear in config.sys files:
NeTraverse Merge uses built-in values for some of these commands. If you need to change those values, see ``Making config.sys changes'' in Chapter 5.set at the DOS prompt.
Providing a drive mapping in Windows to a directory shared by many users on the UNIX system (e.g., /tmp) will create problems with Recycle Bin operation. Not all users will be able to empty their Recycle Bins using the "Empty Recycle Bin" selection from the Recycle Bin's pull-down menu. (Right click on the Recycle Bin icon.) While every user will be able to delete individual files they put in the Recycle Bin, the Recycle Bin icon may show content even when the user sees no files listed in their Recycle Bin.
One way to solve the problem is to have each user with a drive mapping to a common access directory on the UNIX system execute this simple procedure: