Working in the SCO Merge environment
The DOS or Windows environment that is created when you start a SCO Merge session has all the important characteristics of DOS or Windows on a conventional personal computer.
Each session under SCO Merge runs in its own separate, protected virtual machine and cannot interfere with the operation of other SCO Merge sessions or the UNIX operating system.
The SCO 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 SCO Merge and DOS or Windows on a conventional personal computer.
This chapter describes those differences.
SCO Merge automatically makes the following devices available to DOS or Windows sessions:
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 not.
Although accessing the UNIX file system from the
top can be very useful, it is sometimes better to configure drive D
to access a more restricted part of the UNIX file system. Moreover,
if all the files you need to access are on drives C and J,
it might be better not to have drive D at all.
See
``Configuring drives''
in Chapter 4
for more information about customizing your drive setup.
Drive J: The shared drive
Drive J is designated as the shared drive.
DOS and
related SCO Merge system files are located on this drive.
It also has some directories where you can easily share files with
other users.
These are subdirectories J:\share and J:\tmp.
Note that files are automatically and periodically
deleted from J:\tmp, so only temporary files should
be placed there.
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 SCO 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 Merge Setup utility in the Desktop environment and using the Start on personal drive option in the Drives and Filesystem view of the Personal Merge 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).
Accessing files with invalid DOS names
You can access any file or directory in the
UNIX file system from a SCO Merge session,
whether it is created with DOS, with Windows, or with the UNIX system
(provided that you have permission).
However, many legal Windows 95 and UNIX system
file names do not conform to DOS rules.
These include:
Generally, SCO Merge creates a mapped name by appending a unique index consisting of an apostrophe or tilde followed by one or more characters. If necessary, SCO Merge truncates the original name before appending the index. Characters that are not valid for DOS file names, such as the space or the plus sign, are either replaced with an underscore or removed. For example, a file called messagetoall might be mapped to the name MESS'BAQ. You use the mapped names with DOS or Windows 3.1 applications whenever you need to refer to files or directories that do not have legal DOS names.
The following table shows how SCO Merge might map various types of Windows 95 or UNIX names.
--------------------------------------------------- UNIX name Mapped name --------------------------------------------------- messagetoall MESS'BAQ message.tobob MESS'BBF.TOB +.ok _'PP.OK okbase.:++ OKBAS'QW._ _ _ a.b.c A_B'SV.CSee ``File name mapping options'' in Chapter 4 for more information about the file-name mapping settings in your drive configuration.
The udir -a option displays all UNIX files, including hidden files, whose names start with a period and are normally not displayed in a directory listing.
You can only the udir command when the current directory is on a drive that shows the entire UNIX filesystem, such as the default D drive.
You cannot use the udir command when you are running Windows 95.
With Windows 95, use the dir command instead.
This command shows both the mapped and actual file name.
Accessing files with uppercase names
On plain DOS file systems, the case of the letters in file names
is completely insignificant.
(Windows 3.1 uses plain DOS file systems.)
With Windows 95 file systems, the case is maintained, but only for
human readability.
You can access the same file regardless of the case of the file name you use.
But, with UNIX file systems, the case is significant.
For example, the file names my.txt, My.txt and MY.TXT are names for
three completely different UNIX files.
But, on DOS or Windows 95 file systems, these names all refer
to the same file.
So, when SCO Merge provides access to the UNIX file system for DOS or Windows,
there can be some confusion about the file being referenced.
SCO Merge has two ways of working around this problem.
Here is a quick overview:
See ``File name mapping options'' in Chapter 4 for more information about the uppercase file-name mapping settings in your drive configuration.
By default, SCO Merge sends all DOS and Windows printing jobs via the UNIX spooler to the default UNIX printer. This printer is always named doslp.
This printer is automatically available if, prior to installing SCO Merge, you have a UNIX printer properly configured on your system. If a printer is not available at that time, but is added later, the system administrator will need to configure doslp before you can use it in your DOS and Windows sessions. You can also configure other local or remote UNIX printers for use under SCO Merge. See ``Printer administration'' in Chapter 5 for more information.
Printer not ready.To print from these applications, you should attach the printer directly to the DOS or Windows process rather than use the UNIX spooler. For information on directly attaching the printer, see ``Directly attaching printers'' in Chapter 4.
Printing from a DOS session
All standard DOS print functions work in the SCO Merge
DOS environment.
These functions include the print command, the copy
command, and printing operations performed by DOS applications.
SCO Merge stores printer output to any of the DOS parallel ports (LPT1, LPT2, or LPT3) in a temporary file. It prints this output when more than 15 seconds have elapsed since the application sent a character to be printed. (15 seconds is the default timeout; see ``Printing through the UNIX system spooler'' in Chapter 4 for instructions on changing it.)
Printing from a Windows session
To print from a Windows session, you first need to set up your Windows printer as you would on a standard Windows PC.
Setting up printers in Windows 95
If you are using Windows 95, follow these steps to set up a
printer:
Setting up printers in Windows 3.1
If you are using Windows 3.1, Windows 3.11, or Windows for Workgroups, you should have the Merge network printing driver installed under Windows. See ``The DOS Merge network printing driver'' in Chapter 2 for information.
To print from a Windows session, a printer must be attached to that session. By default, the UNIX printer doslp is always attached to ports LPT1, LPT2, and LPT3. If you have other printers configured on your system that you would like to use under Windows, see ``Using printers'' in Chapter 4 for information on how to attach them.
Once the printer is attached, you can configure your Windows session to print to the appropriate LPT port using the Windows Print Manager as follows:
Using networking under Windows
SCO 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.
SCO 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, SCO 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 SCO Merge libraries. (If you inadvertently install Microsoft networking, you might be able to remove it and restore the system by running /usr/bin/fixWin95symlinks, but this is not guarranteed.)
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 SCO Merge must share the space of well-known networking ports with UNIX, and UNIX servers are always "listening" on these ports, SCO Merge supports only WinSock client applications; it does not support WinSock server applications. For example, the Netscape browser is supported under SCO Merge, while the Netscape server is not.
16-bit WinSock applications are supported under Windows 3.1, Windows 3.11 and Windows for Workgroups. 16-bit and 32-bit applications are supported under Windows 95.
Installation searches
During installation, many applications look for
a previously installed version by searching all available drives.
In the SCO Merge environment, depending on how much of the UNIX file system
you have available to your session,
searching all UNIX file system drives can take a long time,
especially if you have remote networked file systems available.
It may take so long that it can appear as if your application has hung,
when, in fact, it is just taking a long time to search
through all of the file systems.
To save time, you can change your SCO Merge configuration
to disconnect the drives that you do not need to search,
or re-define the UNIX drives to access much smaller portions of the
UNIX file system.
For more information, see
``Configuring drives'' in
Chapter 4.
Special installation tips for DOS applications
Most applications are installed with a program called
install or setup, which is
run from an installation diskette or CD.
DOS applications typically have more installation options than Windows
programs.
In these cases, installation programs generally prompt you
for specific information about their environment.
Because of this, it is important to install the DOS application in
a way compatible with SCO Merge.
Keep the following in mind when responding to
these prompts:
VGA).
VGA display modes are only supported on the console or in the Desktop environment in zoom mode. You may want to specify CGA or Hercules® in the following cases:
LPT1, LPT2, or LPT3
as your printer port.
Specify the type of printer attached to your UNIX system as the printer type.
no if the application asks whether it should install its own
mouse driver.
However, most DOS applications are meant for the 8086. Of those designed for more powerful processors, many are smart enough to sense the nature of the processor on which they are running and adjust their operation accordingly. For these intelligent applications, you do not need to do anything special. They respond to the virtual 8086 environment as an 8086 processor and automatically run in the 8086-compatible real mode.
For non-Windows applications that offer 286/386 features and fail to adjust to the virtual 8086 automatically, try the following:
A few DOS applications offer a backward-compatible installation option that permits you to specify the processor the application is to run on.
If the most current version of the application requires an 80286 or 80386 processor, investigate earlier releases of the software. For instance, Lotus® 1-2-3® Version 2.2 runs under SCO Merge; Version 3.0 does not.
Although many copy-protection methods exist and it is
impossible to recommend installation procedures
that apply universally, the following sections contain tips for two common classes.
Applications that use key disks
These applications allow you to install part of the application
on the system fixed disk but require you to insert a
protected diskette in the diskette drive whenever you
use the application.
Install them by following the manufacturer's instructions.
When you run these applications under
SCO Merge, use the key disk just as you would on a conventional
personal computer running DOS or Windows.
Applications that must be installed on real DOS file systems
Some applications make modifications directly to the DOS FAT file system
in order to hide copy-protection information.
You can install these applications on SCO Merge systems if you have
a drive that has a real DOS file system.
You can use a real DOS file system that is on your fixed disk, or create
a "virtual" DOS file system to use.
(The procedure for attaching a DOS drive is described in
``Configuring drives''
in Chapter 4.)
Removing applications
To remove installed applications from the fixed disk:
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 SCO Merge uses to run Windows 95 efficiently depend on only you having access to your personal drive.
If you have data files you want to share, 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 SCO Merge user can do the same so that all can use the same
drive letter to access the same location.
File and record locking
Many current applications, especially network versions,
use DOS file- and record-locking facilities.
SCO 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 C:
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.
Applications and file permissions
Some current and many older applications
are designed for a single-user environment and
do not use
DOS file- or record-locking conventions.
When used with SCO Merge in a multi-user environment, these
applications do not protect your files from being
simultaneously updated by you and another user
with write permission.
In such cases, each user is responsible for avoiding simultaneous
updates that could result in file corruption or data loss.
File permission errors
Sometimes the message DOS returns is affected by UNIX file-
permission modes.
For example, when a DOS command you issue
encounters a file
for which you do not have read access,
DOS may display a message that implies the file does not exist,
even though the file does exist.
Similarly, if you try to create a file in a
directory for which you do not have write access,
DOS may display an error message such as
File creation error that does not clearly indicate the
nature of the problem.
Network applications
Applications that can be installed once in one location and then used
by more than one user are often called Network Applications.
(Some applications might be advertised as Network Applications
but actually can work only with shared data files on a network,
and each user must install his or her own copy.)
The shared network versions of applications can usually be installed
and run in the SCO Merge environment, given the same restrictions for
installing and running non-network applications.
But, you need to be aware of a few complications, which are described in
the following three sections.
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 SCO 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 SCO 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, SCO 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, SCO Merge interprets the commands in a config.sys file
just as a conventional DOS system does.
Refer to
Restricted DOS commands
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 SCO Merge
environment just as they do on a conventional
stand-alone DOS computer.
Some DOS commands, however, are either not usable in the
SCO Merge environment or operate differently than they do on a
stand-alone DOS computer.
SCO 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 SCO 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 SCO 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:
SCO 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.
Cutting and pasting between Windows and X applications only works when Windows is running on your Desktop.
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 SCO Merge configuration so that cutting and pasting between X and Windows applications is available when you start Windows, see ``Cutting and pasting between the X Window System and Windows'' 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. SCO 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. SCO Merge supports either X cut buffers or the X clipboard selection. SCO Merge passes your information to the Windows Clipboard, where it is available for pasting into your Windows application using the standard Paste mechanism.
SCO 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.