Wabi 1.0 Frequently Asked Questions
Last Updated 23 December 1993


Q: What versions of Wabi does this document apply to?

A: This document applies to Wabi 1.0 running under Sun's Solaris.
   Information about Wabi from workstation vendors other than Sun and
   information about versions of Wabi other than 1.0 is incidental and
   may not be complete.


Q: Where can I get more information on Wabi from Sun?

A: To get the latest version of the Wabi 1.0 Frequently Asked Questions
   document (this document), send email
   To: wabi1.0-questions@East.Sun.COM

   To get a list of Windows applications that are qualified to run
   under Wabi 1.0, and other information about applications running
   under Wabi 1.0, send email
   To: wabi1.0-apps@East.Sun.COM

   To download Wabi-related files, discuss Wabi with others, or ask
   specific questions get on CompuServe, Go SunSelect, and look in the 
   PWI and Wabi sections.

   Finally, ask your Sun representative for Wabi-related materials.
   Remind them to check SunWIN, anonymous FTP, and the Sun-internal
   Wabi Forum.


Q: What are the hardware/OS requirements of Wabi 1.0?  For example,
   will Wabi run on a SPARC-IPC under SunOS4.1.x ?

A: Wabi release 1.0 from SunSoft will run on any machine running
   the current version of Solaris 2.  Right now that's either a SPARC
   machine running Solaris 2.3 or an Intel machine running Solaris
   2.1.  

   You can run this version of Wabi even if your desktop machines are
   running Solaris 1.  Run Wabi under Solaris 2 on a machine in some
   back room, and use DISPLAY to project Wabi's windows onto your
   Solaris 1 desktop via X11.  To obtain the highest possible
   performance in this configuration, consider using x86 hardware
   running Solaris 2.1 x86 as the central Wabi engine.


Q: Is there a version of Wabi that will run under Solaris 1?

A: There are no significant technical obstacles to producing a version
   of Wabi that will run under Solaris 1.  SunSoft has not yet made a
   final decision on whether to make such a product available, and no
   availability date has been announced.

   You don't necessarily need a Solaris 1 version of Wabi even if your
   desktop systems run Solaris 1.  You can execute multiple copies of
   Wabi on a central Wabi engine running Solaris 2 in some back room,
   and via X11 display Wabi's windows on your Solaris 1 desktop
   systems.  To obtain the highest possible performance in this
   configuration, consider using x86 hardware running Solaris 2.1 x86
   as the central Wabi engine.


Q: How can I format a floppy disk for use with Wabi?

A: Format floppy disks through Unix rather than through Wabi.  Use
   `fdformat -d` from a Unix cmd/shell tool window.  (See Unix manpage
   "fdformat".)

   (You'll probably notice that you can't do this if Wabi is up and has
   already used the floppy drive.  Wabi not letting go of the floppy
   drive is a known problem that will be fixed in the next release.
   This is easy enough to work around, though.  One option is whenever 
   you get a new box of floppies, stop Wabi and format the whole boxful 
   then start Wabi again.  Now whenever you need a floppy you've 
   already got one.  Another option is to use somebody else's 
   SPARCstation that isn't running Wabi right now to do the 
   formatting.)


Q: Do I need to have "real Windows" installed to format floppy disks?

A: You can format floppies for Wabi use whether or not you have "real
   Windows" installed.  Whatever your system configuration, format the
   floppies through Unix rather than through Wabi.

   Don't be misled by the floppy disk formatting function you appear to
   get if you install "real Windows".  This function is not supported
   under Wabi 1.0.  See manpage


Q: How do I eject diskettes from a SPARC system that doesn't have
   a physical eject button?

A: Use the Meta+E keys to eject diskettes from the drive.  (The Meta
   key is labeled with a diamond.)  Other methods, such as using a
   paper clip or using the Unix `eject` command, are not only less
   convenient but also may leave the Wabi application confused about
   the state of the drive or even cause Wabi to fail.  You won't always
   be able to continue with the next diskette.


Q: What exactly should I do to enter Meta+E or Shift+Meta+E?  Does
   Meta+E mean I should type Meta, then '+', and then an uppercase E?

A: Meta is a modifier key like Shift or Ctrl or Alt.  Here's an
   illustration of this notation using a more familiar key:  the key
   that is often used to interrupt the current operation is written
   Ctrl+C.

   Meta+E means depress Meta, then depress 'E' (lowercase), then
   release 'E' and release Meta.  Shift+Meta+E means depress both Shift
   and Meta, then depress 'E', then release 'E' and Meta and Shift.


Q: Which key is the Meta key?

A: There are two Meta keys on SPARCstation keyboards.  They are the
   keys on either side of the space bar that are labeled with a
   diamond.


Q: Meta+E doesn't eject the diskette.  What should I do?

A: If Meta+E does not work, first be sure you've coordinated Wabi with
   the Volume Manager.  Either disable the Volume Manager's use of the
   diskette drive, or install all the right versions and patches so
   Wabi and Volume Manager work together correctly.  (See a different
   Q: in this document for further information.)

   If Meta+E still does not work, be sure a Wabi window has "input
   focus" when you press Meta+E.  A problem commonly occurs if your
   desktop window manager is configured for focus-follows-mouse.  You
   start accessing a diskette, then move the mouse to a different
   window to do some other work in the meantime.  Then when Wabi puts
   up a dialog box asking for the next diskette you simply press
   Meta+E.  This will not work!  You must explicitly click on a Wabi
   window so its title bar changes from gray to a color before you
   press Meta+E.  After the diskette is ejected and the next diskette
   inserted and confirmed, you can move the mouse back to the other
   window and continue with your other work.

   If Meta+E still does not work, try Shift+Meta+E.  Some X systems may
   be set up so the window manager "consumes" Meta+E and the keystroke
   never gets through to Wabi.  Shift+Meta+E should get past these
   systems, and will be handled by Wabi the same way as Meta+E.


Q: Is it necessary to install Microsoft Windows under Wabi?

A: Probably not.  Wabi 1.0 is largely self-contained, but does not yet
   include native support for DDE/OLE or the online help viewer, or any
   support for the multimedia parts of the Windows API or networking
   APIs such as WinSock and NetBIOS.  Only two qualified applications
   require Microsoft Windows to be installed in order to run under
   Wabi:  Borland Paradox for Windows and Microsoft PowerPoint 3.0.


Q: If Wabi IS Windows, why is it necessary to install "real Windows"
   to get some applications (ex: PowerPoint and Paradox) to run under
   Wabi?

A: This is just a temporary requirement with Wabi 1.0.  Wabi 1.0 has
   a few holes in it, and the easiest way to fill them in the short
   term is to merge in "real Windows".  The requirement to install
   "real Windows" to run these apps will go away ASAP.  After all, one
   of the advantages of Wabi is not paying Bill Gates' taxes !-)


Q: Are there other benefits to installing "real Windows"?

A: Not many.  

   You do get the "applets" in the Accessories group.  These largely
   duplicate applications that are already available on most Unix
   desktops.  For example, it's unclear why you would want to switch
   from OpenWindows Calendar Manager to the Calendar applet.  It surely
   wouldn't make sense to use both of them.  Could you imagine having
   some of your appointments in Calendar and others in Calendar
   Manager?

   And you do a couple of neat games.  


Q: Why are some of the icons in the Main program group (including
   Print Manager, Windows Setup, PIF Editor, and the Read Me file)
   missing after I install Windows under Wabi?

A: Don't be misled by the phrase "installing Windows under Wabi".  Wabi
   IS Windows.  What's really going on when you click "Windows Install"
   is some parts of MS-Windows are selectively "merged" into Wabi.

   Wabi 1.0 supplies a pretty complete set of configuration tools.
   Most of the "real Windows" configuration tools are at best
   duplicates that are irrelevant to the Wabi environment.  Wabi omits
   as many duplicate, meaningless, and non-functional Windows tools as
   it can.

   The granularity of what can be selected or omitted is unfortunately
   rather large: a whole program or icon.  In the cases where all the
   functions are either already provided by Wabi or are meaningless,
   the "Windows Install" process omits the entire icon.


Q: I want to avoid any possibility of file corruption.  How can I be
   sure generation of UDP checksums is enabled on every machine that
   Wabi accesses?

A: For machines running SunOS 4.x, check if UDP checksum generation is
   enabled by executing as root
   echo "udp_cksum?d" | adb -k /vmunix /dev/mem
   If the value displayed is not "1", edit /sys/netinet/in_proto.c to
   set udp_cksum=1, rebuild the kernel, and reboot the system.

   For machines running SunOS 5.x, check if UDP checksum generation is
   enabled by executing
   ndd /dev/udp udp_do_checksum
   If the value displayed is not "1", to change it immediately as root
   execute
   ndd -set /dev/udp udp_do_checksum 1
   To change the value that will be used the next time your system
   boots, find out where during system startup UDP checksum generation
   is being disabled, and re-enable it.  Most likely you'll find UDP
   checksums being disabled in /etc/rc2.d/S69inet.  If you can't find
   where they're being disabled, try executing `egrep ndd /etc/rc*d/S*`
   to have the system look for you.  Once you find where UDP checksums
   are being disabled, either remove the "ndd -set /dev/udp
   udp_do_checksum ..." line altogether to revert to the default value
   of UDP checksums enabled, or change the line to explicitly say "ndd
   -set /dev/udp udp_do_checksum 1".


Q: How do I keep OpenLook icons and Wabi icons from overlapping each
   other on my screen?

A: From the OpenLook root menu select Properties..., go to the Icons
   category, and select "bottom" "left" or "right" (but not "top") for
   Location, and click Apply.  Also, if you're in the habit of placing
   your Console window at the top left of your screen you may want to
   move it somewhere else, for example the top right.

   (When an OpenLook application is Closed, its icon will be placed at
   the top, bottom, left, or right edge of your screen depending on the
   OpenLook window manager's property setting.  When a Wabi group is
   Minimized, its icon will be placed within the Application Manager
   window.  When an individual Wabi application or file is Minimized,
   its icon will be placed at the top of your screen.  You can move the
   icon to a new location by selecting it and dragging it with the
   mouse.  The icon will stay at the new location either until you Exit
   Wabi or until you bring up the Task List and ask it to Arrange
   Icons.)


Q: How do I Cut Copy and Paste to or from an application running under
   Wabi?

A: Use the Cut Copy and Paste items from a menu for applications
   running under Wabi.  Do not use shortcut keys labeled Cut Copy or
   Paste.


