DOCUMENT ID: 1476-02

SYNOPSIS:    How to use Windows apps. already installed under DOS, for Wabi

OS RELEASE:  Solaris - All versions Wabi runs on

PRODUCT:     Wabi 2.0 & 2.1

KEYWORDS:    wabi install windows


SYMPTOMS:    

Applications available under Windows do not show up under Wabi after
installation. 


DESCRIPTION:

Because you must reinstall Windows separately for Wabi to use, it does
not know about the applications you have already installed under actual
Windows. 

Since most of us have limited disk space we don't want to have to
install these files more than once, if it can be avoided. 

This is an achievable goal for most programs and is actually a way to
get a program installed that doesn't install under Wabi, but will run
just fine once it is installed.  This is because some install programs
are unable to run under Wabi, even though the programs they install will
run just fine. 


SOLUTION:

MOUNTING YOUR EXISTING DOS DRIVE(S)

The solution starts with mounting your DOS partition(s).  Create a
directory under root called DOSC (caps added for emphasis).  Then add an
entry like the following to /etc/vfstab:

 /dev/dsk/c0t0d0p0:c      /dosc               -         -

You then must assign this to a drive letter in the Drives section of the
Wabi Config utility.  You will find this in the Control Panel for 2.0
and 2.1, plus in the Wabi group for the 2.0 version. 

If you have more than one drive with a DOS partition, you should note
that the :c represents the first DOS partition for that drive.  Here is
an example where you mount two DOS partitions on a second drive:

 /dev/dsk/c0t1d0p0:c      /dosd               -         -
 /dev/dsk/c0t1d0p0:d      /dose               -         -

The above examples are for SCSI disk drives.  For IDE drives the t# is
not used and the d# for the second drive would be d1.  Note that I
started with :c again for the primary partition on the second drive. 
The letters :d to :z are only legal for logical drives in an extended
DOS partition. 


Note that it is a good idea to attach your CD-ROM drive and any
partition other than the DOS C: drive as the same letters that they are
when DOS boots.  This means fewer changes in your configuration between
Windows and Wabi. 

HOW TO ORGANIZE YOUR DRIVES

Given the choice you should try to organize your drives such that drive
C under DOS has only DOS applications, DOS itself (naturally), Windows,
and any drivers that are loaded by DOS. 

You can then do the exact same thing under Wabi.  Leave the drive C for
just installing Windows and your pseudo AUTOEXEC.BAT & CONFIG.SYS. 

It is worth noting here that if you use NFS drives on a server and
install your Windows applications there, they would all be accessible
from whatever workstation you log into if you use NIS/NIS+.  This is
because drive C for WABI is your home directory, and if it is also an
NFS drive you will essentially have your whole environment available at
any workstation you log into. 

This would require you to have NFS available while running Windows,
also.  In that case drive C would be the only real hard drive and
everything else, except your CD, would be an NFS drive.  For this you
can use PC-NFS to provide NFS drives from the DOS level, or PC-NFSPro to
provide them only from within Windows. 

HOW TO ENABLE EXISTING WINDOWS APPLICATIONS FOR WABI

The best way to enable a Windows application for Wabi is to duplicate
the files it placed in drive C: under DOS/Windows into your drive C:
under Wabi.  The easiest way to check what changes is to save a copy of
an ls for the C:\WINDOWS and C:\WINDOWS\SYSTEM directories before doing
the installation.  After installing the new application, do another ls
of those directories and then do a diff to see what has changed. 

If you see that a .INI file has changed, do a diff between that file and
the one you have for Wabi.  The changes are generally quite obvious in a
.INI file.  Only bring over those changes that are related to the
application you have just installed.  To make it easier you can save the
old Windows versions at the same time you do the original ls command. 
The files you are generally interested in are: PROGMAN.INI, WIN.INI, and
SYSTEM.INI.  The CONTROL.INI may also change if an application adds
something to the control panel, as Soundblaster does. 

This process of doing a diff can also warn you of programs that won't
run properly under Wabi.  If you see that a driver with an extension of
.VxD is being loaded, you know there will be a problem. 

See if there is a file with the same name, but a different extension
that was also installed.  If there is you may want to try either
reinstalling in standard mode (start Windows with: win /s) or by
installing the WABI version under Wabi.  This will work when both
Standard and Enhanced modes are supported.  A .DLL or .DRV file can work
under Wabi, but a .VxD will not. 

