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.}