Q: How do I Maximize, Minimize, re-order, or Close the windows of
   applications running under Wabi?

A: Click on the buttons in the application's window frame, and select
   from the menu at the top left of each window frame or the Windows
   menu in the Application Manager.  The shortcut keys labeled Front
   and Open may not work the way you wish them to.


Q: How can I change drive connections without using the Configuration
   Manager?

A: If for some reason you either don't want to or can't use the
   Configuration Manager, stop Wabi, manually edit the configuration,
   then restart Wabi.  The drive connections are defined in editable
   ASCII file ~/wabi/windows/wabi.ini (wabi.ini, not win.ini).  Edit
   lines of the form Drives.?=... in the [CommonSettings] section of
   the file to whatever you want (including nothing).  (Ignore the
   Drives.?=...  lines in the [] sections.)


Q: Is it possible to use Wabi to access SunPC's C: drive -- the one
   that appears as Unix file C.pcs?

A: Wabi 1.0 can't access SunPC's C: drive directly.  If users have
   followed SunPC's recommendation of not storing applications or data
   on its emulated C: drive, there won't be much benefit in accessing
   the drive from Wabi.  Store files you need to see from both Wabi and
   SunPC on H: (your home directory unless you've changed the default
   settings).  If the files are currently on SunPC's C: drive, bring up
   SunPC and move them from C: to H: by first copying them then
   deleting the originals.


Q: Which keyboard focus setting does Wabi prefer, click-to-type
   (ClickSELECT), or follow-mouse (MoveMouse)?

A: "Real Windows" only supports one model of keyboard input focus,
   click-to-type with the focus window always coming to the front.
   That's the only keyboard focus model MS-Windows-based applications
   expect, the only keyboard focus model they have ever seen, and the
   only keyboard focus model they can deal with.  So Wabi windows will
   always behave that way no matter what your X window manager
   preferences are set to.

   Your desktop will be less confusing if you make all your windows
   --both Wabi and Unix-- behave the same way.  To do this, choose
   click-to-type, and also auto-raise, for your Unix windows to make
   them as much like your Wabi windows as possible.

	- To choose click-to-type with OpenWindows, bring up your
	  desktop Properties, select the Miscellaneous category, Set
	  Input Area

   Click SELECT, then click on Apply.

	- To choose auto-raise with OpenWindows, in a cmdtool execute
		echo "OpenWindows.AutoRaise: true" | xrdb -merge
		xrdb -edit $HOME/.Xdefaults


Q: What window managers does Wabi work with?

A: Wabi fully supports and has been tested with `olwm` and `mwm`.
   Wabi will work with `olvwm`, although Wabi windows will always move
   to the current screen and the ALT-F4 keystroke will be captured by
   the window manager rather than passed through to Windows apps.  Wabi
   will probably work with other window managers such as `twm` and
   `Mwm`.


Q: Who draws the borders around Wabi windows, the X window manager, or
   Wabi itself?

A: Wabi itself draws the borders around Wabi windows.  From X's point
   of view, the windows are "undecorated".


Q: Why does Wabi itself draw the borders around Wabi windows rather
   than letting the X window manager do it?

A: MS-Windows-based applications expect their window borders to be
   intimately and quickly accessible.  And MS-Windows-based
   applications expect their window borders to have a particular look
   and feel.  If Wabi let the X window manager draw the window borders,
   it would not be able to satisfy all the applications' expectations.

   Here's another way of looking at this situation: MS-Windows-based
   apps expect to see similar window system functionality and timing
   whether they're running under "real Windows" or under Wabi.  To
   satisfy them, Wabi has to make the window system appear to be
   synchronous, local, and inflexible even though the X window system
   is capable of much more.


Q: How can I change the size of fonts, borders, etc. of Wabi windows?

A: Wabi supports the same options for changing the size of window
   fonts, borders, etc. as real Windows -- and no more.


Q: If I'm using an X-terminal that doesn't have a diskette drive, can I
   still use diskettes?

A: Yes.  Wabi's mapping of A: and B: to diskette drives always refers
   to the machine Wabi is executing on rather than the machine Wabi is
   projecting its windows onto.  So your references to A refer to the
   diskette drive on the machine where Wabi is executing.  If you have
   an X-terminal on your desk, the machine where Wabi is executing is
   probably a server in a closet.


Q: Can I make Wabi access the floppy disk drive on some other machine?

A: No, sorry, Solaris 2 doesn't currently support having one machine
   access a DOS format floppy in the drive on a different machine.
   That's what the NOTES section of `man mount_pcfs` means when it says
   "pcfs is currently not NFS mountable.  Trying to mount a pcfs file
   system through NFS will fail with an EACCES error."  Wabi 1.0 does
   not provide any functionality beyond what its host operating system
   provides.


Q: How can I install applications onto a machine that doesn't have a
   floppy disk drive, for example an SS1000 being used as a central
   Wabi engine?

