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