Thank you for contacting wabi1.0-questions@East.Sun.COM.
This current version of Wabi1.0 Frequently Asked Questions is being
sent back to you by an automatic email responder. This document
changes frequently, so contact this address again to obtain a fresh if
your existing copy is more than a couple weeks old. The document is
marked with the date of its most recent change near the top, just below
the title.
If your email request contained a subject or any content, it will be
ignored.
If you want to find out which applications run under Wabi, send email
To: wabi1.0-apps@East.Sun.COM.
Thanks!
-Wabi Sustaining Engineering
>From wabi1.0-questions@east.sun.com
Subject: Wabi 1.x FAQ Index
====================================================================
Wabi 1.x Frequently Asked Questions
Last Updated 26 May 1994
Subjects covered:
information about Wabi
patches related to Wabi
searching the Wabi FAQ
address space
API
obtaining applications
application versions
Type Managers
Wabi 1.0 & 1.1 status
bad value error
key mappings
BackSpace and Delete keys
32-bit interfaces and operations
CD-ROM access
color settings
colors
Corel Draw installation - fonts, and using CD-ROM
entering text in CorelDRAW
obtaining Wabi
processor type
cut copy paste
window decoration
dynamic link libraries
DOS applications
DOS partitions
drive connections
badidchoice error
ejecting floppy disks
MS-Word equation editor
error messages
common error messages related to OS version
font cache
font cache build
font cache rebuild
File Manager
using floppy disks
using floppy disk drives on other machines
sharing floppy drive between Wabi and SunPC
Font Service Protocol Problems in X11R5
font server
creating folders
additional fonts
formatting floppy disks
floating point
floating point precision
hardware/software requirements
icon overlap
icons
idle looping
installing applications under Wabi
sharing apps
installing MS-Windows
interprocess communication
window function shortcut keys
kernel modules
app network/site licenses
monochrome displays
multimedia
networking support
message: not enough memory
administering system memory
Novell Netware interoperability
ODBC
MS-Office
OLE/DDE
OS patches
virtual memory pagesize other than 4KB
UFS_HOLE panic
Wabi performance
printer configuration
printer drivers
printer problems
printing speed
refresh window
"root"
root menu
serial port use
sizing a central Wabi engine configuration
Wabi on a server
DOS/Windows file sharing and locking
Wabi file sharing and locking
sound
available disk space
startup group
temporary files
TrueType fonts
UDP checksums for NFS
virus protection
Visual Basic/Visual C/C++
Volume Manager
patches to Wabi
X display types
library problems on x86
X11 and Wabi coexistence
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: information about Wabi
Keywords: versions Wabi 1.0 Solaris workstation vendor Sun email
X-Applies-To:
X-Source-Info: File--1info.txt Version--1.4 Date--94/04/21
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 names and versions that are
certified 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: Where can I get more information about Wabi on non-Sun platforms
(e.g. systems other than SPARC/x86 with Solaris)?
A: Ask the platform vendor for more information about Wabi on a
particular platform. For example to get more information about Wabi
on the IBM PowerPC, on CompuServe GO POWERPC and see both the
Operating Systems message section and the Software library section.
(Currently these Unix platform vendors OEM Wabi: SunSoft, IBM, HP,
Novell(USL), and SCO.)
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: patches related to Wabi
Keywords: hang crash lock fail patch openwindows 2.3 3.3
X-Applies-To: Sun
X-Source-Info: File--3patch.txt Version--1.3 Date--94/02/23
Q: What if my system sometimes hangs or locks up or crashes when I
start Wabi?
A: There is a problem in OpenWindows 3.3 that Wabi tickles that has
extremely varied symptoms. Problem symptoms range all the way from
none at all to complete system failure.
If you are running OpenWindows 3.3 (which comes with Solaris 2.3) on
the machine where Wabi displays its windows, be sure you've applied
patch 101362 to your OpenWindows. Any revision -01 or above of the
patch will satisfy Wabi.
Note that if you're executing Wabi on one system and displaying it
on a different system (DISPLAY is not :0), the patch should be
applied to the system where Wabi displays. Applying the patch to
the system where Wabi executes will neither hurt nor help.
Don't spend any of your valuable time looking for the root cause of
a problem until you're sure patch 101362 is installed. Don't let
the fact that some systems seem to run okay without the patch
mislead you into thinking you don't need it.
Q: What if my system fails shortly after Wabi begins to build a font
cache?
A: There is a problem in OpenWindows 3.3 that Wabi tickles that has
extremely varied symptoms. Problem symptoms range all the way from
none at all to complete system failure.
If you are running OpenWindows 3.3 (which comes with Solaris 2.3) on
the machine where Wabi displays its windows, be sure you've applied
patch 101362 to your OpenWindows. Any revision -01 or above of the
patch will satisfy Wabi.
Note that if you're executing Wabi on one system and displaying it
on a different system (DISPLAY is not :0), the patch should be
applied to the system where Wabi displays. Applying the patch to
the system where Wabi executes will neither hurt nor help.
Don't spend any of your valuable time looking for the root cause of
a problem until you're sure patch 101362 is installed. Don't let
the fact that some systems seem to run okay without the patch
mislead you into thinking you don't need it.
Q: What if my system works fine for a while, then fails when I stop and
restart Wabi?
A: There is a problem in OpenWindows 3.3 that Wabi tickles that has
extremely varied symptoms. Problem symptoms range all the way from
none at all to complete system failure.
If you are running OpenWindows 3.3 (which comes with Solaris 2.3) on
the machine where Wabi displays its windows, be sure you've applied
patch 101362 to your OpenWindows. Any revision -01 or above of the
patch will satisfy Wabi.
Note that if you're executing Wabi on one system and displaying it
on a different system (DISPLAY is not :0), the patch should be
applied to the system where Wabi displays. Applying the patch to
the system where Wabi executes will neither hurt nor help.
Don't spend any of your valuable time looking for the root cause of
a problem until you're sure patch 101362 is installed. Don't let
the fact that some systems seem to run okay without the patch
mislead you into thinking you don't need it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: searching the Wabi FAQ
Keywords: search find searchit question csplit mail mailtool format structure keywords applies source info
X-Applies-To:
X-Source-Info: File--5srch.txt Version--1.4 Date--94/03/02
Q: How is this document structured?
A: This document is structured to look like a Unix "mail folder".
Each "mail message" contains one or more closely related Q&As. The
mail messages are concatenated in no particular order into a single
large document.
Q: How is this document formatted?
A: This document is ASCII text. It has a hard return code at the end
of every line so you can read it even if your display software
doesn't do line wrapping. Max line length is 80 (except for lines
that begin Keywords:).
Q: How can I find something quickly in this document?
A: The best option is to use sophisticated search software (ex:
SearchIt). Such software searches the full text, not just the
subjects or keywords or questions. And most such software
understands that a Unix "mail folder" is really a concatenation of
many shorter documents. So it treats each "mail message" as a
separate document even though they're all in the same file.
A second option is to point your mail reader at the Wabi FAQ. (For
example, with mailtool type the name of the file [ex:
/home/user/wabi-faq] on the filename line and then click the Load
button.) A display of headers will show you the subject of each
"mail message". The subject describes the general area addressed by
the Q&As in the message.
A third option is to split the document into separate files, with
one subject ("mail message") in each file. A Unix command that will
do this is (assume the filename is wabi-faq):
csplit -k wabi-faq '/^From /' '{99}'
The resulting small files will have names of the form xxNN. You can
use them as is, or rename them. (Each file contains a suggested
filename. The suggested filenames are short [6.3 characters] so
they can be used on any system.)
Q: What is the Keywords: line in each message for?
A: This line contains words that can be used to search for a particular
topic if you have older search software that can't do full text
searches.
This line is also useful with full text searches. It may include
words that you might search for but that aren't contained in the
text of any of the Q&As.
Q: What is the X-Applies-To: line in each message for?
A: This line can note that a particular topic only applies to some
versions of Wabi (ex: Sun-only, or Wabi 1.0-only). Usually this
line is blank, meaning the topic applies to all current versions of
Wabi.
Q: What is the X-Source-Info: line in each message for?
A: This line contains version tracking information useful for
maintaining the Wabi FAQ. The information may also be useful to
you.
File is a suggested filename for this item. It's short (6.3
characters), and uses only lower case letters and digits. So it can
be used on almost any system.
Version indicates how many times this item has been updated. The
initial version is 1.0, the next version is 1.1, and so on. If you
find you have two versions of the same item (perhaps because you had
archived an older version of the Wabi FAQ), use the item with larger
version number.
Date is the yy/mm/dd when this item was last updated. A recent date
indicates that the item was just created or revised.
Q: How can I find the beginning and end of this document? How can I
isolate documents that were returned by the email auto-responders?
A: Every Wabi info document or sub-document begins with a "From "
line. Any application such as SearchIt that understands email
folders will isolate the documents and sub-documents correctly
whether they're stored in one file or several files.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: address space
Keywords: simulated address space memory size
X-Applies-To:
X-Source-Info: File--adrspc.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: API
Keywords: Unix calls direct launches API fork file manager
X-Applies-To:
X-Source-Info: File--api.txt Version--1.2 Date--94/05/03
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.
Q: Is it possible to launch a Unix application from Wabi?
A: In general, no. Once you choose to use the Wabi desktop tools
(Application Manager, MS File Manager, etc.) rather than your Unix
desktop tools (X11 root menu, OW File Manager, etc.) you're limited
in what you can do.
Except for the mappings in Configuration Manager, Wabi is not aware
of the wider world of your entire workstation.
There is one partial exception. The Wabi API call that launches a
subtask does a little bit more than the equivalent "real Windows"
call. Like "real Windows", Wabi 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 under certain conditions fork() a
Unix executable as a separate processes. This capability is
limited. For example it cannot be used to launch a Unix app from
the MS File Manager.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: obtaining applications
Keywords: site network license obtain application
X-Applies-To:
X-Source-Info: File--apps.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: application versions
Keywords: certified 1.0 1.1 1.x applications versions
X-Applies-To: Wabi 1.x
X-Source-Info: File--appver.txt Version--1.3 Date--94/04/27
Q: Will newer versions of SST-certified apps (ex: WordPerfect 6.0
rather than WordPerfect 5.0, MS-Word 6.0 rather than MS-Word 2.0,
etc.) run under Wabi 1.x? In other words, If an app is
SST-certified to run under Wabi 1.x, does that mean _any_ version of
the app, or only the version listed?
A: Several applications now have a newer version than that
SST-certified to run under Wabi 1.x. Since the newer version wasn't
available when Wabi 1.0 was being developed, it hasn't been tested
and hence isn't SST-certified.
Only the exact version listed has been tested and SST-certified to
run under Wabi 1.x. To find out about other versions, check the
document 'Wabi 1.x Application-Specific Notes For "Other"
Applications'. (That document is included in the response from
email To: wabi1.0-apps@east.sun.com.)
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
certified. However our experience is that newer versions of many
apps do not run right under Wabi 1.x. Newer versions of most
MS-Windows-based apps are significantly different, and Wabi 1.x is
still relatively immature. So it's not unusual for the newer
version of an app to expose a problem in Wabi 1.x.
Q: Should I try hard to get the "latest version" of an app?
A: No, check the Wabi 1.0 app information to see which version is
certified and/or known to work. Then try to get exactly that
version.
Q: Will newer versions of certified apps run under Wabi 2.0 in the
future?
A: Yes, Wabi 2.0 will SST-certify both the newer and the older version
of all 13 apps SST-certified under Wabi 1.x. So for example both
WordPerfect 5.0 and WordPerfect 6.0, both MS-Word 2.0 and MS-Word
6.0, etc. will be SST-certified to run correctly under Wabi 2.0.
Wabi 2.0 will also SST-certify seven additional applications, for a
total of twenty.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Type Managers
Keywords: adobe type manager fonts
X-Applies-To:
X-Source-Info: File--atm.txt Version--1.2 Date--94/04/14
Q: Do I need any custom fonts at all on my system?
A: Not really. Wabi will run fine without any proprietary fonts
available, and all of the SST-certified apps will work fine.
The reason you would need to install some proprietary 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: Why do some app installation procedures suggest I install a custom
type system (ex: Adobe Type Manager)?
A: One reason is that very few fonts are available by default on a
"real PC". To do useful work on a "real PC" you will probably need
some additional fonts.
(Another reason is clever marketing :-)
Q: So should I obtain and install the custom type system that the app
install procedure suggested?
A: Probably not. Since Wabi already makes all the existing X fonts
available to the apps that run under it, there's often no need for a
custom type system. Don't pay money for a custom type system if you
don't really need it.
In fact, we suggest you do NOT obtain and install a custom type
system under Wabi 1.x. No custom type system --including Adobe
Type Manager-- has yet been tested under Wabi 1.x and there's no
guarantee they will work correctly. So you may actually cause
yourself problems if you install a custom type system under Wabi
1.x. The custom type system may appear to install correctly but
then cause an app to mis-behave later.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Wabi 1.0 & 1.1 status
Keywords: available floating bug spreadsheet shipping CD coupon 1.0 1.1
X-Applies-To:
X-Source-Info: File--avail.txt Version--1.2 Date--94/05/02
Q. I understand there was a technical problem with Wabi 1.0. Has this
problem been corrected?
A. Yes, Wabi 1.0 contained a bug which affected the Lotus AmiPro(TM)
and Borland QuattroPro(TM) applications. Using these applications
could result in corruption of data. This problem was corrected in
Wabi 1.1.
Q. When will Wabi 1.1 be available from SunSoft?
A. SunSoft began shipping Wabi 1.1 April 15.
Q. Why didn't SunSoft ship Wabi 1.0 to customers who returned their
coupon after December 31, 1993?
A. SunSoft elected to send the newer version, Wabi 1.1, when it became
available. The alternative was to send users older software, then
ask them to get a patch, then almost immediately send them newer
software.
Q. If I am a Wabi customer who received Wabi 1.0, should I also receive
Wabi 1.1?
A. Absolutely. If you turned in a Wabi coupon and subsequently
received Wabi 1.0, by now you should have automatically received
Wabi 1.1 at no additional charge.
Q. If I have Wabi 1.0 and the patch necessary to fix the data
corruption problem which affects Lotus AmiPro and Borland
QuattroPro, should I still install Wabi 1.1?
A. Yes, Wabi 1.1 contains more bug fixes than just the one for the
extended floating point zero problem, and is overall a better
product than Wabi 1.0.
Q: Does Wabi 1.1 contain any new functionality beyond that in Wabi 1.1?
A: No. Wabi 1.1 is a "bug fix" release. It does not contain new
functionality.
Q: Does the list of SST-certified apps for Wabi 1.1 contain any
additions to or changes from the list of SST-certified apps for Wabi
1.0?
A: No. The list of SST-certified apps is the same for Wabi 1.1 and
Wabi 1.0.
Q: What changed between Wabi 1.0 and Wabi 1.1?
A: Significant improvements of Wabi 1.1 over Wabi 1.0 are:
* The floating point emulation bug in Wabi 1.0 that affected
operation of Lotus AmiPro (TM) and Borland Quattro Pro (TM) is
fixed.
* The Sharing Enabled box in ConfigurationManager:Drives now
works correctly, so it's no longer necessary to manually
edit wabi.ini to enable file sharing on a drive.
* Wabi's use of the display's colormap now follows X11 usage
better, and is more flexible.
* Many miscellaneous appearance problems have been improved.
* Corel PhotoPaint works in color as well as in black&white.
* Several problems that made it hard to use the MS-Windows File
Manager have been fixed.
* Several problems that made it hard to use the MS-Windows Card
File applet have been fixed.
* Wabi now allows you to use other apps on your X11 desktop while
Wabi is rebuilding its font cache.
* The CapsLock & NumLock keys now work correctly on all keyboards
with all apps.
* The tendency of text displayed in some fonts to spill past the
right margin has been eliminated.
* The distributed default font cache matches OpenWindows 3.3, so
users running Wabi under Solaris 2.3 won't have to build and
store a font cache file for each system.
* Implemented support for the new Compact1 keyboard.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: bad value error
Keywords: window bad value integer range start X11 font cache
X-Applies-To:
X-Source-Info: File--badval.txt Version--1.3 Date--94/04/07
Q: Why might I get the error message "window error: bad value (integer
out of range) window will exit" when I start Wabi?
A: We're not sure.
One theory is this sometimes happens if a user aborts out of a font
cache build with ^C (rather than ESC), then tries again to start
Wabi. Perhaps some file inside ~/wabi is damaged in a way that
prevents Wabi from starting in the future.
Another theory is this is due to a conflict between Wabi and some
other app that's running to the same X-server. (Frequently
mentioned suspects for the "other app" include Frame and 1-2-3 for
Solaris.)
Q: If I see this error message what can I do to get Wabi to come up?
A: A possible workaround that's been reported to work is to "wait a
couple days". The problem often goes away by itself. This may be
due to the user logging out and back in, or a different user logging
in, or restarting the window system, or rebooting the machine, or
stopping other apps, or...
Another possible workaround for this problem that's been reported to
work is to move the entire user's wabi directory out of the way and
restart Wabi from scratch.
cd ~
mv wabi wabi.old
wabi
Another possible workaround for this problem that's been reported to
work is to remove then reinstall Wabi with `pkgrm` and `pkgadd`.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: key mappings
Keywords: DEC control X11 widget Motif resources XmText translations VMS DECwindows delete word end start line VAX
X-Applies-To:
X-Source-Info: File--bakde2.txt Version--1.4 Date--94/04/19
Q: I'm running DECwindows (or Motif) on a VMS system and get XTWarning
messages about missing functions such as "Beginning-Of-Line",
"End-Of-Line", "Delete-Previous-Word", "Redraw-Display",
"Delete-To-Start-Of-Line", "Delete-To-End-Of-Line", or "Self-Insert"
when I start an app under Wabi 1.x. What's the first thing I should
do?
A In all the files
DECW$SYSTEM_DEFAULTS:DECW$LOGIN.DAT
DECW$SYSTEM_DEFAULTS:DECW$SMB_KEYBOARD.DAT
DECW$USER_DEFAULTS:*.DAT
if you see an entry of the form
*XmText.translations:
also add an entry of the form
*WabiCore.XmText.translations:
Then restart Wabi and retest. This change may solve your problem.
Q: Why else would Wabi sometimes not be able to map functions such as
"Beginning-Of-Line"?
A: Wabi maps your keystrokes to the corresponding keytop on a virtual
PC keyboard, then feeds these virtual PC keystrokes to the app.
Under MS-Windows, modified keystrokes show up as two separate key
events, one for the modifier and a second for the key (ex:
WM_Keydown Ctrl followed by WM_Keydown E).
As a result, Wabi cannot map keystrokes that combine keystroke
modifiers onto different keytops than on a PC keyboard.
For example, on a PC keyboard the E keytop generates 4 possible
combinations: E, Shift-E, Ctrl-E, and Alt-E. Whatever X11 keytop on
your system generates E must generate all 4 of these combinations.
If you attempt to use X11 to map one of these combinations to a
function that's on an entirely different keytop on a PC keyboard,
Wabi will ignore the mapping. (ex: if X11 tries to report Ctrl-E as
End-Of-Line), Wabi will be unable to handle the mapping.
Provided your keyboard is similar to a PC keyboard (lots of keytops,
numeric pad, etc.) --which most newer keyboards are-- this will not
be a problem.
Q: What should I do if I want to run Wabi from an older or smaller
keyboard that's not at all similar to a PC keyboard (ex: doesn't
have many keytops)?
A: Try to use X11 to map the Cursor control & motion and Misc function
keys that are missing from your keyboard (or are assigned to Ctrl-*
keys) to other keytops.
Q: Many of the "widgets" in Wabi have names the same as Motif widgets. Is
there any possibility that Wabi will interfere with resources belonging
to the Motif widgets?
A: In general, no, none of the Wabi widgets with familiar names use
familiar X11 resources. So they will neither consume nor confuse
nor overwrite nor respond to resources intended for the Motif
widgets used by some other processes.
However there are some specific problems with Wabi 1.x. For
example, resources of the form *XmText.translations: intended for
other applications may modify Wabi's behavior incorrectly. This
will not occur in Wabi 2.0.
Q: What can I do to keep a resource of the name "*XmText.translations: "
from affecting Wabi?
A: Add a resource that more explicitly matches Wabi to keep Wabi from
being affected by the more generic resource.
For example, define
*WabiCore.XmText.translations:
with an empty value. (Wabi works correctly when the value of this
particular resource is empty.)
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: BackSpace and Delete keys
Keywords: numeric keypad delete del backspace erase xmodmap keysym keycode X11 left key
X-Applies-To:
X-Source-Info: File--bakdel.txt Version--1.4 Date--94/04/25
Q: How many "move left" functions are available in most current software?
A: Nowadays three flavors of "move left" functions are provided by most
applications. 1) Erase (Destructive Backspace) removes the char to
the left of cursor and shifts the rest of the line left to fill the
gap. 2) Delete (Delete Char) removes the char under the cursor and
shifts the rest of of the line left to fill the gap. 3) Left
(Non-Destructive Backspace- moves the cursor left without changing any
character.
Q: How many "move left" functions were available in the early days of
Unix?
A: With ASR33 Teletype terminals, typically only two "move left"
functions were available and only one of them had its own key. Erase
was usually assigned to a key called Rubout (later Delete). And Left
was available as ^H.
This history continues to affect the keyboard layout and key
assignments of Unix systems.
Q: What considerations are there for getting older and newer (or Unix and
MS-Windows) apps to work together on the same keyboard?
A: Ideally all three of these considerations should be met:
- Have MS-Windows apps match their documentation, so for example when
their documentation talks about the Backspace function, you can
simply look for "Backspace" on your keyboard.
- Have existing apps continue to work exactly the way you're used to.
- Have both existing apps and new MS-Windows apps attach the same
functions to the same keys.
Q: Is it possible to meet all three considerations?
A: Not always. Depending on your keyboard layout and how your existing
apps are configured, you may not be able to meet all three
considerations simultaneously. You may need to decide which two
considerations are most important to you.
For example suppose you're used to using the Delete key at the top
right of the main area of your keyboard for the Erase function. If
you want to have your existing apps work unchanged and have both
existing apps and new apps attach the same functions to keys, then you
won't be able to get your MS-Windows apps to exactly match their
documentation. Whenever their documentation refers to the Backspace
key, you'll have to translate since you're using a key labelled Delete
for that function.
Q: How are the "Backspace" and "Delete" keys mapped in Unix?
A: These keys are mapped twice, once by X11 and a second time by Unix.
The first mapping determines which X11 keycode the Xserver should send
when you press a particular key. The usual default is for the key
labelled "Backspace" to generate an XK_BackSpace event, and the key
labelled "Delete" to generate an XK_Delete event.
The second mapping determines which key event is connected to which
function. This mapping is set by the `stty` command and is observed
by most Unix apps. The destructive backspace function is called
"erase" and may be mapped to one of many different key events, for
example `stty erase ^?`. The left arrow function has no name, and
will be mapped to ^H if that key isn't mapped to some other function.
Q: How are the "Backspace" and "Delete" keys mapped by Wabi?
A: These keys are openly mapped only once, by X11. Wabi sometimes
performs a second mapping behind the scenes.
There is no analogue of `stty`, no command to change key mappings
for Wabi. And there are no useful Wabi*IO.KeyTranslations X11
resources.
Q: How can I have my Unix apps and my Wabi apps use the same keys?
A: One way is to have both your Unix apps and Wabi use the same mapping,
then make all changes to X11. That way all changes you make will
affect all apps.
To make the second of Unix's two key mappings be the same as Wabi's
mapping, `stty erase ^H` (Backspace).
(You may find it confusing to get Wabi and the rest of your Unix
system to work the same way simply because of a difference in
terminology. If your systems are set to `stty erase ^?`, you may be
using the word "Delete" to refer to both the key and the function
that DOS/Windows apps call "Backspace". There's less of a problem
here than it may seem. In both cases the function you want and the
system provides is the same: erase the character that's to the left
of the cursor, then move the cursor left one position. Only the
terminology is different.)
Q: How can I swap the definitions of the Backspace and Delete keys in X11
so all apps are affected?
A: To use X11 commands to swap the Delete and BackSpace functions so
the Delete key generates the BackSpace function and vice versa,
enter something like `xmodmap -e "keycode 50 = Delete" ; xmodmap -e
"keycode 83 = BackSpace"`.
(The keycode numbers may be different on your machine. The examples
in the previous paragraph are for a Sun Type4 keyboard running
OpenWindows. To find out what numbers you should use, enter
`xmodmap -pk | fgrep -i "back|del"`.)
(It seems you could avoid having to know these numbers by using the
"keysym ..." form rather than the "keycode ..." form. But the
action of the "keysym ..." form may change depending on the current
state of your X11 keyboard mappings. And you can't use the "keysym
..." form to swap two keys since the definition of the second key
will have been changed before the second command can reference it.)
Q: How can I swap the definitions of the Backspace and Delete keys just
in Wabi so existing apps aren't affected?
A: Save file /opt/SUNWwabi/lib/locale//wabi/wabi_kb and
make a copy of it. Then edit the working copy of the file to swap
MS-Windows virtual key codes VK_DELETE and VK_BACK.
For example, suppose you're using the default locale en_us. Then
cd /opt/SUNWwabi/lib/locale/en_us/wabi
mv wabi_kb wabi_kb.orig
cp wabi_kb.orig wabi_kb.swapped
ln -s ./wabi_kb.swapped wabi_kb
Then edit wabi_kb.swapped. Find the two lines that say "... Backspace
..." and "... Delete ...", and swap the XK_... symbols between them.
When you're done, one line will say
... Backspace ... VK_BACK ... XK_Delete ...
and the other will say
... Delete ... VK_DELETE ... XK_BackSpace ...
(Use an editor that can handle 8-bit wide characters. This file may
contain extended characters. It may be damaged if your editor
understands only 7 bits per character and clears the 8th bit of
every character before it rewrites the file.)
(Swapping the XK_* symbols is easier than the earlier recommendation
of swapping the VK_* symbols, and works in all cases.)
Note that after you swap keys in this way, the documentation for
your MS-Windows apps may not quite match the keyboard.
If your keyboard has a numeric pad, the function DOS/Windows calls
Delete will remain attached to it on the same key as the decimal
point no matter what you do to the keyboard mapping.
Also note that this affects all copies of Wabi that execute on the
machine where you made the change, even if your rlogin from another
machine with a different keyboard layout. If you want to make this
change for some keyboards but not others, you'll need to take some
additional steps.
Q: Can I assign both the DOS/Windows Delete and Destructive Backspace
(Erase) functions to the same key on my X11 keyboard?
A: Yes, if you wish, you can assign both functions to the same key on
your X11 keyboard, and use Shift to distinguish which one you mean.
Initialize your X11 session with something like this ` `xmodmap -e
"keycode 50 = BackSpace Delete" ; xmodmap -e "keycode 83 = BackSpace
Delete"`.
(The keycode numbers may be different on your machine. The examples
in the previous paragraph are for a Sun Type4 keyboard running
OpenWindows. To find out what numbers you should use, enter
`xmodmap -pk | fgrep -i "back|del"`.)
Operation of your other apps should be unaffected. Wabi will
interpret either key unshifted as the Destructive Backspace (Erase)
function. And if you hold down Shift while pressing either key,
Wabi will interpret it as Delete.
Q: What does Wabi do if I have an old Unix style keyboard that doesn't
have any key labelled Backspace?
A: Since the Erase function that's usually attached to a Backspace key is
critical to many MS-Windows apps, Wabi checks that a key for this
function exists. If there isn't one, Wabi will attempt to assign
the Erase function to some other key, perhaps to a key labelled
Delete.
This may interfere with the previous function of either the Delete
key or the Del key on the numeric pad.
Q: Has Wabi always done this?
A: Yes, all FCS versions of Wabi and the betaII version of Wabi 1.0 have
done this. Versions of Wabi 1.0 prior to July 1993 did not do this.
Q: If I have an old Unix style keyboard that doesn't have any key
labelled Backspace, how can I choose which key the Erase function
should be attached to and prevent Wabi from picking a key for me?
A: Use X11 to relabel the key of your choice Backspace before starting
Wabi. Choose some key that isn't used otherwise so you can leave
the change in place all the time without affecting other apps. Then
you can do this when the Xserver first starts up.
For example, if you choose the key labelled F7, add the command
"keysym F7 = BackSpace" to your ~/.xmodmaprc file. (You may also
need to modify ~/.openwin-init [or is it ~/.xinitrc?] to include the
command `xmodmap .xmodmaprc` to read and process this file if it
isn't already being done.)
Q: Is there a way to change the function of the Del key on the numeric
keypad?
A: Sometimes the same procedures that change the definitions of keys in
the main area of the keyboard will also change the definitions of
keys on the numeric keypad. But because of the complications
introduced by the numeric keypad and the NumLock key, these
procedures do not always work exactly as expected.
So if you need to change some key functions, try to change the
definitions of keys in the main area of the keyboard and avoid keys
on the numeric pad.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: 32-bit interfaces and operations
Keywords: win16 win32 win32s win32c Chicago Daytona 16-bit 32-bit API 386 protected mode
X-Applies-To:
X-Source-Info: File--bit32.txt Version--1.2 Date--94/04/29
Q: Can apps running under Wabi use 32-bit sections?
A: Yes, Wabi runs in 386 "enhanced" mode and includes integral support
for all the entry points in WINMEM32.DLL. This allows apps to use
32-bit code or 32-bit data objects or both.
Apps that use some "386-mode" or "enhanced-mode" instructions will
run just as well under Wabi as apps that don't.
Q: Will Wabi support 32-bit API apps (ex: "Chicago apps")?
A: Yes, as 32-bit API apps become important to PC users and popular
on PC desktops (as evidenced by their shipping in volume), Wabi will
offer 32-bit API support. This is an important future direction for
Wabi.
Wabi 1.x and Wabi 2.0 support 16-bit API apps only.
Q: Why will Wabi wait until 32-bit API apps start shipping in volume to
offer 32-bit API support?
A: Wabi's primary goal is to be an enabler of end-user productivity
tools, not a development system. So there's very little reason to
provide 32-bit API support before the apps that need it appear in
volume.
Q: What do the code names Chicago, Cairo, and Daytona refer to?
A: Chicago is the merge of MS-DOS and MS-Windows into one desktop
environment. Among other things, it will emphasize support for
32-bit apps.
Daytona is the next minor version of Windows NT.
Cairo is the next major version of Windows NT. Among other things,
it will emphasize exposing object orientation to the API.
Q: What do the API names WIN16, WIN32s, WIN32c, and WIN32 mean?
A: WIN16 is the current MS-Windows API. It includes about 1500
calls, and is available to 16-bit apps.
WIN32 is the Windows NT API. It includes additional functionality
to support large multi-part apps. And it passes arguments as 32-bit
values and is available only to 32-bit apps.
WIN32s is a subset of WIN32 that's functionally quite similar to
WIN16. It's available now under MS-Windows 3.1 with the inclusion
of the WIN32s libraries. You can think of it as WIN32
"compatibility mode" for 16-bit apps.
WIN32c is the subset of WIN32 that will appear in Chicago. It was
originally identical to WIN32s. It's been extended to include
additional functions such as an implementation of multi-threading
for use by apps.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: CD-ROM access
Keywords: CD CD-ROM access mount MSCDEX.EXE Rock Ridge High Sierra File System
X-Applies-To:
X-Source-Info: File--cdrom.txt Version--1.2 Date--94/01/30
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.)
o From Unix, the CD-ROM will conventionally show up as
/cdrom/[volume name as seen by filemgr]
If you need to explicitly mount it,
mount -F hsfs -o ro /dev/sr0 /cdrom
o For Wabi: Use the Wabi Configuration Manager to map for example
N: -> /cdrom/[volume name as seen by filemgr]
For SunPC: 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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: color settings
Keywords: colors xray technicolor color flashing X11 win.ini cube solid percent free ZX Leo 24-bit truecolor pseudocolor colormap fruit salad
X-Applies-To: Wabi 1.1 and above
X-Source-Info: File--color1.txt Version--1.4 Date--94/05/25
Q: Is Wabi's use of colors different in Wabi 1.1 than it was in Wabi 1.0?
A: Yes. The color allocation and use part of Wabi was completely redone
for Wabi 1.1.
Among other things, the new implementation gives much more control to
you the user. You can set several settings in win.ini, and make Wabi
do almost anything you want with colors.
Q: What were some of the problems with colors in Wabi 1.0?
A: Wabi would always allocate all the rest of the entries in the default
colormap, which could lead to various problems.
Sometimes an app would see that the default colormap was full, and
allocate their own private colormaps, thereby increasing the amount of
flashing you'd see.
Sometimes an app that still used the default colormap would find the
spread of colors insufficient, and come up with some truly ugly
combinations.
Sometimes an app that still used the default colormap would try to
allocate colors anyway, and then exit when the allocation failed.
Q: What's the general outline of Wabi 1.1's algorithm for colors?
A: Wabi will create a color cube in the default colormap, copy over a
range of previously allocated cells and the cube from the default
map into its private colormap, and then free back a percentage of
the cells it allocated in the default map. This percentage is
controlled by a user-tunable variable called PercentFree, whose
default value is 50%. If you want to have Wabi Wabi leave your
default colormap alone, you can set PercentFree=100.
Q: What section do the colormap controlling variables in win.ini go in?
A: Each variable can be set either in the [ColorMap] section in win.ini,
or they can be set in the [foo:0.0] section (for the X-server named
"foo" on screen 0). In this way, some of the settings can be set only
on some X-servers, which might be desirable if you use some 24-bit
servers and some 8-bit or 4-bit servers.
Q: What are the colormap controlling variables in win.ini?
A: 1) "PercentFree" tells how much of the default colormap Wabi should
free up after allocating its colors. Default value is 50. Legal
range is 0 - 100. Setting this lower will retain more of Wabi's
colors in the default colormap, and so reduce color flashing.
Setting it higher will reduce problems with other X apps not finding
sufficient free color entries available.
2) "Technicolor" controls whether Wabi allocates colors from the
default map and then copies them to the Wabi colormap, or just
allocates the Wabi colormap without modifying the default map.
This variable defaults to 0 (no) unless there are more than one
hardware colormap in the X-Server for this screen. If there are more
than one hardware colormaps, it is assumed one will be available for
Wabi, and the value defaults to 1 (yes).
Users on X-Servers with more than one hardware colormap can set this
to 0 if all hardware colormaps are usually already in use by other
apps when Wabi is started.
Users on X-Servers with only one hardware colormap may set this to 1
to give Wabi and the apps running under it the most flexibility in
allocating and changing colors. But since in this case Wabi won't
attempt at all to be compatible with the existing colormap, you will
probably see severe color flashing when switching between Wabi apps
and non-Wabi apps.
If Technicolor is 1, Wabi allocates one of X11's standard 256 cell
colorcubes. Wabi then ignores the remaining colormap controlling
variables.
3) "SolidColorCount" defines how many shades of each of the seven
colors --red, green, blue, cyan, magenta, yellow, and gray-- are
allocated. A total of (7 * solid_count) are allocated before the
color cube.
This variable defaults to 7. It may range from 1 - 16.
When Technicolor is 0, these "solid" colors are allocated in the
default colormap, then copied to Wabi's private colormap, then
depending on the setting of PercentFree some of them may be freed from
the default colormap.
When Technicolor is 1, this variable is ignored.
Set this variable larger to have Wabi pre-allocate more colors so that
apps running under Wabi don't find it necessary to allocate new
colors. Set this variable smaller if most colors have already been
defined by non-Wabi apps before Wabi starts, or if you'll be manually
defining all your colors anyway (ex: through a "paint" program), and
so have no use for pre-allocated colors.
4) "RedCubeCount" defines the dimension of the red component of the
color cube. After the (7 * solid_count) allocations above, (red_count
* green_count * blue_count) allocations are made in the same way.
This may result in many of the same colors, so the total number of
allocations will be less that ((7 * solid_count) + (red_count *
green_count * blue_count)).
This variable defaults to 5. It may range from 4 - 9.
When Technicolor is 0, the color cube is allocated in the default
colormap, then copied to Wabi's private colormap, then depending on
the setting of PercentFree some of it may be freed from the default
colormap.
When Technicolor is 1, this variable is ignored.
Set this variable larger to have Wabi pre-allocate more colors so that
apps running under Wabi don't find it necessary to allocate new
colors. Set this variable smaller if most colors have already been
defined by non-Wabi apps before Wabi starts, or if you'll be manually
defining all your colors anyway (ex: through a "paint" program), and
so have no use for pre-allocated colors.
5) "GreenCubeCount" is the same as "RedCubeCount" above, except for
the green component of the cube.
6) "BlueCubeCount" is the same as "RedCubeCount" above, except for the
blue component of the cube.
Q: How does Wabi process these variables? What has precedence, and when
is the default value used?
A: The same processing is followed for each variable. First, the
variable is set to a default value. Next, if there is a setting for
that variable in the [Colormap] section of win.ini, the variable is
set to the value specified there. Then if there is a setting in the
[foo:0.0] section of win.ini, the variable is set to that value.
Finally, the variable is compared to maximum and minimum values and
modified if it is found to be out of range.
Q: Will I see any of these variables in win.ini?
A: You won't see any of these variables in win.ini unless you put them
there yourself. Wabi runs with default values for all of these
variables. Only if you've explicitly set one of them will you see it
in win.ini.
Q: What if my X-server provides 24-bit truecolor?
A: With a 24-bit truecolor visual, colors are set directly rather than
through a colormap. There is no colormap. None of the colormap
controlling variables (except perhaps "UseRootWindow") are
relevant. So if some future version of Wabi were to be able to use
a 24-bit truecolor visual, it would ignore all the colormap
controlling variables.
The colormap controlling variables apply when Wabi is using an 8-bit
pseudocolor visual. Since Wabi 1.1 and Wabi 2.0 use an 8-bit
pseudocolor visual even if the X-server also provides 24-bit
truecolor, Wabi 1.1 and Wabi 2.0 will always pay attention to the
colormap controlling variables.
Q: What if Wabi 1.1 on a 24-bit color display (a ZX) has terrible
color flashing?
A: This is a known problem in Wabi 1.1 that did not occur in Wabi 1.0.
Wabi 1.1 is mistakenly defaulting Technicolor to 1 on a ZX display.
To fix this problem, in ~/wabi/windows/win.ini, add either section
[ColorMap] or section [:0.0] and specify Technicolor=0
in it. Then restart Wabi. This will force Wabi 1.1 to coexist as
much as possible with the existing colormap, thus greatly reducing
color flashing.
Q: Are there any other possible variables in win.ini that are related
to colors?
A: Yes. "UseRootWindow" tells whether or not Wabi can draw to and read
from the root window. The default value is 1 (yes), unless Wabi's
colormap and the default colormap have a different number of
entries, in which case the default is 0 (no). The main reason for
this is to control whether or not Wabi can do "saveunder" operations
to the root window.
If Wabi is running with 8-bit color (256 colors) on an X-server
that's capable of 24-bit (truecolor) operation, drawing damage
may occur after some operations on some X-servers. This variable
changes Wabi's behavior in this case, and may reduce the drawing
damage.
The function of this variable is slightly different in Wabi 1.1 and
in Wabi 2.0. Do not set this variable unless you have a 24-bit
display and are experiencing drawing damage. Only then experiment
with this variable to see if you can reduce the drawing damage. If
this variable does nothing, or makes the drawing damage worse,
remove it. Most of the time variable will not need to be set by
users.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: colors
Keywords: colors colormap X11 technicolor xray flashing cell dithering
X-Applies-To:
X-Source-Info: File--colors.txt Version--1.2 Date--94/04/06
Q: How does Wabi 1.0 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" sometimes
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" or "fruit salad".
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 with Wabi 1.0 you can control to some extent
which side of that tradeoff you land on. With Wabi 1.1, use the
colormap control variables in win.ini to control 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: Here are a couple hints that will definitely be helpful with Wabi
1.0, and probably be helpful even with Wabi 1.1 and above.
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.
Making the colors change only when you click on a different window
will definitely be helpful with Wabi 1.0, and probably be helpful
even with Wabi 1.1 and above.
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
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Corel Draw installation - fonts, and using CD-ROM
Keywords: two second twice custom Symbols WFN TrueType some none CD-ROM setup setup2
X-Applies-To:
X-Source-Info: File--corfnt.txt Version--1.3 Date--94/04/13
Q: Per the directions in the release notes, I try to do two
installations of CorelDRAW (one to install the main part of the app
and the second to install fonts). But the "Fonts and "Symbols
Selection Window" disappears almost immediately after it appears.
So there's no way I can make selections. What should I do?
A: After you set "Fonts and Symbols" to and everything else
to , wait without clicking any mouse button. The "Fonts and
Symbols Selection Window" will appear by itself eventually. If you
click the mouse while you're waiting, the click will be queued up,
and probably interpreted by the "Fonts and Symbols Selection Window"
as thus dismissing the window as soon as it appears.
Q: The special installation instructions for CorelDRAW are very terse.
How would they read if they were less abbreviated?
A: Follow these procedures to install CorelDRAW:
1. If you're installing CorelDRAW off a CD-ROM rather than floppys,
first use Tools:ConfigurationManager:Drives to map a drive letter
to your CD-ROM drive.
2. Perform the first installation of the program using one of the
install options ("Full," "Minimum," or "Custom"). This will
complete successfully, and everything will be installed except
possibly the fonts.
3. To install fonts, perform a second installation using the "Custom
Install" option. (If you're running SETUP2.EXE off a CD-ROM,
you won't see a "Custom Install" option. Perform the whole
installation a second time -- it's short.)
4. Specify the same destination drive letter and path to the second
installation as you did to the first.
5. In the "Choose which files to install" dialog, set all the
other options to , and click on "Fonts and Symbols"
. (Click on even if it's already the default
setting.) The border around the "Choose which files to install"
window will go white, and the "Fonts and Symbols Selection
Window" will appear all by itself. Do not click the mouse while
you are waiting.
6. In the "Fonts and Symbols Selection Window" dialog, select the
TrueType Fonts you want to install and the Symbols/WFN fonts you
want to install.
7. Complete the Custom Install.
CorelDRAW is now fully installed.
Q: Do I have to do anything special to install off a CD-ROM?
A: Use Tools:ConfigurationManager:Drives to map a drive letter directly
to the CD-ROM.
On "real PCs" the CD-ROM drive is always a whole drive letter. App
installation programs have never been tested under other
circumstances and may have latent bugs. If your CD-ROM is a
subdirectory (ex- R:\cdrom) rather than a whole drive letter (ex-
I:) the app installation program may not work right.
Q: There are two installation programs on the CorelDRAW CD-ROM. Which
one should I use?
A: Both installation procedures work under Wabi 1. Use whichever one
fits your situation best.
If you want to install Corel onto your hard drive, or want to
install Corel the same way it would be installed from floppies, use
SETUP.EXE.
If you want to install only a skeleton of Corel on your system then
execute CorelDRAW directly off the CD-ROM forever, use SETUP2.EXE.
This saves hard disk space at the expense of tying up your CD-ROM
drive. Unless you very seldom use your CD-ROM drive for anything
else, use SETUP.EXE to install Corel on to your hard drive.
Q: I'm using SETUP2.EXE to install Corel in such a way I can execute
it directly off the CD-ROM forever. SETUP2.EXE doesn't give me a
"Custom Install" option. What should I do?
A: Go through the complete Corel install procedure twice (unless you're
sure the TrueType fonts got installed the first time). SETUP2.EXE
takes only a couple minutes, so it isn't time-consuming to do the
whole install twice.
Q: Near the end of the Corel install procedure I get an error message
about "out of string space". What should I do?
A: Rerun the install procedure and select the specific fonts you might
use rather than just defaulting to "all" fonts.
Corel comes with more fonts than you'll probably ever use. Often
"real Windows" can't install all the fonts that come with Corel at
one time. In fact, Wabi may be able to install more fonts than
"real Windows".
If you were doing a custom install to install only fonts, restart
the procedure, click on Fonts and Symbols, and explicitly Add
or Delete the fonts you do or don't want.
If you were doing a full install or a minimum install, start over
and do a custom install instead. Select the components for a "full"
or "minimum" install, except click on Fonts and Symbols and
explicitly Add or Delete the fonts you do or don't want.
Q: About 20% of the way through the initial installation of Corel I get
an error message mentioning the name of some font file. What should
I do?
A: Start Corel's installation program through the File->Run menu option
of Application Manager or Program Manager. Do not double-click on
the installation program in File Manager. And do not use File
Manager's File->Run menu option.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: entering text in CorelDRAW
Keywords: Corel DRAW text fonts colors
X-Applies-To:
X-Source-Info: File--cortxt.txt Version--1.1 Date--94/02/25
Q: I can't enter text into CorelDRAW. What might be the problem?
A: You probably need to double-install CorelDRAW per the release notes
in order to get its fonts installed. If the fonts aren't installed,
you probably won't be able to enter text.
Q: Corel's fonts are correctly installed, but I still can't see the
text I enter. When I first type text into CorelDRAW, I see it on
the screen. But as soon as I press it disappears as an
object in the middle of the image. I can still edit the text, but
there is no way that I can preview it. What's wrong?
A: CorelDRAW is rendering the text in a color that's the same as the
background color, so the text is invisible. The problem is that you
don't have enough available colors. Look in the Wabi docs or Wabi
FAQ for info about how to get the most colors for Wabi.
One partial solution is to find the text color in the Corel palate
and change it manually. But then you have to do this for all of the
colors you find mapped incorrectly.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: obtaining Wabi
Keywords: card coupon media kit Solaris 2.2 2.3 December 1993 licenses lost
X-Applies-To: Sun
X-Source-Info: File--coupon.txt Version--1.2 Date--94/05/02
Q: I haven't received my copy of Wabi yet. Is the floating point
extended zero problem the reason why?
A: No. If you sent back your "get Wabi" card well before the end of
December 1993, you should have received both your copy of Wabi 1.0
and your copy of Wabi 1.1. If you sent back your "get Wabi" after
the end of December 1993, you should have received your copy of Wabi
1.1.
Q: Can I get a copy of Wabi without buying a Solaris 2.[23] package or
upgrade?
A: Currently the only way to obtain Wabi for Solaris is to buy Solaris.
There is no other ordering procedure.
Q: My copy of Solaris 2.[23] had a "get Wabi" card or coupon in it rather
than a CD. Do I have to send back this card?
A: Yes. The only way to obtain a CD of Wabi is to return the card or coupon
you found in the Solaris 2.[23] box.
Q: I lost my "get Wabi" card. What should I do?
A: Contact your local Sun sales representative. They have access to
a procedure for replacing lost cards.
Q: How do I find out what happened to my copy of Wabi? How do I make
sure I get a copy of Wabi?
A: Please, if anyone has not already done so, send in the accurate
names and addresses of the customers who may not have received their
Wabi mailing in spite of the fact that they sent in their coupon.
Sun's fulfillment vendors can examine their records and respond
accordingly. Send the accurate names and addresses To:
wabi93_offer@East.Sun.COM (note email address is different from one
published earlier).
Q: If I want to use Wabi on say 10 systems, do I have to fill out and
send back 10 cards, or can I send back just one?
A: You need a right to use license for every system Wabi will execute
on. Rather than filling out and sending back several cards, you can
send back just one card and write "NNN Licenses" across it in large
letters.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: processor type
Keywords: 80386 80486 80586 extended standard CPU
X-Applies-To:
X-Source-Info: File--cputyp.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: cut copy paste
Keywords: cut copy paste clipboard images
X-Applies-To:
X-Source-Info: File--cutpst.txt Version--1.4 Date--94/04/07
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: Can I map some keys (ex: the Cut Copy and Paste keys at the left
of most Sun keyboards) to these functions?
A: No, we don't know of any way to map particular keys to these
functions.
It can't be done with keyboard mappings because MS-Windows has no
single keycodes (eg VK_* symbols) for these functions. The keyboard
events appear to the apps as multiple keystrokes. (Shift-Delete
appears as WM_KEYDOWN 16, WM_KEYDOWN 46; Ctrl-Insert appears as
WM_KEYDOWN 17, WM_KEYDOWN 45; and Shift-Insert appears as WM_KEYDOWN
16, WM_KEYDOWN 45.)
Q: Is there a "standard" in MS-Windows for which keys are mapped
to the Cut Copy and Paste functions?
A: Yes and no.
It's very common for apps to assign Cut to Shift-Delete, Copy to
Ctlr-Insert, and Paste to Shift-Insert. But it's not universal.
Most app, especially apps from MS, handle this convention. And both
the MS and BWCC widget sets pre-map these keystrokes to these
functions.
Yet there's no written standard or enforcement mechanism. And
MS-Windows itself doesn't understand the common keystroke
assignments or help apps process them.
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`.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: window decoration
Keywords: borders decoration window manager X11
X-Applies-To:
X-Source-Info: File--decor.txt Version--1.1 Date--94/01/21
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. Real Windows
lets you change the size of window borders by changing Borders= in
C:\WINDOWS\WIN.INI. It can range from 1 (thin) to 49 (very fat). The
default is 3.
Wabi windows appear very much like the windows drawn by MS-Windows
on a PC. Your choice of font and fontsize for non-Wabi windows will
have no effect on Wabi windows. Depending on what font and fontsize
you've chosen for your non-Wabi windows, the appearance of Wabi
windows and non-Wabi windows may be quite different.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: dynamic link libraries
Keywords: dll support kernel user gdi native interpret win87em winmem32 keyboard system sound toolhelp display mouse commdlg shell
X-Applies-To:
X-Source-Info: File--dlls.txt Version--1.3 Date--94/04/26
Q: What does the acronym DLL stand for?
A: DLL is MS-Windows terminology for a dynamic link library.
MS-Windows DLLs are quite similar to Unix libXXX.so's.
Q: How does Wabi support DLLs?
A: Wabi has four ways of supporting DLLs, and uses whichever way is
appropriate for each DLL.
1) A few core DLLs are implemented inside "wabiprog" itself. They
appear to apps to retain their identity even though they aren't
contained in a separate file under Wabi.
2) Where performance is critical, Wabi may provide a "native" version of a
DLL. These DLLs appear to apps to have all the same entry points
and functionality as the x86 version. They are compiled into
native (usually RISC) opcodes. [Note: it's possible for a DLL
to be both native (2) and alternate (3).]
3) Wabi provides an alternate version of some other DLLs so you
don't have to buy "real Windows". You can identify these alternate
DLLs by looking for Z at the end of their name. [Note: it's
possible for a DLL to be both native (2) and alternate (3).]
4) If a DLL isn't available otherwise, Wabi can execute the actual
x86 DLL, the exact same one that would be executed on a real PC.
Wabi does this the same way it executes stretches of app code
between API calls: by interpreting the opcodes.
Q: Are any DLLs specifically supported, or specifically unsupported?
A: Wabi support is specified in terms of which applications will run.
Obviously all DLLs used by the certified apps work under Wabi. Most
other DLLs do to.
Since one of the ways Wabi can provide DLL functionality is to
interpret the x86 opcodes in a *.DLL file, any DLL has just as much
chance of running under Wabi as a *.EXE does.
Q: What could a DLL do that wouldn't work?
A: If an app calls a DLL, and the DLL in turn calls an MS-Windows API
entry point that isn't supported under Wabi, a failure code will be
returned to the app. With Wabi 1.x, this is most likely to happen
if the DLL attempts to call some of the 300 or so "multimedia
extension" API entry points.
Q: What are the core DLLs that comprise Wabi?
A: MS-Windows is mainly comprised of several DLLs. The core of
MS-WIndows 3.1 is the three DLLs KERNEL.DLL, USER.DLL, and GDI.DLL.
The Unix executable "wabiprog" in Wabi 1.x internally duplicates all
three of these core DLLs.
Q: What other DLLs are implemented internally in "wabiprog"?
The "wabiprog" in Wabi 1.x also contains enough of many other
DLLs to implement the MS-Windows API and get common apps to work.
In a couple of cases Wabi implements the complete DLL: WIN87EM.DLL
and WINMEM32.DLL. In other cases Wabi implements enough of the
DLL to support all documented MS-Windows API functions and get
common apps to work: KEYBOARD.DLL, SYSTEM.DLL, SOUND.DLL, TOOLHELP.DLL,
DISPLAY.DLL, and MOUSE.DLL.
Q: What DLLs does Wabi 1.x provide externally?
A: Wabi 1.x provides two DLLs as separate files. COMMDLZ.DLL is a
replacement for the COMMDLG.DLL in MS-Windows 3.1. And SHELLZ.DLL
is a replacement for the SHELL.DLL in MS-Windows 3.1.
Q: Are there any DLLs in Wabi 1.x that are specific to Wabi rather
than duplicating the functionality of MS-Windows?
A: Yes. Internal to "wabiprog", WABICFG.DLL provides special support
for the Wabi Configuration Manager. And separate file PWI.DLL
provides some additional host-OS links called internally by Wabi.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: DOS applications
Keywords: DOS emulator PIF icon launch
X-Applies-To:
X-Source-Info: File--dosapp.txt Version--1.2 Date--94/02/28
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: Does a DOS emulator come bundled with Wabi 1.0?
A: No. Although Wabi 1.0 can launch a DOS emulator, Wabi 1.0 does not
include a DOS emulator.
Q: Do I need a DOS emulator to make Wabi 1.0 function?
A: No. Wabi 1.0 is self-contained. Wabi's ability to launch a DOS
emulator is a convenience. It doesn't indicate a requirement.
Q: What does the message "You must define a DOS Emulator in the
Configuration Manager in order to run DOS programs..." mean?
A: It means you've attempted to execute a program that's not in
MS-Windows executable format. If you're installing an app and the
app installation disk has both "install.exe" and "setup.exe" on it,
run "setup.exe". ("install.exe" is probably specifically for
non-MS-Windows systems.)
Q: Where's Wabi 1.0's PIF Editor?
A: Wabi 1.0 doesn't include a PIF editor because none is needed. Wabi
1.0 doesn't need a PIF file to launch a DOS emulator and tell it to
execute a DOS program.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: DOS partitions
Keywords: mount DOS disk partition files
X-Applies-To: Solaris x86
X-Source-Info: File--dosdsk.txt Version--1.2 Date--94/04/06
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 for accessing DOS
format hard disks 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 then 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: Why does my x86 system sometimes panic() when I'm running Wabi?
A: There is a generic problem in Solaris 2.1 x86 that can cause it
to panic() when a file on a mounted DOS partition is opened. This
problem is hardware dependent, and doesn't occur on most machines.
Wabi is often the first --or even only-- application to stumble over
this bug in Solaris 2.1 x86.
This will be fixed in the next release of Solaris x86. For more
information, refer to Solaris bug number 1162032.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: drive connections
Keywords: Configuration Manager Drives wabi.ini connect map C: emulated hard drive
X-Applies-To:
X-Source-Info: File--drives.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: badidchoice error
Keywords: window bad choice BadIDChoice invalid resource dxlib performance X11 direct
X-Applies-To: Sun
X-Source-Info: File--dxlib.txt Version--1.2 Date--94/05/25
Q: What is "dxlib"?
A: Dxlib is "direct X11". When the X11 server (application program)
and X11 client (display) are on the same machine, dxlib routes the
communication between them through shared memory rather than through
a loopback network interface. And it accelerates some operations by
accessing the frame buffer directly.
Q: Why might I want to use dxlib?
A: Using dxlib can improve performance of some apps.
Dxlib will not provide any additional functionality.
Q: How is dxlib implemented, installed, and invoked?
A: Dxlib is implemented as a dynamic library substitute for libX11.so.
Dxlib is installed through pkgadd of the package SUNWdxlib. The
default location of the software if installed is /opt/SUNWdxlib.
Dxlib can be invoked explicitly for one app with the command
/opt/SUNWdxlib/bin/dxlib
Dxlib can be invoked automatically for all apps by prepending
/opt/SUNWdxlib/lib/dxlib/SunOS5.x to your LD_LIBRARY_PATH
environment variable. Dxlib can be explicitly disregarded for one
or more apps even if LD_LIBRARY_PATH includes it by also setting
DIRECTX_DISABLE to a non-zero value in your environment before
starting the app.
Q: Can Wabi use dxlib?
A: Wabi 1.x is not compatible with dxlib.
Q: Why might I get the error message "X Window System Error:
BadIDChoice (invalid resource ID chosen for this connection) Wabi
will exit now." when I start Wabi?
A: This is what happens if you attempt to use dxlib with Wabi 1.x.
Q: If I get this error message, and didn't explicitly invoke dxlib,
what should I do?
A: You probably have use of dxlib enabled for your entire desktop.
Disable use of dxlib by Wabi 1.x.
To find out if you've got dxlib enabled for your entire desktop,
either echo $LD_LIBRARY_PATH or ldd /opt/SUNWwabi/bin/wabiprog
and look for a reference to .../lib/dxlib/...
One way to disable use of dxlib by Wabi 1.x is to set environment
variable DIRECTX_DISABLE to any non-zero value in the environment
Wabi will be started from.
Q: Why might I get the error message about BadIDChoice when running under my
own userid, but not when I `su` to some other userid?
A: For security, `su` clears any existing setting of LD_LIBRARY_PATH.
So if you've enabled dxlib for your entire desktop by setting
LD_LIBRARY_PATH, the `su` will disable it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: ejecting floppy disks
Keywords: eject floppy disk meta+e SunOS4 Solaris
X-Applies-To: Sun SPARC
X-Source-Info: File--eject.txt Version--1.2 Date--94/02/01
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. Especially be sure
you've completely installed Wabi onto your desktop system if you
originally installed Wabi on a different system and are NFS-mounting
it from there. (See different Q:'s in this document for further
information. Look for Volume Manager and/or Server.)
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: MS-Word equation editor
Keywords: fonts display garbled equation editor word fences extra
X-Applies-To:
X-Source-Info: File--eqn.txt Version--1.1 Date--94/02/25
Q: What if the MS-Word equation editor doesn't seem to work quite right?
A: Try it on a "real PC" before concluding the problem is with Wabi.
The equation editor is a relatively new feature in MS-Word 2.0, and
doesn't always function like you think it should.
Q: What if many of the symbols in the MS-Word equation editor don't
display correctly?
A: The MS-Word equation editor uses TrueType fonts Fences and Extra
to display its special symbols. Under Wabi these fonts may not get
installed correctly when you install MS-Word.
Win.ini should mention these fonts and should point at *.FOT files.
The *.FOT files should exist and in turn should point at *.TTF files
(use `strings` to see where the *.FOT files point).
If it's clear the fonts aren't installed correctly, try installing
the MS-Word equation editor again. If the fonts still aren't
installed correctly, try installing the MS-Word equation editor to a
"real PC" and then copy over the *.FOT files, *.TTF files, and lines
in win.ini. Be sure to put the *.FOT and *.TTF files into the same
directories they were in on the "real PC".
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: error messages
Keywords: error messages native exception signal SIGSEGV 11 D General Protection Fault
X-Applies-To:
X-Source-Info: File--errmsg.txt Version--1.4 Date--94/05/11
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: What does "Exception D ..." in an error message mean? And what can
I do to work around the problem?
A: Exception D (hex) is Exception 13 (decimal) which is an Intel chip's
way of saying "General Protection Fault" or "General Protection
Exception".
An Intel chip (which Wabi is simulating) will report this error in a
wide variety of situations: segment limit exceeded, transferring
control to a non-executable segment, writing into read-only memory,
reading from an execute-only segment, making the stack read-only,
pointing an app at system memory, setting up an app to read from an
execute-only segment, making the stack executable, switching to a
busy task, violating privilege rules, setting non-sensical processor
configuration, interrupt or exception from V86 mode to privilege
level other than 0, or exceeding the instruction length limit of 15
bytes.
This is very common. It could mean almost anything. Most likely
some part of application or Wabi memory has been overwritten and
then later executed. Most likely this message doesn't have anything
to do with other events that happened at about the same time (ex: an
app's attempt to access a file on a CD-ROM).
If it happens occasionally, do the same thing under "real Windows"
and you'll probably find it happening occasionally there too. If it
happens every time you try to start the application, you can
conclude that the app won't run under Wabi 1.0.
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: What does "...assertion failure..." in an error message mean? And
what should I do?
A: These messages are a standard thing developers insert into the
code. They mean "this should never happen ...but if it does, stop
immediately". There are typically hundreds of these messages in a
modern application.
Every "...assertion failure..." message is different. The
developers will need to know the entire message exactly to identify
it and hopefully figure out what the problem is. Just knowing Wabi
emitted an "...assertion failure..." message is no more useful than
knowing the kernel emitted a "...panic..." message.
Since all of these messages come out of "this should never
happen..." situations, there's probably nothing you as a user can do
if one appears. Unless of course you can figure out what function
is failing and avoid using that function until the problem is
fixed.
Q: Why does the message "The application has encountered an
unrecoverable error and will be terminated. Do you want to exit
Wabi as well?" sometimes appear? How should I answer the question?
A: Wabi issues this message because "real Windows" would issue a
similar message in a similar situation. Respond to it the same way
you would respond to the message from "real Windows".
If you see this message, it's quite likely that Wabi has been
damaged and will not be able to continue indefinitely. If you've
seen the particular situation before and know Wabi will not be able
to continue at all, answer "yes". Otherwise, try answering "no",
then immediately save all Wabi application files, close down all
Wabi applications, and close down Wabi.
Q: What does the message "Zmalloc returned NULL" mean? And what should
I do?
A: Almost certainly it means your system has run so low on swap space
that it can't satisfy a request for memory made by an app running
under Wabi.
The Wabi startup script does check that there's adequate free swap
space available when you start Wabi. But this is no guarantee.
If you see this message, use your host OS's administration tools
(ex: mkfile, swap -a, edit /etc/dfs/dfstab) to increase your
system's swap space.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: common error messages related to OS version
Keywords: solaris sunos error message tcp dontlinger driver 5.3 parent
X-Applies-To:
X-Source-Info: File--errors.txt Version--1.2 Date--94/04/04
Q: When might I get a message about missing the Wabi locking driver
wabi.sparc.5.3.o?
A: You'll get this message if you attempt to install some old pre-FCS
versions of Wabi 1.0 on Solaris 2.3. Get the FCS version of Wabi
1.0.
Q: What does a message about "...TCP DONTLINGER..." mean?
A: This error message doesn't mean anything. It may appear when you
start Wabi to a display running Solaris 2.3. It's harmless. You
can ignore it.
This message will not appear (at least not unless there really is a
problem) in the next version of Wabi.
Q: What does a message "Error: XtCreatePopupShell requires non-NULL
parent" mean?
A: It means you've got either a pre-FCS version of Solaris 2.3, or
a pre-FCS version of Wabi 1.0, or perhaps both.
The last bug that could cause this error message was fixed only
hours before Solaris 2.3 went to FCS, so a Solaris 2.3 that's only a
few days pre-FCS isn't good enough. If you had a special
arrangement with Sun to get "early" copies of Solaris 2.3, you may
have gotten a not-quite-FCS version.
Q: What does a message "WABI INFORMATION Starting non-windows program
OK??" mean?
A: Wabi emits this message whenever you try to execute a file that's
marked executable but does not appear to be in DOS/Windows format.
If this message appears when the user is attempting to start one of
the applications or applets that come with MS-Windows, it means the
user has loaded MS-Windows 3.1.1 rather than MS-Windows 3.1.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: font cache
Keywords: xlsfonts font metrics cache
X-Applies-To:
X-Source-Info: File--fch1gn.txt Version--1.6 Date--94/02/21
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: Are the actual font "glpyhs" stored in the font cache?
A: No. Wabi's font cache contains a list of all available fonts,
and detailed metrics about each one. Wabi's font cache does not
contain the actual font glyph information.
Another way of saying the same thing is that Wabi's font cache
contains a lot of names and numbers, but no pixels.
Q: Can I disable Wabi's use of the font cache?
A: No. Wabi must always have a font cache. If there were no font
cache, Wabi wouldn't be able to perform in a reasonable amount of
time even a basic function like supplying a list of available fonts
to your word processor app. Without a font cache, Wabi would be
unusable.
Wabi will use an existing font cache rather than build a new one if
possible. So most times you start Wabi you won't see it building a
new font cache. Wabi is still using a font cache even though it
didn't just build one.
What can be disabled is not Wabi's font cache, but rather Wabi's
font server. The font cache and the font server are different
features.
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: How can I force the font cache to be rebuilt if I know my X-server's
list of available fonts has changed, but Wabi for some reason didn't
detect this?
A: Truncate the existing font cache file to zero length. (Don't just
delete the file. Doing so may cause Wabi to use a "default" font
cache that will escape detection the same way the file you just
deleted did.)
cd ~/wabi/fc
rm 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: I run several different Xwindows server software packages on my
system. I frequently stop one and start a different one. How can I
run Wabi with all these different X-server software packages without
rebuilding a font cache all the time?
A: Set up a different font cache file for each X-server software package,
and switch Wabi to use a different font cache file at the same time you
switch to different X-server software.
Make your directory look something like this:
~/wabi/fc:
foohost0_ow.fc
foohost0_mit.fc
foohost0_blue.fc
foohost0.fc -> foohost0_ow.fc
Then make your switch to different X-server software include something
like this:
cd ~/wabi/fc
set HOSTNAME=`uname -n`
set DISPLAYNAME=${HOSTNAME}0
if (-s $DISPLAYNAME.fc) then
rm $DISPLAYNAME.fc
else
echo "$HOME/wabi/fc/$DISPLAYNAME.fc is a real file,"
echo "rename it to save it, then rerun this X-server switch"
then
exit 1
endif
switch($SERVER) {
case "ow":
case "mit":
case "blue":
ln -s $DISPLAYNAME_$SERVER.fc $DISPLAYNAME.fc
break;
case "*":
echo "unknown X-server software package $SERVER"
exit 1
}
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: font cache build
Keywords: xlsfonts font metrics cache build default
X-Applies-To:
X-Source-Info: File--fch2bd.txt Version--1.10 Date--94/05/04
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.
Some default font caches are provided with Wabi. One of them may
be suitable for your site.
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 default font cache file with
versions of Wabi that include a $WABIHOME/lib/wabifs.displays 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"
To activate use of the new default font cache file with versions of
Wabi that include a $WABIHOME/lib/fontconfig file, modify file
$WABIHOME/lib/fontconfig. Make the fourth field on the line for
your X-server be the name of the default font cache file you just
added into $WABIHOME/lib. If you're not sure which line in this
file is for your X-server, execute `xdpyinfo | grep '^vendor'` and
match the vendor string and vendor version information. Enter just
the unqualified name of the font cache file, not the full path to
it.
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 default font caches come with Wabi 1.0 for Solaris?
A: One of the default font caches provided with Wabi 1.0 for Solaris
matches vanilla OpenWindows 3.1 or 3.2 for use with Solaris 2.2.
Another default font cache provided with Wabi 1.0 for Solaris
matches the X-windows system in Solaris 2.1 x86.
None of the default font caches provided with Wabi 1.0 matches
vanilla OpenWindows 3.3 for use with Solaris 2.3. If the majority
of systems at your site run Solaris 2.3, you may want to replace one
of the default font caches that comes with Wabi 2.0 with one that
matches Solaris 2.3.
Q: Why does building the font cache take so long?
A: When building its font cache, Wabi asks the X-server to scale every
possible font to every possible size and report the resulting metrics.
Most X-server implementations have never before been asked for so
much detailed information about all their fonts at once. So they're
not at all optimized to answer such requests, and typically do a
poor job of it.
Some X-servers crash, some start quick but slow down dramatically
(apparently once they start paging), and a few complete quickly.
Q: Why does Wabi's font cache build begin quickly at first, then slow
down dramatically?
A: The speed of Wabi's font cache build depends on the speed of your
X-server. When asked to scale a large number of fonts, some
X-servers run quickly until they've exhausted free RAM, then slow
dramatically. This change in speed, if it occurs, is an artifact of
the X-server implementation.
Q: What factors control how long it takes Wabi to build its font
cache?
A: Some of the factors that determine how long it will take Wabi to
build a font cache include:
1) how many scalable fonts your X-server has (run `xlsfonts` and look
for lines with "0" in the font size positions),
2) how quickly your X-server can scale fonts, and
3) how much RAM your X-server has.
With a negligible number of scalable fonts and fast font scaling
(ex: vanilla MIT X11R5 distribution with no additional fonts), font
cache building may be quite fast.
Q: Why is my system completely locked up while Wabi is building its
font cache?
A: Responding to Wabi's requests when Wabi builds a font cache will
overtax some X-server implementations so badly they won't even
respond to a keystroke until the process is completed. If your
X-server has hardware mouse support, you'll still be able to move
the mouse, and may get the mis-impression your X-server is able to
do something else while Wabi is building its font cache.
To make it clear that Wabi knows your X-server is unable to respond
to other requests, and that this is not due to a transient problem,
Wabi 1.0 constrains the mouse to stay within the message box while
it's building a font cache.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: font cache rebuild
Keywords: xlsfonts font metrics cache rebuild
X-Applies-To:
X-Source-Info: File--fch3rb.txt Version--1.8 Date--94/04/13
Q: How come Wabi keeps telling me my "font path has changed" even
though I haven't changed my font path?
A: Many things other than an explicit action by you will change your
X-server's font path. For example, many X11 apps change the
X-server's font path when they come up.
So probably your X-server's font path really has changed even though
you didn't explicitly do anything to it.
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: 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: /foopath,/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.
One way to prevent font cache rebuilding is to modify your
X-server's startup instructions so all fonts are always in the
path. 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
Another way you might prevent font cache rebuilding is to modify the
Wabi startup script to reset the X-server's font path to a known
value before starting wabiprog. In most cases this won't affect
apps that are already running, since the fonts they use will have
already been loaded by the X-server and so it won't matter that
their fonts aren't in the X-server's font path.
# before starting wabiprog
set old_fp="`xset q | sed '1,/^Font Path:/ d'`"
xset fp default
# to optionally restore old font path after wabiprog exits:
# 1) remove "exec" from start of wabiprog line
# 2) add after wabiprog exits
xset fp= $old_fp
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 <From wabi1.0-questions@east.sun.com (---------------------------)
Subject: File Manager
Keywords: file manager update display new change directory refresh
X-Applies-To:
X-Source-Info: File--filmgr.txt Version--1.1 Date--94/04/26
Q: How come MS File Manager's display isn't automatically updated when
I add or delete a file or directory?
A: MS File Manager behaves the same under Wabi as it does under "real
Windows".
It automatically refreshes its display whenever you switch to a
different drive or directory.
Q: How can I manually force MS File Manager to update its display?
A: Pull down Window from the MS File Manager menu bar, and select
Refresh. (Or use the F5 shortcut key.) This will tell MS File
Manager that you want it recheck and redisplay the disk's contents.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: using floppy disks
Keywords: floppy disk diskette Drives configure device ready install application
X-Applies-To: Sun Solaris
X-Source-Info: File--floppy.txt Version--1.1 Date--94/04/28
Q: If an app or install procedure says "drive not ready" when I attempt
to access a floppy, what are the most likely problems?
A: Floppy problems are usually one of
- incomplete configuration of the Volume Manager, or unexpected
interaction between the Volume Manager and Wabi
- ownership of the floppy drive by another application, such as
File Manager, SunPC, or Mac Application Environment
- actual physical problem with the media, such as floppy not fully
seated in the drive, or damaged floppy
Q: Could it help to re-configure Wabi's A: to map to a different device
name?
A: Almost certainly not. The default device names you see in
Tools:ConfigurationManager:Diskettes are correct for almost all
Solaris systems. If Wabi has a problem accessing the floppy drive,
changing the Unix device name is much more likely to obscure or
confuse the original problem than it is to solve it.
Q: The familiar "abort, retry, or ignore" dialog that appears after Wabi
has a problem accessing the floppy drive doesn't always behave the
way I expect it to. Can I learn anything from its behavior?
A: You probably can't learn anything additional about Wabi's problem
accessing the floppy drive from Wabi 1.x's behavior after the
"abort, retry, or ignore" dialog first appears.
In Wabi 1.x, this dialog has some problems of its own, over and
above the original problem Wabi had accessing the floppy. These
additional problems will probably confuse your understanding of the
original problem. Once the "abort, retry, or ignore" dialog
appears, note simply that Wabi is having a problem accessing the
floppy drive. Don't attempt to learn anything further about the
original problem from Wabi 1.x's subsequent behavior after "abort,
retry, or ignore" first appears.
Q: The only time I use the floppy drive under Wabi is when installing
an application. I find using it even for this purpose inconvenient.
Is there some way I can install an application without accessing
the floppy drive from Wabi?
A: Yes. You can copy the installation floppys to your hard drive once,
then install the app from the hard drive with no manual intervention.
Detailed instructions on how to do this are included in instructions
on how to install apps under Wabi.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: using floppy disk drives on other machines
Keywords: floppy disk diskette remote file copy Xterminal X-terminal
X-Applies-To: Sun Solaris
X-Source-Info: File--flpoth.txt Version--1.3 Date--94/04/28
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.x 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:Drives--
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 drive and
path (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 remotely on some other machine and
projecting its windows back to your machine, there's no way with
Wabi 1.x 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 by copying all the files to a location where
Wabi can access them.
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
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: sharing floppy drive between Wabi and SunPC
Keywords: floppy disk drive Wabi SunPC attach detach active use
X-Applies-To:
X-Source-Info: File--flpshr.txt Version--1.1 Date--94/03/21
Q: Can both Wabi and SunPC share use of the floppy disk drive?
A: Yes, Wabi and SunPC can share the floppy drive. You can start Wabi,
start SunPC, and access a diskette from either process without
having to quit either process. Wabi and SunPC cannot both have the
floppy drive "attached" at the same time, but with some simple user
actions, either process can use the drive.
Running SunPC and Wabi at the same time, and using the above
mechanisms, I have no problem accessing the same diskette from
either process. We've tested this with Wabi 1.1 and SunPC 4.0.1.
As far as we know it works the same with earlier releases of Wabi
and of SunPC.
Q: How do I get SunPC to attach and detach the floppy drive?
A: SunPC "attaches" the floppy as drive A: when the A: button on
the SunPC UI is attached. When the button is released, SunPC
releases the drive for access by other processes. The drive can be
attached and released without ejecting the floppy. The SunPC user
ejects the floppy using either the Operations menu, the Popup menu,
or the Meta-E key. In SunPC, ejecting the floppy does not release
the drive. Note that for SunPC to operate correctly with the floppy,
volmgr floppy management must be turned off.
Q: How to I get Wabi to use and release the floppy drive?
A: Wabi does not have an attach/release UI. Wabi accesses the floppy
if it is not controlled by another process. Once Wabi has accessed
the floppy, it keeps control of it until the user ejects the
diskette using Meta-E. As long as no other process attaches the
drive in the meantime, Wabi can access the drive again when a new
diskette is inserted in the drive.
Q: Will the Wabi mechanism for releasing the floppy drive be further
improved in the future?
A: Yes. Wabi 2.0 will release the floppy drive after a period of
inactivity even if the user doesn't explicitly press Meta+E.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Font Service Protocol Problems in X11R5
Keywords: font service protocol x11r5 x11r6 patch X-server mit distribution
X-Applies-To:
X-Source-Info: File--fntbug.txt Version--1.2 Date--94/05/04
Q: Are there problems with the X-server implementation of the "font
service protocol" in X11R5?
A: Yes, there are several known bugs in the X11R5 X-server
implementation of the "font service protocol".
Q: Are there patches for any of these?
A: Most major vendors have fixed the most severe of these problems in
their X-server code. For example, Sun OpenWindows 3.3 plus patch
101362 works with Wabi. And the HP "January 1994" patch of the
X-server code works with Wabi.
There are no official patches available for the MIT distribution.
The X consortium's priority is to fix all these problems in X11R6
rather than distribute patches to X11R5.
Q: What symptoms can these problems cause for Wabi users?
A: The X-server may never finish building Wabi's font cache. Or the
X-server may crash about the same time Wabi tries to exit. Or the
X-server may "hang" or behave very erratically.
You will probably not get any error message from either Wabi or the
X-server in any of these situations.
Q: What's the easiest way to avoid any possibility of these problems?
A: The easiest way to avoid any possibility of these problems is to
disable Wabi's use of the font service protocol altogether. As
root, edit file $WABIHOME/lib/wabifs.displays (or file
$WABIHOME/lib/fontconfig). ($WABIHOME is probably /opt/SUNWwabi.)
Comment out (or change 'Y' to 'N' on) the line that describes your
X-server. To comment out a line, insert a sharp ('#', also called
poundsign or numbersign) in the first column. If there's a 'Y' or
'N' in the line, change it rather than commenting out the line.
The good news is this will always work. The bad news is it may may
noticeably degrade Wabi's performance if you use TrueType fonts
heavily.
Q: Rather than disabling Wabi's use of the font service protocol,
can I make my X-server running the MIT distribution work?
A: Yes, you can probably make it work. Install all the available
patches. Be sure your build environment is set up to define the
right number of bits in the X-server's file descriptor select mask.
Then attempt to fix the bug that manifests itself as wrong FPE (font
path element) reference counts when a font server is removed from
the X-server's font path. Make changes similar to these to the code
(these changes are from a customized version of the X-server code,
and may not apply exactly as is to the MIT distribution of X11R5):
--- server/dix/dixfonts.c Wed Dec 22 20:04:14 1993
***************
*** 328,334 ****
err = BadFontName;
goto bail;
}
! pfont->fpe = fpe;
pfont->refcnt++;
if (pfont->refcnt == 1) {
UseFPE(pfont->fpe);
--- 328,335 ----
err = BadFontName;
goto bail;
}
! if (!pfont->fpe)
! pfont->fpe = fpe;
pfont->refcnt++;
if (pfont->refcnt == 1) {
UseFPE(pfont->fpe);
*** - Thu Jan 6 15:29:56 1994
--- fonts/server/difs/fonts.c Wed Dec 22 20:15:00 1993
***************
*** 402,408 ****
WriteReplyToClient(client,
SIZEOF(fsOpenBitmapFontReply), &rep);
if (pfont->refcnt == 0) {
! pfont->fpe = fpe;
UseFPE(pfont->fpe);
}
pfont->refcnt++;
--- 402,409 ----
WriteReplyToClient(client,
SIZEOF(fsOpenBitmapFontReply), &rep);
if (pfont->refcnt == 0) {
! if (!pfont->fpe)
! pfont->fpe = fpe;
UseFPE(pfont->fpe);
}
pfont->refcnt++;
*** - Thu Jan 6 15:31:49 1994
--- fonts/lib/font/fontfile/fontfile.c Thu Jan 6 15:31:58 1994
***************
*** 308,313 ****
--- 308,314 ----
if (scaled->pFont)
{
*pFont = scaled->pFont;
+ (*pFont)->fpe = fpe;
ret = Successful;
}
else if (scaled->bitmap)
***************
*** 317,322 ****
--- 318,324 ----
if (bitmap->pFont)
{
*pFont = bitmap->pFont;
+ (*pFont)->fpe = fpe;
ret = Successful;
}
else
***************
*** 324,329 ****
--- 326,333 ----
ret = FontFileOpenBitmapNCF (fpe, pFont, flags, entry,
format, fmask,
non_cachable_font);
+ if (ret == Successful && *pFont)
+ (*pFont)->fpe = fpe;
}
}
else /* "cannot" happen */
***************
*** 403,408 ****
--- 407,413 ----
ranges = 0;
else
(*pFont)->fpePrivate = (pointer) 0;
+ (*pFont)->fpe = fpe;
}
}
}
***************
*** 438,443 ****
--- 443,449 ----
if (bitmap->pFont)
{
*pFont = bitmap->pFont;
+ (*pFont)->fpe = fpe;
ret = Successful;
}
else
***************
*** 444,449 ****
--- 450,457 ----
{
ret = FontFileOpenBitmapNCF (fpe, pFont, flags, entry, format,
fmask, non_cachable_font);
+ if (ret == Successful && *pFont)
+ (*pFont)->fpe = fpe;
}
break;
case FONT_ENTRY_ALIAS:
***************
*** 460,465 ****
--- 468,475 ----
ret = (*scalable->renderer->OpenScalable)
(fpe, pFont, flags, entry, &bc->vals, format, fmask,
non_cachable_font);
+ if (ret == Successful && *pFont)
+ (*pFont)->fpe = fpe;
break;
default:
ret = BadFontName;
*** - Thu Jan 6 15:33:29 1994
--- fonts/lib/font/fontfile/bitsource.c Thu Dec 16 20:13:37 1993
***************
*** 115,120 ****
--- 115,121 ----
if (scaled->pFont)
{
*pFont = scaled->pFont;
+ (*pFont)->fpe = FontFileBitmapSources.fpe[source];
ret = Successful;
}
else if (scaled->bitmap)
***************
*** 124,129 ****
--- 125,131 ----
if (bitmap->pFont)
{
*pFont = bitmap->pFont;
+ (*pFont)->fpe = FontFileBitmapSources.fpe[source];
ret = Successful;
}
else
***************
*** 131,136 ****
--- 133,140 ----
ret = FontFileOpenBitmap (
FontFileBitmapSources.fpe[source],
pFont, flags, entry, format, fmask);
+ if (ret == Successful && *pFont)
+ (*pFont)->fpe = FontFileBitmapSources.fpe[source];
}
}
else /* "cannot" happen */
format, fmask,
non_cachable_font);
+ if (ret == Successful && *pFont)
+ (*pFont)->fpe = fpe;
}
}
else /* "cannot" happen */
***************
*** 403,408 ****
--- 407,413 ----
ranges = 0;
else
(*pFont)->fpePrivate = (pointer) 0;
+ (*pFont)->fpe = fpe;
}
}
}
***************
*** 438,443 ****
--- 443,449 ----
if (bitmap->pFont)
{
*pFont = bitmap->pFont;
+ (*pFont)->fpe = fpe;
ret = Successful;
}
else
***************
*** 444,449 ****
--- 450,457 ----
{
ret = FontFileOpenBitmapNCF (fpe, pFont, flags, entry, format,
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: font server
Keywords: wabifs font server X11R5 TrueType displays
X-Applies-To:
X-Source-Info: File--fntsvr.txt Version--1.5 Date--94/05/04
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 (or
file $WABIHOME/lib/fontconfig). ($WABIHOME is probably
/opt/SUNWwabi.) To find out the name and release number of your
X-server, execute `xdpyinfo`.
Each entry on the list appears on its own line. The first field on
the line is the X-server's vendor string. The second field is the
lowest acceptable vendor release number. Depending on your version
of Wabi, the line may also include two further fields. The third
field is 'Y' or 'N' to indicate whether or not to use the font
service protocol with this X-server. And the fourth field is the
name of the "default font cache" file to try using with this
display. The first field probably contains blanks and so should be
enclosed in double-quote marks. Fields should be separated by a
comma.
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 (or
$WABIHOME/lib/fontconfig) that describes your X-server. To get the
information to enter, execute
xdpyinfo | grep '^vendor'
Enter the information in the same format as the other lines in the
file. Enter the vendor string enclosed in double-quotes as the
first field, the vendor release number as the second field, possibly
a 'Y' as the third field, and possibly "" as the fourth field unless
you have a "default font cache file" that matches this display.
Separate fields with commas.
The second field in the file, the version number, is the lowest
version number that will to be considered to match. The actual
version number returned by a particular X-server may be higher. If
you want several entries in the file for different X-server versions
from the same vendor, make a separate line for each version and
enter the lines into the file with the highest version number
first. The lines in the file are searched in order, so your
X-server will be matched to the first line whose vendor string
matches and whose vendor version is less than or equal to that of
your X-server.
Q: How can I force my system to not use a separate font server process?
A: You can disable Wabi's use of a separate font server process. 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.
Note that you're disabling Wabi's font server, not Wabi's font
cache. The font server and the font cache are different features.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: creating folders
Keywords: directories folders create delete file manager mkdir rmdir rm
X-Applies-To:
X-Source-Info: File--folder.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: additional fonts
Keywords: Adobe Type Manager PC fonts X X11 default extra additional installation
X-Applies-To:
X-Source-Info: File--fonts.txt Version--1.2 Date--94/04/21
Q: At the end of the installation of several apps, a message suggests we
install the Adobe Type Manager. Is this recommended under Wabi?
A: No, you do not need additional fonts to run apps usefully under Wabi.
Wabi gives apps access to all the fonts in your Xserver (typically 10
or more type faces) even if you have no PC fonts and no PC font
manager installed.
This is dramatically different from the situation under MS-Windows.
Under MS-Windows you probably get by default only a handful of
typefaces (Times, Courier, Helvetica, Symbols).
MS-Windows-based app installation defaults and suggestions assume
installation under "real Windows". They're often inappropriate for
installing the app under Wabi.
Q: Is Adobe Type Manager even supported under Wabi 1?
A: No, Adobe Type Manager is not certified to run under Wabi 1. And
because of its intimate knowledge of the internals of "real
Windows", it will probably not work correctly if you do install it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: formatting floppy disks
Keywords: format floppy disk MS-Windows fdformat
X-Applies-To: Sun Solaris SunOS
X-Source-Info: File--format.txt Version--1.1 Date--94/01/21
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 `fdformat`.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: floating point
Keywords: coprocessor x87 floating point math emulator inline RISC x86
X-Applies-To:
X-Source-Info: File--fp.txt Version--1.2 Date--94/01/30
Q: How are floating point operations handled when Wabi runs on x86
hardware?
A: The app will check at load time (or run time depending on how the app
was compiled and linked) to see whether or not the system has a
floating point coprocessor. Wabi answers with the actual capabilities
of the hardware. Since Solaris 2 x86 requires a floating point
coprocessor, the answer for Wabi under Solaris 2 will always be "yes,
a floating point coprocessor is present".
App execution will proceed just as it would under MS-Windows.
Typically this means floating point opcodes will be passed directly to
the machine's floating point hardware.
Q: How are floating point operations handled when Wabi runs on RISC
hardware?
A: The app will check at load time (or run time depending on how the app
was compiled and linked) to see whether or not the system has a
floating point coprocessor. Wabi 1.0 answers "no, no floating point
coprocessor is present" since the exact sort of FP hardware the app is
asking about indeed is not present on the system.
App execution will proceed just as it would under MS-Windows on
hardware with no floating point coprocessor. Typically under Wabi 1.0
this means floating point operations will become calls into an 80x87
emulator library. The 80x87 emulator library is internal to Wabi --
Wabi does not rely on the presence of the MS-Windows version of
WIN87EM.DLL. The internal emulator library uses the hardware's native
floating point capabilities to execute the requested floating point
operations as quickly as possible.
In most cases an app's floating point operation request is passed
through unchanged to the RISC hardware's FPU. So long as the app is
well coded so it doesn't rely on the extended precision of an x87
floating point coprocessor, it will get the same answers under Wabi
on a RISC machine that it would get when run on x86 hardware.
(An enhancement to a future version of Wabi to provide other options
and/or to make Wabi's floating point behavior more controllable by the
user is under consideration.)
Q: What about apps that *require* that an 80x87 floating point
coprocessor be present before they will run?
A: The vast majority of apps follow the recommended build procedure to
run either with or without a floating point coprocessor. Under
MS-Windows, these apps run whether or not the system has a floating
point coprocessor. They just run faster if a floating point
coprocessor is present. These apps run fine under Wabi.
A few apps that think they will run unacceptably slowly on a PC
without a floating point coprocessor *insist* that a math coprocessor
be present. Usually these apps are built with /FPc87 or /FPi87.
These apps will not start up under Wabi 1.0 running on non-x86
hardware.
Q: What can I do to make an app that *insists* that a floating point
coprocessor be present run under Wabi 1.0?
A: For Wabi 1.0, there are two ways you might get an app that requires a
floating point coprocessor to run.
First, you could relink the app to not *insist* that a floating point
coprocessor be present (use /FPi or /FPc or /FPa). The relinked app
should work fine. (If the same message comes out even after changing
the build option, look for either explicit specification of a *7.DLL
despite the build option, or an explicit check for floating point
coprocessor present. The app may make its own explicit check for
floating point coprocessor so it can issue its own message.)
Second, you could run the app under Wabi on x86 hardware that actually
has a floating point coprocessor.
Q: Performace of a very math intensive application under Wabi on SPARC
seems to be over an order of magnitude slower than on a DX-33. Is
this expected?
A: Wabi excels with display-intensive apps. Wabi focuses on enabling you
to "run your business" on your Unix machine. "Run your business"
means run business applications and personal productivity tools.
Technical, compute-intensive apps do not perform as well under Wabi.
If you need serious number crunching power, consider running the
number crunching app native.
The combination of the interaction of two OSs (Solaris and Wabi),
integer instruction opcode interpretation, control instruction
opcode interpretation, and floating point emulator calls may make
Wabi on a RISC machine run compute-intensive apps noticeably slower
than they run under "real Windows". This is true despite Wabi's use
of the native floating point capability of the RISC machine. If
Wabi didn't use the RISC machine's floating point hardware
capability at all, floating point intensive apps would run even
slower under Wabi 1.0.
You can expect the performance of Wabi with compute-intensive apps to
improve in the future. Compute-intensive apps will probably never run
as fast under Wabi as they do under "real Windows" on high-end
hardware.
Q: Which floating point build option should I use to build an app to run
under Wabi?
A: The same build option you'd use to build an app to run under "real
Windows" on machines both with and without a floating point
coprocessor.
/FPi87 and /FPc87 will restrict your app to running only on machines
that have an Intel-style floating point coprocessor. Such apps will
run under Wabi 1.0 only on x86 hardware.
There are lots of floating point build options available. In several
cases it's possible to effectively override the floating point compile
option by explicitly specifying a different library at link time. If
in doubt, start by using the compile-time defaults provided by your
Integrated Development Environment and omitting any link-time
specification. Your IDE will probably default to /FPi "use emulator",
which will generate code that can be used on any machine: Wabi on x86,
Wabi on RISC, and MS-Windows on machines both with and without a
floating point coprocessor.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: floating point precision
Keywords: ieee strict precision 64 80 bit internal intermediate register overrun underrun WIN87EM WIN87EM.DLL
X-Applies-To:
X-Source-Info: File--fpieee.txt Version--1.1 Date--94/01/30
Q: What's the difference between IEEE floating point arithmetic and x87
floating point arithmetic?
A: SPARC, and most other RISC machines, provide "strict" IEEE floating
point capability. Computations are done in the precision specified
(32 bit or 64 bit). There are no 80 bit registers whatsoever. The
x87, on the other hand, has 80 bit intermediate registers (which it
arranges in the form of a stack).
For single operations with either 32 bit or 64 bit operands, the
strict IEEE and x87 FPUs will return exactly the same answer. In a
long series of operations where the programmer has been careless
about letting near-underflow or near-overflow conditions occur, the
strict IEEE and x87 FPUs may return slightly different answers.
Q: What if an app *must* have the 80 bit internal precision of an x87
floating point coprocessor?
A: If for some reason a user can't tolerate the difference in internal
precision between the IEEE 64-bit standard and the x87 floating point
coprocessor chips, Wabi 1.0 could be made to use the real win87em.dll
instead of the SPARC FPU. But doing this would not only require the
user to buy MS-Windows to get WIN87EM.DLL, but also would degrade
performance significantly since all floating point operations would be
simulated in software using only integer operations. So we don't
recommend it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: hardware/software requirements
Keywords: SPARC 1.0 x86 SunOS4 Solaris
X-Applies-To:
X-Source-Info: File--hs_req.txt Version--1.2 Date--94/04/29
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 execute under Solaris 1?
A: No. Although they considered, it, both SunSoft and SMCC have
decided not to offer such a product.
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: Then why did a few versions of the SunExpress catalog mention the
possibility of a version of Wabi that would execute under Solaris 1?
A: During the short time in which one of the Sun planets was planning
to offer Wabi 1.1 on Solaris 1.x, one geographical subdivision of
SunExpress published "Wabi for Solaris 1.x" as a likely future
product. We apologize for any confusion this may have created.
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: icon overlap
Keywords: SunOS4 Solaris OpenWindows
X-Applies-To:
X-Source-Info: File--icnovr.txt Version--1.1 Date--94/01/21
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.)
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: icons
Keywords: icons groups desktop
X-Applies-To:
X-Source-Info: File--icons.txt Version--1.1 Date--94/01/21
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 in
that you can have executables available yet not have desktop icons
for them. (And icons on the "real Windows" are similar to icons in
the OpenWindows File Manager - they may not launch their application
correctly.)
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
user needs to have their own 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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: idle looping
Keywords: shared central Wabi engine share spin idle loop CPU use poll busy
X-Applies-To:
X-Source-Info: File--idloop.txt Version--1.3 Date--94/02/24
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, MS-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.
This application behavior is often called "polling" or "busy
waiting".
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.)
Q: Will the next release of these ill-behaved apps behave better?
A: Almost certainly yes. We expect the misbehavior of these
applications will be corrected in the near future. It's becoming
widely known that these apps interfere with power-saving technology
(ex: they 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.
Even if the application misbehavior is not corrected soon, Wabi 2.0
will detect this situation and handle it gracefully.
Q: If idle users leave one of these ill-behaved apps up, they load the
CPU of my central Wabi engine so much that the performance seen by
other Wabi users is degraded. What can I do about this?
A: Wabi 2.0 will detect idle loops in ill-behaved apps and avoid loading
the CPU unnecessarily.
Even under Wabi 1.0, you won't necessarily notice degradation caused
by this problem. Depending on which apps you use and how many apps
your users typically leave open but idle, the problem may not be
worth worrying about.
We suspect it may be possible to patch Wabi 1.0 to reduce the
effects of this problem. But our initial attempt to produce such a
patch failed, and other priorities have precluded us from trying
again.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: installing applications under Wabi
Keywords: install application run compression speed C: share
X-Applies-To:
X-Source-Info: File--insapp.txt Version--1.6 Date--94/05/13
Q: Where can I get more information about the process of installing
applications?
A: Start with each app's own installation instructions.
Then, for Wabi-specific issues, see the section "Installation of
Windows-Based Applications" in the Wabi Users' Guide. And refer to
a recent version of the SST-certified app installation notes. (The
version available by sending email To: wabi1.0-apps@east.sun.com
might be more current than the Wabi 1.x Release Notes available in
the Tools group inside the Wabi distribution.)
Q: Why might app installation fail? For example, why might PowerPoint
or CorelDRAW installation stop, complaining about not enough disk
space for some temp file or font file?
A: For best results, apps should be installed through the File->Run
menu option of Application Manager (or Program Manager). Avoid
double-clicking on the SETUP.EXE (or INSTALL.EXE) program in MS File
Manager. And avoid MS File Manager's File->Run menu option. App
installations started by MS File Manager may not complete
successfully, particularly under Wabi 1.x.
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.
The Wabi Users' Guide says you can install apps to C: if you wish.
Unfortunately, the wording may seem to imply that installing apps to
C: is suggested or even required. In fact, apps can be installed to
any drive you wish. As discussed above, in most cases you will want
to install apps to a drive other than C:.
Q: What if installation of an app fails? Does that mean it definitely
will not work under Wabi 1.0?
A: No, just the opposite. A great many apps will run fine under Wabi
1.0 although their installation procedure will not run under Wabi
1.0 If installation under Wabi 1.0 fails, install the app on a real
PC. Then copy the entire app (typically the entire contents of a
subdirectory tree, an {app}.ini file in C:\windows, an {app}.grp
file in C:\windows, a line near the end of progman.ini, and possibly
a section in win.ini) to a Wabi system and try to run it.
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, PROCOMM)
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 supplies 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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: sharing apps
Keywords: share network networked .INI .DLL one single copy
X-Applies-To:
X-Source-Info: File--insash.txt Version--1.1 Date--94/01/26
Q: When "wabi" is run, it creates $HOME/wabi for each user and maps it to
C: for that instance of Wabi. Does that mean that all software
installed through Wabi is installed on a per-user basis? Or can I
install an app once in a "network" configuration and have other users
mount and use it?
A: This is application dependent.
MS Windows application are primarily written for Single User Single
tasking non protected environments. As the Windows market matures,
some of the applications are making allowing for LVEU (Large Volume
End User) installations.
Q: What problems might I see if I try to have several users share one
copy of an app?
A: Some possible problems:
1) Does the Software License allow you to do this? If not, then
don't do it (you'll be breaking the law).
2) Applications create ".INI" files in the application directory.
If multiple people use the software, the ".INI" file will get
corrupted as several user attempt to execute the application at
once.
3) Many applications install DLLs into the C:\windows directory.
The C:\windows directory in MS-Windows and in Wabi is unique for
each user. The software will only find the DLL for the user who
installed it.
4) Record/File locking may not be turned on in the application.
Q: Is there a way I can get a quick feel for how difficult it would be to
make an app work in a "networked" configuration under Wabi?
A: Read the app's documentation, if the DOC has a chapter on the subject
then the ISV has thought about it, and there's some hope of making it
work under Wabi. If not, then you are probably wasting your time.
Q: Is there a way I can check whether or not an app I think I've
installed in a "network" configuration will actually work correctly
if used by several users?
A: Yes. Mount the file system containing the app "read-only". Start
Wabi as a different userid than the one you used when installing the
app, and start the app. Do enough operations to cause a "temp" file
to be written and to change the default document names at the end of
the "File" menu, and resize all of the app's windows. Quit the app.
Restart the app and make sure all your changes were saved correctly.
If you can do all this without ever getting an error message about
"...file access denied..." or "...read-only file...", your
installation of the app will work correctly for multiple users.
Q: Assuming an application has a "network install" option, can I use
the option to install the app in such a way that several users or
systems can share one copy of it?
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.
Wabi 1.0 does support file sharing/locking. So if you could get an
app installed in a way that it understood it was running on a network,
it would probably work correctly.
However Wabi 1.0 does not set the bits correctly to inform the
application that a drive is a "network" drive. (Setting these bits
correctly is non trivial.) This prevents use of the "network
install" option of most applications. Thus Wabi 1.0 will not easily
support shared apps.
Engineering and testing to support this functionality is planned for
Wabi 2.0.
Q: Has Wabi 1.0 been tested using any application in a "networked"
configuration?
A: No, Wabi 1.0 has not been tested using any application in this way.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: installing MS-Windows
Keywords: MS-Windows install under merge applets games
X-Applies-To:
X-Source-Info: File--inswin.txt Version--1.3 Date--94/04/21
Q: Is it necessary to install Microsoft Windows under Wabi?
A: Probably not. Wabi 1.x 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 SST-certified
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.x. Wabi 1.x 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 get 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.x 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: 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.x 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.
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: interprocess communication
Keywords: shared files tooltalk DDE OLE OLE2
X-Applies-To:
X-Source-Info: File--ipc.txt Version--1.3 Date--94/05/03
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 2.0 will include networking support, and some future
version of Wabi may also include 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. The definition of an
OLE<->ToolTalk translation will wait until COSE is better defined
and until many of the significant technical obstacles to
OLE<->ToolTalk interoperability are resolved.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: window function shortcut keys
Keywords: cut copy paste open close front back x86 minimize iconize
X-Applies-To:
X-Source-Info: File--keymap.txt Version--1.2 Date--94/03/30
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: 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 .xmodmaprc
then create ~/.xmodmaprc with contents something like this
keysym F1 = L6
keysym F2 = L8
keysym F3 = L10
keysym F5 = L9
keysym F9 = L7
keysym F10 = L5
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: kernel modules
Keywords: kernel module driver modload demand extend I/O magic cookie volume manager
X-Applies-To:
X-Source-Info: File--knlmod.txt Version--1.1 Date--94/02/21
Q: What does a Solaris "kernel module" do?
A: Kernel modules are pieces of the OS that can be installed separately.
Kernel modules eliminate what used to be a very common procedure with
Unix -- rebuilding a kernel to add a feature.
Q: What might these modules be called?
A: These modules could be called any of several things: "kernel drivers",
"kernel modules", "modloadable drivers", and more.
The word "driver" is common because many of the modules perform I/O
functions. "modload" is the name of the command used to force their
loading.
Q: Where are kernel modules stored?
A: Kernel modules are usually stored either in /kernel/drv or in
/usr/kernel/drv.
By convention, those kernel modules needed to boot the OS are stored
in /kernel/drv. And anything that can wait until after the kernel is
booted (and /usr is mounted) is traditionally put into /usr/kernel.
In /etc/system, you'll find a variable called "moddir" that
establishes a search path for these modules. By default, this search
path is /kernel and /usr/kernel.
Q: When are kernel modules loaded?
A: Solaris 2.x loads its modules "on demand" as you need them.
So when you start Wabi for the first time since you've booted and it
needs its kernel module, it first looks in /kernel/drv, and then looks
in /usr/kernel/drv and hopefully finds it. The module will then stay
resident in the kernel until the kernel decides that its running tight
on space and tries to autounload it (or someone runs modunload(1M) on
it!)
You can check this by running modinfo(1M) on your freshly booted
kernel, run Wabi, and run modinfo again. The second time 'round,
you'll see something similar to the following:
128 fc30a000 12e4 105 1 wabi (Wabi Driver v1.1)
Q: Is there a way I can watch automatic loading and unloading of kernel
modules?
A: Yes, if you're really curious you can watch this automatic loading and
unloading of kernel modules by tweaking the variable moddebug in your
kernel with adb:
# adb -kw /dev/ksyms /dev/mem
physmem 1661
moddebug/W 0x80000000
moddebug: 0x0 = 0x80000000
$q
(Other possible values for moddebug are described in )
Now when you start Wabi for the first time, you should see something
similar to the following in your console:
load 'drv/wabi' id 80 loaded @ 0xfc442000 size 4560
installing wabi, module id 80.
You'll see the corresponding message if you unload the module with
modunload.
Q: What does Wabi's kernel module do?
A: Wabi's kernel module performs two functions needed by Wabi and not
otherwise available from Solaris 2.x.
First, it provides an interface between Wabi and the Volume Manager.
And second, it gives Wabi direct access to the "magic cookie" of a
file that's accessed via NFS. Wabi needs this "magic cookie" so it
can build RPC requests to the remote lock daemon and thus fully
implement file locking and sharing.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: app network/site licenses
Keywords: app application network site license licenses manager wrapper
X-Applies-To:
X-Source-Info: File--licens.txt Version--1.3 Date--94/04/14
Q: How can I obtain network or site licenses for the various apps I want
to run under Wabi?
A: Most ISVs do offer a network or site license for their apps. All you
need to do is figure out who to ask. If there's a "PC Support Group"
in your organization, ask them for help in figuring out how to get a
network or site license for each app you plan to use. Or try calling
the ISV directly.
Wabi neither provides licenses for apps nor eliminates the need for
network/site licenses.
Currently every ISV offers network/site licenses differently. What
works with one ISV will probably not work with the next.
The one constant seems to be that no ISV offers their network/site
license through retail channels. So if you ask the friendly
salesperson at your local computer software store about a network or
site license, they'll probably respond "Gee, I don't know...".
Q: Can I run a network app license tool under Wabi to monitor and control
my use of network licenses for the apps I run under Wabi?
A: In theory, yes. An MS-Windows-based network app license tool program
that places "wrappers" around the real applications should run under
Wabi and provide the same functionality it does under "real Windows".
In practice, no network app license tool has been certified to run
under Wabi 1.x. Even disregarding formal certification, we haven't
yet found a network app license tool program that we know runs under
Wabi 1.x. hDC's Express Meter product requires a Virtual Device
Driver (VxD), something Wabi doesn't support. SaberLan's product is
so enmeshed with the other apps it's packaged with that we haven't
been successful at installing and running it under Wabi 1.x. Other
network app license tools we've looked at require access to a
networking API (NetBIOS, WinSock, etc.), something Wabi 1.x does not
support. SoftInfo's product hasn't been eliminated yet, and there's
at least one other product that merits further investigation.
You can expect this situation to improve in the near future. We're
working at including some networking APIs in Wabi 2.0. And we're
encouraging ISVs to certify at least one network app license tool
under Wabi 2.0.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: monochrome displays
Keywords: monochrome black white display screen
X-Applies-To:
X-Source-Info: File--mono.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: multimedia
Keywords: sound video extensions multimedia API
X-Applies-To:
X-Source-Info: File--multim.txt Version--1.2 Date--94/04/14
Q: Can Wabi 1.x run Windows 3.1 multimedia applications?
A: Wabi 1.x 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 SST-certified apps require the
multimedia extensions.)
Q: Does Wabi 1.x support the devices and services used by multimedia
applications?
A: Wabi 1.x 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.x does not support Compact Disc Audio Services.
Wabi 1.x 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.x 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.x does not support MIDI Audio Services.
Q: Does Wabi 1.x 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.x fully and conveniently supports only those devices known to
the X11 protocol: display, keyboard, and mouse. Wabi 1.x does not
support any sound device.
Q: Can I develop multimedia apps under Wabi?
A: Wabi 1.x's primary purpose is to run shrink-wrapped apps. Wabi 1.x
expects that multimedia development will be done either directly under
Unix or else on a "real PC".
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: networking support
Keywords: 1.0 1.1 1.x WinSock NetBIOS IPX Novell Netware
X-Applies-To: Wabi 1.x
X-Source-Info: File--netwrk.txt Version--1.2 Date--94/04/14
Q: How does Wabi 1.x 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.x doesn't appear to
support networking. Applications running under Wabi 1.x 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.x, most
network licensing schemes don't work under Wabi 1.x, applications
that need a network API to do anything useful (ex: PowerBuilder,
MS-Access) don't run meaningfully under Wabi 1.x, and built-in
application support for various kinds of networking can't be
utilized under Wabi 1.x.
Q: Can I add networking support to Wabi 1.x 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 versions of Wabi 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 certified apps.
WinSock is an extension of the familiar Unix TCP/IP networking API.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: message: not enough memory
Keywords: not enough out of memory swap RAM sar unrecoverable error
X-Applies-To:
X-Source-Info: File--nomem.txt Version--1.5 Date--94/05/18
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: Can I troubleshoot a problem starting from a "- not enough memory!"
message?
A: Probably not. Because they are so common and so often don't mean
exactly what they say, these messages aren't much more meaningful
than just saying "it doesn't work". They don't give you enough
information to identify a problem. They probably aren't even
sufficient as a starting point for troubleshooting a problem.
Q: If an app complains about not having enough memory, is there something
I can do to make sure memory isn't the real issue?
A: Yes. Temporarily increase your system's swap space (ex: `mkfile;
swap -a`) to double its current size, then rerun your test. If you
still get a message about not enough memory, memory isn't the real
problem.
Q: Do apps running under Wabi ever really run out of memory, like they
might on a real PC if RAM was exhausted?
A: The only time apps running under Wabi (and non-Wabi processes too)
will really run out of memory is when your system swap space is
exhausted. If your system has enough swap space, apps running under
Wabi will never run out of memory.
Q: Are there situations where an app running under Wabi would run short
of memory when the same app running under MS-Windows wouldn't?
A: None that we know of.
Q: Are there any limitations on the amount of memory an app running
under Wabi can use?
A: There are no memory limitations in Wabi tighter than you'd find on a
"real PC". If the application has enough memory on any "real PC"
(even one with lots and lots of RAM), it will get enough memory
under Wabi as well.
In most cases Wabi will make more memory available to the apps
running under it than they'd see on a "real PC". In a few cases the
app will hit the same limit in either environment. This can happen
when there's no more memory "handles". Memory handles under
MS-Windows are so closely tied to Intel hardware architecture that
there's no way for Wabi to increase the number of memory handles
transparent to applications.
This of course assumes there's enough swap space on your system that
Wabi's calls to malloc() never fail.
Q: How does Wabi obtain and grant memory?
A: Wabi obtains memory via malloc(). Wabi relies on the host OS's
virtual memory implementation to do all the real work
transparently.
Wabi gives memory to apps running under it the same way MS-Windows
does.
Q: Are there any switches (command line, environment, *.ini, etc.)
that will control how Wabi obtains or grants memory?
A: No.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: administering system memory
Keywords: memory swap RAM resources malloc sar config.sys
X-Applies-To:
X-Source-Info: File--nomem2.txt Version--1.1 Date--94/05/18
Q: Can system configuration limit the amount of memory Wabi makes
available to the apps running under it?
A: Yes. Wabi, like other Unix apps, assumes your system has enough
swap space that its calls to malloc() will never fail. If one of
Wabi's calls to malloc() fails, Wabi will usually tell the app the
system is "out of memory" since this will evoke the most relevant
response from the app.
Q: How can I manage the amount of memory Wabi makes available to the
apps running under it?
A: Simply make sure your system has plenty of swap space, then
let Wabi handle sub-allocating memory to the apps running under it.
Provided adequate swap space is available, there are no
configuration options or limits on the amount of memory Wabi makes
available to the apps running under it.
Q: On a "real PC" administering memory is a significant issue. Why
are there no memory administration options under Wabi?
A: As much as possible Wabi leaves the administration and configuration
of your system to the host OS. Wabi does not provide an alternate
way to manage your system.
Manage the memory of your system using the administration tools your
host OS provides (ex: `sar`, `swap`). Don't try to manage your
whole system from inside Wabi, and don't try to manage Wabi the same
way you'd manage a "real PC".
Q: Should I improve my system by adding more swap, or by adding more
RAM?
A: The answer is the same for Wabi as for non-Wabi apps on your
system. To be sure apps don't run out of memory, add more swap
space. To make the system run faster, add more RAM.
Use your host's system administration tools (ex: `sar`) to determine
whether or not your system overall has enough RAM.
Q: Which of the options a "real PC" provides in CONFIG.SYS have
analogues in Wabi?
A: None. The options in CONFIG.SYS were motivated by a need to tune
memory use very tightly so DOS would run on a real memory machine
with very limited RAM.
Wabi runs on virtual memory machines with much much more available
memory, so there's no motivation for options like those in
CONFIG.SYS.
Q: Does Wabi even read C:\CONFIG.SYS?
A: No. Wabi doesn't require this file to exist, and doesn't read or
process it if it does exist.
If you need to to make an application happy, you can create a file
with this name and put anything you want in it.
cd ~/wabi
cat - <config.sys.unix
FILES=30 # example
unix2dos config.sys
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Novell Netware interoperability
Keywords: Novell Netware NFS NLM IPX client vnode network API
X-Applies-To:
X-Source-Info: File--novell.txt Version--1.3 Date--94/05/03
Q: Can Wabi 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.
If your host OS can mount remote files from a Novell server even
when the Novell server doesn't have the NFS NLM installed, Wabi can
access those files by simply mapping a drive letter to the mount
point of the Novell filesystem. Having the host OS provide this
support as another kind of "vnode" makes it available to the entire
system, not just to apps running under Wabi. 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.
If your host OS does not provide this capability as part of its
core, you may still be able to obtain it as an extension, possibly
as custom software or from a third party.
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 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 support the NetWare API calls?
A: No, Wabi 1.x 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: Will the NetWare API be supported in Wabi 2.0?
A: The NetWare API calls will not be directly supported by Wabi 2.0.
Access to files and execution of program stored on a Novell server
will be largely the same in Wabi 2.0 as in Wabi 1.x.
Note there's no connection between being able to access files that
are stored on a Novell server and supporting the NetWare API.
Q: Will the NetWare Client be one of the SST-certified apps for Wabi 2.0?
A: No, the NetWare Client will not be one of the SST-certified apps for
Wabi 2.0.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: ODBC
Keywords: ODBC SLQ driver DLL database access DBMS client server
X-Applies-To:
X-Source-Info: File--odbc.txt Version--1.1 Date--94/05/11
Q: What is ODBC?
A: ODBC stands for Open Database Connectivity.
ODBC is an API.
ODBS's intention is to allow MS-Windows-based clients to interact
generically with a database server without knowing exactly which
DBMS system the server is running.
Q: What's the architecture of ODBC?
A: ODBC is a component of Microsoft's Windows Open Services
Architecture (WOSA), like printing. Apps call a generic API, which
is probably implemented in the same DLL as the Driver Manager.
Those calls are in turn routed to the appropriate device-specific
(in this case database-specific) driver. ODBC drivers come in files
named *.DLL.
Beyond these broad outlines, the architecture is up to each database
vendor. For example, some drivers are implemented as a single *.DLL
that calls a network API directly. Other drivers are implemented as
a translation layer that pass the calls to a native API (a library
of proprietary functions) that in turn calls a network API.
Q: What are possible competitors to ODBC?
A: Other standards and products in this same area of enabling
multidatabase applications development include IDAPI, Glue, QELIB,
and SAG.
Q: When was the ODBC standard published?
A: ODBC 2.0 was announced in September 1993. The total number of
distributed and downloaded copies of the ODBC SDK was approximately
9100 by September 1993. ODBC is still a relatively new phenomemon.
Q: Does Wabi 1.x support ODBC?
A: ODBC sits between an app and a networking API. Since Wabi 1.x
supports neither app versions that use ODBC nor a networking API,
it's not meaningful to ask whether or not Wabi 1.x supports ODBC.
Q: Will Wabi 2.0 support ODBC?
A: Because of the wide variety and immaturity of ODBC implementations,
it's not possible to state categorically either that Wabi 2.0 does
support ODBC or that it doesn't.
To determine whether or not a specific configuration will run under
Wabi 2.0, ask these questions:
1) Will Wabi 2.0 support an ODBC Driver Manager?
An ODBC Driver Manager, which will be implemented as a *.DLL,
will almost certainly run under Wabi 2.0. No specific capabilities
are needed beyond driver loading and unloading, something that
Wabi already does to support printing.
2) Will Wabi 2.0 support an implementation of the ODBC API?
The implementation of the ODBC API will probably reside in the
same *.DLL as the ODBC Driver Manager. Such a *.DLL should
execute correctly under Wabi.
3) Will Wabi 2.0 support the network API that a particular ODBC
driver needs?
Wabi 2.0 will support both the WinSock network API and the
NetBIOS network API (NetBIOS over TCP/IP, RFC 1001/1002). If a
particular ODBC driver can use one of these network APIs, it
should execute correctly under Wabi 2.0.
Q: How do I find out about the availability of and requirements of ODBC
drivers to access particular database servers?
A: Ask the database ISV.
Q: How do I find out whether or not an app can use ODBC?
A: See the app's documentation.
Q: How do I configure an app to use ODBC?
A: See the app's documentation. Don't be too surprised if configuring
an app to use ODBC turns out to be either moderately difficult or
poorly documented.
Q: What should I watch out for?
A: The ODBC spec provides for three levels of conformance and five
levels of transaction isolation. Different database systems may
exhibit very different performance characteristics, and even return
different answers, when presented with the same SQL query. And
successive versions of an ODBC driver may differ significantly in
performance and correctness.
So just knowing that an app can talk to ODBC, and that a database
provides an ODBC driver, is not enough to say for sure that
particular app will work well with that particular database. This
issue of compatibility is outside the scope of Wabi itself.
Nevertheless it's something you should be aware of.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: MS-Office
Keywords: bundle MS-Office SHARE.EXE MS-Word6.0
X-Applies-To:
X-Source-Info: File--office.txt Version--1.3 Date--94/04/14
Q: Will MS-Office run under Wabi 1.x?
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.x.
MS-Office 3.0 contains MS-Word 2.0, MS-Excel 4.0, and MS-PowerPoint
3.0 which are all SST-certified to install and run correctly under
Wabi 1.x. MS-Office 3.0 also contains the client part of MS-Mail,
which does run imperfectly under Wabi 1.x although it is not a
certified 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. The separate
installation procedures, which are the same as you would get with
the separate apps, are supported and definitely work.
Like MS-Office 3.0, MS-Office 4.0 contains MS-Excel 4.0 and
MS-PowerPoint 3.0, which are SST-certified to install and run
correctly under Wabi 1.x. 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.x although it is not a certified app. MS-Office 4.0
contains MS-Word 6.0, which is not certified to run under Wabi 1.x
and does not run correctly. A version of MS-Office 4.0 also
contains MS-Access 1.1, which is not certified to run under Wabi 1.x
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 at
least need to `touch ~/wabi/windows/system/share.exe`. Even then,
you may not be able to get the procedure to run. This installation
procedure, which is different than the ones that come with the
invidual products, is not certified/supported under Wabi 1.x.
Also, since MS-Word 6.0 won't run under Wabi 1.x, there's not much
point in trying to install it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: OLE/DDE
Keywords: DDE OLE OLE2 DLL object linking embedding dynamic data exchange
X-Applies-To:
X-Source-Info: File--oledde.txt Version--1.2 Date--94/05/10
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 make this happen Wabi 1.x depends on having the
DDE/OLE *.DLLs loaded.
DDE/OLE is specifications and libraries. (*.DLLs in MS-Windows are
analogous to *.so*s in Solaris.) Wabi will execute the OLE *.DLLs
just like any other *.DLL. It's up to the apps to take advantage of
the capability. There's nothing particular about OLE that Wabi
either explicitly supports or explicitly disallows.
Q: Does Wabi include all the parts that are necessary for DDE/OLE?
A: Wabi 1.x relies on the .DLLs being provided outside Wabi itself.
Many application installation diskettes include the OLE libraries,
so it's often not necessary to purchase and install "real Windows"
to get DDE/OLE support even under Wabi 1.x. Wabi 2.0 will include
its own .DLLs so OLE will always be available no matter what
other software you have or have not installed.
Q: Does Wabi support OLE2?
A: Like DDE/OLE, OLE2 works between supported windows applications
running under Wabi. To make this happen Wabi depends on having the
OLE2 *.DLLs loaded.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: OS patches
Keywords: Solaris 2.2 2.3 x86 OpenWindows 3.2 3.3 ZX Leo panic UFS_HOLE WinSock QuattroPro
X-Applies-To: Sun
X-Source-Info: File--os_pat.txt Version--1.6 Date--94/05/19
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 resetting the Volume
Manager daemon (see elsewhere in this document for more
information.)
Q: What patches other than those listed as "mandatory" for Solaris 2.3
are required for running Wabi under 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 (or file $WABIHOME/lib/fontconfig).
($WABIHOME is probably /opt/SUNWwabi.) Comment out (or change 'Y'
to 'N' on) the line that includes "Sun Microsystems, Inc.", 3300.
To comment out a line, insert a sharp ('#', also called poundsign or
numbersign) in the first column. If there's a 'Y' or 'N' in the
line, change it rather than commenting out the line.
Q: What other patches should I consider when running Wabi under
Solaris 2.3?
A: If you want to install Quattro Pro to a local disk (or have
experienced a failure "panic ... UFS_HOLE"), consider obtaining and
installing patch 101318-45 (or later rev) to SunOS.
If you have a ZX (Leo) frame buffer, consider obtaining and
installing patch 101284-05 (or later rev) to OpenWindows 3.3.
If you are experimenting with WinSock support in a future version of
Wabi, consider obtaining and installing patch 101429-02 (or later
rev) to OpenWindows 3.3. The equivalent patch for OpenWindows 3.2
is 101189-01 (or later rev).
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: virtual memory pagesize other than 4KB
Keywords: virtual memory pagesize 4K 4KB 8K 8KB solbourne Sun4E Sun4/330 Sun4/370 Sun4/390 Sun4/3xx 3xx Sun4/430 Sun4/470 Sun4/490 Sun4/4xx 4xx
X-Applies-To:
X-Source-Info: File--pagsiz.txt Version--1.4 Date--94/02/09
Q: Will Wabi work on any machine regardless of hardware differences such
as virtual memory "pagesize"?
A: In theory, yes. In practice Wabi 1.0 isn't quite there yet. The Sun
version of Wabi 1.0 for Solaris 2.x as distributed only runs correctly
on hardware with a 4KB pagesize.
Q: When will I see this problem?
A: SPARC desktops and current SPARC servers have a 4KB pagesize, so Wabi
works on them.
Some older Sun4 machines have an 8KB pagesize. Sun Wabi 1.0 for
Solaris 2.x won't come up on them. You may run into this problem if
you're using one of these older machines (ex: Sun4/3xx, Sun4/4xx).
You may run into this problem if you're using a SPARCalike machine
(ex: machines from Solbourne). And you may run into this problem if
you're using an embedded SPRC system (ex: Sun4E).
If `uname -m` returns simply "sun4" (rather than "sun4c" or "sun4m"
or ...), your machine has an 8KB pagsize and you will experience
this problem.
Q: How can I know I'm experiencing this problem?
A: This problem may show up as Wabi not starting at all. Or it may show
up with a message like "Error Loading File: C:\windows\commdlz.dll,
File Read Error" or "Error Loading File: C:\windows\pwi.dll, File Read
Error" when you try to start the first application.
Q: How can I make Wabi 1.0 work on my machine despite this problem?
A: To make Sun Wabi 1.0 for Solaris 2.x execute on machines with an 8KB
pagesize, patch it as follows (0x2000 is 8K in hex; provide a
different value if your machine has a different pagesize):
su
adb -w /opt/SUNWwabi/bin/wabiprog
0x221ad0?X # s.b. 1000 (4K in hex), if not abort
0x221ad0?W0x2000 # (0x2000 is 8K in hex)
$w
$q
Note that once you do this, this copy of the executable will no longer
run correctly on machines with a 4KB pagesize. You may need two copies
of the executable, one with and one without this patch.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: UFS_HOLE panic
Keywords: UFS_HOLE panic local network disk putpage ufs nfs file systems Quattro Pro application installation
X-Applies-To:
X-Source-Info: File--panic.txt Version--1.4 Date--94/05/19
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 was partially fixed
in Solaris 2.3. Upgrade to Solaris 2.3.
If this happens repeatedly on Solaris 2.[012] and you need a
short-term fix and cannot yet upgrade to Solaris 2.3, try this
workaround. 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 the part of
the Solaris bug that isn't fully fixed yet. To work around this
problem, install the application to an NFS-mounted remote file
system rather than to a local hard disk.
Or try to obtain patch 101318-45 (or later rev) to SunOS. It should
fix this problem completely.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Wabi performance
Keywords: tuning Wabi configuration parameters swap fast performance virtual memory
X-Applies-To:
X-Source-Info: File--perf.txt Version--1.1 Date--94/01/21
Q: What can I do to make sure Wabi runs as fast as it should?
A: Make exactly the same performance tuning checks and changes with
Wabi that you would make with any other app. Have enough RAM to
avoid paging during intense system activity. Check that there's no
runaway process (ex: a background sendmail daemon gone wild)
dragging down your system. Fix apparent I/O problems (usually
caused by a too-long SCSI cable). Be sure the network your system
is connected to is working well (reasonably low collision rate, very
low CRC rate, low retry rate). Tune NFS blocksizes, attribute cache
timeouts, and use of symlinks. And so on...
Q: Are there any configuration parameters in Wabi that can have a large
impact on performance (similar to the memory amount setting in SunPC
on 4m architecture machines)?
A: No, there are no configuration parameters in Wabi that can have a
large impact on performance.
Q: My machine is connected to an overloaded, poorly maintained network.
I can't do anything about the network. What can I do to minimize the
impact of the network problems on Wabi performance?
A: Store as many files used by Wabi as you can on a local disk to avoid
accessing them over the problem network. If possible store all of
~/wabi, /opt/SUNWwabi, and /usr/openwin on a local disk.
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: 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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: printer configuration
Keywords: Configuration Manager printers lp lpr command spool
X-Applies-To:
X-Source-Info: File--prtcfg.txt Version--1.2 Date--94/04/13
Q: What's Wabi's "default" print configuration?
A: Send output through the "lp" subsystem to the same printer that
your Unix windows default to.
Q: Do I need to change Wabi's print configuration?
A: Not usually. In the usual case, Wabi prints "right out of the
box".
Q: When do I need to change Wabi's print configuration?
A: Change Wabi's print configuration only if one of the following isn't
true:
1) Your system uses the "lp" subsystem that comes with Solaris 2.x.
2) Wabi print should go to the same printer as output from your
non-Wabi windows.
3) Wabi print should be spooled just like output from your
non-Wabi windows (in other words, Wabi won't be driving a
physical printer directly).
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"
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: printer drivers
Keywords: PCL PostScript printer driver install SPARCprinter NeWSprint Generic Text
X-Applies-To:
X-Source-Info: File--prtdvr.txt Version--1.4 Date--94/05/13
Q: What kinds of printers does Wabi include drivers for?
A: Sun Wabi 1.x includes a PostScript printer driver that will drive
a couple hundred common PostScript-capable printers.
Sun Wabi 2.x will also include a PCL printer driver that will drive
most PCL (e.g. HP) printers.
Q: Does Wabi support any printer drivers other than the ones that
come with it?
A: Yes. Wabi supports the Generic/Text printer driver that comes
with MS Windows. This driver will drive most character printers.
If you Install Windows, this printer driver will be copied onto your
system and will show up in the ConfigMan:Printers list of available
printer drivers.
Q: Can I install any printer driver software I want under Wabi?
A: Wabi does not support installation of arbitrary printer drivers.
The printer driver that comes with an HPGL plotter, for example,
is not supported by Wabi and may not work correctly under Wabi.
Q: Can I copy the printer driver from a "real PC" to Wabi?
A: It depends. If the printer driver on your real PC is one of the
ones Wabi supports, it will work under Wabi. (But it's probably
already on your Wabi system, in which case there's no point in
providing another copy.)
If the printer driver on your real PC is not the exact version of
one that Wabi supports, it's not supported under Wabi and may not
work correctly under Wabi.
Q: Does this lack of support for arbitrary printer drivers under
Wabi mean that Wabi's printing capabilities are quite limited?
A: No, the printer drivers that are supported with Wabi will drive
most printers.
Wabi 1.x provides and supports the couple hundred printers 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).
And Sun Wabi 2.0 will be able to drive PCL printers as well as
PostScript printers.
Q: Can Wabi 1.x 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 that comes with MS-Windows
to print text only (no graphics) all in one font.
Q: When I select the "Generic / Text" printer driver, output is still
in PostScript. Isn't the output of this printer driver supposed to
be plain ASCII?
A: Yes, the output of the "Generic / Text" printer driver that comes with
MS-Windows should be plain ASCII.
Sometimes because of a bug we don't yet fully understand, the output
will be PostScript.
To force the output to be plain ASCII, stop Wabi, manually edit
~/wabi/windows/win.ini, and restart Wabi. On all the lines that
mention "Generic", change "adobeps" to "TTY".
If later you make a change in Tools:ConfigMan:Printers, for example
to change the default printer, this problem may recur. If it does,
you'll need to manually edit ~/wabi/windows/win.ini again.
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 Sun Wabi provide some PCL printer drivers?
A: Wabi 2.0 from SunSoft will provide PCL printer drivers.
Q: What printer driver comes with Wabi?
A: The Adobe Version 2.1 printer driver. This is the same code that's
been available for "real PCs" since fall 1993.
Q: If Wabi is compatible with MS-Windows 3.1, shouldn't the printer
driver that's included with it also be version 3.1?
A: No. There's no connection between the Adobe printer driver version
(ex 2.1) and the MS-Windows version number (ex 3.1).
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: printer problems
Keywords: diagnose printer problems print file spool debug generic swap space tmp temp
X-Applies-To:
X-Source-Info: File--prtprb.txt Version--1.5 Date--94/05/12
Q: Why would it appear that Wabi 1.0 could not print to any PostScript
printer, but only to Sun's NewsPrint?
A: Wabi 1.0 can print to any PostScript printer.
If you are having trouble printing to a non-NewsPrint printer, check
if your printers are configured to use TranScript software. Maybe
the output of the Adobe 2.1 printer driver is incompatible with
older versions of TranScript software.
Q: Why would it appear that printing works from a "real PC" but not
from Wabi?
A: Check the version of the printer driver the "real PC" is using.
If you find an Adobe printer driver with a version less than 2.1,
you're not comparing apples to apples. Possibly the problem is an
incompatibility between the newest Adobe printer driver and some
other older software.
Install a copy of the Adobe 2.1 printer driver on your "real PC" and
retest. On both the Wabi system and the "real PC", print to a
file. Except for the ^D at the top of the file produced on the
"real PC", the two files should be identical. (The ^D is needed if
the file is included inside some other document as encapsulated
PostScript.)
Q: How can I test various printer combinations without having to bring
up Wabi and bring up an app and bring up a document and format it
for printing every time?
A: Bring up Wabi and the app and a document once, and print to
a file. From then on, just use a Unix command to print the file.
Your results will be identical to what you'd get if you started Wabi
every time ...except the process will be much quicker.
Wabi passes its print output as "stdin" to the Unix command shown in
the Printer Output Connections screen. (To get to this screen, open
Tools : Configuration Manager : Printers, select the printer, and
click on Connect.) If you enter that same command to Unix with the
print file as "stdin", you'll get the same results.
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
/* or lpr on Solaris 1 */
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: Why might printing work from some apps but not others?
A: Printing can work from some apps yet fail from others if your system
is marginally short of swap (and hence /tmp) space.
Assuming /tmp is using tmpfs and hence is really part of swap, try
simply adding more swap space to your system and see if the printing
problems go away.
Use the standard administration procedures provided by your host
OS. For Solaris 2.x, standard procedures probably involve using
`mkfile` and `swap -a` and editing /etc/dfs/dfstab.
Q: Why does the printed output from my word processing application spill
over the right margin? (It spills over on the screen too if I've checked
"Fonts & Line Breaks As Printed".)
A: There's a subtle problem with font metrics in Wabi 1.0 that
sometimes causes a string of characters to seem a different length
than it really is. This problem is most evident with MS-Word when
using a TrueType font. The root problem is with rounding the width
of a character (e.g. is that 3.499 twips or 3.5 twips?).
This problem will be fixed in Wabi 1.1.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: printing speed
Keywords: printing speed document justify margin
X-Applies-To:
X-Source-Info: File--prtspd.txt Version--1.1 Date--94/01/21
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.
Another thing you can do to make printing faster is to select
a "draft" mode if the application offers one and you don't need
final copy quality.
Q: Can I speed up printing by adding "temp" space or manipulating the
Print Manager's priority?
A: Under Wabi print spooling is handled by the native Unix printing
subsystem rather than by an MS-Windows-like "Print Manager". In
Solaris 2.x the native printing subsystem is called the "lp
subsystem". The Solaris 2.x OS does automatically for the lp
subsystem what MS-Windows requires manual intervention to do for its
Print Manager. The Solaris 2.x OS provides temporary space to all
processes that need it. And the Solaris 2.x OS changes processes'
priority dynamically according to changing demands.
The temporary space and priority provided to the lp subsystem by the
Solaris 2.x OS are near-optimal. So trying to manually add temp
space or manipulate a process's priority probably won't speed up
printing and may even slow it down.
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.)
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: refresh window
Keywords: refresh window minimize close open
X-Applies-To:
X-Source-Info: File--refrsh.txt Version--1.1 Date--94/01/21
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: "root"
Keywords: userid run root guest demo system maintenance
X-Applies-To:
X-Source-Info: File--root.txt Version--1.4 Date--94/02/07
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. No matter what you do (large partitions, symlinks, etc.)
Wabi 1.0 may not even come up if you're running as "root". This
is due to a known problem in Wabi 1.0 that will be fixed in the next
release.
If Wabi 1.0 comes up even though you're running as "root", it may
still fail to execute some basic operations. Functions that test
for free disk space may get incorrect information, causing
applications to misbehave. For example the Install Windows program
may fail with a message about "...0 bytes available..." or "...you
need at least 6MB...". This mis-behavior when attempting to run
Wabi as "root" is a known problem in Wabi 1.0 that will be fixed in
the next release.
Q: Should I even attempt to run Wabi as "root"?
A: Running an app as "root" can be useful during problem isolation
since it may bypass problems with file permissions or disk space.
(This won't work with Wabi 1.0, however.)
For production use, we strongly suggest you don't run Wabi (or any
other windows-based network-aware app) as "root", for several
reasons:
1) Ownership of the data files you create will be unclear. (Is
that "root@foohost", or "root@barhost"? And who is "nobody"?).
2) Access to some NFS-mounted files may fail since by default
NFS maps the local user "root" to remote user "nobody".
3) You will not see the same problems that regular users will
see.
4) 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. (This will happen for any user for which $HOME is
"/" or "", not just for "root".)
Q: Isn't it true that most Unix apps will run as "root" even when they
won't run as a regular user? Why is Wabi the exception?
A: Older smaller independent Unix apps sometimes run as "root" even
when they won't run as a regular user. Newer larger network-aware
GUI apps typically will not run fully and correctly as "root".
(Frame for example complains "FrameServer/LiveLinks not available
because you are running as root.").
Wabi, a modern large network-aware app, is no exception.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: root menu
Keywords: launching individual applications root menu
X-Applies-To: Sun OpenWindows
X-Source-Info: File--rtmenu.txt Version--1.1 Date--94/01/21
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
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: serial port use
Keywords: serial port comm tty term newsprint COM1 COM2 local printer LPT1 cua
X-Applies-To:
X-Source-Info: File--serial.txt Version--1.3 Date--94/03/10
Q: Can another process use the serial comm ports while Wabi is up?
A: Yes. Wabi intends to open /dev/ttya (or whatever else COM1 is
mapped to) only when an app actually uses it. At other times, the
port should be free for another process to use.
Q: Can Wabi run on a machine that has a NeWSPrint printer connected
to its serial port without conflict?
A: There should be no conflict between Wabi and a local printer, not
even one connected to a serial port.
Q: What would make the serial port appear to be in use by Wabi?
A: Perhaps some app running under Wabi is opening COM1 or COM2.
Or perhaps Wabi's printer is configured to drive a local printer
directly (COM[1234]) rather than spool its output through Unix
(LPT[123]).
Q: Are there situations where Wabi 1.0 will lock up /dev/ttya the
entire time it's running even though no Wabi app is using COM[1234]
and even though the Wabi printer isn't configured to use port
COM[1234]?
A: It's been reported that Wabi 1.0 will sometimes lock up /dev/ttya
the entire time Wabi is running for no obvious reason.
We believe this happens when Wabi 1.0 is launched from an
environment that has no controlling terminal (ex: exec'ed from the X
root menu). Do `ps -ef | egrep wabi` and check that the controlling
terminal of the Wabi processes is not ttya or term/a or cua/a.
Q: How can I prevent Wabi from locking up /dev/ttya the entire time
it's running?
A: If `ps` shows that you're experiencing this problem, try changing
your root menu to say
... /opt/SUNWwabi/bin/wabi >>/dev/console 2>&1
rather than
... exec /opt/SUNWwabi/bin/wabi
Although this will slow Wabi's launch very slightly, it should make
the problem go away.
Q: Are there situations where Wabi 1.0 will attempt to access /dev/ttya
momentarily even though all references to it have been removed via
Configuration Manager?
A: Yes. Wabi 1.0 will momentarily access the default serial port even
though all references to it have been removed via Configuration Manager.
Usually this doesn't cause any trouble since the access is only
momentary and since Wabi will accept being told the port is already
in use.
Q: How can I prevent Wabi from accessing /dev/ttya at all, even
momentarily?
A: Stop Wabi, manually edit ~/wabi/windows/wabi.ini, then restart
Wabi.
In ~/wabi/windows/wabi.ini, find all references to the port you
don't want accessed, and change them all to /dev/null. Remember
that ports have several names. For example what you think of as
/dev/ttya may be called /dev/cua/a in ~/wabi/windows/wabi.ini.
Q: On Solaris 2, what's the difference between /dev/ttya and
/dev/term/a and /dev/cua/a?
A: None of significance to Wabi. Under Solaris 2 ttya and term/a and
cua/a are effectively synonymous. Some processes use one name and
other processes use another.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: sizing a central Wabi engine configuration
Keywords: performance X-terminals Viking 30MHz 40MHz 50MHz 60MHz 70MHz central server
X-Applies-To:
X-Source-Info: File--serve2.txt Version--1.3 Date--94/05/18
Q: How much memory do I need in an X-terminal to run Wabi on it?
A: The answer varies tremendously depending on which apps you're
running under Wabi.
Apps that use a very large number of fonts simultaneously will
require more memory in the X-terminal. And apps that treat the
entire screen as an image (e.g. "paint"-type apps) may require
even more memory in the X-terminal.
A starting rule of thumb is 8MB of memory in each X-terminal.
Q: Will the amount of memory in the X-terminals have any effect on
performance?
A: No. X-terminals use "real" memory rather than the "virtual" memory
used by workstations. So they either have enough memory and work,
or they don't have enough memory and fail. There's nothing in
between. Unlike workstations, adding RAM to an x-terminal will have
no effect on performance.
Q: How much can I rely on the information about Wabi in the X-terminal
Sizing Guide?
A: Note the footnote at the bottom of the first page of the Wabi
chapter in the X-terminal Sizing Guide.
The numbers in the X-terminal Sizing Guide were generated using an
app that's almost purely display-intensive, doing virtually no
computation outside that required to generate the display. Most
common productivity apps --word processors, spreadsheets, etc.-- do
more non-display computation. So you may find the numbers in the
X-terminal Sizing Guide overly optimistic if you're trying to size a
configuration that will use common productivity apps.
Q: Will I need multiple CPUs in a central Wabi engine?
A: Almost certainly yes a central Wabi engine should be a
multi-processor machine. To support enough users to justify the
administrative effort of maintaining a separate system, you will
need more than one CPU.
Q: How many active Wabi users can I have per SPARC CPU?
A: A very rough rule of thumb with common productivity apps is 4
active users per 50MHz SPARC CPU, assuming the CPUs aren't also
trying to perform other significant work (ex: NIS service) at the
same time. So for example a 4-way SS1000 could support up to 16
simultaneously active Wabi users.
Of course this will depend on the customer's performance
expectations, the details of the workload, and how much the users
"stop and think".
Q: How do I translate from active users to total users supported per
SPARC CPU?
A: It depends on the environment.
You may be able to simply do a little arithmetic with the "usage
rate" of Wabi by users. For example if a typical user uses Wabi 20%
of the time, then a SPARC CPU could support 4/20% = 20 active
users.
Of course, this reasoning breaks down if all the users sometimes use
Wabi at the same time.
A starting point --which you should then adjust to account for
application mix, usage pattern, performance expectations, etc.-- is
10 total users per SPARC CPU.
Q: Can Wabi support power users that are used to running MS-Windows
applications on high end (ex: 486-33, Pentium processor) x86
machines?
A: Current Wabi performance will probably not meet the expectations
of users that are used to running on high end x86 machines.
Q: How much RAM do I need on the central Wabi engine?
A: You need enough RAM to prevent any significant paging/swapping
activity.
With Solaris SPARC, you should have 32MB for Solaris, daemons,
occasional Unix use, and 1 copy of Wabi. And you should another
6-8MB per active Wabi user.
With Solaris x86, you should have 24MB for Solaris, daemons,
occasional Unix use, and 1 copy of Wabi. And you should another
4-6MB per active Wabi user.
Q: Can I use x86 hardware rather than SPARC hardware for the central
Wabi engine?
A: In theory using x86 hardware for the central Wabi engine will
provide better performance and responsiveness. You can have both
SPARCs on the desktops and excellent Wabi performance.
In practice, though, x86 hardware has two disadvantages.
First, good multi-processor x86 systems aren't currently widely and
easily available. So even if Wabi computed faster on a
single-processor x86, a SPARC with several CPUs in it would support
more Wabi users.
Second, the I/O subsystem of the typical x86 isn't as good as that
of a SPARC. The I/O subsystem may become saturated with only a
handful of Wabi users. So even if a multi-processor x86 system were
available, most of the CPUs would probably be wasted. This I/O
subsystem problem is sometimes noticeable even on single-CPU
systems. For example many early Pentium machines had blazing fast
compute performance but mediocre I/O performance.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Wabi on a server
Keywords: server NFS central Wabi engine DISPLAY mount wabiload rmmount Volume Manager
X-Applies-To:
X-Source-Info: File--server.txt Version--1.2 Date--94/02/08
Q: Can I install Wabi onto a central Wabi engine and then execute it
there and have Wabi's window projected back onto my desktop
machine?
A: Yes. You can execute Wabi on a central Wabi engine and use DISPLAY
to project Wabi windows onto your desktops. In fact, several users
can use the same central Wabi engine at the same time for this
purpose. Each user will have their own Wabi process.
Note that if you do this, there's no way to make Wabi 1.0's A: refer
to the floppy drive on your desktop machine. Wabi 1.0's A: always
refers to the machine where Wabi is executing, regardless of where
Wabi's windows are displayed. A suggested operational workaround
for using floppies is available.
Q: Can I install Wabi onto a file server and then NFS-mount it from
my desktop machines?
A: Yes, you can install Wabi onto a file server and NFS-mount it.
You will need to manually perform some additional installation steps
on each machine that NFS-mounts Wabi.
Q: When do you need to run the wabiload script?
A: If when you start Wabi you see the message " Warning: The Wabi
kernel driver is not installed. Run $WABIHOME/drvr/wabiload as
root to install the driver." stop what you're doing, become "root",
run the wabiload script, and try again to restart Wabi.
Q: Why do you need to run the wabiload script?
A: During installation of Wabi, a modloadable "kernel driver" was
added to the system. This driver serves two purposes, first to
fully enable Wabi's file sharing/locking capability, and second to
fully enable the Wabi<->VolumeManager interaction.
If you installed Wabi onto a file server and are NFS-mounting it
from another system, the "kernel driver" will not have been
installed on that other system. The Wabiload script copies Wabi's
kernel driver from the file server to the local system, and installs
it.
(Note: The wabiload script only installs the kernel driver. If you
installed Wabi onto a file server and are NFS-mounting it from another
system, you will need to do more than just run the wabiload script
to fully install Wabi on your system.)
Q: If I install Wabi into a file server and then NFS-mount it from
another system, what additional steps do I need to perform on that
other system?
A: If you have enough disk space around to keep a copy of the Wabi
installation CD online, or have a CD drive you can put the Wabi
installation CD in indefintely, the procedure is simple.
Simply (auto)mount the files from the server onto a client, then
have the client run `pkgadd` from the installation CD image. The
`pkgadd` is smart enough to realize the files are already in place,
and won't install them again. It will go ahead and run install
postprocessing to take care of `wabiload` volmgr config, and
classing engine update. This is exactly what you need done to
prepare the client to run Wabi.
Q: I can't keep the Wabi installation CD accessible. How can I prepare
clients to run Wabi without the whole Wabi installation CD?
A: You need to perform three (or perhaps only two) additional steps
on each desktop machine that NFS-mounts Wabi and executes it locally:
1) Per the message issued when you start Wabi, execute `wabiload`.
If you've mounted the /opt/SUNWwabi tree, you've mounted
`wabiload` too. This script installs mod-loadable kernel drivers
needed by Wabi to implement file locking/sharing and to implement
device sharing with the Volume Manager.
2) Finish installation of the Wabi<->Volume Manager link. First
rcp :/usr/lib/rmmount/action_wabi.so.1 /usr/lib/rmmount
Second add a line to /etc/rmmount.conf:
cd /etc
cp rmmount.conf rmmount.conf.orig
cp rmmount.conf rmmount.conf.tmp
vi rmmount.conf.tmp
#after Actions add--
action -premount floppy action_wabi.so.1
cp rmmount.conf.tmp rmmount.conf
If you don't do this, Wabi will not interact with the Volume
Manager correctly. You may find for example that Wabi always
reports the floppy drive is "not ready" or "in use". And you may
find that the Meta+E key doesn't work no matter what you do.
3) Optionally you may add Wabi information to your "classing engine"
so you can start Wabi apps simply by double-clicking on an icon
in the file manager. If /etc/cetables doesn't yet exist on a
client system, simply copy the whole tree from the file server:
rcp -r :/etc/cetables /etc
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: DOS/Windows file sharing and locking
Keywords: lockd NFS lock SHARE.EXE share flock install locking sharing
X-Applies-To:
X-Source-Info: File--share.txt Version--1.7 Date--94/04/19
Q: What does the DOS file SHARE.EXE do?
A: Under DOS and MS-Windows, the file SHARE.EXE contains a loadable
driver or TSR that adds file sharing and locking support to the
system. Once SHARE.EXE is loaded, all file open requests made by a
DOS or MS-Windows app for files on on local disk drives will cause a
file sharing/locking request to be issued automatically. And once
SHARE.EXE is loaded, applications can request the OS to lock a range
of bytes of a file.
Q: What does the file VSHARE.EXE do?
A: SHARE.EXE, which is implemented as a TSR (Terminate and Stay
Resident program) has been around for a long time. It's used by
DOS, MS-Windows 3.0 or 3.1 in standard or enhanced mode, and
Windows-for-Workgroups in standard mode. Windows-for-Workgroups 3.1
in enhanced mode uses a newer version, contained in file
VSHARE.EXE.
VSHARE.EXE provides equivalent functionality to SHARE.EXE.
VSHARE.EXE is written as a "Virtual Device Driver" (VxD). It is
said to be more "programmer friendly". From the point of view of an
application that just wants to make file sharing and locking calls
without caring exactly how they are implemented, VSHARE.EXE and
SHARE.EXE are identical.
Q: What if both SHARE.EXE and VSHARE.EXE are loaded?
A: Handling of this situation seems to be release-specific. Consult
Microsoft documentation for complete information.
It seems that if VSHARE.EXE finds SHARE.EXE already present, it
hides SHARE.EXE and takes over its functions just as though
SHARE.EXE had never been present. If later VSHARE.EXE is unloaded,
it restores SHARE.EXE to its former state.
Q: Is there something analogous to file SHARE.EXE in Windows NT?
A: Like Wabi, Windows NT does not carry around its file sharing and
locking implementation in a separate file. File sharing and locking
is integral to Windows NT just as it is to Wabi.
Q: Do I need SHARE.EXE (or VSHARE.EXE) on my Wabi system?
A: No. Wabi's file sharing and locking support is fully integrated
into Wabi itself rather than being implemented in a separate
driver. So Wabi doesn't need a separate file. (In fact, Wabi
wouldn't and couldn't use it even if it existed.)
Q: How should applications test for the availability of file
sharing/locking?
A: In article Q72744 from Microsoft they say:
To determine under enhanced mode Windows whether SHARE is installed,
call Interrupt 21h Function 5Ch to lock a region of a file. This
function is available only when SHARE is installed, and unlike using
the OpenFile function with sharing modes, the lock region function
always fails with error 1 (invalid function) if SHARE is not
loaded. Perform the following six steps to determine whether SHARE
is loaded:
1. Create a temporary file using MS-DOS Interrupt 21h Function 5Ah.
2. Lock a region of the returned temporary file using MS-DOS
Interrupt 21h Function 5Ch. Set AL = CX = DX = SI = 0 and DI = 1.
3. If the call in step 2 returns with the carry flag set and AX = 1,
SHARE is not loaded. Move to step 5.
4. SHARE is loaded. Unlock the region of the file using MS-DOS
Interrupt 21h Function 5Ch. Set CX = DX = SI = 0 and AL = DI = 1.
5. Close the file using MS-DOS Interrupt 21h Function 3Eh.
6. Delete the file using MS-DOS Interrupt 21h Function 41h.
Note that the drive on which the temporary file is created is
important in a network environment. Typically, SHARE is always
loaded for network drives; however, a copy of SHARE is running on
the server, not on the workstation. Therefore, the application
should run the test above against the drive(s) from which it will
access files.
Q: Can I test for the presence of file locking/sharing functionality
by calling INT2Fh FUNC10h SUB00h?
A: In theory, yes, this is a way to test for the presence of
file locking/sharing functionality. It's common to have code
something like this:
union _REGS inregs, outregs;
inregs.x.ax = 0x1000;
_int86 (0x2f, &inregs, &outregs);
if (outregs.h.al == 0xff) ...
But in practice this often won't work.
This method always returns true in enhanced mode Microsoft
Windows version 3.0 even if the SHARE is not loaded.
This method always returns false with Wabi 1.0 or Wabi 1.1.
(Wabi 2.0 will return 0xFF.)
If the drive of interest is a network drive, the return from this
method bears little relationship to whether or not file
locking/sharing is available on that drive. The presence of
server-side file locking/sharing functionality on the remote system
matters more than the presence of client-side SHARE on the local
system.
Q: Why does the INT2Fh FUNC10h SUB00h method always return true under
MS-Windows 3.0?
A: Windows returns true for Interrupt 2Fh Function 1000h to prevent
SHARE from installing itself in a MS-DOS virtual machine (VM) under
Windows. If SHARE installed a local copy in a VM, the system would
become unstable and data corruption on the hard drive(s) might
result.
Q: What if an app running under Wabi 1.0 or Wabi 1.1 complains that
SHARE.EXE is not available?
A: Wabi 1.0 and Wabi 1.1 respond incorrectly to the INT2Fh FUNC10h
SUB00h test. So an app that's using this test may think
locking/sharing isn't available. (Apps really shouldn't use this
method to test, but some do.) In this situation an app may simply
copy the words from the MS manual as error message text. This text
misleadingly refers to the actual file SHARE.EXE.
The real problem is not that this file doesn't exist or hasn't been
executed. Attempts to locate or execute a copy of the file won't
solve the problem. The real problem is that Wabi returned an
incorrect answer to the app's query about whether or not
locking/sharing functionality is available locally.
Q: What if an application installation procedure insists that a file
called SHARE.EXE exists on my system?
A: Some application installation procedures insist either that the file
SHARE.EXE exist or that it appear to be executed in your
AUTOEXEC.BAT or loaded in your CONFIG.SYS. To satisfy these
installation procedures, `touch ~/wabi/windows/system/share.exe`.
Also if necessary add a line invoking or specifying SHARE.EXE to
~/wabi/autoexec.bat or ~/wabi/config.sys.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Wabi file sharing and locking
Keywords: lockd NFS lock SHARE.EXE share flock locking sharing rpc drives checkbox modload kernel driver wabiload flags
X-Applies-To:
X-Source-Info: File--shrlck.txt Version--1.7 Date--94/04/22
Q: What file sharing and file locking functionality is provided by Wabi?
A: Wabi includes the same file sharing functionality that you would get
under MS-Windows by loading the additional DOS driver SHARE.EXE.
All the file and record locking options on all API calls work 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.
Q: What's the difference between "file locking" and "file sharing"?
A: File sharing prevents apps from running into each other. If enabled
with DriveFlags.X=Sharing in wabi.ini (in the future with the Sharing
check box in Tools:ConfigurationManager:Drives), file sharing happens
no matter what the apps do or don't do. File sharing is checked at
the time the file is opened, and works only on whole files. Apps can
control its operation with a parameter to the OpenFile() call.
Sharing is enforced on all files even if apps don't do anything
special. Apps can control the level of file sharing by specifying
OF_SHARE_COMPAT, OF_SHARE_DENY_NONE, OF_SHARE_DENY_READ,
OF_SHARE_DENY_WRITE, or OF_SHARE_EXCLUSIVE on their call to
OpenFile(). This functionality notifies the user of files already in
use, and prevents inadvertent simultaneous updates to a file by two
apps.
File locking happens only if an app calls it explicitly by passing
the handle of an open file to _locking() or DOS3Call(0x5C). It
works on byte ranges. Byte ranges usually specify an individual
record, sometimes specify a whole file, and may specify anything
else -- including bytes that don't exist in the file. If an app
requests file locking, it will happen no matter how Wabi is
configured (unless you set WABI_NOLOCK).
Some applications don't use file locking at all. Some lock files only
if they're on what appears to be a "network" drive (Wabi drives by
default do not appear to be "network" drives). And some applications
(Excel is the premier example) lock all files no matter what.
Q: What do apps use file sharing for?
A: Apps use file sharing to get information. They use it to be sure no
other app has the same file open at the same time without both apps
being aware of it.
File sharing does not guarantee the apps will work correctly. If
two apps knowingly both open the same file at the same time, it's up
to the apps to work correctly. File sharing doesn't guarantee the
apps will work correctly. It doesn't even help the apps do what
they need to to work correctly.
Q: What do apps use file locking for?
A: Apps use file locking for the nitty-gritty implementation of making the
system work correctly when more than one app is changing the same file
at the same time.
File locking isn't needed much on a single system since MDI (multiple
document interface) usually obviates the need to run more than one
copy of any one app at the same time.
File locking is very necessary on a network. As apps are enhanced
to work correctly and usefully under MS-Windows-for-Workgroups, they
start making extensive use of file locking. MS-Word 6.0, for
example, is reputed to set over 500 file locks in some situations.
Q: How do I enable Wabi's file sharing functionality? (The sharing
checkbox in Tools:ConfigurationManager:Drives doesn't seem to do
anything.)
A: Turn on Wabi's file sharing functionality separately for each drive
letter (rather than all at once as with SHARE.EXE). It's off by
default, both to be as similar to real Windows as possible and for
better performance. (SHARE.EXE isn't loaded by default by real
Windows. If you want it you have to explicitly load it, usually with
an entry either in AUTOEXEC.BAT or in CONFIG.SYS.)
In Wabi 1.0 the Sharing Enabled check box in
Tools:ConfigurationManager:Drives doesn't work right. Turning it on
does nothing useful; it may show checked on drives where file
sharing has not actually been enabled; it may not show checked on
drives where file sharing has been correctly enabled. To enable
file sharing for a particular drive in Wabi 1.0:
a) stop Wabi
b) edit ~/wabi/windows/wabi.ini
in the last section [Common Settings] add
DriveFlags.X=Sharing
^-whatever drive letter
(note spelling is "Sharing", not "Share")
c) restart Wabi
In Wabi 1.1 the Sharing Enabled check box in
Tools:ConfigurationManager:Drives works correctly. It will
automatically modify your wabi.ini.
Q: Rather than pick which drives I want to be set up for sharing, why
don't I just enable sharing for *all* drives?
A: Using a drive with sharing enabled has an additional performance
penalty -- Wabi must check the sharing status with the remote
rpc.lockd for ALL file opens on that drive, regardless of whether or
not the particular application intended to use Sharing when it opened
its given file. As this involves an additional RPC call and return,
this can cause a noticeable delay on busy networks or with saturated
servers.
Note that this is very different from file locking. In the case of
file locking, you only perform the RPC call to the remote lock daemon
if your app has explicitly made a locking call.
Q: How is file sharing and file locking implemented by Wabi?
A: All Wabi file locking operations are converted to Unix/Posix
requests for advisory exclusive (read-write) locks on an open file
through lockf()/fcntl(). If the file is remote, the host OS will
forward this request to the remote system through the lock daemon
and the original part of the ONC file locking RPC protocol.
All Wabi file sharing operations are converted to requests sent
directly to the lock daemon on the machine where the file resides
using the extensions added to the file locking RPC protocol in
version 3. Because there is no library or kernel interface to this
functionality, Wabi generates its own RPC and sends it to the
machine where the file is stored.
Q: Do MS-Windows-based apps make any file locking/sharing calls that
can't be exactly mapped to Posix/ONC equivalents?
A: Almost all DOS/Windows file locking/sharing calls map exactly to
Unix/Posix semantic equivalents. (Of course internal encodings of
various values differ. For example a request to lock "to EOF" will
appear inside DOS/Windows with length=-1, and inside Unix/Posix with
length=0.)
There are two cases where the mapping isn't perfect. Both are
detected and specially translated by Wabi so they work correctly.
Recent versions of some MS-Windows-based apps (none of the versions
SST-certified to run under Wabi 1.x) sometimes make lock requests
for byte ranges far beyond the actual range of the file. While DOS
uses unsigned (32 bit) quantities to specify file positions, the
ONC/RPC lock protocol uses signed (31 bit) quantities. When a
request that would overflow a signed long is found, the next version
of Wabi will translate the request to lock a range of bytes starting
at 0x7fffffff with a length of 1.
DOS file sharing specifies 5 possible kinds of share: COMPAT,
DENY_NONE, DENY_READ, DENY_WRITE, and EXCLUSIVE. The ONC/RPC file
locking/sharing protocol supports 4 kinds of share: deny_none,
deny_read, deny_write, and deny_read_write. Four of these types of
sharing map exactly. The DOS COMPAT type of sharing is translated
to ONC/RPC deny_none.
Q: Could a problem with file locking affect file sharing?
A: In theory file locking and file sharing are unrelated.
In practice, the implementation of file sharing in Wabi 1.x also
makes some hidden file locking calls in order to control NFS
client-side caching. If one of these locking operations fails, the
entire share operation may be reported as failing.
And of course file locking and file sharing use the same RPC
protocol and are implemented by the same daemon process. So a
temporary failure of one of them will often be accompanied by a
temporary failure of the other.
Q: How can I trace file sharing/locking activity in the course of
isolating a problem?
A: One possibility is to use the debug options on `lockd`.
Another possibility is to arrange your test so all the files are on a
remote system, and then run `snoop` to capture the transactions as
they traverse the network. Snoop's decoding of lockd RPCs is quite
good.
`Truss` is not a useful tool for tracing file sharing/locking, since
locking activity probably looks like nothing more than a bunch of read
and write operations on a socket. Even if you could normally identify
locking activity, you might miss most of Wabi's activity since in many
cases Wabi directly generates and handles the RPC call to a remote
lock daemon.
Q: How do the file sharing and file locking operations done by Wabi mesh
with the file locking operations done by Solaris or by PC-NFS?
A: Wabi, Solaris, and PC-NFS (and any other NFS-compatible system) all
use the same RPC file locking service. So all the locks set by one
system are seen and honored by the other systems.
Q: What does the environment variable WABI_NOLOCK do?
A: If the environment variable WABI_NOLOCK exists when Wabi is started,
it disables all file sharing and all file locking no matter what
configuration options you've selected and no matter what calls
applications make. All returns to the application act as though the
share or lock request succeeded, when in fact nothing was even
attempted.
So `setenv WABI_NOLOCK 1` only in emergency situations where you need
to get a demo working or isolate a problem. Don't ever set this
variable from a script since you might forget it. If it's
inadvertently left defined --even with a value other than 1 or an
empty value-- all file sharing and file locking will be disabled with
no notice or obvious symptoms.
Q: Do I need to do anything special to the Solaris kernel when I install
Wabi for file sharing to work?
A: Wabi needs two privileged hooks into the kernel, one to make file
sharing work right in all combinations of local and remote files,
the other to make coexistence with the Volume Manager as user
friendly as possible. Wabi implements these two privileged hooks by
installing a kernel driver. Installation and activation of this
kernel driver is done by the script `wabiload` (probably
/opt/SUNWwabi/drvr/wabiload). Installation and activation of this
kernel driver requires "root" access to the machine.
If Wabi is installed separately on each machine, `pkgadd` notices that
"root" access is required, verifies with the user that this is okay,
then runs `wabiload` as part of the installation of the Wabi package.
So by the time a user tries to run Wabi, Wabi's kernel driver is
already in place and everything works.
If however Wabi is installed only on a file server and then `mount`ed
to individual machines, Wabi's kernel driver must be installed and
activated on every machine that might run Wabi. If you start Wabi on
a machine that doesn't have the kernel driver installed and activated
yet, you will receive a message "Warning: the Wabi kernel driver is
not installed." Stop Wabi and install the kernel driver before trying
again. Otherwise all of Wabi's file sharing will be bypassed.
Q: Why does Wabi's implementation of file sharing require a "kernel
driver"?
A: In order to construct its own RPCs for file sharing, Wabi needs to
know the network-wide file handle (the NFS "magic cookie"). This
information is available only inside the kernel (and thence to
"root"). Wabi uses its kernel driver to get this information it
needs to construct RPCs for file sharing.
Q: If I run without Wabi's "kernel driver" installed, what happens
to file locking and sharing?
A: If you run without Wabi's kernel driver installed, file sharing
will be completely disabled. Apps will always be told all their
file sharing calls succeeded, even though nothing was actually
done. You will receive no indication (beyond the startup message
about the driver being missing) that file sharing has been
disabled.
If you run without Wabi's kernel driver installed, file locking will
be unaffected.
Q: What dependencies does Wabi's file sharing/locking support have on its
host OS?
A: Wabi's file sharing and locking depend on the Solaris lock daemon. So
problems with a lock daemon may show up as Wabi problems. Be sure you
have the latest lockd patch on all your systems.
The recent lock bug that's most relevant to Wabi's use of locking is
bug #1142365. The fix for it, applicable to Solaris 2.3, is included
in patch 101318-21 and later revs (it's also in patch 101267-01). The
fix for it applicable to Solaris 2.2 is included in patch 100999-51
and later revs. The effect of this bug is to make the same file
appear to be two different files if one machine accesses it remotely
via NFS and the other accesses it locally via UFS. So if two systems
running Wabi both open a file on a third system via NFS, this lockd
bug shouldn't get in your way.
Q: Will operation of file sharing/locking be exactly the same under Wabi
as it is under MS-Windows? Or will there be slight differences?
A: File sharing/locking under Wabi 1.0 may not behave quite the same way
it does under real Windows. In particular, two apps running under the
same Wabi can access a file without conflict under Wabi 1.0. In this
situation, the same two apps running under MS-Windows will result in a
"...File In Use..." message. Windows.
This is because in Wabi 1.0 all file share/locks are done on behalf of
the user who owns the Wabi process, so file share/lock requests that
start out from different applications end up all appearing to come
from the same place.
This difference may make demonstrating Wabi's file sharing/locking
functionality a bit more difficult since it doesn't work in one
"simple" situation. But the situation of two apps on the same machine
on behalf of the same user wanting to protect themselves from each
other seems unlikely in the real world.
Q: Is file sharing/locking always effective?
A: For file sharing/locking to be effective with networked MS-Windows,
all systems must participate. If one system has file sharing/locking
configured out, that system will be able to access any file at any
time regardless of any locks the other systems have set.
Likewise, for file sharing/locking to be effective with Wabi, all
systems must participate. For example, suppose system foohost maps
Wabi drive J: to serverhost:/dir/subdir, and has file sharing enabled
on drive J:. Suppose further that system barhost maps Wabi drive K:
to serverhost:/dir/subdir, but does not have file sharing enabled on
drive K:. File sharing will be ineffective for both foohost and
barhost.
Since barhost, with file sharing disabled, never checks a sharing
lock, it won't notice if a Wabi app on foohost already has a file
open. And since barhost, with file sharing disabled, never sets a
sharing lock, foohost won't be aware that a Wabi app on barhost already
has a file open. So if you have file sharing enabled on some Wabi
systems for a particular filesystem, enable it on all Wabi systems
(and all PC-NFS systems too).
Q: Can I use file sharing/file locking on a DOS partition mounted with
`mount -F pcfs /dev/dsk/cNtNdNpN:X /dosdisk` under Solaris 2.1 x86?
File sharing and file locking do not work on a DOS partition mounted
under Solaris 2.1 x86. The Solaris 2.1 x86 implementation of "-F
pcfs" does not support the lock manager. Wabi is limited by this just
like any other Solaris app.
If a Wabi app does not make any file locking calls, you can set file
sharing "off" on the Wabi drive letter corresponding to the DOS
partition, and run without file sharing protection on that drive.
It's up to you to be sure two apps don't ever write to the same file
at the same time.
If an app does make file locking calls (as Excel does), you can either
disable file sharing/locking altogether with WABI_NOLOCK [not
recommended for production use]. Or you can set up a procedure to
copy the file you want from the DOS partition to a Solaris partition,
work on it with the Wabi app, then copy the modified file back to the
DOS partition. This procedure minimizes exposure to file damage from
simultaneous writes, and also keeps a backup copy of every file.
Q: How can I quickly verify that file sharing/locking under Wabi is
working?
A: To demonstrate file sharing quickly, log on to two different machines
as two different users. On each machine edit ~/wabi/windows/wabi.ini
and add the following line to the [Common Settings] section at the end
of the file:
Drive.S=/share.sample
DriveFlags.S=Sharing
On each machine,
mount -F nfs {fileserver}:/demoloc /share.sample
Start Wabi on each machine.
On one machine, start up an app (ex: Accessories:Write), create a new
file (ex: S:\foobar.wri), save the file, and exit the application.
On each machine, start up that app (ex: Accessories:Write), and open
that file (ex: S:\foobar.wri). The first open will execute as
expected. The second open will fail after displaying this message in
a dialog box: "This file is already in use. Use a new filename or
close the file in use by another application."
Q: What other problems might I run into when testing or demonstrating
file sharing?
A: MS-Write has a bug/feature that can get in the way of demonstrating
file sharing, and may even make it appear there's a problem in file
sharing when there isn't. Sometimes when you attempt to change
drive letters in MS-Write's File->Open dialog box, you'll get a
failure message "Cannot select drive X:". This problem seems to
affect only MS-Write, and seems to have something to do with both
short path names and symlinks. To avoid any possibility of this
problem, use an app other than MS-Write to test and demonstrate file
sharing.
If there's a program crash a file sever may be left thinking some
locks are still set. These stale locks can cause false
sharing/locking failures later on. There appears to be no easy way to
find out which locks are and aren't set.
Q: How can I clear stale locks if I suspect they exist and are causing
problems?
A: If you suspect stale locks are causing problems, or if you're testing
and must have a consistent starting point every time, you can do
either of two things.
You could reboot the client machines. The server notices this, and
clears all outstanding locks for those machines. This is guaranteed
to work, although it may be slower and more painful than you wish.
Or you could go to each of the client machines and execute
`/opt/SUNWwabi/bin/clear_locks {serverhost}`. This will get rid of
all existing locks owned by the machine you run clear_locks on for
files stored on the machine you name on the command line. Beware:
this will clear not only all stale locks but also all current locks,
both those belonging to Wabi and those belonging to any other process
on the machine.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: sound
Keywords: soundblaster multimedia x86 risc wav au sound
X-Applies-To:
X-Source-Info: File--sound.txt Version--1.2 Date--94/04/14
Q: Does Wabi directly support PC sound cards such as the SoundBlaster?
A: No. There's no way to plug a PC I/O card into most RISC computers.
Since the hardware doesn't exist, Wabi software doesn't support it.
Q: What about Wabi running on x86 hardware? In that case it is possible
to plug in a PC sound card. Will Wabi drive it?
A: Wabi tries to avoid special-case and hardware-dependant support. Wabi
doesn't treat the possibility of a PC sound card on x86 hardware any
differently than it does on RISC hardware.
Q: Does Wabi translate an application's instructions to a PC sound card
into instructions to Sun audio?
A: Wabi 1 will "beep" your desktop whenever an app requests it. Wabi 1
contains no support for the "multimedia extensions", and that includes
full sound.
Q: Can Wabi translate an entire PC sound *.WAV file into a SPARC sound
*.au file, so that an app could drive the Sun audio?
A: No, Wabi 1 has no way to deal with *.WAV files.
Q: What's the priority for adding sound capability to a future version of
Wabi?
A: If a future version one of the certified apps requires the use of
sound, the priority for having sound capability in Wabi will be very
high.
Q: How could a future version of Wabi possibly handle sound, given that
the X11 protocol doesn't recognize a sound device?
A: An extension to X11 to handle sound devices is in the works.
Hopefully it will be ready by the time Wabi needs it.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: available disk space
Keywords: bytes available overhead root ratio free total disk space newfs tunefs minfree metadisk
X-Applies-To:
X-Source-Info: File--space.txt Version--1.5 Date--94/05/12
Q: What should I do if Install Windows fails with the message about
"...0 bytes available..." even though I'm not running as "root" and
even though there's plenty of disk space available?
A: Try again later. This is an intermittent problem. It typically
goes away if disk space is either used or freed. We suspect it's
related to the ratio of free disk space to total disk space.
Q: Why does the available disk space reported by Wabi sometimes not match
that reported by the Unix `df` command?
A: Wabi 1.0 assumes that all disks have minfree set to the default 10%
free space. Wabi 1.0 does the calculation of available vs. total
space itself. If your disk was newfs'ed or tunefs'ed with other than
the default 10% free space, Wabi's calculation will be incorrect.
This problem will be fixed in the next release of Wabi.
To calculate the amount of disk space that Wabi 1.0 thinks is free,
execute `df` on the filesystem in question. Then calculate
("kbytes" * 0.90) - "used"
Q: Might this error in free disk space calculation be the root cause
of Wabi apps reporting insufficient file space?
A: If the number you calculated from the `df` output is small or 0 or
negative, Wabi's miscalculation of free disk space might be the root
cause of your problem. But if the number you calculated is
comfortably large, Wabi's miscalculation of free disk space is not
the root cause of your problem.
Q: Does Wabi calculate available disk space correctly on very large
disk partitions -- for example a 4GB metadisk?
A: We're not sure. There's some indication that on such very large
disk partitions Wabi will always tell its apps there's 0 bytes
available. This may be another manifestation of one of the above
problems with available disk space reporting, or it may be a
separate problem that occurs on very large disk partitions.
If this is indeed a problem, we expect that it will be fixed in the
next release of Wabi.
Q: What can I do to get an app installed under Wabi 1.0 on a very large
disk partition such as a 4GB metadisk?
A: If the app install always tells you there's 0 bytes available no
matter what, you can work around the problem by temporarily moving
your entire wabidir to another location, installing the app, then
moving it back. Once the app is installed, it should work despite
this problem.
cd $HOME
tar -cvf - ./wabi | (cd /tmp; tar -xvpf -)
mv wabi wabi.old
setenv WABIDIR /tmp/wabi
wabi
unsetenv WABIDIR
cd /tmp
tar -cvf - ./wabi | (cd $HOME; tar -xvpf -)
rm -rf wabi
cd $HOME
wabi
The new application should be there, as should everything that was
there before. If something didn't work, you made a backup of wabi's
original dir when you mv'd wabi to wabi.old. If all works out ok,
you can then rm -rf wabi.old
Note that if you're not using csh you will have to change the setenv
and unsetenv lines to reflect the proper way of setting and
unsetting your shell's environment variables.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: startup group
Keywords: startup program group initial
X-Applies-To:
X-Source-Info: File--start.txt Version--1.1 Date--94/02/21
Q: I noticed that Wabi doesn't create a StartUp program group, either
when I first start Wabi or when I install MS-Windows 3.1. Why not?
A: Wabi doesn't create a StartUp group at the end of installing
MS-Windows because Wabi avoids having features depend on whether or
not MS-Windows is installed. Even if Wabi did create a StartUp group
when installing MS-Windows, it's not clear what should be in it since
MS-Windows isn't necessarily the first thing being installed.
If you follow the suggestion suggestion of starting individual apps
from an X root menu or icons in a desktop dashboard, a StartUp group
doesn't seem very useful. In fact, you probably think of the initial
configuration of your desktop as being controlled by your X window
manager, not by Wabi.
Q: If I create a StartUp group will it pre-start apps for me just like it
does in MS-Windows 3.1?
A: Yes, If Wabi finds that a StartUp group exists, Wabi will launch the
apps in the group.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: temporary files
Keywords: C: TEMP TMP /tmp symlink environment AUTOEXEC.BAT tempfs RAM ramdisk performance files
X-Applies-To:
X-Source-Info: File--tmpfil.txt Version--1.1 Date--94/04/27
Q: Where do MS-Windows-based apps store their temp files?
A: Most MS-Windows-based apps follow the MS-Windows convention for wher
to store their temp files --even though in theory each app is free
to store its temp files wherever it likes. The MS-Windows
convention is that temp files are stored under a system-wide common
location that defaults to C:\tmp.
Q: What's the corresponding location in Wabi?
A: C:\tmp under Wabi maps to the Unix location $HOME/wabi/tmp.
Q: How can one override the default location in "real Windows"?
A: In C:\AUTOEXEC.BAT, set environment variable TEMP (or TMP) to
the full path to the desired storage location.
Q: How can one override the default location in Wabi?
A: Stop Wabi and in Unix
cd $HOME/wabi
mv tmp tmp.old
ln -s tmp
The next time you start Wabi temp files will be stored in
.
Q: Why might I want to override the default location where temp files
are stored?
A: The most common reasons for wanting to override this location are
storage management and performance.
If your home directory doesn't have much space, you may want to
override this location to reduce the amount of disk space Wabi uses
in your home directory.
If your home directory is accessed over the network, you may want to
override this location to point it to the local machine instead and
so eliminate some network traffic.
Q: Can I tell Wabi to write its temp files in the same place my host OS
(ex: Solaris) writes its temp files?
A: Yes. For example if your host OS follows the usual Unix convention
of writing temp files under /tmp, stop Wabi and in Unix
cd $HOME/wabi
mv tmp tmp.old
ln -s /tmp tmp
The next time you start Wabi, its temp files will get all the
advantages your host OS provides to temp files. For example, if
you've optimized /tmp by using a "tempfs" type file system and
having lots of RAM in your system, you can make those performance
advantages available to apps running under Wabi too. This is
analogous to instructing "real Windows" to place temp files in a
location you've set up as a ramdisk.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: TrueType fonts
Keywords: TrueType fonts type manager
X-Applies-To:
X-Source-Info: File--trutyp.txt Version--1.2 Date--94/04/14
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 SST-certified 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.x. 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.x?
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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: UDP checksums for NFS
Keywords: possible file corruption UDP checksums NFS x86
X-Applies-To:
X-Source-Info: File--udpchk.txt Version--1.2 Date--94/05/16
Q: I want to avoid any possibility of file corruption. How can I be
sure all NFS file transfers are fully protected in both direction?
A: Enable UDP checksums on both ends of the connection. (Enabling UDP
checksums on one end of the connection but not the other is not
sufficient. In fact it may provide no protection at all.)
UDP checksums enabled is the default setting for Solaris 2.x. So
the machine Wabi is executing on will probably already have UDP
checksums enabled.
Q: How can I be certain UDP checksums are still enabled on my machine?
A: Execute
ndd /dev/udp udp_do_checksum
and make sure the value displayed is "1".
Q: How can I check that UDP checksums are 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
still enabled by executing
ndd /dev/udp udp_do_checksum
If the value displayed is not "1", find out why not, fix it, and
reboot the system. (You can change the setting immediately for new
connections by executing as root `ndd -set /dev/udp udp_do_checksum
1`. But this does not change the setting for existing connections.)
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, 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"). After you've fixed the startup setting, reboot
the system.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: virus protection
Keywords: virus boot sector windows apps Unix Solaris Wabi scanner
X-Applies-To:
X-Source-Info: File--virus.txt Version--1.1 Date--94/04/07
Q: Can DOS/Windows viruses "infect" Wabi?
A: No DOS/Windows virus that we know of could infect Wabi.
Viruses that we know of either
- infect the DOS "boot sectors", or
- infect the application"loader", or
- infect DOS, or
- infect MS-Windows, or
- rely on "back doors" into MS-Windows.
None of these things can happen under Wabi.
- There are no DOS "boot sectors".
- There is no DOS.
- The application "loader" in Wabi is written in "native" instructions
and so appears as gobbledygook to a DOS/Windows virus.
- There is no MS-Windows. (Not even if you've
installed MS-Windows under Wabi. "Install Windows" installs only
some parts of MS-Windows, not including the kernel parts that a
virus would infect.)
- Wabi only implements the published MS-Windows API, not "back doors".
Q: Will common DOS/Windows virus scanning programs run under Wabi?
A: We don't know of any DOS/Windows virus scanning program that would
run under Wabi.
This is good news. Virus scanning programs look at the same "hooks"
and "back doors" that the viruses themselves use. The virus
scanning programs won't run because the "hooks" and "back doors"
aren't there. In other words, it's generally true that if virus
scanning programs won't run on a system, then the viruses it looks
for can't infect that system either.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Visual Basic/Visual C/C++
Keywords: visual basic C/C++ runtime development VBRUN100.DLL VBRUN200.DLL VBRUN300.DLL
X-Applies-To:
X-Source-Info: File--visdev.txt Version--1.3 Date--94/04/14
Q: Will Visual Basic applications run under Wabi 1.x?
A: Although Visual Basic isn't on the certified list, both our own
experiences and feedback from users indicate Visual Basic apps run
fine under Wabi 1.x. We believe although we haven't tested
exhaustively that everything in VBRUN100.DLL (or VBRUN200.DLL or
VBRUN300.DLL) works under Wabi 1.x.
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.
Q: Will Visual C/C++ applications run under Wabi 1.x?
A: Many apps developed with Visual C/C++ will run under Wabi 1.x.
The Visual C/C++ development envirnoment itself, though, does
not run under Wabi 1.x.
You should be able to 1) develop your apps under Visual C/C++ 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.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: Volume Manager
Keywords: SPARC Solaris Volume Manager CD CD-ROM floppy disk
X-Applies-To:
X-Source-Info: File--volmgr.txt Version--1.5 Date--94/04/26
Q: How does Wabi work together with the Volume Manager?
A: Wabi will work together well with the Volume Manager (provided that
Wabi is fully installed on your system). 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
notify Volume Manager of the change
To notify Volume Manager of the change, first remove any media from
the drive so Volume Manager will forget any previous state. Then,
beginning with Solaris 2.3, send a HUP signal to the daemon.
PID=`/usr/bin/ps -ef | grep /usr/sbin/vold | awk '{print $2}'`
if [ ! -z "$PID" ] ; then
/usr/bin/kill -HUP ${PID}
fi
(You may find the easiest way to be sure the Volume Manager daemon
is reset and understands your change is simply to 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: Volume Manager is continuing to act like Wabi isn't there even
though I just installed Wabi. Since the Volume Manager has already
given access to the drive to the File Manager, Wabi reports "device
not ready" when I try to access the floppy drive from Wabi. What
should I do?
A: The problem is probably that Volume Manager is "remembering" the state
of the floppy drive from before Wabi was installed. If there was
already a diskette in the floppy drive when Wabi installation was
completing, Volume Manager will not notice that Wabi has been
installed and should be given access to the floppy drive.
Remove any floppy that's already in the drive. Execute `ls -l
/vol/dev/rdiskette0` and be sure no disk name appears. Then
re-insert the floppy disk (`ls -l /vol/dev/rdiskette0` will now show
the name of the floppy).
If you want to be sure you don't get into this situation in the
first place, simply be sure the floppy drive is empty while you're
installing Wabi.
Q: How can I know that Wabi is "fully installed" on my system? Is the
mere fact that it comes up evidence enough?
A: If you did `pkgadd` of Wabi directly onto your system, Wabi is fully
installed.
If however you did `pkgadd` of Wabi onto some other system and are
NFS-mounting Wabi from your system, you will need to perform some
additional steps. Until you perform these additional steps, Wabi
and the Volume Manager probably will not work together very well.
In this situation, Wabi will come up on your system even though it's
not been fully installed.
Q: How can I find out more about what Volume Manager is doing so I can
understand and isolate a problem?
A: Turn on Volume Manager debugging output by editing /etc/vold.conf.
Change the lines that reference /usr/sbin/rmmount to include the -D
flag. For example
insert /vol*/dev/diskette[0-9].* user=root /usr/sbin/rmmount -D
Beginning with Solaris 2.3, you need to send a HUP signal to the
daemon to tell it to reread its configuration file after you've
finished editing it.
PID=`/usr/bin/ps -ef | grep /usr/sbin/vold | awk '{print $2}'`
if [ ! -z "$PID" ] ; then
/usr/bin/kill -HUP ${PID}
fi
Q: How can I disable the connection between Volume Manager and Wabi,
yet continue to have Volume Manager broker use of the floppy drive
by other apps such as File Manager?
A: To disable the floppy drive connection between Volume Manager and Wabi:
edit /etc/rmmount.conf
find the line that refers to action_wabi.so.1
comment it out by inserting a sharp ('#') in the first column
write out the new file
Q: How can I disable Volume Manager's management of the floppy disk
drive altogether?
A: If you choose to simply disable Volume Manager's ownership of the
floppy disk drive rather than letting Wabi and Volume Manager work
together, comment out the line that includes the words "...use
floppy..." in /etc/vold.conf then reset the Volume Manager daemon.
Resetting the Volume Manager daemon at least requires getting it to
release any current interest it has in the device you're trying to
change. Probably this means removing any floppy disk that's in the
drive. Beginning with Solaris 2.3, you also need to send a HUP
signal to the daemon to tell it to reread its configuration file.
PID=`/usr/bin/ps -ef | grep /usr/sbin/vold | awk '{print $2}'`
if [ ! -z "$PID" ] ; then
/usr/bin/kill -HUP ${PID}
fi
You may find the easiest way to be sure the Volume Manager daemon is
reset and understands your change is simply to reboot your system.
Q: How can I turn off the Volume Manager altogether on my system?
A: if you choose for some reason to disable Volume Manager altogether,
both immediately and after a reboot:
su
cd /etc/rc2.d
mv S92volmgt disabled.S92volmgt.save #disables VolMgt after reboot
/etc/init.d/volmgt stop #disables VolMgt immediately
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: patches to Wabi
Keywords: 0 enter 2 spreadsheet extended zero floating point
X-Applies-To: Sun
X-Source-Info: File--wabpat.txt Version--1.2 Date--94/04/14
Q: What's the problem with floating point?
A: An error in the SPARC version of Wabi 1.0 can cause a load
of a floating point extended zero to get two instead. In affected
spreadsheet apps if you entered a literal 0 (not a formula) into a
cell, the cell value would change to 2.
Q: What apps does this affect?
A: So far as we know, this only affects apps that do their internal
arithmetic in floating point, and only when they load a literal
zero. Of the 13 SST-certified apps, this problem affects only
QuattroPro and AmiPro.
Q: What versions of Wabi have this problem?
A: Only the SPARC version of Wabi 1.0 has this problem. The x86
version of Wabi and non-Sun versions of Wabi do not have the
problem. Releases of Wabi later than 1.0 do not have the problem.
Q: Is a patch available for the problem?
A: Yes, standard Sun patch 101547 (rev -01 or later) can be applied to
Wabi 1.0 and will fix this problem.
Q: Is it true that this problem caused Sun to temporarily stop shipping
Wabi?
A: After the problem was discovered, further shipments of Wabi 1.0 were
held until a follow-on version of Wabi with the fix incorporated was
available. Doing this kept the number of affected users and the
number of users that would have to apply a patch as small as
possible.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: X display types
Keywords: truecolor pseudocolor true pseudo color graphics accelerator 24 24bit default visual
X-Applies-To:
X-Source-Info: File--x24bit.txt Version--1.4 Date--94/05/25
Q: What sort of X display does Wabi require?
A: In theory, Wabi should work with any kind of X display. In theory
Wabi will begin by requesting an 8bit pseudo color visual, and
negotiating downward until it finds something available.
In practice, Wabi 1.0 requests the "default" visual. If it's an 8bit
pseudocolor visual, Wabi 1.0 uses it. If it's something less, Wabi
1.0 will use that too. If it's a 24bit true color visual, Wabi 1.0
will not work.
Wabi 1.1 does not have this problem. Wabi 1.1 always requests the
specific visual it needs (8bit pseudocolor) no matter what the
default visual is.
Q: When is Wabi 1.0's inability to run on an X server whose default
visual is 24bit true color likely to manifest itself?
A: This problem will manifest itself on high-end displays, usually those
offering 3D rendering in hardware, or unlimited simultaneous colors,
or both. For example, this problem manifests itself if you try to
display Wabi on an X dipslay that uses an Evans and Sutherland
Graphics Freedom Series Graphics Accelerator.
Q: How can I know I'm experiencing this problem?
A: You can find out if you'll see this problem without ever starting
Wabi 1.0. Use `xdisplay` to find out about your X display. If its
default visual is 24bit true color, Wabi 1.0 won't work.
If you try to run Wabi 1.0 and get a message "... bad match invalid
parameter (attributes) ...", you're probably experiencing this
problem.
Another symptom of this problem is Wabi only "half" displaying
windows. This may happen for example when displaying Wabi 1.0 on an
HP9000/735 with HP-VUE (HPUX 9.01, X11R5).
Q: How can I solve this problem?
A: The best solution is to upgrade to Wabi 1.1.
If you must use Wabi 1.0, try tweaking the X server side to change
the default visual to 8bit pseudo color. Most X servers provide
options that allow you to override the default display. For
example, for OpenWindows 3.3:
xinit -- ./Xsun -dev /dev/fb defclass PseudoColor defdepth 8
Another workaround is to run Wabi 1.0 to a different X display.
Q: What if I see this problem on a SPARC SX?
A: Most likely the openwin startup procedure has been locally
customized to explicitly specify a 24bit default visual for the SX.
If you're starting OpenWindows with a manual override something
like
openwin -d /dev/fb defdepth 24
go back to starting openwin with the defaults and Wabi should run.
Q: Upgrading to Wabi 1.1 solved the problem of getting Wabi to display
on a 24bit monitor. But now I experience other problems. What
should I do?
A: If you experience severe color flashing when displaying Wabi 1.1,
see the color setting Technicolor= in win.ini.
If you experience problems with rectangular areas not being redrawn
when you change window stacking order, see the color setting
UseRootWindow= in win.ini.
More information on both of these settings is in the color settings
section of this document.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: library problems on x86
Keywords: libm libXext x86 Solaris 2.1 2.4 EA1 EA1-a libm.so.1 libXext.so.0 math library wabifs ld.so.1 dlopen ldd not found dynamic program loader
X-Applies-To: Solaris x86
X-Source-Info: File--x86lnk.txt Version--1.3 Date--94/04/22
Q: What does the message "Can't find libm.so.1" mean?
A: Libm is the name of the Unix "math" library, which is an extension to
Unix's "stdC" library. The Wabi 1.0 font server process "wabifs"
expects to be able to find a dynamically loadable version of library,
probably in /usr/lib/libm.so.1.
The Solaris x86 "end user" cluster may not include this library.
The Wabi 1.0 main process "wabiprog" includes a statically linked
version of this library and so doesn't require that a dynamically
loadable version of the library exist on the system. In other
words, you'll only experience this problem if
i) you're running Wabi on an x86 machine, and
ii) only the "end user" Solaris cluster was installed on the x86
machine, and
iii) you're displaying Wabi windows on a machine running Solaris 2.3
(or any other Xserver that supports the font service protocol).
To fix the problem, simply load the required library down onto the
system. You can copy /usr/lib/libm.so.1 from a Solaris x86 system
that has it installed. Or you can load the Solaris "developer"
cluster onto the machine. Or you can attempt to copy just that one
file from the Solaris distribution CD onto your machine (you'll
probably prefer to use one of the other options).
Q: How can I know that I've got the right library available to Wabi?
A: When the right libm.so.1 is available to Wabi, you should be able
to run from the same environment Wabi will be started from
ldd /opt/SUNWwabi/bin/wabifs
and get a list of library references and locations that doesn't
include the words "(not found)".
Q: What does the message "Can't find libXext.so.0" mean?
A: With both Wabi 1.0 and Wabi 1.1 for Solaris x86, envronment variable
LD_LIBRARY_PATH should include the path to the X11 libraries
(probably $OPENWINHOME/lib).
The environment variable will usually be set automatically if you
run OpenWindows on a Solaris 2.1 x86 system. That version of
$OPENWINHOME/bin/openwin will set LD_LIBRARY_PATH when it starts up
the window system.
This will not happen automatically on a Solaris 2.4 x86 system, not
even if you run OpenWindows. The new version of
$OPENWINHOME/bin/openwin no longer sets the environment varable by
default. The intention is that the great majority of applications
should run without requiring any setting of LD_LIBRARY_PATH.
If you run a window system other than OpenWindows under either
Solaris 2.1 x86 or Solaris 2.4 x86, you may see this problem. You
can work around it by setting the environment variable as required
by Wabi. Almost all the time the same setting that works for Wabi
will also work for (or at least not do any harm to) other
applications. So you may want to set the environment variable
system-wide.
Q: Where should I set this environment variable?
A: This environment variable needs to be set in the parent process that
will launch Wabi. If you're launching Wabi from your root window,
one place to set it is in your openwin startup script. If you're
launching Wabi from a cmdtool, one place to set it is in your
~/.cshrc.
Q: How do I set this environment variable?
A: If the environment variable isn't yet defined, define it.
C-shell example:
setenv LD_LIBRARY_PATH $OPENWINHOME/lib
Bourne/Korn shell example:
LD_LIBRARY_PATH=$OPENWINHOME/lib; export LD_LIBRARY_PATH
If the environment variable is already defined, and doesn't yet
include $OPENWINHOME/lib, redefine it to include both its existing
value and the new value.
C-shell example:
setenv LD_LIBRARY_PATH $OPENWINHOME/lib:$LD_LIBRARY_PATH
Bourne/Korn shell example:
LD_LIBRARY_PATH=$OPENWINHOME/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
Q: Is there a way I can set this environment variable just for Wabi in
my OpenWindows root menu?
A: Yes. Use Bourne shell syntax to add commands to your
~/.openwin-menu. Change Wabi's line to look something like this:
"Wabi..." LD_LIBRARY_PATH=$OPENWINHOME/lib; export LD_LIBRARY_PATH; exec wabi
Q: How can I know that I've got LD_LIBRARY_PATH set correctly for Wabi?
A: When LD_LIBRARY_PATH is set correctly for Wabi, you should be able
to run from the same environment Wabi will be started from
ldd /opt/SUNWwabi/bin/wabiprog
and get a list of library references and locations that doesn't
include the words "(not found)".
Q: Isn't some of this due to a "dlopen()" problem in Solaris 2.4 EA1?
A: No, we no longer think so. If you find that Wabi won't run yet
`ldd` says all libraries needed by "wabiprog" can be found, please
let us know.
>From wabi1.0-questions@east.sun.com (---------------------------)
Subject: X11 and Wabi coexistence
Keywords: X11 model focus window manager
X-Applies-To:
X-Source-Info: File--x_v_win.txt Version--1.5 Date--94/04/15
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 X11 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: Do I need to do anything if I want to continue using follow-mouse
focus rather than click-to-type focus?
A: In some cases, yes. `twm` for example will continue to send your
keystrokes to Wabi even after you've moved the mouse into a different
window. To make this work, you should be able to do any one of:
- explicitly execute "Unfocus"->f.unfocus from the root menu
after you move out of a Wabi window, then move the mouse into
a non-Wabi window
- add the following to your ~/.twmrc
Button1 = m : root : f.unfocus
then explicitly hold down the Meta key and press the left mouse
button after you move out of a Wabi window, then move the mouse
into a non-Wabi window
- after you move the mouse from a Wabi window to a non-Wabi window,
explicitly execute the twm function f.focus (perhaps by clicking
the mouse button)
- reconfigure your window manager to use click-to-type focus
This issue is between the X11 window manager and Wabi. It's not
related to the X-server itself, and may occur whether you're running
MIT code or OpenWindows code or ...
Q: What window managers does Wabi work with?
A: Wabi fully supports and has been tested with `olwm` and `mwm`.
Wabi will probably work with other window managers such as `twm` and
`Mwm`, although it hasn't been tested and isn't supported.
Q: Will Wabi work with virtual ("rooms"-like) window managers?
A: With virtual ("rooms"-like) window managers such as `olvwm` and
`tvwm`, 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.
Otherwise, Wabi should work exactly the same under a virtual window
manager as it does under the corresponding non-virtual window
manager.
Q: Why doesn't Wabi interact more closely with the X11 window manager?
Is there a technical reason that prevents it from behaving like
other OpenWindows and Motif apps?
A: Architecturally, X11 and MS-Windows aren't as similar as one might
wish or expect. While X11 is fundamentally "asynchronous",
MS-Windows is fundamentally "synchronous".
Furthermore, an MS-Windows application expects to be able to
directly manipulate its geometry, stacking order, icons, etc.
without any outside interference. This is at odds with the basic
philosophy behind X Window managers. (For example, an MS-Windows
app can get a "handle" to the "non-client" area of its window and
proceed to manipulate it. What MS-Windows calls the "non-client"
area is what X11 calls the "window decoration". In X11 access to
this area is usually restricted to the X window manager.)
So far as we know, Wabi is the first system to attempt to allow two
competing window management styles to coexist.
The bottom line is that for "total" compatibility of X11 windows and
Wabi windows, X11 window managers must be Wabi-aware. We are in
contact with most X11 vendors on this issue, and hopefully someday
there will be a set of Wabi mods for most popular Window managers.
A CDE may also solve most of these problems.
Q: Do Wabi windows try to look just like they'd look on a "real PC", or
do they try to look as much as possible like the non-Wabi windows on
the same X-server?
A: Wabi windows try to look just like they'd look on a "real PC". (And
they do a pretty good job of it too. Do a side-by-side comparison
of Wabi and a "real PC" to see for yourself.)
Of course there's a downside as well as an upside. Wabi windows may
look very different than the non-Wabi windows displaying on the same
X-server. In particular the window decoration styles (border colors,
fonts, sizes, etc.) may be noticeably different.
This downside will be less of a problem in the future as OpenWindows
transitions to Motif style windows. Motif and MS-Windows are
descended from a common parent style, and appear quite similar.
>From wabi1.0-apps@east.sun.com
Subject: Supported Windows Applications
====================================================================
Wabi 1.x Supported Windows Applications
Last Updated 94/04/14 (Revision 1.14)
Windows Applications SST-Certified To Run Under Wabi 1.x
--------------------------------------------------------
(SST is SunSelecT, the creator of Wabi.)
* 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.0b
* 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
{Note: Only the exact version listed has been tested and SST-certified
to run correctly under Wabi 1.x. For information about other versions
of these apps, see the document titled 'Wabi 1.x Application-Specific
Notes For "Other" Applications'.}
Windows Applications ISV-Certified To Run Under Wabi 1.x
--------------------------------------------------------
(ISV is Independent Software Vendor, creator of an app.)
Windows Applications Rumored To Run Under Wabi 1.x
--------------------------------------------------
{Note: Users have run these windows applications extensively under Wabi
1.x and report that they work. There is however no commitment either by
Sun or by the ISV that these applications work under Wabi 1.x.}
{Note: If you've used an application extensively and think it should be
included in this list, tell us about it in an E-mail
To: wabi1.0-apps@East.Sun.COM or To: wabi1.1-apps@East.Sun.COM.}