A: Go to some machine that does have a floppy drive and copy all the
   installation diskettes to a single newly created subdirectory that's
   available to others on the network.  Then go to the machine that has
   no floppy drive, start Wabi, map a Wabi drive letter to the location
   you just copied the diskette contents to, and install the
   application.

   Copying all the installation diskettes to a single newly created
   subdirectory will look something like this:
	foohost% cd /files/wabi
	foohost% mkdir barapp.dsk
	foohost% mount -F pcfs  /dev/diskette /pcfs
	foohost% cp -r /pcfs/* .
	foohost% eject
	 # repeat for each diskette #

   Mapping a drive letter to the location of the diskette contents will
   look something like this:
     in Unix--
	wabihost% cd /files1/maint
	wabihost% mkdir install.dsk
	wabihost% 
mount -F nfs foohost:/files/wabi/barapp.dsk /files1/maint/install.dsk 

     in Wabi Tools:ConfigurationManager:Disks--
	I: -> /files1/maint/install.dsk
   If your system runs an automounter to access other systems, it's
   even easier.  You don't need to do anything in Unix.  Inside Wabi,
   just map
	I: -> /net/foohost/files1/maint/install.dsk

   During installation when the application prompts for something like
   "Location of Installation Files:", overtype the default (probably
   A:) with the location you just mapped (I: in this example).


Q: How can I use the diskette drive on my local machine if I'm
   executing Wabi on some other machine and projecting its windows back
   to my machine with X?

A: If you're executing Wabi on some other machine and projecting its
   windows back to your machine, there's no way with Wabi 1.0 to map
   any drive letter (A: or B: or any other) directly to the floppy
   drive on your machine.  Here's a recipe for handling diskettes
   indirectly.

   setup--
	in Unix-- mkdir /foo/bar/baz/diskette
	in Unix-- rm -rf /foo/bar/baz/diskette/*
	in Wabi-- Tools:ConfigurationManager:Drives
	in Wabi-- X:
	in Wabi-- /foo/bar/baz/diskette
	in Wabi-- Connect
	in Wabi-- OK

   to read a whole physical diskette before you start working--
	in Unix-- mount -F pcfs /dev/diskette /pcfs
	in Unix-- cp -r /pcfs/* /foo/bar/baz/diskette
	in Unix-- eject
	in Unix-- umount /pcfs

   to work from the staged diskette contents--
   in Wabi-- read and write files as usual, except specify X: instead
   of A: to write a whole physical diskette when you're done working--
	in Unix-- mount -F pcfs /dev/diskette /pcfs
	in Unix-- cp -r /foo/bar/baz/diskette/* /pcfs
	in Unix-- eject
	in Unix-- umount /pcfs


Q: Will Wabi run faster if I set up a permanent swap file for it?
   And if so, how do I do the setup?

A: Unix handles all the paging/swapping for the Wabi environment.
   There's no need to worry about paging/swapping at the Windows
   level.  Applications running under Wabi will get all the memory they
   need, up to the local max supported by Unix.

   The memory set up by the Unix `swap` command is used by both Unix
   applications and Wabi applications.  Using only one mechanism for
   both Unix and Wabi paging/swapping simplifies administration and
   guarantees you'll always get the most performance out of your RAM,
   even if you switch back and forth frequently and unpredictably
   between Unix applications and Wabi applications.

   Since there's no need to set up a separate swap file for Windows,
   Wabi Windows Install doesn't load the "386 Enhanced" icon.  Wabi
   applications see a full 386 Windows environment nevertheless.


Q: Why does Wabi always report that it's running on an 80386 CPU, no
   matter what the CPU really is?

A: Several applications (for example WinTach) use heuristics to find 
   out what kind of hardware they're running on.  Wabi knows what all 
   of the common heuristics are, and intercepts all of them.  In every 
   case Wabi returns "reasonable lies" to the application.  Wabi always 
   makes the application think it's running on an 80386 chip.

   To MS-Windows-based apps, there are only two possibilities that
   matter: an 80286 chip implies "standard" mode and an 
   80386/80486/80586 chip implies "enhanced" mode.  Once we say 
   "80386", the application knows it's okay to go ahead and do all the 
   "enhanced" things it wants.  Saying something else besides 80386 
   would give zero further performance or functionality gains.  In 
   other words, saying "80386" is a very good lie.

   Versions of Wabi run on lots of different kinds of hardware: SPARC,
   PA-RISC, POWER-PC, Intel, etc.  Wabi obviously can't return the
   "truth" in every case: lots of applications wouldn't know what to do
   if they found out they were running on a SPARC CPU.  So Wabi always
   returns what it's "simulating" rather than what it's actually 
   running on.  And Wabi is always "simulating" an Intel enhanced mode 
   chip: an 80386.

   Wabi doesn't make a special case for the times when it's running on
   real Intel hardware.  Wabi will always return what it's 
   "simulating", even if the simulation is simply passing Intel opcodes 
   through to a "real" Intel 80386/80486/80586.

   Two important points to remember are: 1) Wabi's behavior gives apps
   permission to use "enhanced" mode extensions, and 2) always saying
   80386 rather than 80486 or 80586 has no impact on performance or
   functionality.


Q: During a long disk-intensive operation, such as installing a large 
   application, I sometimes get the following messages:
	panic: ufs_putpage: bn== UFS_HOLE
	syncing file systems... 
   What does this mean?

A: If your Solaris system is using a swap file instead of or in
   addition to a swap partition, you are probably encountering a known 
   Solaris 2.x/SunOS 5.x kernel problem.  This bug has been fixed in 
   Solaris 2.3.  Upgrade to Solaris 2.3.

   If this happens repeatedly and you need a short-term fix and cannot
   yet upgrade to Solaris 2.3, disable any swapfiles in /etc/vfstab.
   Note that if your system really needs the swap space you just
   disabled, you'll need to create a swap partition to replace it.

   If you upgraded to Solaris 2.3 or disabled all swapfiles in
   /etc/vfstab and still have problems, you're running into a residual
   problem that's still under investigation.  To work around this
   problem, install the application to an NFS-mounted remote file
   system rather than to a local hard disk.


Q: How can I re-install MS Windows under Wabi?

A: Remove the previous copy of MS Windows before installing a new one.

   To completely remove MS Windows from Wabi, remove all files that
   were installed via the Windows install program (probably most files
   under ~/wabi/windows).

   To re-install MS Windows over a previously installed MS Windows and
   avoid multiple icon entries in the groups, simply delete all the
   program items and groups (main, games, accessories) before
   re-installing.


Q: Can I Cut/Paste from any application to any other application?

A: Yes.  Wabi implements one shared clipboard for use by both
   Windows-based applications and X-based applications.  The clipboard
   in Wabi is really a clipboard viewer program that shows you what's
   currently on the clipboard as though it were stored in native
   Windows format.  So you can cut/paste from one X app to another,
   from one Windows app to another, from an X app to a Windows app, or
   from a Windows app to an X app.

   If you're unable to cut/paste from a Windows app to an X app, check
   whether you're using the OpenLook window manager.  If you are, be
   sure that you click inside the destination window rather than on the
   title bar.  (Whenever you click on the title bar of a window, the
   OpenLook window manager clears the clipboard.)


Q: Can I cut an image, such as a portion of the screen, from an
   application to the clipboard, then paste it into a different
   application?

A: In theory yes you can cut/paste any type of material from any app to
   any other app.  The clipboard uses ICCCM-compliant selection type
   tags and can contain any type of material.

   In practice, it will probably work only if both source and
   destination apps are Windows-based.  Most current X-based apps only
   know how to cut and paste text material.  If they're asked to cut an
   image, they ignore the request.  If they find an image on the
   clipboard, they ignore the material.  To work around this problem
   with deficient applications, use something like OpenLook Snapshot to
   capture the image to a file.  Then convert the file to the format 
   the destination application wants using one of many conversion 
   programs such as `pbmplus` or `alchemy`.


Q: Can several users or systems share one copy of Windows?  

A: There must be a separate copy of the windows directory for each
   user.  Windows, and most windows applications, assume they can write
   anything they want in directory C:\windows any time they want.

   The amount of disk space required to give a separate copy of the
   windows directory to each user is not very large.  The size of
   ~/wabi was reduced from >10MB in wabi_prefcs to <500KB in
   wabi_1.0_fcs.  Its size will shrink even further when Wabi 2.0
   removes the last vestiges of need for installing "real Windows".

   Since you don't need real Windows at all, not being able to share a
   copy of it isn't very important.  Wabi IS Windows, and Wabi systems
   need not include real Windows.  Many Wabi 1.0 installations do not
   include real Windows.  And hardly any Wabi 2.0 installations will
   require real Windows.

   Finally, if Wabi made it too easy for several users or systems to
   share one copy of MS-Windows, it might look like Wabi was
   allowing/encouraging people to share copies of MS-Windows without
   paying for a network license.  We don't want to give Microsoft an
   easy excuse to start a fight.


Q: Can several users or systems share one copy of an application?
   Specifically, can I use an application's "network install" option
   for this purpose?

A: Probably not.  Wabi 1.0 presents to applications the same 
   environment they'd see if they were running on "standalone" PCs.  
   Although Wabi resources may be extensively networked with NFS etc., 
   the applications running under Wabi think they're not on a network.  
   Most of them will not allow you to choose their "network install" 
   option since it seems to them that your machine is not on a network.


Q: Can several Wabi 1.0 users share a single copy of an app?

A: Probably not.  While Wabi 1.0 does support file locking which is
   necessary to support the sharing of files, it does not set the bits
   correctly to inform the application that file structures are 
   "network" drives.  Setting these bits correctly is non trivial.

   For this reason Wabi 1.0 will not easily support shared apps.

   Engineering and testing to support this functionality is planned for
   Wabi 2.0.



Q: How do I make Windows applications display right on a Monochrome 
   screen?

A: Get Wabi to tell the truth (there's a monochrome screen) to the
   apps, and let each app make whatever adjustments are necessary.  The
   apps are remarkably good at doing this.

   Here's two ways to change what color settings Wabi tells the apps,
   depending on whether or not you've installed "real" MS Windows.

   - To do this without "real" MS Windows, stop Wabi and edit
     ~/wabi/windows/control.ini.  In the [current] section, change the
     "color schemes=..." line (near the top of the file) to
     "color schemes=Monochrome".  Save the file, then start Wabi.  

   - If you've installed "real" MS Windows, you can bring up the
     ControlPanel (probably in group Main) and click on Color.
     About half way down the list of Color Schemes is a predefined
     one called "Monochrome".   Click on it to highlight it, then 
     click on the OK button at the bottom left of the box.  


Q: How can I change the Unix print command Wabi print output is routed
   to?

A: Start the Wabi Configuration Manager, click on Printers, click on
   Port..., and click on Connect.  You'll get a dialog box titled
   Printer Output Connections.  You can enter another
   Unix command in place of the default
	lp -d%p -t%t
   in the field Native Print Command.  The command can be anything that
   understands 'stdin', even for example
	rsh print_host "lpr -P%p -T%t"


Q: Why do a few Windows applications seem to use inordinate amounts of
   CPU, even when they aren't doing much of anything?

A: When it's idle, Word spins blinking its text cursor, and apparently 
   touching its code to try to prevent
   itself from being paged out.  To prevent Word from using
   up most of your CPU when it isn't doing anything, move your mouse to
   some other window and click to take input focus away from Word.

   WordPerfect spins madly when it's idle, and seems to completely
   redisplay all of its windows any time any of them change.  This
   ensures the application will display correctly even in the face of
   lurking bugs, but at the cost of heavy CPU usage to perform all
   those unnecessary redisplay operations.  To minimize WordPerfect's
   overzealous behavior, size and move its windows so they don't
   overlap any other window.

   These applications misbehave under "real" Windows too, but you don't
   see it so easily there without monitoring utilities like `perfmeter`
   or `vmstat`.  (Also, under "real" Windows it matters less because
   it's unlikely there's any other important processing going on on the
   system.)  

   We hope the misbehavior of these applications will be corrected in
   the near future.  It's becoming widely known that these apps prevent
   laptop PCs from going into standby mode to conserve their batteries
   when idle.  So there's pressure on the ISVs to modify these
   applications.


Q: How much RAM should a system have to both locally execute and
   locally display Windows-based applications under Wabi?

A: Each Wabi system should have enough RAM to run the OS, and the
   window system, and common Unix-based apps, well.  If the performance
   of Unix-based apps (for example mailtool) isn't up to your
   standards, the performance of Windows-based apps running under Wabi
   won't be either.

   For SPARC systems running Solaris 2 you should have at least 32MB.
   For Intel systems running Solaris 2 you should have at least 16MB
   and preferably 24MB.


Q: How can I get Windows-based apps to appear in my root menu just like
   other apps, and execute on my Unix desktop without dragging along
   the entire Windows desktop?  I want to run my favorite Windows-based
   application on my Unix desktop -- I don't want to learn a whole new
   desktop metaphor.

A: This is the recommended way for Unix users to use Wabi.  It's
   documented in the Wabi User's Guide under a heading something like
   "Running an Application Directly".  Because the documentation is
   generic to all Unix systems, it may not be immediately clear.  So
   here's info tailored specifically to OpenLook:

   To start your favorite Windows-based application directly from your
   OpenLook root menu, insert lines similar to these into your personal
   ~/.openwin-menu-programs:

	"Word..."	exec wabi -s /foobar/winapps/winword/winword.exe
	"Excel..."	exec wabi -s /foobar/winapps/excel/excel.exe

   You can start up as many applications as you wish simultaneously
   under Wabi this way.  The applications will automatically find each
   other and coalesce into a single Wabi process.

   You may occasionally want to bring up the Wabi Configuration Manager
   to make a configuration change such as re-mapping a drive.  One easy
   way to allow this is to modify your personal ~/.openwin-menu like
   this:

	"Properties" MENU
	    "OpenLook..."	PROPERTIES
	    "Wabi..."		exec wabi -s "W:\WBIN\CONFIG.EXE"
	"Properties" END
 
   If you're using OpenLook's default root menu instead of a personal
   root menu, see the OpenLook documentation.  If your local
   conventions are for each person to have their own root menu, do
   something like this:

	cp /usr/openwin/lib/openwin-menu ~/.openwin-menu
	cp /usr/openwin/lib/openwin-menu-programs ~/.openwin-menu-programs
	cp /usr/openwin/lib/openwin-menu-utilities ~/.openwin-menu-utilities
	vi ~/.openwin-menu
	  :g/\$OPENWINHOME\/lib\//s//$HOME\/./
	  :wq
	 

Q: Do all the apps running under Wabi share a single address space?

A: All applications running under Wabi for the same user at the same
   display will coalesce into a single Unix process with one address
   space.  All apps running under Wabi will share this single address
   space.  A Unix `ps` command will show only one Wabi process per user
   and terminal, no matter how many apps the user is running.

   Wabi is the same as "real Windows" in this regard.  It's a good
   thing, as some windows-based apps take advantage of this to
   communicate with each other directly through what amounts to shared
   memory.


Q: Do the windows-based apps running under Wabi run in "protected
   mode"?

A: Yes.  Wabi simulates to the applications running under it exactly
   the same environment MS-Windows 3.1 would present: 16/32-bit
   protected mode.


Q: Can I run DOS-based applications under Wabi?  If so, how do I set up
   icons for these applications so users don't have to pull down
   File->Run and enter the path to the app?

A: Yes, Wabi supports launching of all the common DOS emulators.  To
   create an icon for a DOS-based application, just pull down
   File->New, check Application Item, enter the requested information,
   and click OK.  You don't need a "PIF editor" to create icons for
   DOS-based apps.

   All this will work once you've entered the right program name and
   command line parameters for the DOS emulator into the Wabi
   Configuration Manager.  

   The documentation under the heading "DOS Emulator Settings" is
   correct ...except for the string that should be entered into the DOS
   Emulator Command field.  (This field is in the DOS Emulator Settings
   dialog box that's accessible from the Wabi Configuration Manager.)
   This field should include not only the path to the DOS emulator
   program itself, but also some parameters including especially the
   name of the DOS application.

   Here's a brief description of what should be in that field:
  
	The first item must be a Unix path to a valid executable file.

	The token %d will be replaced with 
	    the X display name on which Wabi is running.
	The token %f will be replaced with 
	    the DOS filename that is being run.
	The token %c will be replaced with 
	    the remainder of the cmd line.

	For sunpc, a reasonable string is:

	    sunpc -display %d -c %f %c


Q: How does Wabi 1.0 support networking?  

A: Whatever networking support the host OS provides will also be
   available to all Wabi environment connections.  Looked at from the
   outside, Wabi running on a typical Unix system is network-rich.

   - Any drive letter can be mapped to any Unix pathname, so files
     may really be remotely accessed via a network file system
     such as NFS.

   - Wabi print operations are directed to a Unix command, which
     may be the entry to a network-aware print subystem.  Hence
     Wabi printers can be on other systems.

   - The user running Wabi may have used rlogin/telnet to access
     the system.

   - Wabi may be displaying its windows to a remote desktop using
     X over a network.

   - Identification of the user that's running Wabi may be
     mediated through a network name service such as NIS or NIS+.

   - All "real Windows" file and record locking options are fully
     supported, via RPCs to a remote lock daemon when necessary.

   If you look at it from the inside from the point of view of an
   application running under it, though, Wabi 1.0 doesn't appear to
   support networking.  Applications running under Wabi 1.0 do not have
   access to any networking API (WinSock, NetBIOS, etc.).  And all Wabi
   drives look to the application as if they were local drives even if
   in reality they are NFS-mounted from a remote machine.  So most
   network-aware installation options don't work under Wabi 1.0, most
   network licensing schemes don't work under Wabi 1.0, applications
   that need a network API to do anything useful (ex:  PowerBuilder,
   MS-Access) don't run meaningfully under Wabi 1.0, and built-in
   application support for various kinds of networking can't be
   utilized under Wabi 1.0.


Q: Can I add networking support to Wabi 1.0 by copying in a *.DLL
   file?

A: No.  Copying the relevant *.DLLs to Wabi will not increase the level
   of support for direct access to the network interface by
   applications.  It may however obscure the error message that reports
   an attempt to use an unsupported API call.


Q: Can Wabi support applications which make TCP/IP socket calls?

A: The initial version of Wabi, Wabi 1.0, will not support any
   networking APIs (WinSock, NetBIOS, etc.)  Wabi 2.0 will support
   networking APIs at least to the extent necessary to add several
   network-intensive applications to the list of "qualified" apps.

   WinSock is an extension of the familiar Unix TCP/IP networking API.  


Q: Can Wabi 1.0 access files that are stored on a Novell server?

A: Yes, if the Novell server exports those files through its NFS NLM.
   Solaris will then be able to mount the files just as though they 
   were stored on another Solaris machine.  And Wabi will be able to 
   map a drive letter to the mount point in the Unix file system and so 
   see the files.

   A future version of Wabi will allow you to map a drive letter to a
   filesystem on a Novell server even if the Novell server doesn't have
   the NFS NLM installed.  Our preferred route to this support is to
   have the host OS provide it to the entire system by making it
   available as another kind of "vnode".  Imagine being able to say
   `mount -F netware //foohost/barfiles /baz` and have the files on the
   Novell server show up everywhere on your system, including inside
   your existing File Manager program.  Then Wabi could simply for
   example map M: -> /baz and access the files stored on the Novell
   server.

   Note there's no connection between being able to access files that
   are stored on a Novell server and supporting the NetWare API.


Q: Can Wabi 1.0 execute programs that are stored on a Novell server?

A: Yes, if the Novell server exports those files through its NFS NLM.
   Wabi can execute any file that it can read.  So the problem of being
   able to execute a program is the same as the problem of being able 
   to access a file.


Q: Does Wabi 1.0 support the NetWare API calls?

A: No, Wabi 1.0 does not support any networking API, not WinSock nor
   NetBIOS nor the NetWare API.

   Note there's no connection between being able to access files that
   are stored on a Novell server and supporting the NetWare API.


Q: Is it possible for a Wabi application to communicate with a Unix
   application?

A: An app under Wabi 1.0 and a Unix app can be made to communicate
   crudely through shared files.  This may be sufficient if the level
   of interaction needed isn't very high.  Have one app open the file,
   write a "work request", and close the file.  Have the other app open
   the file, see a change, consume the "work request", close the file,
   and perform the request.


Q: Will there be better ways for a Wabi application and a Unix
   application to communicate in the future?

A: Yes.  Wabi futures should include one or the other (or hopefully
   both) of a) networking support and b) an OLE<->ToolTalk
   translation.  Both approaches have the added advantage of allowing
   apps to communicate with each other whether or not they're running
   on the same machine.

   With the networking support, both the Unix app and the app under
   Wabi could use "sockets" to access what amounted to a TCP pipe
   between the two apps.  Performance will be good, reliability is
   guaranteed (this is TCP), and it will handle much finer grained
   interactions than the shared file approach.

   With the OLE<->ToolTalk approach, and possibly a bit of development
   on the Unix side, you'll be able to implement the same sorts of
   things you can with ToolTalk between two apps under OpenWindows, or
   with OLE between two apps on a PC.


Q: Can applications running under Wabi call any Unix functions 
   directly?

A: No.  Wabi 1.0's primary purpose is to run shrink-wrapped apps.  And
   no shrink-wrapped app attempts to call a Unix function.  

   Wabi 1.0 provides exactly and only the MS-Windows API regardless of
   additional services that might be available from the host OS.

   There is one exception.  The MS-Windows API call that launches a new
   task does a little bit more than the "real Windows" call.  Like
   "real Windows", it will check the type of the executable.  It will
   direct DOS executables to a DOS emulator if one is available.  It
   will start Windows executables inside Wabi.  And unlike "real
   Windows", it will fork() Unix executables as separate processes.


Q: How does Wabi work together with the Volume Manager?

A: Wabi will work together well with the Volume Manager although Wabi
   doesn't require that your system use the Volume Manager.

   If you're running Solaris 2.2 and Wabi gives you an error message
   about needing a Volume Manager patch, you can either install the
   patch, or ignore the message and disable Volume Manager's use of the
   floppy drive altogether so there's no question that Wabi has access
   to the drive.  To make Volume Manager work together with Wabi,
   obtain and install patch 101168, and be sure Volume Manager's use of
   the diskette drive is enabled.  To disable Volume Manager's use of
   the floppy drive altogether:

	edit /etc/vold.conf
	  find the line that refers to /dev/diskette
	  comment it out by inserting a sharp ('#') in the first column
	  write out the new file
	reboot your system

   (If you neither installed the patch nor disabled Volume Manager's
   use of the floppy drive, you may find you can get Wabi to appear to
   access the drive by changing the drive device assignment to
   /dev/fd0a.  This is a red herring.  If you experience this, change
   the drive device assignment back to /dev/diskette and either install
   the patch or disable the volume manager.)

   If you're running Solaris 2.3, the Volume Manager is complete as
   supplied.  So don't attempt to install patch 101168.  As with
   Solaris 2.2, you can if you wish disable Volume Managr's use of the
   floppy drive altogether.

   (Some other situations may also sometimes cause problems with your
   use of the diskette drive-
	o Use the Meta+E key sequence to eject a diskette.  
	o If you're using X to run Wabi remotely while displaying on
	  your system, drive A: refers to the diskette drive on the
	  machine where Wabi is executing.  This fundamental limitation
	  of the X window system may make it difficult to access the
	  diskette drive on your own system.)


Q: How do I access the CD-ROM drive under Wabi or SunPC4.0? 

A: From Unix `mount` the CD-ROM drive in your Unix file tree, then map
   a Wabi or SunPC drive letter to that point.  (Unless you're running
   the Volume Manager, which automatically does the `mount` for you
   when you insert the CD in the drive.)

   From Unix, the CD-ROM will conventionally show up as
	/cdrom/[volume name as seen by filemgr]

   Use the Wabi Configuration Manager to map for example
	N: -> /cdrom/[volume name as seen by filemgr]

   From within SunPC, execute for example
	prompt> net use N: /cdrom/[volume name as seen by filemgr]

   Note that the drive letter you choose (N: in the examples above)
   must be less than the setting of "lastdrive".  For SunPC lastdrive
   defaults to R: -- for Wabi it's Z:.


Q: What CD-ROM data formats can Wabi 1.0 access?

A: Wabi 1.0 accesses data files on the CD-ROM via Unix file system
   support after the CD has been mounted as part of the Unix file 
   system.  Any CD-ROM that can be mounted by the version of Unix 
   you're running can be used by Wabi.  Solaris supports CDs in the 
   Rock Ridge (High Sierra File System +) format.

   To Wabi 1.0 under Solaris, the CD looks like a High Sierra File 
   System (ISO 9660).  The Rock Ridge extensions are relevant to Unix, 
   not DOS/Windows/Wabi.


Q: Will Wabi take advantage of a hardware accelerator card?

A: Recently software technology has improved so much and RISC speeds
   shot up so fast that hardware accelerators don't offer the
   performance advantage they did just a year or two ago.  A hardware
   accelerator card wouldn't improve performance very much if at all,
   and wouldn't be cost effective.

   That doesn't mean future releases of Wabi won't be significantly
   faster -- they will.  


Q: Where should I install applications?  On my C: drive?

A: Most application installation procedures, when they sense a
   "standalone" environment, will suggest a location on your C: drive.
   Change this default location to some other drive, for example G:.
   Installing apps on a drive other than C: or D: will make your Wabi
   systems easier to administer both now and in the future.

   Reserve drives C: and D: for files that every user must have their
   own copy of and for apps that must access a simulated hard drive for
   their copy protection scheme to work.


Q: Why do most application installs take so long, especially since a 
   few apps install quickly?

A: What's going on is that most MS-Windows application installation
   diskettes contain compressed files that have to be decompressed at
   installation time.  A few packages use the "standard" compression
   algorithm via the "standard" MS-Windows API calls, which are 
   supported by Wabi -- these are the packages that install quickly.  
   Unfortunately most packages use custom compression algorithms which 
   are not accessible through any MS-Windows API call and hence cannot 
   be natively supported by Wabi.  Wabi has no choice but to actually
   execute the application's own decompression code one Intel opcode at 
   a time.  

   A few MS-Windows-based packages (ex: MS-Windows itself) call the
   compression and decompression routines in MS-Windows.  These calls
   are intercepted by Wabi and executed in native code, so they run
   much much faster.  That's why these packages install so much more
   quickly.


Q: What can I do to make application installation easier?

A: Here's some things to try:

   1) See if the ISV supplied the application on a CD-ROM as well as
      on diskettes.  Wabi installs apps from a CD-ROM very well.  One
      reason is that CD-ROMs are so large that ISVs don't compress the
      files on them.  So Wabi doesn't have to decompress any files, and
      there's no chance of running up against a performance problem
      with decompression.

   2) Copy each set of application installation diskettes to a single
      subdirectory on a hard drive somewhere on your network.  Then
      load them from the hard drive rather than diskettes.  Although
      this doesn't speed things up much, it does eliminate the need to
      babysit the installation to change floppies.  You can start an
      installation and answer its questions to get it started, then
      leave for the night.  The installation will be done when you come
      in the next morning.

      Most apps will figure out by themselves that all the files are
      available in a single subdirectory and there's no need to watch
      for diskette boundaries.  If an app does care about diskette
      boundaries, simply add a symlink to the subdirectory for each
      diskette, so it looks something like this:  
	fooapp.dsk/
	  disk1 -> .
	  disk2 -> .
	  disk3 -> .
	  disk4 -> .
	  disk5 -> .
	  disk6 -> .
	  file1
	  file2
	  file3
	  ...

   3) Investigate to see if the app has some installation options that
      allow you to do a "partial" installation to decompress the files.
      If so, use it and store the decompressed files somewhere where
      everyone can use them to do the "second half" of the install.

   4) Investigate the possibility of all the users on the network
      referencing a single copy of the application.  That way you only
      have to install the app once.  You'll have to do manually some of
      the work usually done by the application's setup program: store
      .ini in ~/wabi/windows, update ~/wabi/windows/win.ini, etc.
      If you start investigating this, remember it's a way to shorten 
      the installation process, not a way to "cheat" on application 
      licenses.


Q: Many app installation programs take over the whole screen when
   they're installing the app.  How can I work in other windows while
   the installation is proceeding?

A: Press the Front key once to make the installation program go to the
   back.  Then you'll be able to see and work in other windows.

   Note it may take Wabi several seconds to respond to the Front key if
   the application installation is heavily loading your machine.  Also
   note pressing the Front key doesn't work with a few application
   installation programs.


Q: How come some applications install some *.DLL files into
   C:\windows\system?

A: Many applications include on their installation diskettes some files
   that are usually thought of as a part of "real Windows" (*.DLL,
   WINHELP.*, etc.) This allows these applications to install under
   systems other than MS-Windows 3.1 (for example MS-Windows 3.0), and
   still provide full functionality.  Typically the application
   installation places these files in the same place "real Windows"
   would place them, which means other applications can use them.


Q: When I copy an application to Wabi, why doesn't the application show
   up on my Windows desktop immediately?

A: The "real Windows" desktop is similar to the OpenWindows desktop.
   You can have executables available yet not have desktop icons for
   them.  (You can have icons that don't launch their application
   correctly, too.)

   In OpenWindows you can start an application even though you don't
   have an icon or root menu entry for it by typing the startup command
   into a cmdtool window.  One way to do the same thing for a Wabi
   application is to pull down the File menu from the Application
   Manager, select the Run option, and type in the path and name of the
   application you want to execute.  

   (Another way to launch a Wabi application is to add it to your
   OpenWindows root menu and launch it directly rather than going
   through the Application Manager.  The entry in your root menu should
   be something like 
	"AppName..."   exec wabi -s 


Q: How can I copy desktop icons from an existing Wabi to a new one?

A: Wabi icons are grouped together.  Each group of icons is stored
   in a file named *.GRP.  These files are stored in C:\WINDOWS.  

   To copy a bunch of icons to a new Wabi, locate the relevant 
   ~/wabi/windows/*.grp file in the old Wabi, check that there's no 
   file with the same name in the new Wabi, then copy the file.  Also 
   edit ~/wabi/windows/progman.ini and add another line to the [Groups] 
   section near the end of the file to point to the *.GRP file you just 
   copied.  


Q: Why are some of my icons not visible in Application Manager?

A: Application manager will sometimes allow you to place icons off the
   edge of its window.  If you suspect some of your icons aren't
   visible, especially if the size of the Application Manager window
   has changed recently, pull down the Windows menu and select Arrange
   Icons (or Tile).


Q: I've copied both the application and its icons to a new Wabi.  But 
   when I try to launch the application I get an error message about 
   not being able to find some file.  What else do I need to do?

A: Most Windows-based applications keep their per-user parameters
   in one or more *.INI files, similar to ~/.*rc file in Unix.  Each
   use needs to have their own private copy of these files.  

   The exact details of which files are involved and where they should
   be stored is different for each application, and depends on your
   local networking conventions.  One method that usually works is to
   find all the files named *.INI related to the application in its old
   location, and copy them to the new user's ~/wabi/windows directory.


Q: How does Wabi calculate its colormap?

A: Wabi 1.0 sets up all 256 colormap entries when it first starts up,
   so it can give colors to applications running under it whenever
   necessary.  Wabi first preallocates a wide spectrum of colors it
   needs in its colormap.  Then it fills out the rest of the colormap
   with colors that were already in the shared colormap when Wabi was
   started.

   If most or all 256 colormap entries are already in use when Wabi
   starts up, Wabi may not behave well.


Q: Why are the colors Wabi gives to the applications running under it
   sometimes not pure?  Why for example do I sometimes see a yellow
   color with a few blue pixels in it, or a green color with a few
   yellow pixels in it?

A: This is "color dithering".  Both Wabi and "real Windows" do this
   when an application asks for a specific color that isn't available
   exactly.  Wabi gives the application a color that almost matches,
   then mixes in enough pixels of a different color to correct the
   overall effect.  If you stand back, the color you see will be
   exactly what the application requested.  If you look closely,
   though, you may be able to see the pixels of the "other" color.


Q: Why do the colors on my screen sometimes change when I move the
   mouse?

A: This is a typical X-windows behavior, commonly called "color
   flashing" or "X-ray colors" or "technicolor".

   Here's why it happens:  The X-Server (your terminal) advertises one
   palette of 256 colors.  But several apps each want their own palette
   of colors, totaling more than 256.  So the X-Server tries to keep
   everybody happy by storing away multiple 256-color palettes in
   software, and installing the "right" one into the hardware at the
   right time so the current window always has the correct colors even
   if other windows do not. As you move the mouse around, the X-Server
   keeps swapping different 256-color palettes into the hardware,
   resulting in the "flashing" you see.

   OpenWindows lets you modify and control this behavior.  OpenWindows
   calls this "color focus".  The previous paragraph describes the
   default behavior of most X-servers, including OpenWindows.  See the
   `olwm` manpages for more information about the three X resources
   that control this behavior:

	OpenWindows.AutoColorFocus [true|false]
	OpenWindows.ColorTracksInputFocus [true|false]
	OpenWindows.ColorFocusLocked [true|false]


Q: How can I prevent "color flashing" and still have all the colors I 
   want whenever I want?

A: In the end, you probably can't.  You can minimize "color flashing",
   or you can have all the colors you want whenever you want, but you
   probably can't have it both ways at the same time.  If you have an
   app that runs under Wabi and wants to display a near-true-color
   picture, you'll have to put up with the "color flashing".

   Think of Wabi colors as presenting you with a tradeoff choice.
   (This isn't 100% technically accurate, but it's a good place to
   start.)  Here's how you can control to some extent which side of
   that tradeoff you land on:

	clear existing Wabi color info  /* see another Q: for details */
	if (you want most accurate possible Wabi colors) then {
		/* almost certainly you'll get colormap flashing */
		start Wabi first;
		start all your other apps;
	} else /* (you want to minimize color flashing) */ {
		/* Wabi apps may display "ugly" "dithered" colors */
		start all your other apps;
		start Wabi last;
	}