Other files you will often see showing up after an install are .GRP
files.  These are the group file that holds the information about what
icons belong to that group, what position each icon is in, what size and
position the group windows is when opened, etc.  This copies over
easily, but note that if the drive letter does not match between
DOS/Windows and Wabi you must use the File->Properties menu item in
Program Manager to change the drive letter info for each icon.  To avoid
this painful process is why you should strive to keep each drive letter
the same between the two systems. 

You should also check to see if an application has .INI files in the
directories it creates during installation.  If your drive letters are
not identical between DOS/Windows and Wabi you should try to move these
files into the Windows directory for each OS.  Hopefully, they will look
there if it is not found in the directory you moved it from.  Be sure
that Windows is always early in your path (right after DOS), followed by
any application you have installed.  If it still doesn't work you can
try changing the starting directory using the Files->Properties menu
item in Program Manager. 

Even if your drive letters do match, or the .INI file does not have any
references to directory paths other than C:, you should move it into the
C:\WINDOWS directories to insure that you have your own private copy (in
case other people use this application when it is installed on an NFS
drive).  This insures that someone changing a setting in a .INI file on
one system does not change another user's .INI settings.  A program that
allows a network installation option should ask where you want the
"private" files kept, for this very reason. 

It is worth mentioning here that some programs actually write info, that
should be kept in a .INI file, into the executable itself.  These
programs also trigger anti-virus software that looks for .EXE files
being written.  For these programs you may want to copy that .EXE file
into your Windows directory, just like you would a .INI file.  This
practice has mostly been dropped, except for programs that personalize
themselves at installation with the users' name, company, etc.; and that
is only done the one time. 

ADDING WINDOWS APPLICATIONS INSTALLED BEFORE WABI

This section details how you can create a Group and Icons for
applications you already had installed in DOS/Windows before you
installed Wabi under Solaris. 

 1. Boot up under DOS and get into Windows
 2. Close each of your Group windows that are open
 3. Select a group you want to appear under Wabi with a single mouse-click
 4. Ignoring the pop-up menu, select File->Properties from the menu bar
 5. Write down the name of the group file to be copied later

Repeat the process listed above for every group you want to bring into
Wabi.  When you have the names of all the group files, exit Windows and
reboot into Solaris.  Log in under your account and copy all the .GRP
files you have noted into $HOME/wabi/windows.  You also need to copy the
[Groups] section entries from the DOS/Windows PROGMAN.INI file to enable
the groups.  Be sure to number them sequentially. 

You should now look at the WIN.INI and SYSTEM.INI files for any entries
that may have been added when those applications were installed.  Search
for either the name of the application (Word, Excel, etc.) or the names
of the directories it uses.  Copy any sections you find into your
matching Wabi .INI file.  All this will be relatively easy using a GUI
editor and cut-and-paste. 

After all this is done you can try to bring up Wabi.  Watch for warning
messages about missing files.  You may want to do a directory comparison
first and copy over any obvious .DLL files you will need.  You may need
to try several times to find any missing files, especially if you are
adding a lot of pre-installed applications. 

To play it safe you may want to try bringing up one application group at
a time.  Creating backup copies of the working configurations as you get
each one working before going on to the next. 

This method is also useful for those applications that do not install
under WABI, but might still be able to run under Wabi.  This can happen
because the install program being used breaks under Wabi.  Often these
are commercial install packages that are not even written by the creator
of the program you are installing.  That is why so many install programs
look alike, even from different vendors. 

WHEN ALL ELSE FAILS...

When all else fails you can always try to install a copy under Windows
and then install it under Wabi.  If you do this you might want to use
separate directories and see how each installation differed. 

If this is one of those cases where the install program fails under
Wabi, bring up Windows with the /S option.  This will bring it up in
"Standard" mode, which means not in 386 Enhanced mode.  This makes it
look like a 286 as far as memory features are concerned and should stop
it from installing any .VxD files.  Again, I suggest you do this into a
separate directory and compare the .INI files to see how the two
installations differ.  Use the Standard mode configuration for Wabi and
the normal installation for real Windows.  This gives the best
performance in both worlds. 


DATE APPROVED: 07/28/95