Q: How can I minimize color flashing, even if I can't eliminate it
   altogether?

A: First, use a plain color or simple tiled pattern as your Unix 
   windows background rather than a "true color" photograph.  

   And second, if you're running both SunPC and Wabi, start SunPC 
   before Wabi rather than using Wabi to launch SunPC.  


Q: How else can I minimize color flashing?  For example is there a way
   to have the colors change only when I click on a different window?

A: Yes, you can do this a couple of ways.  In fact you may want to
   implement both these solutions.

   One way is to maximize all Wabi windows to full screen size when you
   use them.  You may want to do this anyway since it makes the window
   easier to read and less distracting.  Since no other windows are
   visible on the screen, there's no way to accidentally activate a
   different window and so induce color flashing.

   Another way is to modify the behavior of your window manager.  If
   you're using the OpenWindows window manager and have already told it
   you want click-to-type focus, you can reduce the amount of color
   flashing by executing the following commands:
		echo "OpenWindows.AutoColorFocus: false" | xrdb -merge
		echo "OpenWindows.ColorFocusLocked: false" | xrdb -merge
		echo "OpenWindows.ColorTracksInputFocus: true" | xrdb -merge
		xrdb -edit $HOME/.Xdefaults


Q: What's the purpose of the "font cache"?

A: Wabi needs to get lots of detailed information about fonts
   all the time.  Wabi avoids the constant overhead of making a
   round-trip call to the X-server every time it needs some
   information.  Instead, Wabi collects all this information from the
   X-server once and stores it locally.  The file where all this
   information is saved is called the "font cache".


Q: Why is the font cache sometimes "rebuilt"?

A: Wabi may sense that the X-server's list of available fonts has 
   changed in some way.  If so, Wabi has to throw away any information 
   it had previously collected from the X-server and ask all over 
   again.  This process is called "rebuilding the font cache".  


Q: When exactly is the font cache rebuilt?

A: The font cache will be rebuilt if your X-server's current "font
   path" doesn't exactly match the font path stored in the existing
   font cache in file 0.fc in directory ~/wabi/fc.  To
   say the same thing the other way around, the font cache will NOT be
   rebuilt if Wabi can find an existing file for the same user and same
   X-server whose "font path" exactly matches the current font path of
   the X-server.


Q: At my site, every user who starts Wabi for the first time has to
   wait for it to "build a font cache".  Apparently the default font
   cache supplied with Wabi doesn't work for me.  Is there a way I can
   customize Wabi's default font cache to match to my site?

A: Yes.  It's easy to customize Wabi to provide a "default font cache"
   that matches your site.  

   The default font cache provided with Wabi 1.0 for Solaris matches
   vanilla OpenWindows 3.1 or 3.2.  
   
   To create a font cache file that you can then use as the default
   font cache for your site, login as a representative user using your
   site-standard windowing setup, and start Wabi.  Wabi will spend
   several minutes creating a file called ~/wabi/fc/{systemname}0.fc.
   This is the file you want.

   To make this file available for use as a default font cache, copy it
   into Wabi's file tree $WABIHOME/lib (probably location
   /opt/SUNWwabi/lib), with a meaningful name (ex: foo_org_1.dflt.fc).
   Putting that all together, and assuming for example that your
   organization name is "Widgets Inc", do something like this:
	% uname -n
	sneezy
	% id
	uid=12345(jane) gid=1001(developers) groups=1001(developers)
	% su
	# cp  ~jane/wabi/fc/sneezy0.fc /opt/SUNWwabi/lib/widget_1.dflt.fc

   Finally, to activate use of the new file, modify startup script
   $WABIHOME/bin/wabi.  Find the existing line that says
	$LN "../wabihome/lib/sol_spc.dflt.fc" "$FCNAME" 
   Insert a new line that points at your new file instead, for example
	$LN "../wabihome/lib/widget_1.dflt.fc" "$FCNAME" 

   If you have just a few Wabi "central engines", you can add the new
   default font cache file and change the wabi startup script on each
   of them.  If you install Wabi on individual workstations, you may
   find it easier to modify the installation package or procedure to
   include the new file and the change.


Q: What's the most common reason why Wabi builds a new font cache file
   every so often even though the user has run Wabi on that system
   before?

A: Usually it turns out that some other application modifies the
   X-server's font path when it starts up.  Many more apps do this than
   you'd think -- they do it transparently so you never notice.  

   The X-server's font path is reset each time your window system is
   restarted.  If this other application is started before Wabi, Wabi
   will then see a longer font path (ex: /fopath,/barpath).  If on the
   other hand Wabi is started before this other app has ever been
   started, wabi will see a shorter font path (ex: /foopath).  Every so
   often the font cache file left from the last time Wabi ran doesn't
   match the X-server's current font path, so Wabi builds a new font
   cache file.


Q: How can I prevent this font cache rebuilding?

A: Find out all the additional fonts that might ever be added to your
   X-server by an application you run.  Then add them all to your
   X-server's font path when you first start your window system.  Since
   all the extra fonts always appear in the font path, Wabi shouldn't
   have to rebuild its font cache file.

   To do this, add lines like this to your X-server's initialization 
   file (probably ~/.xinitrc), one line for each additional font 
   directory that might be added to your X-server's font path by an 
   application.
	xset fp+ /fooapps/fonts
	xset fp+ /etc/etc/etc
	xset fp+ /barapps/fonts


Q: I don't know for sure what "font path" my X-server is using.  And I
   don't know for sure which of my apps are modifying the font path
   or what they're modifying it to.  How can I find out?

A: To fully understand what's going on, insert this debug code into the
   Wabi startup script and run with it for a few days.  Insert it near
   the end of the script, just before the launching of "wabiprog".
   Compare your system's behavior with the email this debug sends you,
   and you'll soon understand your system well enough to prevent most
   Wabi font cache rebuilds.

	------ code fragment to use for debugging ---------
	------ insert into startup script $WABIHOME/bin/wabi ---------
	SEADDR=  # insert secondary email address if you wish
	USERNAME=`who am i | awk '{ print $1 }'`
	mail $USERNAME $SEADDR <0.fc
	touch 0.fc


Q: How can I ensure my existing font cache isn't deleted if I
   inadvertently start Wabi while my x-server's font path is different
   from its usual setting?

A: With Wabi stopped, rename your existing font cache file, then create
   a symlink pointing from the expected name to the actual file.  If
   you inadvertently start Wabi while your X-server's font path is
   modified, Wabi will remove the symlink yet leave the actual data
   file untouched.  You can abort Wabi, fix the font path, recreate the
   symlink, and restart Wabi and not have to wait while Wabi rebuilds a
   font cache file.

   To do this:
	foohost% cd ~/wabi/fc
	foohost% mv foohost0.fc foohost0_sav.fc
	foohost% ln -s ./foohost0_sav.fc foohost0.fc


Q: Does Wabi support DDE/OLE (Dynamic Data Exchange / Object Linking
   and Embedding)?

A: Yes, DDE/OLE works between supported windows applications running
   under Wabi.  To do this Wabi 1.0 depends on having the DDE/OLE
   *.DLLs from Microsoft loaded.  Many application installation
   diskettes include these libraries, so it may not be necessary to
   purchase and install "real Windows" to get DDE/OLE support even
   under Wabi 1.0.  In the future Wabi will provide its own support of
   DDE/OLE.


Q: What can I do to my documents to make printing faster?

A: The one change you can make to your documents to make printing
   significantly faster is to be sure all the paragraph alignments are
    (straight left margin, ragged right margin) rather than
    (straight left margin, and straight right margin).
    requires adding a tiny bit of space between every single
   character so the line of text ends just at the margin.  Doing this
   puts a lot of strain on Wabi.  If you change from  to
   , printing will be faster, and you'll be less likely to see
   "out of memory" messages too.


Q: Can I do something else while my document is going to the printer?

A: Yes.  Your machine is not "locked up" while a document is going to
   the printer.    

   You won't be able to resize or move the window that's sending the
   data to the printer, though.  So plan ahead -- put that window off
   to one side before you begin printing.  (Put it somewhere where you
   will be able to see the dialog boxes the printing process produces.
   That way you can tell what page the printing is on, and you'll have
   an opportunity to "Cancel".)  After you start the printing, you can
   move the mouse over a different window, click on it, and work in it
   while Wabi is composing the print job.

   This concrete example assumes MS-Word is going to do the printing.
   Before you begin printing:
    - Move the MS-Word window to one corner of your screen.
    - Shrink the MS-Word window a little bit.
    - Be sure any other window you want to work in is at least
      partly visible.  (The MS-Word window won't respond to "back" 
      while it's printing, so any window that's entirely obscured by it 
      won't be accessible.)


Q: Can I install any printer driver software I want under Wabi?

A: Wabi 1.0 provides and supports the couple hundred printer drivers
   shown in the Available Printer Drivers panel in the Printer Settings
   dialog box.  No matter what PostScript-capable printer you've got,
   at least one of these available drivers will match it very closely
   if not exactly.

   If you've installed "real Windows", you'll also find a Generic Text
   printer driver in the list of available drivers.  Use this driver to
   print text to a printer that understands ASCII text but not
   PostScript.  The output will be only text not graphics, and will all
   be in the printer's default font (probably Courier 10).


Q: Can Wabi 1.0 print to my HP PCL printer?

A: Yes, provided you do one of the following:

     1) Install a PostScript cartridge in the printer so it understands
	PostScript as well as PCL.  

     2) Use the Generic Text printer driver to print text only all in
  	one font.  


Q: Can Wabi print to my SPARCprinter?

A: Yes.  The SPARCprinter appears to Wabi as yet another
   PostScript-capable printer.

   The SPARCprinter, unlike most printers, changes its capabilities
   depending on exactly what fonts you have installed.  Assuming you've
   got the standard set of fonts in /usr/openwin/lib/fonts, the best
   match to the SPARCprinter's capabilities is the "Apple LaserWriter
   Plus v42.2".  The SPARCprinter will also work with most other
   PostScript printer drivers, but may not render fonts as well or
   have the correct margins.


Q: When will Wabi provide some PCL printer drivers?

A: Wabi from SunSoft will provide PCL printer drivers no later than
   release 2.0.  You can expect to see Wabi 2.0 about half a year after
   you see Wabi 1.0.


Q: How can I diagnose problems accessing the printer I choose?

A: First, assuming you're using a printer that's already available on
   your network, be sure you can print to the printer from Unix.  (If
   you've got the printer connected directly to the port on your own
   machine and want to access it directly from Windows, different
   instructions apply).  From a cmdtool, you should be able to say
	lp  
   and have the right information appear on the printer.  Do not go on
   to try to access the printer from Wabi until you have this working.
   If it doesn't work this way, there's no chance Wabi will be able to
   use it.  Trying to access it from Wabi will just make problem
   diagnosis more difficult.

   Second, be sure you've chosen the right printer driver in Wabi.
   Open Printers in Wabi's Configuration Manager and check that the
   "Available Printer Driver" that most closely describes the physical
   printer you plan to use shows up as an "Installed Printer".  The
   pre-selected "Adobe Default Printer" will work for almost any
   PostScript-capable printer.  The advantages of choosing a more
   specific printer driver are speed, more accurate margins and
   clipping, and access to special features.

   Third, try to print to a file from within Wabi, then direct that
   file to the printer from a cmdtool.  Open Printers in Wabi's
   Configuration Manager, select the printer, click Port..., select
   FILE:, and click OK.  Then go to the app and print something.  The
   app will ask you for the name of a file -- enter for example
   "h:\test.ps".  When the application finishes its printing operation,
   go to a cmdtool and check that the file exists.  Then try to view
   it, and try to print it:
	cd $HOME
	ls -l test.ps
	pageview test.ps
	lp test.ps

   If the application never asks you for a filename, double-check which
   Wabi printer it's going to.  If necessary reset Wabi to default to
   the correct printer.  Open Printers in Wabi's Configuration Manager,
   select the printer, click Set as Default, and click OK.   (Although
   the words are the same, this "default printer" has no connection to
   the "default printer" you see following the legend "Native Printer
   Name" after you click Connect...  The "default printer" setting at
   the top level of ConfigurationManager:Printers tells applications
   running under Wabi which printer driver and configuration to use if
   they're not told otherwise.  The "default printer" setting below
   Connect... tells Wabi to use the same physical printer as Unix.)

   If you get some sort of error message that indicates insufficient
   disk space when you try to print the file from the cmdtool, use
   normal Solaris administrative procedures to fix the problem.  This
   may mean either adding more swap space to your system (assuming /tmp
   is using tmpfs), or pointing /var/spool into a different disk
   partition with more available space.

   Finally, when everything works, correct Wabi's printer configuration
   to make Wabi access the Unix print spooling system automatically.
   Open Printers from Wabi's Configuration Manager, select the printer,
   click Port..., select LPT1:, click Connect, make sure the Native
   Print Command is the same one you tested from the cmdtool above
   (probably lp ...), click OK, and click OK again in the previous
   dialog box.


Q: How can I force a Wabi window to refresh itself?

A: You've probably noticed that unlike most X/Unix windows, MS-Windows
   windows don't include a "Refresh" option in the menu at their upper
   left corner.  If your display becomes corrupted and you want to
   force an application to completely redraw itself, Minimize (close)
   the application, then reopen it.


Q: How can I create directories ("folders") for my Wabi applications to
   use?  And how can I delete files that my Wabi applications have
   created?

A: Use either your Unix desktop file manager or Unix shell commands to
   create and delete paths and files that your Wabi applications don't
   automatically do for themselves.

   Be sure everything you create has a name that follows DOS' filename
   conventions: a max of eight characters followed optionally by one
   period and up to three more characters.  The characters should all
   be lower case alphas or numerics or the underscore or dash.  If you
   create something with a name that doesn't fit within these
   restrictions and then try to view or use it from within a Wabi
   application, the name may appear "corrupted" and the file or path
   may not be accessible at all.

   Wabi uses the same Unix->DOS filename translation scheme as other PC
   emulation products such as PC-NFS.  Translated names are hard to
   work with; and it's difficult to always predict in advance which
   files will be used only by Wabi apps, which files will be used only
   by Unix apps, and which files will be used by both.  So get in the
   habit of making all names on your system follow the DOS 8.3
   convention.

   Actually, DOS rules allow some punctuation characters to be used in
   filenames.  DOS rules explicitly exclude only / \ [ ] | < > + = ; *
   ? and space.  However for maximum usability and guaranteed
   portability to any media including any CD-ROM, avoid all punctuation
   except _ .  Also avoid names that begin with aux, com, con, lpt,
   nul, or prn as these may confuse some DOS/Windows applications.


Q: Why do I sometimes see the message "- not enough memory!" from apps
   running under Wabi even though my system has plenty of RAM and 
   plenty of swap space?

A: Many "real Windows" applications whenever they run into an
   unrecoverable error and don't know what else do to simply say "not
   enough memory" and quit.  Take all "not enough memory" messages from
   Windows apps with a grain of salt, since they often don't mean quite
   what they say.


Q: What is the process named "wabifs" that shows up on some machines?

A: Wabifs is Wabi's auxiliary "font server" process.  (The main Wabi
   process is named "wabiprog".)  If Wabi recognizes that your X-server
   is capable of speaking the X11R5 "font server" protocol, it starts
   up this secondary process to feed font information to your X-server
   behind the scenes.


Q: What's the advantage of using a font server?

A: When a separate font server process is active, the regular Wabi
   process can always send text rather than bitmapped images to the
   X-server no matter what font you're using.  Even if you're using 
   some TrueType font your X-server never heard of before, the regular 
   Wabi process can act as though the X-server knows about the font.
   The X-server and the separate font server process will work out the 
   details of passing the font information.

   Because your X-server understands that it's dealing with font glyphs
   rather than just any old bitmapped image, it can optimize its use of
   the information and it can cache the information for future use.  So
   use of fonts that aren't already known to your X-server is
   substantially faster.  In fact, with the separate font server 
   process active, there's no performance difference between using an X 
   font and using a TrueType font.


Q: What systems can use the font server process?

A: Any X-server that supports the font service protocol that was first
   defined in X11R5 can take advantage of Wabi's separate font server
   process capability.

   The font service protocol is a recent addition to X.  Because the
   original X never imagined it, there's no easy way to find out
   whether or not a particular X server supports the font service
   protocol.  So Wabi maintains a list of X-server names and releases
   that are known to support the font service protocol.

   Wabi maintains this list in file $WABIHOME/lib/wabifs.displays.
   Each entry on the list appears on its own line.  The first field on
   the line is the X-server's vendor string, and the second field is
   the vendor release number.  The first field probably contains blanks
   and so should be enclosed in double-quote marks.  The two fields
   should be separated by a comma.  To find out the name and release
   number of your X-server, execute `xdpyinfo`.


Q: My X-server supports the X11R5 font service protocol, but Wabi 
   doesn't use a separate font server process with it.  How can I make 
   Wabi use a separate font server process with my X-server?

A: Add a line to file $WABIHOME/lib/wabifs.displays that describes your
   X-server.  To get the information to enter, execute `xdpyinfo`.
   Enter the vendor string enclosed in double-quotes as the first
   field, a comma separator, and the vendor release number as the
   second field.


Q: How can I force my system to not use a separate font server process?

A: To force Wabi to not use a separate font service process with your
   X-server even though it usually would, edit file
   $WABIHOME/lib/wabifs.displays.  Find the line that describes your
   X-server, and comment it out by inserting a sharp ('#', also called
   poundsign or numbersign) at the beginning of the line.


Q: Do I need any patches to run Wabi with Solaris 2.2?

A: In addition to other patches required by SunOS or by other apps, it
   will be helpful to install patch 101168-02 (or higher rev) "SunOS
   5.2: Patch (package fix) to volume management to support Wabi".

   This patch is available on the Wabi 1.0 CDROMs.  Don't be concerned
   by the "T101168-02" label in the patch README on the CDROM - the
   patch binaries on the CDROM exactly match the binaries on the patch
   database.

   Note that if you choose not to install the patch, you will have to
   make a change to your system to allow Wabi to use the floppy disk
   drive, and you will get a warning message when Wabi starts.  The
   change is to disable the Volume Manager's ownership of the floppy
   disk drive entirely by commenting out the line that includes the
   words "...use floppy..." in /etc/vold.conf and rebooting your
   system.


Q: Do I need any patches to run Wabi with Solaris 2.3?

A: In addition to other patches required by SunOS or by other apps, you
   should obtain and install 101362-01 (or higher rev) "OpenWindows
   3.3: Patch to fix several misc. Window Server bugs".

   As Solaris 2.3 was still under development when the Wabi 1.0 CDROM's
   were pressed, this patch naturally isn't present on the CDROM.
   However, it is available on the various patch databases throughout
   the company.  Version -02 of this patch is now available.  

   The critical bugfix here is Bugtraq BugID #1146111, "Xsun goes into
   infinite loop when connected to a font server, has to be killed".
   This bug concerns a glitch in the file descriptor usage in the X11R5
   font server code present in OpenWindows 3.3.  Because of this
   glitch, the X server could get confused over which file descriptor
   it has open to a given client, and could get stuck in an infinite
   loop reading from the wrong descriptor.  As a result, the
   OpenWindows Desktop would appear to the user to be "hung".

   While this bug was originally triggered by Wabi, it could be
   provoked by any X client application using the X11R5 font server
   feature.  (As a side note, Wabi works on both X11R4 and X11R5 X
   servers -- if it detects that it is running on X11R5, it will use
   the advanced font handling capabilities of that server.)

   If you find that you MUST run Wabi on an OpenWindows 3.3 desktop
   that does not have this patch, you should be able to work around the
   problem by only letting a couple of X clients attach to your X
   server (i.e. run OpenWindows with only a terminal window or two and
   Wabi).  Clearly, this is not a "real world" solution, and is only
   useful for a Wabi demo where this patch for some reason isn't
   available.  Any customer or production 2.3 machine that wants to run
   Wabi should have this patch.

   Another temporary workaround for running Wabi on an OpenWindows 3.3
   desktop that does not have this patch is to disable Wabi's use of
   the X11R5 font server feature.  As root, edit file
   $WABIHOME/lib/wabifs.displays (probably
   /opt/SUNWwabi/lib/wabifs.displays) and comment out the line that
   says "Sun Microsystems, Inc.", 3300 by inserting a sharp ('#', also
   called poundsign or numbersign) in the first column.


Q: Where can I get applications to run under Wabi?

A: Purchase individual or network or site licenses for applications
   from the applications vendors just as you would to run the apps
   under "real Windows".  Wabi does not provide any applications, nor
   does it provide any special application licensing arrangements.


Q: My x86 system running Solaris x86 doesn't have the block of shortcut
   keys Open/Copy/Cut/Paste/Front/etc. on the left side of the 
   keyboard.  How can I get the functionality of these keys --
   especially the Front key-- on my x86 system?

A: You can map these functions to other keytops.  Here's an example:

   in ~/.openwin-init (or ~/.xinitrc?) add
        xmodmap xmapfile

   then create ~/xmapfile with contents something like this
        keysym F1 = L6
        keysym F2 = L8
        keysym F3 = L10
        keysym F5 = L9
        keysym F9 = L7
        keysym F10 = L5


Q: I have an x86 system with both a Solaris disk partition and a
   DOS/Windows disk partition.  How can I see the files on the
   DOS/Windows partition from inside Wabi?

A: Wabi can see anything you can see from the host OS (for example
   SunOS/Solaris), not more and not less.

   You can see the files on a DOS/Windows partition from Solaris x86 
   after using the Solaris mount command.  See manpage mount_pcfs.  
   The mount command will look something like this:
	mount -F pcfs /dev/dsk/c0t1d0p0:c /dosdisk


Q: Excel running under Wabi refuses to open a spreadsheet on the
   DOS/Windows partition.  Why?  Is there anything I can do about it?

A: Currently the Solaris type "pcfs" file system does not support file
   locking.  Applications like Excel that try to lock every file they
   open will be told "operation not supported" when they try to open
   and lock a file.

   You can bypass this problem by setting environment variable
   WABI_NOLOCK to 1 before you start Wabi.  This short-circuits all
   Wabi file locking operations and makes Wabi pretend to apps running
   under it that all the lock requests succeeded.  We suggest you do
   not do this in a production environment since it leaves you with NO
   protection against two users opening the same file at the same time
   and destroying it.


Q: Will newer versions of qualified apps (ex: WordPerfect 6.0
   rather than WordPerfect 5.0) run under Wabi 1.0?

A: Several applications now have a newer version than that qualified
   to run under Wabi 1.0.  Since the newer version wasn't available
   when Wabi 1.0 was being developed, it hasn't been tested and hence
   isn't qualified.

   There's no theoretical reason why a newer version of an app wouldn't
   run under an older version of Wabi even though it isn't officially
   qualified.  However our experience is that newer versions of most
   apps do not run right under Wabi 1.0.  Newer versions of most
   MS-Windows-based apps are significantly different, and Wabi 1.0 is
   still relatively immature.  So it's not unusual for the newer
   version of an app to expose a problem in Wabi 1.0.


Q: Will newer versions of qualified apps (ex: WordPerfect 6.0
   rather than WordPerfect 5.0) run under Wabi 2.0 in the future?

A: Yes, Wabi 2.0 will qualify both the newer and the older version
   of all 13 apps qualified under Wabi 1.0.  So for example both
   WordPerfect 5.0 and WordPerfect 6.0 will be qualified to run
   correctly under Wabi 2.0.

   Wabi 2.0 will also qualify seven additional applications, for a
   total of twenty.


Q: What user id should I use to run Wabi?  For example, can I run Wabi
   as "root"?

A: Run Wabi as a real user, not as a system/maintenance user such as
   "root".  If necessary, create a "guest" or "demo" user on your
   machine.  Wabi 1.0 will not run as "root" no matter what you do.

   Although Wabi 2.0 will run as "root", we suggest you don't do it.
   For "root", the Wabi C: drive which maps to $HOME/wabi will map to
   /wabi.  Thus your entire C: drive will appear in your machine's /
   disk partition, which is probably very small and nearly full.  And
   ownership of the data files you create will be unclear (is that
   "root@foohost", or "root@barhost").


Q: What support for file and record locking does Wabi 1.0 provide?

A: All the file and record locking options on all API calls work
   correctly under Wabi 1.0.  All application requests are translated
   to the equivalent Unix advisory lock request, and the request is
   forwarded over the network to a remote machine if necessary.

   Some applications never lock files, some applications lock only
   files on drives marked as "network" drives, and some applications
   always lock files.

   MS-Excel is the most notable example of an app that makes extensive
   use of file and record locking options whether or not it thinks it's
   running on a network.  This is why if you have problems with Excel
   much more than with other apps we suggest you look first to the area
   of file and record locking.

   You can disable all of Wabi's file locking support by setting
   environment variable WABI_NOLOCK to 1 before you start Wabi.  This
   short-circuits all Wabi file locking operations and makes Wabi
   pretend to apps running under it that all the lock requests
   succeeded.  We suggest you do not do this in a production
   environment since it leaves you with NO protection against two users
   opening the same file at the same time and destroying it.


Q: What does the file SHARE.EXE do?  And do I need it on my Wabi 
   system?

A: Under DOS, the file SHARE.EXE contains a loadable driver that adds
   file locking support to DOS.  Once SHARE.EXE is loaded, both DOS and
   MS-Windows can make file locking requests.

   Wabi's file locking support is fully integrated into Wabi itself
   rather than being implemented in a separate drive. So Wabi doesn't
   need this file.

   Note though that some application installation procedures insist
   either that the file exist or that it appear to be executed in
   your AUTOEXEC.BAT.  To satisfy these installation procedures,
   `touch ~/wabi/windows/system/share.exe` and add a line invoking
   SHARE.EXE to ~/wabi/autoexec.bat.  


Q: Can Wabi 1.0 run Windows 3.1 multimedia applications?

A: Wabi 1.0 does not support the "multimedia extensions" of MS-Windows
   (the approximately 300 new API calls that appeared for the first 
   time in MS-Windows 3.1).  Support for some of these calls in a 
   future Wabi is under consideration.

   (Please tell us which apps you hope to use that either support or
   require multimedia.  None of the qualified apps require the 
   multimedia extensions.)


Q: Does Wabi 1.0 support the devices and services used by multimedia
   applications?

A: Wabi 1.0 does not support the Microsoft Multimedia CD extensions
   (MSCDEX.EXE) and so does not support the high quality sound that
   multimedia functionality provides.

   In other words Wabi 1.0 does not support Compact Disc Audio 
   Services.  Wabi 1.0 has no way to route sound from a CD directly to 
   your speaker, something many multimedia programs expect to be able 
   to do.

   Since Wabi 1.0 does not support a sound device, it does not support
   Waveform Audio Services either.  Wabi can read a *.WAV file off a CD
   but cannot sent the data to a speaker.

   And Wabi 1.0 does not support MIDI Audio Services.


Q: Does Wabi 1.0 support either the built-in audio output device on 
   SPARC systems, or cards like the SoundBlaster on x86 systems, or 
   MIDI cards on x86 systems?

A: Wabi 1.0 supports only those devices known to the X11 protocol:
   display, keyboard, and mouse.  Wabi 1.0 does not support any sound
   device.


Q: Can I develop multimedia apps under Wabi?

A: Wabi 1.0's primary purpose is to run shrink-wrapped apps.  Wabi 1.0
   expects that multimedia development will be done either directly 
   under Unix or else on a "real PC".


Q: Will MS-Office run under Wabi 1.0?

A: MS-Office is a "bundle" of other products.  At least one version of
   many of the products it contains do run under Wabi 1.0.

   MS-Office 3.0 contains MS-Word 2.0, MS-Excel 4.0, and MS-PowerPoint
   3.0 which are all qualified to install and run correctly under Wabi
   1.0.  MS-Office 3.0 also contains the client part of MS-Mail, which
   does run imperfectly under Wabi 1.0 although it is not a qualified
   app.

   MS-Office 3.0 contains both a separate installation procedure for
   each app and a single unified installation procedure for the entire
   bundle.  If you have problems with the single unified installation
   procedure, use the separate installation procedures.  They
   definitely work.

   Like MS-Office 3.0, MS-Office 4.0 contains MS-Excel 4.0 and
   MS-PowerPoint 3.0, which are qualified to install and run correctly
   under Wabi 1.0.  And like MS-Office 3.0, MS-Office 4.0 also contains
   the client part of MS-Mail, which does run imperfectly under Wabi
   1.0 although it is not a qualified app.  MS-Office 4.0 contains
   MS-Word 6.0, which is not qualified to run under Wabi 1.0 and does
   not run correctly.  Some versions of MS-Office 4.0 also contain
   MS-Access 1.1, which is not qualified to run under Wabi 1.0 and does
   not run usefully.

   MS-Office 4.0 contains only a single unified installation procedure
   for the entire bundle.  To get this procedure to run, you will need
   to `touch ~/wabi/windows/system/share.exe`.  


Q: What does "native exception ... in an error message mean?  And what
   can I do to work around the problem?

A: The first number in the error message is a Unix signal number.
   Usually you'll see either 11 which is SIGSEGV, or occasionally 10
   which is SIGBUS.

   Unix SIGSEGV or SIGBUS usually means the application tried to follow
   an invalid pointer.  There are many ways an application running
   under Wabi could find one of its pointers invalid: overwriting of
   some other function's memory; unexpected result from a Wabi routine;
   unwarranted assumption about the initial value of a pointer; array
   index out of bounds; program logic error exposed when running under
   Wabi; inability to deal with unexpected display screen sizes; etc.
   In other words, it's almost impossible to say specifically what the
   problem is.

   The error message also contains an address.  But since the source
   code for the application is almost certainly not available to us,
   this address is not very helpful.

   If you see one of these messages, copy it completely and exactly and
   include it when you report the problem.  But don't expect that you 
   or anyone else will be able to figure out what the real problem is 
   or how to work around it just from the information in the error 
   message.


Q: Do I need any TrueType fonts at all on my system?

A: Not really.  Wabi will run fine without any TrueType fonts 
   available, and all of the qualified apps will work fine.

   The reason you would need to install some TrueType fonts is if you
   must be able to move documents back and forth between Wabi systems
   and real PCs with no changes whatsoever --not even imperceptible
   changes-- in the documents' appearance.


Q: What TrueType fonts do I get by default?

A: No Truetype fonts come with Wabi 1.0.  If you install "real
   Windows", you'll get several TrueType fonts: Ariel, Courier New,
   Times New Roman, Symbol, and WingDings.


Q: I've installed "real Windows", but my applications such as MS-Word
   still don't show any Truetype fonts as being available.  Do I need 
   to do something more?

A: After you install "real Windows", restart Wabi.  Wabi doesn't make 
   new fonts available to all applications until the next time it 
   starts.


Q: How do I install additional TrueType fonts under Wabi 1.0?

A: Getting TrueType fonts installed requires three things.  Some
   application installation procedures (ex: MS-Word Setup) handle all
   three things automatically and correectly.  Other installation
   packages don't do everything.

   The three things you need to install a TrueType font for use by all
   applications are:

        1) Copy *.TTF files into C:\WINDOWS\SYSTEM from another system, 
           a "real PC", or a floppy diskette.

                These files contain the actual font data.

        2) Copy *.FOT files into C:\WINDOWS\SYSTEM from another system, 
           a "real PC", or a floppy diskette.

                These files contain an embedded path that points at the
                *.TTF file.  If that pointer is a relative path (ex: 
                just a name like ARIAL.TTF) you can copy these files 
                around and it will work fine.  If that pointer is an 
                absolute path, you must copy the *.TTF files into the 
                directory specified by the path in the *.FOT files.

        3) Update the [fonts] section of C:\WINDOWS\WIN.INI

   Additionally you need to restart Wabi, since Wabi doesn't make these
   new fonts available to apps until the next time it's started.


Q: Will Visual Basic applications run under Wabi 1.0?

A: Although Visual Basic isn't on the "qualified" list, both our own
   experiences and feedback from users indicate Visual Basic apps run
   fine under Wabi 1.0.  We believe although we haven't tested
   exhaustively that everything in VBRUN100.DLL (or VBRUN200.DLL) works
   under Wabi 1.0.

   The Visual Basic "development environment" is not supported under 
   Wabi and won't be until they change the product significantly.  The 
   Visual Basic development environment currently requires a "Virtual 
   Device Driver" (VxD), something Wabi doesn't support.

   You should be able to 1) develop your apps under Visual Basic on 
   "real Windows", 2) port the apps to Wabi with only a tiny amount of 
   effort and perhaps no changes at all, then 3) deploy the apps you've
   developed on both "real Windows" and on Wabi.



====================================================================

Wabi 1.0 Supported Windows Applications
Last Updated 6 December 1993


Windows Applications Qualified by Sun To Run Under Wabi 1.0
-----------------------------------------------------------

	* Microsoft Excel(tm) 4.0
	* Microsoft Word for Windows(tm) 2.0
	* Lotus 1-2-3 for Windows(tm) 1.1
	* WordPerfect for Windows(tm) 5.2
	* Microsoft PowerPoint(tm) 3.0
	* Microsoft Project(tm) 3.0
	* Harvard Graphics for Windows(tm) 1.0
	* CorelDRAW 3.0
	* Lotus AmiPro(tm) 3.0
	* Aldus PageMaker(tm) 4.0
	* Microsoft Windows 3.1
	* Borland Paradox for Windows(tm) V1.0
	* Borland Quattro(R) Pro For Windows V1.0
	* PROCOMM PLUS for Windows(tm) 1.0