From wabi1.0-questions@east.sun.com Subject: Wabi 1.x Knowledge Base Q&A (FAQ) Index ==================================================================== Wabi 1.x Knowledge Base Q&As (Frequently Asked Questions) Last Updated 15 Sep 1994 This is all the items in the Q&A section of the Wabi 1.x Knowledge Base, concatenated into a large file or files in email folder format for distribution. To recover the individual items, divide at each line beginning with From. Item Subject - Item Classification information about Wabi - patches related to Wabi - searching the Q&A portion of the Wabi Knowledge Base - 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 - Wabi and dxlib (BadIDChoice) - 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 - non-English keyboards - window function shortcut keys - kernel modules - app network/site licenses - monochrome displays - Wabi and Motif window manager - 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 - Unix processes - printer configuration - printer drivers - printer problems - printing speed - refresh window - "root" - root menu - color schemes - 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 overview - Volume Manager problems - patches to Wabi - X display types - library problems on x86 - X11 and Wabi coexistence - From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: information about Wabi Keywords: versions Wabi 1.0 1.1 1.x Solaris workstation vendor Sun email X-Applies-To: X-Classification: X-Source-Info: File--1info.txt Version--1.11 Date--94/09/06 Q: What versions of Wabi do these items apply to? A: These Q&A items apply to Wabi 1.0 and Wabi 1.1 (together referred to as Wabi 1.x) running under Sun's Solaris. Information about Wabi from workstation vendors other than Sun, and information about versions of Wabi other than 1.0 and 1.1, is incidental. Q: How can I contribute to this knowledge base? A: If you have a contribution, or find one of the existing items incorrect or misleading, put your comment in the body of the email you send To: wabi1.0-questions@East.Sun.COM Your input and feedback will help make these items more useful. Thanks in advance. Q: Where can I get more information on Wabi from Sun? A: For information about future versions of Wabi, ask your Sun representative. Also refer non-technical questions, such as pricing and availability questions, to your Sun representative. For technical information about current versions of Wabi, begin with the Wabi User's Guide. It's distributed on the same CD-ROM as the Wabi software. It's distributed in Answerbook form, which means it can be read on the screen, searched, or printed. Next look at the Release Notes that are included with the Wabi software. Install and start up Wabi, open the Tools group, and launch the item with the File Viewer or Write icon labeled Release Notes. To get the latest version of the entire Q&A portion of the Wabi 1.x Knowledge Base (Frequently Asked Questions) as a single large file, 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.x, and other information about applications running under Wabi 1.x, send email To: wabi1.0-apps@East.Sun.COM To ask a specific question of have an automatic program that searches for an answer to it, send email To: wabi-query@East.Sun.COM To discuss Wabi with others or ask specific questions, see Usenet news groups comp.sys.sun.apps or comp.unix.solaris. Another way to discuss Wabi with others or ask specific questions, or view and download Wabi-related files, is to get on CompuServe, Go SunSoft, and look in the Wabi & PWI section. 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 (A Wabi 1.x Knowledge Base Item) Subject: patches related to Wabi Keywords: hang crash lock fail patch openwindows 2.3 3.3 X-Applies-To: Sun X-Classification: X-Source-Info: File--3patch.txt Version--1.4 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: searching the Q&A portion of the Wabi Knowledge Base Keywords: search find searchit question csplit mail mailtool format structure keywords applies source info X-Applies-To: X-Classification: X-Source-Info: File--5srch.txt Version--1.9 Date--94/09/06 Q: How is this file structured? A: If you're looking at a single large file, it's all the items in the Q&A portion of the Wabi 1.x Knowledge Base. If you received this file via email, all the items are concatenated into a single file in a format that makes it look like a Solaris "mail folder". Each "mail message" is one item from the Knowledge Base, which contains one or more closely related Q&As. There is no particular order to the individual items in this single large file. If you're looking at individual items, there is no single large file and no structure to worry about. Each item is a separate closely related group of Q&As from the Wabi Knowledge Base. The navigation software you're using knows how to move between items. Q: How are these Q&A items formatted? A: These Q&A items are ASCII text. They have a hard return code at the end of every line so you can read them 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? A: If you're accessing the Wabi Knowledge Base via navigation software that provides a search function, just follow the navigation software's lead. If you're constructing your own search engine, the best option is to use sophisticated full text search software (ex: SearchIt or WAIS). Q: For full text search can I leave the Q&A portion of the Wabi Knowledge Base as one large file, or do I need to split it into many smaller files? A: It depends on which search software you're using. Some search software understands that a "mail folder" is really a concatenation of many shorter items. So it treats each "mail message" as a separate item even though they're all stored in one large file. In this case you can store the entire Q&A portion of the Wabi Knowledge Base as one large file. Other search software wants each group of Q&As to be split out into a separate file. Q: Is there another way to scan through the Q&A portion of the Wabi Knowledge Base besides using full text search software? A: Yes. Obtain all these Q&A items as a single large file via email, and point your mail reader at the file. (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 Knowledge Base item. You will usually be able to find the info you're interested in without having to read all the items. Q: I received the entire Q&A portion of the Wabi Knowledge Base as one large file. How can I split it into separate files? A: The file is structured as a "mail folder". So split it 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 item 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 item 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 item for? A: This line contains version tracking information useful for maintaining the Wabi Knowledge Base. 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 Q&A portion of the Wabi Knowledge Base [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: What is the X-Classification: line in each item for? A: This line indicates any restrictions on distribution of this item. Usually the rest of this line is blank, which means the item is freely distributable to anyone. Q: I received all the items in the Q&A portion of the Wabi Knowledge Base as a single large file. How can I find the beginning and end of individual items? A: When Wabi Knowledge Base Q&A items are concatenated into one file each item begins with a "From " line. Any application such as SearchIt that understands email folders will isolate the items correctly whether they're stored in one file or several files. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: address space Keywords: simulated address space memory size X-Applies-To: X-Classification: X-Source-Info: File--adrspc.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: API Keywords: Unix calls direct launches API fork file manager X-Applies-To: X-Classification: X-Source-Info: File--api.txt Version--1.4 Date--94/08/11 Q: Can applications running under Wabi call any Unix functions directly? A: No. Wabi 1.x's primary purpose is to run shrink-wrapped apps. And no shrink-wrapped app attempts to call a Unix function. Wabi 1.x 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 (A Wabi 1.x Knowledge Base Item) Subject: obtaining applications Keywords: site network license obtain application X-Applies-To: X-Classification: X-Source-Info: File--apps.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: application versions Keywords: certified 1.0 1.1 1.x applications versions X-Applies-To: Wabi 1.x X-Classification: X-Source-Info: File--appver.txt Version--1.7 Date--94/07/20 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 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.1 app information to see which version is certified and/or known to work. Then try to get exactly that version. Q: I have a "later" version of an application. What should I do to get the exact application version I need? A: Have the "later" version at hand, especially the purchase and licensing info. Then try calling the application vendor and asking them for a copy of the version you need. The application vendor's service number is probably included in the support docs shipped with the product. Q: Will an application vendor be upset if I buy a later version but then execute an earlier version? A: Almost certainly not. Most software companies don't care if you use down-level software in place of what you are licensed for. They have a big problem with using upgraded versions you didn't pay for. Check with the application vendor to be sure, though. This is not a legal opinion or ruling. Q: How can I exchange documents between PCs running MS-Word 6.0 and workstations running MS-Word 2.0 under Wabi? A: Microsoft can provide a converter program that allows MS-Word 2.x to read MS-Word 6.0 doc files. If this can be made to work, then those with nomadic or home machines running MS-Word 6.0 could easily share files with their workstations running Wabi and MS-Word 2.x. Note though that the converter program requires a DOS facility not available within Wabi 1.x itself. You may be able to use a DOS emulator such as SunPC. Or you may be able to set up one or more PCs as "conversion servers" easily accessible to Wabi systems. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: Type Managers Keywords: adobe type manager fonts X-Applies-To: X-Classification: X-Source-Info: File--atm.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: Wabi 1.0 & 1.1 status Keywords: available floating bug spreadsheet shipping CD coupon 1.0 1.1 X-Applies-To: X-Classification: X-Source-Info: File--avail.txt Version--1.4 Date--94/08/11 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 (A Wabi 1.x Knowledge Base Item) Subject: bad value error Keywords: window bad value integer range start X11 font cache X-Applies-To: X-Classification: X-Source-Info: File--badval.txt Version--1.5 Date--94/08/18 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.) Yet another theory is that some earlier problem has left the X-server in an inconsistent state. 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 log out and back in, thus forcing the X-server software to restart. Another 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... Yet 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 Yet 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 (A Wabi 1.x Knowledge Base Item) Subject: key mappings Keywords: DEC control X11 widget Motif resources XmText translations VMS DECwindows delete word end start line VAX X-Applies-To: X-Classification: X-Source-Info: File--bakde2.txt Version--1.6 Date--94/07/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. 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 (A Wabi 1.x Knowledge Base Item) Subject: BackSpace and Delete keys Keywords: numeric keypad delete del backspace erase xmodmap keysym keycode X11 left key X-Applies-To: X-Classification: X-Source-Info: File--bakdel.txt Version--1.5 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--bit32.txt Version--1.4 Date--94/07/19 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 supports 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 (A Wabi 1.x Knowledge Base Item) Subject: CD-ROM access Keywords: CD CD-ROM access mount MSCDEX.EXE Rock Ridge High Sierra File System X-Applies-To: X-Classification: X-Source-Info: File--cdrom.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) 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 X-Classification: X-Source-Info: File--color1.txt Version--1.6 Date--94/07/19 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 uses an 8-bit pseudocolor visual even if the X-server also provides 24-bit truecolor, Wabi 1.1 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: Some displays report that they have multiple colormaps available when in fact all the colormaps are reserved. When this happens, Wabi will default Technicolor to 1 even though this setting probably isn't what's desired. To force a particular value when the default isn't what you want, 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. 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 (A Wabi 1.x Knowledge Base Item) Subject: colors Keywords: colors colormap X11 technicolor xray flashing cell dithering X-Applies-To: X-Classification: X-Source-Info: File--colors.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--corfnt.txt Version--1.4 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: entering text in CorelDRAW Keywords: Corel DRAW text fonts colors X-Applies-To: X-Classification: X-Source-Info: File--cortxt.txt Version--1.4 Date--94/08/11 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 Knowledge Base [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 (A Wabi 1.x Knowledge Base Item) Subject: obtaining Wabi Keywords: card coupon media kit Solaris 2.2 2.3 December 1993 licenses lost X-Applies-To: Sun X-Classification: X-Source-Info: File--coupon.txt Version--1.4 Date--94/07/19 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: I sent in my coupon, but have not yet received a CD-ROM. How do I find out what happened to my copy of Wabi? A: If four weeks have passed since the coupon was sent in, please email the customer's accurate name and address and the date they sent in their coupon to wabi94-ship@suneast.East.Sun.COM. (note email address is different from ones published earlier). Sun's fulfillment vendors can examine their records and respond accordingly. 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 (A Wabi 1.x Knowledge Base Item) Subject: processor type Keywords: 80386 80486 80586 extended standard CPU X-Applies-To: X-Classification: X-Source-Info: File--cputyp.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: cut copy paste Keywords: cut copy paste clipboard images X-Applies-To: X-Classification: X-Source-Info: File--cutpst.txt Version--1.5 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: window decoration Keywords: borders decoration window manager X11 X-Applies-To: X-Classification: X-Source-Info: File--decor.txt Version--1.3 Date--94/08/11 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. Change the size of fonts, borders, etc. of Wabi windows the same way you would under real Windows. Most of these settings are not visible through a GUI, so you'll have to first get a book on real Windows to find out what the parameters are, and second manually edit the appropriate file. 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. Likewise under Wabi, edit C:\WINDOWS\WIN.INI (usually mapped to $HOME/wabi/windows/win.ini) to change these values. Q: Why might Wabi windows appear very different from other windows on the same X-display? A: 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 (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--dlls.txt Version--1.7 Date--94/08/17 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: Where does Wabi look for a DLL when an app references it? A: Wabi looks for DLLs in the same places in the same order as real Windows: 1) Your current working directory 2) Your "windows" directory (typically C:\WINDOWS --> ~/wabi/windows) 3) Your "system" directory (typically C:\WINDOWS\SYSTEM --> ~/wabi/windows/system) 4) The directory containing the current task's executable 5) The directories listed in your DOS PATH variable. Q: Where is Wabi's "path" set? A: Your DOS PATH is established in your C:\AUTOEXEC.BAT (usually ~/wabi/autoexec.bat) file. On startup, Wabi searches this file for DOS environment modifying lines similar to the following: PATH=C:\WINDOWS The DOS PATH used by Windows and Wabi to search for executables and DLLs is not the same as your Unix shell PATH. Q: How can I make Wabi search for DLLs that are stored in some unusual place? A: Edit your AUTOEXEC.BAT file and add that directory to the "PATH=" line. This line can be a semicolon delimited list of directories in DOS format similar to the following: PATH=C:\FOO;C:\BAR;C:\BAZ (the = is optional...) Q: Why might I get an error message about a missing DLL even though the DLL is clearly available in the right location? A: Sometimes an error message names the next DLL the app wanted to load, and not the one that couldn't be found. If this happens, there will be two error messages. The first one will always be meaningful. 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 1.x provides an alternate version of some other DLLs. 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"? A: 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 (A Wabi 1.x Knowledge Base Item) Subject: DOS applications Keywords: DOS emulator PIF icon launch X-Applies-To: X-Classification: X-Source-Info: File--dosapp.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: DOS partitions Keywords: mount DOS disk partition files X-Applies-To: Solaris x86 X-Classification: X-Source-Info: File--dosdsk.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: drive connections Keywords: Configuration Manager Drives wabi.ini connect map C: emulated hard drive X-Applies-To: X-Classification: X-Source-Info: File--drives.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: Wabi and dxlib (BadIDChoice) Keywords: window bad choice BadIDChoice invalid resource dxlib performance X11 direct XID X-Applies-To: Sun X-Classification: X-Source-Info: File--dxlib.txt Version--1.5 Date--94/07/19 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. Q: I know I'm not using dxlib, yet I get the error messages "Xlib: resource ID allocation space exhausted! Unrecoverable Error in Wabi" and "X Window System Error: BadIDChoice (invalid resource ID chosen for this connection)". What should I do? A: These messages have been seen a few times when under Wabi 1.x someone is doing very long or repetitive or complex operations, or starting and stopping many different applications. If you see this message and are sure you're not using dxlib, stop then re-start Wabi to reset the resource problem of running out of XIDs. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: ejecting floppy disks Keywords: eject floppy disk meta+e SunOS4 Solaris X-Applies-To: Sun SPARC X-Classification: X-Source-Info: File--eject.txt Version--1.4 Date--94/07/19 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. Q: When I press Meta+E to eject the floppy, for example after reading the first floppy when installing MS-Windows, Wabi exits. And sometimes my entire desktop window system exits too. What should I do? A: Most likely this is happening because the device name of the floppy drive configured into Wabi isn't quite correct. If you've changed the value in Tools:ConfigMan:Diskettes:DisketteDriveADevice, try changing it back to its original value /dev/fd0c (or /dev/diskette). You may have changed this value unnecessarily while trying to resolve a conflict between Wabi and Volume Manager. To prevent exits even if the floppy device name isn't quite correct, ensure that Wabi starts as a brand new process rather than as an exec of an existing process. While doing this will cause extra processes to appear in the `ps` display, it won't noticeably affect your system. 1) Remove the word "exec" from the last line of /opt/SUNWwabi/bin/wabi so `wabiprog` starts in a brand new process. 2) If you start Wabi from your root menu, remove the word "exec" from the line. 3) Don't start Wabi by double-clicking on it in your File Manager. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: MS-Word equation editor Keywords: fonts display garbled equation editor word fences extra X-Applies-To: X-Classification: X-Source-Info: File--eqn.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: error messages Keywords: error messages native exception signal SIGSEGV 11 D General Protection Fault X-Applies-To: X-Classification: X-Source-Info: File--errmsg.txt Version--1.5 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: common error messages related to OS version Keywords: solaris sunos error message tcp dontlinger driver 5.3 parent X-Applies-To: X-Classification: X-Source-Info: File--errors.txt Version--1.6 Date--94/07/19 Q: When might I get a message about missing the Wabi locking driver wabi.sparc.5.3.o? A: You'll get this message when you attempt to install Wabi, and when you run `wabiload`, if Wabi can't find a kernel driver to match the version of your OS. This could happen if: - you're trying to run an old pre-FCS version of Wabi under Solaris 2.3 - you're trying to run unpatched Wabi 1.1 under Solaris 2.4 - the `uname` command on your system has been modified or aliased so it doesn't return all of the standard information exactly per its manpage 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 a later version of MS-Windows (ex: 3.11 [3.1.1]) that isn't usable under Wabi 1.x. This is true no matter what the printed labels on the installation diskettes say. Wabi 1.x requires that you load exactly MS-Windows version 3.1. Later versions are almost always marked on the printed diskette labels (ex: 3.11 rather than 3.1), and usually on the box too. In a few cases, usually involving "discount" or "remainder" distribution channels, the printed diskette labels will say 3.1 even though there's a later version of software on the diskettes. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: font cache Keywords: xlsfonts font metrics cache rebuild rebuilt build X-Applies-To: X-Classification: X-Source-Info: File--fch1gn.txt Version--1.8 Date--94/08/18 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 Wabi to rebuild its font cache 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 (A Wabi 1.x Knowledge Base Item) Subject: font cache build Keywords: xlsfonts font metrics cache build default X-Applies-To: X-Classification: X-Source-Info: File--fch2bd.txt Version--1.13 Date--94/08/18 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.x for Solaris? A: One of the default font caches provided with Wabi 1.x for Solaris maches the X-windows system in Solaris 2.1 x86. The other default font cache provided with Wabi 1.x is for use with Solaris SPARC. The SPARC default font cache in Wabi 1.0 matches OpenWindows 3.2 which is part of Solaris 2.2. The SPARC default font cache in Wabi 1.1 matches OpenWindows 3.3 which is part of 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. Wabi 1.1 and later versions of Wabi do not constrain the mouse to stay within the message box while they're building a font cache. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: font cache rebuild Keywords: xlsfonts font metrics cache rebuild X-Applies-To: X-Classification: X-Source-Info: File--fch3rb.txt Version--1.9 Date--94/07/19 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 < /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 (A Wabi 1.x Knowledge Base Item) Subject: sharing floppy drive between Wabi and SunPC Keywords: floppy disk drive Wabi SunPC attach detach active use X-Applies-To: X-Classification: X-Source-Info: File--flpshr.txt Version--1.3 Date--94/07/19 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. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: Font Service Protocol Problems in X11R5 Keywords: font service protocol x11r5 x11r6 patch X-server mit distribution X-Applies-To: X-Classification: X-Source-Info: File--fntbug.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: font server Keywords: wabifs font server X11R5 TrueType displays X-Applies-To: X-Classification: X-Source-Info: File--fntsvr.txt Version--1.6 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: creating folders Keywords: directories folders create delete file manager mkdir rmdir rm X-Applies-To: X-Classification: X-Source-Info: File--folder.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: additional fonts Keywords: Adobe Type Manager PC fonts X X11 default extra additional installation X-Applies-To: X-Classification: X-Source-Info: File--fonts.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: formatting floppy disks Keywords: format floppy disk MS-Windows fdformat X-Applies-To: Sun Solaris SunOS X-Classification: X-Source-Info: File--format.txt Version--1.3 Date--94/07/19 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. 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 (A Wabi 1.x Knowledge Base Item) Subject: floating point Keywords: coprocessor x87 floating point math emulator inline RISC x86 X-Applies-To: X-Classification: X-Source-Info: File--fp.txt Version--1.4 Date--94/07/19 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. 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. 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 (A Wabi 1.x Knowledge Base Item) Subject: floating point precision Keywords: ieee strict precision 64 80 bit internal intermediate register overrun underrun WIN87EM WIN87EM.DLL X-Applies-To: X-Classification: X-Source-Info: File--fpieee.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: hardware/software requirements Keywords: SPARC x86 SunOS4 Solaris ow3_u1 X-Applies-To: X-Classification: X-Source-Info: File--hs_req.txt Version--1.4 Date--94/07/19 Q: What are the hardware/OS requirements of Wabi? A: Wabi from SunSoft will run on any machine running the current or previous version of Solaris 2. Right now that's either a SPARC machine running Solaris 2.3 (or Solaris 2.2) or an Intel machine running Solaris 2.1 (2.4 to be available soon). 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. Q: Is there a version of Wabi that will execute under Solaris 1? For example, will Wabi run on a SPARC-IPC under SunOS4.1.x ? A: No. Although they considered, it, both SunSoft and SMCC have decided not to offer a version of Wabi that will execute under Solaris 1 (also called SunOS 4). 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 in this configuration, consider using x86 hardware running Solaris 2.1 x86 as the central Wabi engine. Q: What should I do when Wabi has problems displaying its windows correctly onto a machine running Solaris 1? A: Be sure the X-server (OpenWindows) on the Solaris 1 machine is at a recent revision level. OpenWindows 3.0, which comes with Solaris 1.x, is the only X-server software available from Sun for machines running SunOS 4.x. It had many flaws that escaped attention with simple apps but showed up when it was driven by complex apps such as Wabi. Be sure to install at least the OW3_U1 jumbo patch. It's available on the SunOS 4.1.3_U1 maintenance CD (also called the Solaris 1.1.1 SunSoft Version B CD). It's also known as patch 100444. Q: 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 considering offering 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 (A Wabi 1.x Knowledge Base Item) Subject: icon overlap Keywords: SunOS4 Solaris OpenWindows X-Applies-To: X-Classification: X-Source-Info: File--icnovr.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: icons Keywords: icons groups desktop X-Applies-To: X-Classification: X-Source-Info: File--icons.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: idle looping Keywords: shared central Wabi engine share spin idle loop CPU use poll busy X-Applies-To: X-Classification: X-Source-Info: File--idloop.txt Version--1.5 Date--94/07/19 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. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: installing applications under Wabi Keywords: install application run compression speed C: share X-Applies-To: X-Classification: X-Source-Info: File--insapp.txt Version--1.10 Date--94/07/19 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.x? A: No, just the opposite. A great many apps will run fine under Wabi 1.x although their installation procedure will not run under Wabi 1.x. If installation under Wabi 1.x 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, possibly one or more *.DLL files in C:\windows\system, and possibly a section in win.ini) to a Wabi system and try to run it. Q: How can I know for sure all of the files required by an app? A: Use the DOS file attribute bit that means "modified since last full backup" to locate all files that were added or modified when an app was installed on your PC. On a real PC: Get out of Windows Type c:\dos\attrib -a *.*/s -a turns off the flag /s does it for all subdirectories Restart Windows Install the application Get out of Windows Type c:\dos\attrib *.*/s (be prepared to hit the pause key because if there is a way to keep the detail from scrolling off the screen I haven't found it...) ...or Type c:\dos\attrib *.*/s >filename (which will divert the output to a file...) Look for files that have a capital A next to them that are typically .dll or .exe files, but be aware there may be more. Copy all the new files to your Wabi system. And for all the modified files find out what changes were made and make corresponding edits on your Wabi system. 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. MS-Windows itself and PROCOMM are two examples of MS-Windows-based packages that 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. Unfortunately most packages use custom compression algorithms which are not accessible through any MS-Windows API call and hence cannot be intercepted by Wabi. When this happens Wabi has no choice but to actually execute the application's own decompression code one Intel opcode at a time. Depending on the speed of the Intel instruction interpreter, this can be rather slow. 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 (A Wabi 1.x Knowledge Base Item) Subject: sharing apps Keywords: share network networked .INI .DLL one single copy X-Applies-To: X-Classification: X-Source-Info: File--insash.txt Version--1.3 Date--94/07/19 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.x 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.x 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.x 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.x will not easily support shared apps. Q: Has Wabi 1.x been tested using any application in a "networked" configuration? A: No, Wabi 1.x has not been tested using any application in this way. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: installing MS-Windows Keywords: MS-Windows install under merge applets games starting non windows program X-Applies-To: X-Classification: X-Source-Info: File--inswin.txt Version--1.16 Date--94/08/23 Q: Are there benefits to installing "real Windows"? A: 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. 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. 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. Q: If I run "Windows Install" on a Wabi that's configured for a particular locale, must the MS-Windows diskettes I supply also be for that locale? A: Yes. If for example you've configured Wabi for the German locale, then Windows Install will expect a German version of MS-Windows. The only time you might have a problem with this if you've installed Wabi onto a file server configured for one locale (ex: USEnglish), and are mounting it from your workstation which is configured for a different locale (ex: German). When you run "Windows Install" from your workstation, Wabi will check the locale of the file server (USEnglish) against the locale of the MS-WIndows diskettes (German) and may object to the apparent mismatch with the message "Unable to initialize locale message strings". Be sure that when viewed from your workstation $WABIHOME/lib/locale/${WABI_LANG:-${LANG:-en_US}}/wabi (with the locale [WABI_LANG, LANG, en_US] being converted to all lower case) exists and is readable. And be sure that the configured locale of your workstation matches the locale of the MS-Windows diskettes you're supplying to the Install Windows program. See the appendix International Support in the Wabi User's Guide for more information on locale setting. Q: Does Wabi 1.x require a specific version of MS-Windows? A: Wabi 1.x prefers the original version 3.1 of MS-Windows, not a later version. If when you try to run the MS-Windows applets after installing them you get a message "WABI INFORMATION Starting non-windows program OK??", you've got a later version of MS-Windows. This is true no matter what the printed labels on the installation diskettes say. Later versions are almost always marked on the printed diskette labels (ex: 3.11 rather than 3.1), and usually on the box too. In a few cases, usually involving "discount" or "remainder" distribution channels, the printed diskette labels will say 3.1 even though there's a later version of software on the diskettes. Q: Won't I miss out on some functionality by using MS-Windows 3.1 rather than MS-Windows 3.11? A: No. MS-Windows 3.11 is a minor release of Windows that even most users of Windows 3.1 on a "real PC" do not need. The revision provides some updated printer and graphics-board drivers as well as some minor bug fixes. Wabi doesn't use any of the drivers except the generic print driver. The revision does not include any performance improvements or added functions. It has been stated that the main reason MS released MS-Windows 3.11 was to protect Windows from piracy. Q: I suspect the diskettes I've got are mis-labelled. How can I know for sure whether I've got MS-Windows 3.1 or 3.11? A: Use the date stamp on SETUP.EXE to tell you what you've got. Windows 3.1 --> SETUP.EXE dated 3/10/92 3:10 a.m. Windows 3.11 --> SETUP.EXE dated year 93 3.11 a.m. Q: All I can get is MS-Windows 3.11 [3.1.1]. Is there a way I can make it work with Wabi? A: Yes. Although this takes a bit more effort and time than installing MS-Windows 3.1, it is possible. To do this, you need to run a DOS application. So you will need either a "real PC" or a DOS emulator such as SunPC. 1. Copy the following 2 files off of the Windows Install Disks (LZEXPAND.DL_ and EXPAND.EXE) and put them in a directory accessable from a PC or SunPC (or your favorite DOS emulator) in a directory 2. At the DOS prompt type: C> EXPAND LZEXPAND.DL_ LZEXPAND.DLL 3. Copy the LZEXPAND.DLL to your wabi system directory. Specifically copy it to $HOME/wabi/windows/system. 4. Start up Wabi with the following command line options: wabi -Z 5. Run the Standard Windows Installer. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: interprocess communication Keywords: shared files tooltalk DDE OLE OLE2 X-Applies-To: X-Classification: X-Source-Info: File--ipc.txt Version--1.5 Date--94/07/19 Q: Is it possible for a Wabi application to communicate with a Unix application? A: An app under Wabi 1.x 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. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: non-English keyboards Keywords: dead keys accents WABI_KEYB LANG alt-graph X-Applies-To: X-Classification: X-Source-Info: File--keyb.txt Version--1.1 Date--94/08/28 Q: I have a non-English (German to be specific) keyboard. It works fine with the OpenWindows deskset and other apps. But inside Wabi neither any of the dead keys nor the alt-graph shift work. What should I do? A: In the environment Wabi is started from, set environment variable WABI_KEYB for the language you desire. Values for this variable are generally the same as for the environment variable LANG, and are also similar to the values for the locale setting in MS-Windows. A complete description of these values is given in the Wabi User's Guide (appendix B Internationalization in the Wabi 1.0 Users' Guide). Q: Why does Wabi get some things right about my keyboard, for example the different placement of some characters such as Y or Z, even though I don't yet have environment variable WABI_KEYB set correctly? A: Wabi constructs its key mapping tables using a combination of the keyboard translation table specified by WABI_KEYB and the keyboard mapping information returned by X11. X11 contributes information about the basic keyboard layout, so that will work even if WABI_KEYB isn't set. The keyboard translation table contributes information about dead keys and alternate graphics, so these require WABI_KEYB to be set correctly. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: window function shortcut keys Keywords: cut copy paste open close front back x86 minimize iconize X-Applies-To: X-Classification: X-Source-Info: File--keymap.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: kernel modules Keywords: kernel module driver modload demand extend I/O magic cookie volume manager X-Applies-To: X-Classification: X-Source-Info: File--knlmod.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: app network/site licenses Keywords: app application network site license licenses manager wrapper X-Applies-To: X-Classification: X-Source-Info: File--licens.txt Version--1.5 Date--94/07/19 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 even partially support. SoftInfo's product hasn't been eliminated yet, and there's at least one other product that merits further investigation. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: monochrome displays Keywords: monochrome grayscale black white display screen video card frame buffer openwindows 3.0 X-Applies-To: X-Classification: X-Source-Info: File--mono.txt Version--1.7 Date--94/08/09 Q: Does the term "monochrome" mean different things in the Unix world and the PC world? A: Usually yes. Most PCs have a color-capable video card/frame buffer. If you connect a non-color monitor to this, you get what's called "grayscale" in the Unix world. In the Unix world "monochrome" usually means a black and white frame buffer/video card. This configuration is uncommon in the PC world. In the PC world only a few video cards/frame buffers are truly black and white (original IBM mono card, Hercules cards). Most hardware and software configurations that are called "monochrome" in the PC world would be called "grayscale" in the Unix world. Q: Does Wabi look good on a display that would be called "monochrome" in the PC world ("grayscale" in the Unix world)? A: Yes. To see this for yourself, limit your Unix X display to non-color and run Wabi. For example, start OpenWindows as /usr/openwin/bin/openwin -dev /dev/fb grayvis then run Wabi. Q: Will Wabi run on a black and white display system? A: Like real MS Windows, Wabi will run on a system with a monochrome video card/frame buffer, but it won't look as good as on a color or grayscale display system. Q: What problems might I see if I run Wabi on a black and white display? A: Since this configuration is so uncommon in the PC world, some apps won't deal with it very well. Icons may not look good and may be hard to read, especially small detailed icons that include a drop shadow when displayed on a color screen. Common window components, for example scrollbars, that are created by Wabi whenever an app requests it may seem ugly. Again the most obvious problem area is small detailed icons that include a drop shadow when displayed on a color screen. You might be able to reduce these problems by selecting a color scheme such as "Monochrome" or "LCD Default Screen Settings" or "LCD Reversed" or "Plasma Power Saver". Note that with Wabi 1.x it may be necessary to perform some additional manual steps to permanently select a color scheme other than "Windows Default". On some X-servers with black and white monitors TrueType fonts and PC bitmapped fonts may not display correctly. You'll probably notice this problem as menus or dialogs that are blank where there should be text. This is an X-server problem that Wabi can do nothing about. If you're running OpenWindows 3.0, obtain and install Sun patch 100444-61 (or higher rev). A possible work around is to use only X11 fonts. A test program is available to help X-server vendors isolate and fix the problem in their X-server that's keeping Wabi from displaying TrueType fonts or PC bitmapped fonts correctly. It's attached to bug report 1164052. Q: Is it necessary to change the windows color scheme to run Wabi on a black and white display? A: No. So long as there aren't any overriding entries in the [colors] section of your win.ini, Wabi --like real Windows-- will provide different color schemes depending on what kind of display you're running on. This makes it possible to switch back and forth between color and monochrome displays without changing any part of Wabi's configuration. Q: What is the "color schemes=..." line in the [current] section of control.ini used for? A: This line is used by control panel functions to remember the current color scheme selection. It has no effect on the actual operation of either Wabi or real Windows. The actual operational effect on color scheme is controlled by the settings in the [colors] section in win.ini. If this section is empty, or doesn't exist, Wabi --like real Windows-- will use a "default" color scheme that's appropriate to your current display. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: Wabi and Motif window manager Keywords: Motif mwm front back focus stack order override redirect raise X-Applies-To: X-Classification: X-Source-Info: File--motif.txt Version--1.1 Date--94/06/15 Q: Are there any particular issues with Wabi running on a desktop controlled by the Motif window manager mwm? A: Yes, one. When handling front/back requests, mwm makes circulate requests only to non override-redirect windows. Since Wabi windows are marked override-redirect, they're never notified of the user's request to move to the front or the back. Without active intervention by Wabi, Wabi windows would stay wherever they were created (front or back). It could appear that non-Wabi windows would never come to the front. Q: Is this issue specific to particular X-servers, for example particular models of X-terminal? A: No, the issue is with any X-server that's running mwm. Q: How does Wabi handle moving its windows to the front or back when it's running on a desktop managed by mwm? A: If Wabi detects that the desktop it's running on is being managed by mwm, it intervenes in this simple way: - Whenever a Wabi window gets input focus, Wabi explicitly moves that window to the front. - Whenever a Wabi window loses input focus, Wabi explicitly moves that window to the back. Q: In the X11 model apps aren't supposed to need to know which window manager is controlling the desktop, and so there's no easy way to find out. How does Wabi know whether or not mwm is controlling the desktop? A: Wabi uses the method recommended by the Motif development guide for checking whether or not the window manager is mwm, which is to test for the existence of the property named _MOTIF_WM_INFO. There are only two cases where this might fail: - If mwm then exited in a way that didn't terminate the X-server, Wabi would behave as if mwm were still running. This is rare. - An "mwm-like" window manager that isn't mwm may look like Motif and behave like mwm, yet not define this property and so not be recognized by Wabi. While this is theoretically possible, we have no evidence it actually happens. Q: It appears Wabi's intervention to assist mwm with front/back requests doesn't work in Wabi 1.1. What should I do? A: The simple algorithm that worked in Wabi 1.0 was broken in Wabi 1.1. Even though it recognized that mwm was running, Wabi 1.1 would not intervene to assist with front/back requests. The most commonly reported symptom of this bug is that Wabi windows would obscure non-Wabi windows and there would be no way to get non-Wabi windows to come to the front. There is no workaround for this bug. A patch is being prepared and will be available shortly. Q: Under mwm, Wabi windows sometimes jump to the front when not requested even though I've applied the patch to Wabi. Why is this, and what can I do about it? A: Under mwm, Wabi windows come to the front whenever they get input focus (even if you have the raiseKeyFocus resource set to F so non-Wabi windows don't behave this way). So if you've selected the focus-follows-mouse model and the mouse passes through a Wabi window on the way to somewhere else, the Wabi window will get input focus and so will come to the front. To stop this from happening, either reconfigure mwm for the click-to-type focus model, or be careful not to pass the mouse through a Wabi window if you don't mean to use it. Q: Under mwm, non-Wabi windows sometimes jump to the front when not requested even though I've applied the patch to Wabi. Why is this? A: Under mwm, Wabi windows go to the back whenever they lose input focus (even if you have the raiseKeyFocus resource set to F). It looks to the user like a non-Wabi window has come to the front when what's really happened is the Wabi window has gone to the back. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: multimedia Keywords: sound video extensions multimedia API X-Applies-To: X-Classification: X-Source-Info: File--multim.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: networking support Keywords: 1.0 1.1 1.x WinSock NetBIOS IPX Novell Netware X-Applies-To: Wabi 1.x X-Classification: X-Source-Info: File--netwrk.txt Version--1.5 Date--94/07/19 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: Wabi 1.x does not support any part of any networking APIs (WinSock, NetBIOS, etc.) Q: What is WinSock? A: WinSock is an extension of the familiar Unix TCP/IP sockets networking API to make it usable under the tasking model of real MS windows. The same extensions to sockets needed under real MS windows are also needed under Wabi, for the same reason. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: message: not enough memory Keywords: not enough out of memory swap RAM sar unrecoverable error X-Applies-To: X-Classification: X-Source-Info: File--nomem.txt Version--1.7 Date--94/08/08 Q: Why do I sometimes see the message "- not enough memory!" from apps even though my system has plenty of RAM and plenty of swap space? A: Even under "real Windows" whenever an app runs into any resource limitation it will usually simply say "not enough memory" and quit. One estimate is that 90% of all occurrences of this message under "real Windows" are a result of depletion of system resources -- not a shortage of physical RAM. This is especially common in user-developed apps that may for example keep allocating new "graphics device contexts" without ever freeing the old ones. Q: Is this "- not enough memory!" condition more frequent or less frequent under Wabi than it is under "real Windows"? A: About the same. Because most Wabi operations take place in a 32-bit address space that isn't limited by a 64KB segment size, apps running under Wabi are less likely to experience a resource shortage. On the other hand, Wabi is more likely to exercise untested code paths in an app. Many "real Windows" applications whenever they run into an error they haven't seen before and aren't sure what to do 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 (A Wabi 1.x Knowledge Base Item) Subject: administering system memory Keywords: memory swap RAM resources malloc sar config.sys X-Applies-To: X-Classification: X-Source-Info: File--nomem2.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: Novell Netware interoperability Keywords: Novell Netware NFS NLM IPX client vnode network API X-Applies-To: X-Classification: X-Source-Info: File--novell.txt Version--1.8 Date--94/07/19 Q: Can Wabi access files that are stored on a Novell server? A: Yes, either if the Novell server exports those files through its NFS NLM or if the host OS provides a type "netware" file system. Either one will allow Solaris to mount the files just as though they were stored on another Solaris machine. Then Wabi will be able to map a drive letter to the mount point in the Unix file system and so see the files. Note there's no connection between being able to access files that are stored on a Novell server and supporting the NetWare API. Q: How would a host OS mount remote files from a Novell server when the Novell server doesn't have the NFS NLM installed? A: The host OS would probably include IPX/SPX streams drivers (possibly named /dev/ipx and /dev/spx), and an additional kind of file system including an extention to the `mount` command. 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. For example, although Solaris 2.4 does not include this capability bundled, one may be available from a third party and one may even appear on the Sun price list. Q: How does having NetWare files available to the host OS also make them available to Wabi? A: If the host OS can mount files into its Unix directory tree, Wabi will be able to map a drive letter to the mount point in the Unix directory tree and so see the files. So every file system type supported by the host OS (hsfs, ufs, nfs, nw, etc. etc.) is available to Wabi. Having the host OS provide support for access to NetWare files simply as another kind of file system ("vnode") makes the files available to the entire system, not just to apps running under Wabi. Q: What's the advantage of having files available to the entire system rather than just to apps running under Wabi? A: 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. The files would be visible not just to Wabi apps, but also to your Unix command line, your X11 desktop File Manager, and so forth. Q: Why not make the files available to Wabi first, and have Wabi in turn make them available to the rest of the system? A: First, the basic design of Wabi is hostOS->Wabi. Something in the reverse direction Wabi->hostOS would be contrary to this basic design, and hence could not share existing code or functionality, and hence would be difficult to implement. Second, Unix accesses to the files would probably experience a noticeable performance penalty since all their transactions would be made indirectly through Wabi. 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: Can applications running under Wabi use the Novell print service? A: As with Novell files, the recommendation is to make the Novell print service available to your entire system rather than just to apps running under Wabi. Most likely this will be implemented as a new or replacement `lp` command. Although such a feature is not bundled into the Solaris 2.4 core, you may still be able to obtain it as an extension, possibly as custom software or from a third party. - If the capability is implemented as a replacement for `lp` with the same name, apps running under Wabi will be able to direct their printout to Novell printers with no reconfiguration of Wabi. - If the capability is implemented as a replacement for `lp` with a different name, use Wabi's ConfigurationManager:Printers to Connect... logical port LPT1 to the replacement commmand rather than the default `lp`. - If the capability is implemented as a second command that accesses Novell printers while the `lp` command is still used to access Unix printers, use Wabi's Tools:ConfigurationManager:Printers to Connect... logical port LPT2 to the new commmand. Then within each app direct printout either to LPT1 to use a Unix printer, or to LPT2 to use a Novell printer. 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. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: ODBC Keywords: ODBC SLQ driver DLL database access DBMS client server X-Applies-To: X-Classification: X-Source-Info: File--odbc.txt Version--1.4 Date--94/07/19 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. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: MS-Office Keywords: bundle MS-Office SHARE.EXE MS-Word6.0 X-Applies-To: X-Classification: X-Source-Info: File--office.txt Version--1.5 Date--94/07/19 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. We have not been able to get the single unified installation procedure in MS-Office 4.1 or 4.2 to work under Wabi 1.x. The workaround `touch ~/wabi/windows/system/share.exe` gets past the initial problem. But then other problems arise for which we don't know any workaround. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: OLE/DDE Keywords: DDE OLE OLE2 DLL object linking embedding dynamic data exchange X-Applies-To: X-Classification: X-Source-Info: File--oledde.txt Version--1.5 Date--94/08/02 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. 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. OLE2 doesn't come with MS-Windows 3.1. You can expect that every app that uses OLE2 will also load the OLE2 *.DLLs onto your system when you install the app if they're not already present. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--os_pat.txt Version--1.10 Date--94/07/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 must obtain and install 101362-01 (or higher rev) "OpenWindows 3.3: Patch to fix several misc. Window Server bugs" on machines that might display Wabi windows. Rev -09 of this patch is included on the Wabi 1.1 CDROM for your convenience. This patch is included in Solaris 2.3 maintenance release 1, so if you've installed the maintenance upgrade you already have the required patch. 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.) Q: Do I need any patches to display Wabi windows on a machine running Solaris 1 (SunOS 4) while it's executing on some other machine? A: The Solaris 1 machine is probably running OpenWindows 3.0 since this is the only X-server software available from Sun for machines running SunOS 4.x. Many subtle flaws in OpenWindows 3.0 were uncovered by complex apps such as Wabi. Be sure to install at least the OW3_U1 jumbo patch. It's available on the SunOS 4.1.3_U1 maintenance CD (also called the Solaris 1.1.1 SunSoft Version B CD). It's also known as patch 100444. Q: What if I want to run Wabi and only have an unpatched version of OpenWindows 3.3 and can't locate any copy of patch 101362? A: 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 patch 101362-01 (or later rev). 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-06 (or later rev) to OpenWindows 3.3. Without this patch (or with lower revs of this patch), Wabi performance displaying on a ZX (Leo) frame buffer may be noticeably degraded. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--pagsiz.txt Version--1.5 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: UFS_HOLE panic Keywords: UFS_HOLE panic local network disk putpage ufs nfs file systems Quattro Pro application installation X-Applies-To: X-Classification: X-Source-Info: File--panic.txt Version--1.5 Date--94/07/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 (A Wabi 1.x Knowledge Base Item) Subject: Wabi performance Keywords: tuning Wabi configuration parameters swap fast performance virtual memory X-Applies-To: X-Classification: X-Source-Info: File--perf.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: Unix processes Keywords: coalesce combine process userid share memory address space X-Applies-To: X-Classification: X-Source-Info: File--proces.txt Version--1.2 Date--94/08/08 Q: How many Unix processes are there per Wabi user? A: By default one or perhaps two. Every Wabi user will always have a Unix process named "wabiprog". If the user is displaying on an X-server that supports the X11R5 font service protocol and Wabi's font server is enabled for that display, the user will also have a Unix process named "wabifs". Q: What's the relationship of the various Wabi processes? A: When you first launch Wabi a single process will be executing the Wabi startup shell script "wabi". When this script has completed its work it will "wabiprog", which will then continue using the same Unix process id. If a font server process is needed, wabiprog will a second process named "wabifs", which will be its child process. Q: What happens if a user starts two copies of Wabi on the same machine? A: The two "wabiprog" processes will recognize that they're running on behalf of the same user, and will coalesce (combine) into a single Unix process. Q: Is there a way to force two Wabi processes to remain separate even when they'd otherwise recognize each other and coalesce into a single Unix process? A: Yes, include the '-p' flag when starting Wabi to make that Wabi run as a separate process no matter what. For example: /opt/SUNWwabi/bin/wabi -p -s "X:\yourpath\yourapp.exe" Q: What are the advantages of running a separate Wabi process for each MS-Windows-based app? A: If the app corrupts memory or fails, only that app and that Wabi will be affected. Other apps running under other Wabi processes will continue to run. This can be very useful if you're testing a new MS-Windows-based app and want to remove any possibility of adversely affecting other MS-Windows-based apps. Also, each MS-Windows-based app will participate in the Unix scheduling algorithm just like any other Unix process or app. There's no reliance on a sub-scheduling algorithm inside Wabi. Q: What's the disadvantage of running a separate Wabi process for each MS-Windows-based app? A: Since the different apps running under different copies of Wabi don't share a single memory address space, links between apps don't work. Communication between apps running under Wabi's running as separate processes is only via cut/paste. Q: If I run a separate Wabi process for each MS-Windows-based app, does Wabi consume substantially more memory? A: Probably not (certainly not under Solaris 2). The hostOS treats multiple Wabi processes running separately under a single userid the same as it does multiple Wabi processes running under different userids. The hostOS will probably recognize that all the processes are using the same instructions, and arrange the memory map of each process so that all actually reference the same physical memory. Q: What happens if two different users each start a copy of Wabi on the same machine? A: The two "wabiprog" processes will see that they're running on behalf of different users, and will remain separate processes. Each of them may its own child process running "wabifs". Q: The code parts of all Wabi processes are obviously the same. How can I prevent multiple Wabi processes running on one machine from wasting memory (swap space) with many copies of identical instructions? A: You don't need to do anything explicit. The hostOS itself (Solaris) will automatically recognize that all these processes are using the same instructions. The hostOS will arrange the memory map of each process so that all actually reference the same physical memory. If a process tries to write to one of these shared pages (it probably won't), the hostOS will at that point make a private copy of the page for that process. This page mode is called "copy on write". Sharing memory pages until a write makes it necessary to provide a process with its own copy is a function of the hostOS virtual memory subsystem. It applies to all processes running under the hostOS, not just to Wabi. Q: What happens if a user starts two copies of Wabi on two different machines? A: If both machines reference the same $HOME directory for the user, both copies of Wabi will try to use the same $HOME/wabi directory at the same time. This will not work. Most likely one or the other of the copies of Wabi will either go into an infinite loop or fail. Q: Should every user use their own userid when starting Wabi even if they rlogin to a central Wabi engine and DISPLAY Wabi windows back to their desktop? A: YES! Every user should continue to use their own userid even when they rlogin to a central Wabi engine. If more than one user uses the same userid to start Wabi, then the Wabi processes may mistakenly coalesce into a single process. And files created by those Wabi's won't list the correct owner, so file access permissions checks will be incorrect (either too tight or too loose). From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: printer configuration Keywords: Configuration Manager printers lp lpr command spool paper tray size A4 command name default COM FILE LPT X-Applies-To: X-Classification: X-Source-Info: File--prtcfg.txt Version--1.5 Date--94/07/19 Q: What's Wabi's "default" print configuration? A: Format the output for a lowest common denominator PostScript printer. Then send the output through the "lp" subsystem to the same printer that your Unix windows default to. Q: What are the possibilities for routing of Wabi print output? A: There are three possibilities. 1) If port is any LPTn (Wabi is initially configured to send its print output to LPT1), the output is piped into a Unix command. 2) If port is FILE, the output is written to a disk file. 3) If port is any COMn, the output sent to that configured device driver, which is usually a serial port on your machine. Q: Do I need to change Wabi's print configuration before I'll get any output? A: Wabi usually prints "right out of the box". If Wabi won't print at all, it's unlikely that the default configuration is the problem. Changing the print configuration may obscure or compound the original problem. Q: Do I need to change printer drivers to get output in the exact format I want? A: Probably yes. Typically MS-Windows documents change appearance when you move them to a different system. They try to match their appearance to the known capabilities of the printer on the system they're on. Apps find out what the known capabilities of a printer are by asking the "printer driver". To make the information as correct and complete as possible, you should install the printer driver that most closely matches the actual capabilities of the printer. If you continue to use the "default" or "generic" printer driver, the appearance of your documents will be unnecessarily simplified. Q: When do I need to change the routing of Wabi print output? A: Change the "native print command" and "native printer name" portions of 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" Q: How do I select a particular paper tray? A: All versions of Wabi handle paper tray selection the same way "real Windows" does. They get out of the way and lets the apps talk directly to the printer. First be sure that your printer configuration matches your printer. If the printer has multiple paper trays, the correct choice of "printer driver" will pass that information along to the apps. If you haven't selected a printer driver that matches your printer, your app may not be told that the printer has multiple paper trays. Most apps provide some way to specify which paper tray you want. For example in MS-Word the dialog box you get from File->Print Setup... includes a button labeled Setup... Click that button, and you'll get another dialog box that lets you specify Paper Source. The available options depend on which printer (really which printer driver) you've chosen. Q: How do I select a particular paper size? A: Selection of paper size is handled the same way as selection of paper tray. Wabi gets out of the way and lets the apps talk directly to the printer. Q: My app doesn't list the paper sizes I expect (ex: A4) even though I know the printer hardware supports them. What should I do? A: Use ConfigurationManager:Printers to install and select the printer driver that most closely matches your actual printer. Apps rely on the information they receive from the printer driver to find out what capabilities your printer has. If you're using a printer driver that doesn't match your printer well (ex: "Default Postscript"), apps may think the printer has only one paper tray or supports only one size of paper (probably US/Letter). From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: printer drivers Keywords: PCL PostScript printer driver install SPARCprinter NeWSprint Generic Text X-Applies-To: X-Classification: X-Source-Info: File--prtdvr.txt Version--1.8 Date--94/07/25 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. 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). 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: Can Wabi print to my color SPARCprinter? A: Yes. The color SPARCprinter appears to Wabi as yet another color PostScript-capable printer. The best match to the color SPARCprinter's capabilities is probably the "QMS Colorscript 100 v49.4" printer driver. Q: Do I have to have a color printer driver configured to print in color? A: With PostScript printers, usually you don't need to configure a color printer driver just to print an existing document that's in color. If you have a color printer and you have files that already exist and simply want to print them, usually you can continue to use the same printer driver you use with a black and white printer. The app will send the color info to the printer, expecting the printer to convert the info to grayscale. Most color PostScript printers will use the original info without converting it, and will print the right thing. Q: Do I need to have a color printer driver configured to edit in color? A: It depends on the app. Most often yes you do need to have a color printer driver configured to edit in color. Typically apps ask about the printer's capabilities, and if told by the driver that the printer can't print in color, will give you a grayscale palette instead of a color palette. 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 (A Wabi 1.x Knowledge Base Item) Subject: printer problems Keywords: diagnose printer problems print file spool debug generic swap space tmp temp X-Applies-To: X-Classification: X-Source-Info: File--prtprb.txt Version--1.8 Date--94/08/11 Q: Why would it appear that Wabi 1.x could not print to any PostScript printer, but only to Sun's NewsPrint? A: Wabi 1.x 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. Q: Why might ConfigurationManager:Printers present an odd list of available printers (blackhole devnull bitbucket singularity circularfile) rather than the printers actually available from my system? A: Your system doesn't have enough swap space. ConfigMan:Printers may present this list during a swap space shortage. There may no longer be enough swap space for correct Wabi operation even though there was when Wabi started. Some of the swap space may be in use by other apps that were started after Wabi. And large print jobs may use a significant amount of space. With the "tmpfs" file system, the swap space used by processes and the /tmp space used by the print spooling subsystem share the same space. While this is more efficient, it means that if one gets used up the other will appear exhausted too. Q: What might cause the message "Wabi is unable to print your job due to a general spooling error" to appear? A: It probably means your system doesn't have enough swap space. Files are staged in /tmp during printing. And on most Sun systems /tmp is implemented as part of swap rather than as a file system on the physical disk. In this case the amount of space apps see in /tmp is the amount of unused swap space on your system. If your system doesn't have a large swap space, it won't appear to have a large /tmp, and won't be able to stage large files to a printer. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: printing speed Keywords: printing speed document justify margin X-Applies-To: X-Classification: X-Source-Info: File--prtspd.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: refresh window Keywords: refresh window minimize close open X-Applies-To: X-Classification: X-Source-Info: File--refrsh.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: "root" Keywords: userid run root guest demo system maintenance X-Applies-To: X-Classification: X-Source-Info: File--root.txt Version--1.6 Date--94/07/19 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 was fixed in Wabi 1.1. 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 was fixed in Wabi 1.1. 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 (A Wabi 1.x Knowledge Base Item) Subject: root menu Keywords: launching individual applications root menu X-Applies-To: Sun OpenWindows X-Classification: X-Source-Info: File--rtmenu.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: color schemes Keywords: control panel color scheme X-Applies-To: X-Classification: X-Source-Info: File--scheme.txt Version--1.3 Date--94/07/19 Q: How do I change Wabi to use a color scheme other than the "Windows Default"? A: If you've got "real MS Windows" installed under Wabi 1.x, bring up the ControlPanel (probably in group Main) and click on Color. Select the color scheme you want. If you're running Wabi 1.x without "real MS Windows", stop Wabi and manually edit some files. - Open file ~/wabi/windows/control.ini for editing. Choose the color scheme you want, and write down all the numbers that follow that color scheme. - In the [current] section of ~/wabi/windows/control.ini, change the "color schemes=..." line (near the top of the file) to the color scheme you've chosen. Then close the file. - Edit ~/wabi/windows/win.ini. Insert all the values for the color scheme you've chosen in the [colors] section. (Add the section if it doesn't already exist.) The numbers you wrote down are the RGB (red-green-blue) values for each of the entries in the [colors] section. These entries should be: Background=...^M AppWorkspace=...^M Window=...^M WindowText=...^M Menu=...^M MenuText=...^M ActiveTitle=...^M InactiveTitle=...^M TitleText=...^M ActiveBorder=...^M InactiveBorder=...^M WindowFrame=...^M Scrollbar=...^M ButtonFace=...^M ButtonShadow=...^M ButtonText=...^M GrayText=...^M Hilight=...^M HilightText=...^M InactiveTitleText=...^M ButtonHilight=...^M To determine the value for an entry, take the number you wrote down, make it six characters long by either by adding 0's at the left or discarding extra characters startng at the left, separate the characters into 3 pairs, treat each pair of characters as a hexadecimal number and convert it to decimal, and use the 3 resulting decimal numbers as the value for the entry. For example, if the first number is FFFF, make it six characters long: 00FFFF. Separate the characters into 3 pairs: 00 FF FF. Treat each pair as a hexadecimal number and convert it to decimal: 00 255 255. And use these numbers as the value for the entry: Background=00 255 255^M. Q: After I've selected a different color scheme, when I restart Wabi most of the colors are correct, but a few are not. For example when I select the Monochrome color scheme the next time I start Wabi the title bars of active windows are bright yellow rather than black. What should I do? A: Stop Wabi and edit ~/wabi/windows/win.ini. In the [colors] section, change entries of the form =0 0 0 to =00 00 00. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: serial port use Keywords: serial port comm tty term newsprint COM1 COM2 local printer LPT1 cua permissions asy.conf second X-Applies-To: X-Classification: X-Source-Info: File--serial.txt Version--1.8 Date--94/08/11 Q: Can another process use the serial comm ports while Wabi is up? A: Yes. Wabi intends to open /dev/term/a (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/term/a 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/term/a 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 term/a or cua/a or tty. Q: How can I prevent Wabi from locking up /dev/term/a 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/term/a 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/term/a 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/term/a might be called /dev/ttya or /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: Not much of significance to Wabi. Under releases of Solaris 2 /dev/cua/a is used for outgoing connections and /dev/term/a refers to the same port used for incoming connections. /dev/ttya is is an older style name which is preserved for compatibility. Over time all applications will be converting to the preferred names /dev/term/* and /dev/cua/*. Solaris 2 will someday drop inclusion of the older style names. Q: On my x86 system with two serial ports and running Solaris, I can access COM1 but not COM2. What should I do? A: Wabi expects the hostOS to provide support for all needed hardware devices. Solaris x86 by default expects every machine to have one serial port, which it supports as /dev/term/a and /dev/cua/a. If your machine has more than one serial port, you probably need to make Solaris x86 aware of that fact. Once you do, Wabi will be able to use the port. Look at the comments in file /kernel/drv/asy.conf, or see the Solaris x86 installation and configuration manual. Q: I can't access either serial communications port COM1 or COM2 from Wabi. I can't reconfigure them either. When I look with ConfigurationManager:Ports:Connect...:Advanced..., the drop-down list of available device names is empty. (This happens even though the Advanced... sub-dialog shows the default device directory /dev/cua and the default device name pattern [a-z].) What should I do? A: Check the permissions on the Unix devices. They should be set to allow access to Wabi. If they're set to -rw------- with an owner other than yourself, you'll need to change them. Q: The ownership and permissions of /dev/term/* and /dev/cua/* are exactly as they are on a freshly installed hostOS. Isn't this the way they should remain? A: Not necessarily. Many users are very concerned about the security of /dev/term/* and /dev/cua/*. The original ownership and permissions provided by the hostOS may reflect this, and be either too restrictive or too loose for your environment. Often some adjustment of the ownership and permissions of the serial devices is needed. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: sizing a central Wabi engine configuration Keywords: performance X-terminals Viking 30MHz 40MHz 50MHz 60MHz 70MHz central server X-Applies-To: X-Classification: X-Source-Info: File--serve2.txt Version--1.5 Date--94/08/17 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 moderately 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". If for example the users are fast typers using MS-Word, each SPARC CPU may only give adequate performance to 2-3 users. 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 rough starting point --which you should then adjust significantly 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 (A Wabi 1.x Knowledge Base Item) Subject: Wabi on a server Keywords: server NFS central Wabi engine DISPLAY mount wabiload rmmount Volume Manager X-Applies-To: X-Classification: X-Source-Info: File--server.txt Version--1.6 Date--94/07/19 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: If several users rlogin to the machine where Wabi executes and each display Wabi windows back to their own desktop, can all those users share a single ~/wabi directory? A: No. Every Wabi user should execute Wabi under their own userid, and should have their own ~/wabi directory. Q: If a user rlogin's to the machine where Wabi executes then displays Wabi windows back to their own desktop, does that user's home directory on the execution machine have to be the same as the home directory on the user's desktop? A: No. Although you may wish to use either the automounter or manual NFS mounts to give users the same home directory no matter which machine they login to, you need not do so. Wabi's only requirement is that the home directory of each user on the execution machine be separate. 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: How do I NFS-mount the copy of $WABIHOME (probably /opt/SUNWwabi) that's stored on a file server from my desktop machines? A: Follow your site's conventions. Common site-wide conventions for NFS-mounting packages from a file server include: 1) Create a symlink from the expected location of the package on the client through the automounter to the file server. For example: /opt/SUNWwabi -> /net///SUNWwabi 2) Make an entry in the NIS(+) auto_direct map to cause the files exported from the fileserver to be mounted on mountpoint /opt/SUNWwabi on the client. 3) Add an entry to /etc/vfstab on each client to cause a hard mount of the files exported from the fileserver on mountpoint /opt/SUNWwabi on the client. For testing, you can as root manually execute `mount` to be sure you have all the right parameters. Q: Are there any technical limitations on users sharing the Wabi files that were installed from the Wabi package (typically everything under /opt/SUNWwabi)? A: No. The files in the Wabi package can be mounted by multiple machines, and can be used by multiple users logged into the same machine. (Of course access should be limited to those users who have a Wabi RTU license.) The files that each user must have their own copy of are the ones stored under ~/wabi, not the ones in /opt/SUNWwabi. 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: The procedure is simple for Wabi 1.x, provided 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 indefinitely. For Wabi 1.x, 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 1.x without accessing 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 1.x 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 (A Wabi 1.x Knowledge Base Item) Subject: DOS/Windows file sharing and locking Keywords: lockd NFS lock SHARE.EXE share flock install locking sharing X-Applies-To: X-Classification: X-Source-Info: File--share.txt Version--1.9 Date--94/07/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. 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 (A Wabi 1.x Knowledge Base Item) 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-Classification: X-Source-Info: File--shrlck.txt Version--1.9 Date--94/07/19 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 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 didn't work right. Turning it on did nothing useful; it might show checked on drives where file sharing wasn't actually been enabled; it might not show checked on drives where file sharing had been correctly enabled. This was fixed in Wabi 1.1. 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, Wabi 1.1 translates 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 (A Wabi 1.x Knowledge Base Item) Subject: sound Keywords: soundblaster multimedia x86 risc wav au sound X-Applies-To: X-Classification: X-Source-Info: File--sound.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: available disk space Keywords: bytes available overhead root ratio free total disk space newfs tunefs minfree metadisk X-Applies-To: X-Classification: X-Source-Info: File--space.txt Version--1.7 Date--94/07/19 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 was fixed in Wabi 1.1. 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 1.x calculate available disk space correctly on very large disk partitions -- for example a 4GB metadisk? A: No. On very large disk partitions Wabi 1.x will always tell its apps there's 0 bytes available. So long as the app doesn't ask how much space is available, it will run fine. But if the app asks (as most install procedures do), it will be told 0 bytes available and will then probably display an error message and refuse to perform the desired operation. Q: What can I do to get an app installed under Wabi 1.x 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 (A Wabi 1.x Knowledge Base Item) Subject: startup group Keywords: startup program group initial X-Applies-To: X-Classification: X-Source-Info: File--start.txt Version--1.3 Date--94/07/19 Q: I noticed that Wabi doesn't automatically 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 program group when it's first started because it's so often not useful. If you're implementing a unified desktop (e.g. Unix apps, PC apps, and Mac apps) by starting individual apps from an X root menu or icons in a desktop dashboard, a StartUp program group within Wabi would be a confusing duplication of functionality. Also, even many "real Windows" users find they want a different app first nearly every time and so have no use for the StartUp program group. 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. Q: If I manually 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 (A Wabi 1.x Knowledge Base Item) Subject: temporary files Keywords: C: TEMP TMP /tmp symlink environment AUTOEXEC.BAT tempfs RAM ramdisk performance files X-Applies-To: X-Classification: X-Source-Info: File--tmpfil.txt Version--1.2 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: TrueType fonts Keywords: TrueType fonts type manager X-Applies-To: X-Classification: X-Source-Info: File--trutyp.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: UDP checksums for NFS Keywords: possible file corruption UDP checksums NFS x86 X-Applies-To: X-Classification: X-Source-Info: File--udpchk.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: virus protection Keywords: virus boot sector windows apps Unix Solaris Wabi scanner X-Applies-To: X-Classification: X-Source-Info: File--virus.txt Version--1.3 Date--94/08/17 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: Probably not fully, if at all. 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. Q: Will DOS/Windows virus scanning programs that are distributed as a "driver", a DOS TSR, or a Windows VxD run under Wabi? A: No. Wabi doesn't support arbitrary drivers, DOS TSRs, or Windows VxDs. Q: Will DOS/Windows virus scanning programs that do low-level access to media (ex: read a sector) run under Wabi? A: No. Wabi supports the regular file read and file write API calls. Wabi doesn't support raw sector I/O (INT25, INT26, BIOSINT 13) as these are not part of the MS-Windows API. Q: Can DOS/Windows virus scanning programs check files for viruses without having low-level access to media? A: In some cases yes DOS/Windows virus scanning programs can be configured to scan files using only regular file read API calls. Q: Could a DOS/Windows virus scanning program, configured to check files for viruses without having low-level access to media, run under Wabi to check files for viruses that could infect a "real PC" even though they won't be able to infect Wabi? A: In theory yes, a program could run under Wabi to check for the presence of viruses that could later infect some other system besides Wabi itself. From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: Visual Basic/Visual C/C++ Keywords: visual basic C/C++ runtime development VBRUN100.DLL VBRUN200.DLL VBRUN300.DLL X-Applies-To: X-Classification: X-Source-Info: File--visdev.txt Version--1.4 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: Volume Manager overview Keywords: SPARC Solaris Volume Manager CD CD-ROM floppy disk X-Applies-To: Sun Solaris X-Classification: X-Source-Info: File--volmg2.txt Version--1.2 Date--94/07/19 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 run the Volume Manager or that the Volume Manager manage your floppy drive. If your system does use Volume Manager to manage your floppy drive, Wabi does require that there be a connection between Wabi and Volume Manager else Wabi won't be able to access the floppy at all. 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 management 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 management of the diskette drive is enabled. To disable Volume Manager's management 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 /usr/bin/kill -HUP To notify Volume Manager of the change, first remove any media from the drive so Volume Manager will forget any previous state. Then, with Solaris 2.3 and later, 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're running Solaris 2.3 or later, 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 Manager's management of the floppy drive altogether. (Some other situations may also sometimes cause problems with your use of the diskette drive- o Be sure to use the Meta+E key sequence to eject a diskette. [Of course Meta+E to Wabi won't eject the diskette if Wabi doesn't own the floppy drive. If you can neither read nor eject a diskette from Wabi, Volume Manager has given the floppy drive to some other process.] o If you're using X11 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 X11 window system may make it difficult to access the diskette drive on your own system.) Q: What are the advantages of using the Volume Manager with Wabi? A: The Volume Manager provides ease of use to other applications. It eliminates the need to be "root" to mount a floppy. And depending on the format of the floppy you insert it will give access to the floppy drive to the relevant application. If you already have Volume Manager running on your system to obtain these other advantages, then Wabi will coexist with it. The Volume Manager does not provide any necessary or additional functionality to Wabi. Wabi can access the floppy drive without any help from Volume Manager. Q: Can the Volume Manager look at the inserted floppy and determine whether or it's going to be used by Wabi? A: In general part of Volume Manager's functionality is to look at the media to determine which application is relevant. In the particular case of Wabi Volume Manager can't do this. A floppy formatted with an MS-DOS file system isn't necessarily going to be used by Wabi. It might also be used by the OpenWindows File Manager, or by the type "pcfs" file system in Solaris. Currently (Wabi 1.x) if the Volume Manager sees a floppy formatted with an MS-DOS file system it simply checks to see whether or not Wabi is running. If Wabi is running, Volume Manager always gives the floppy drive to it. Q: Can I see the files on the floppy from both Wabi and the OpenWindows File Manager at the same time? A: No. For you to see the files on the floppy through Wabi, Wabi must completely control the floppy drive and access by all other processes is disallowed. This implementation choice was made so that Wabi could also run on platforms that do not have either a Volume Manager or a type "pcfs" file system. The reverse is also true. If you can seen the files on the floppy through some other process such as OpenWindows File Manager, then you cannot access the floppy through Wabi. 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 OpenWindows File Manager? A: Disabling the connection between the Volume Manager and Wabi will prevent Wabi from ever interfering with the use of the floppy drive by other applications. It will also prevent Wabi from ever using the floppy drive. (Perhaps what you really want to do is disable Volume Manager's management of the floppy drive entirely.) If you really want 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. With Solaris 2.3 and later, 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. (Do not send `/usr/bin/kill -9 ${PID}` to the Volume Manager. The "-9" forces Volume Manager to stop immediately without cleaning up after itself. If you do this, some parts of your system will continue to try to reach the old volume manager process that isn't there any more, and a new volume manager process may appear to start but will not function correctly. To recover, reboot your system.) Q: How can I turn off the Volume Manager altogether on my system? A: if you choose to disable Volume Manager altogether rather than just disabling its management of the floppy drive: 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 (A Wabi 1.x Knowledge Base Item) Subject: Volume Manager problems Keywords: SPARC Solaris Volume Manager floppy disk device not ready abort retry ignore X-Applies-To: Sun Solaris X-Classification: X-Source-Info: File--volmgr.txt Version--1.9 Date--94/07/19 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 OpenWindows 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 started. If there was already a diskette in the floppy drive when Wabi was starting up (perhaps right after you finished installing it), Volume Manager will not notice that Wabi 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 --probably "noname"-- even though this isn't required for the correct operation of Wabi). 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 when you start Wabi. (If you intend to install Wabi and then immediately start it, remove any floppy from the drive before you begin installing Wabi. This will eliminate the possibility of a floppy being in the drive when Wabi is started.) Q: Although I can sometimes see the files on a diskette from Wabi, Wabi's access to the floppy drive isn't consistent. What should I do? A: If you had a problem accessing the floppy drive from Wabi, you might have found by experimenting that you could get Wabi to appear to access the drive by changing the drive device assignment to /dev/fd0a. This is a red herring. It postpones the problem, and may thus appear to partially enable Wabi's access to the floppy drive. In fact, it makes the interaction between Wabi and Volume Manager even worse. By having them use different names to access the same device it makes them unaware of each other's activities. If you've done this, change the drive device assignment back to its original value [/dev/fd0c or /dev/diskette] and begin again to resolve the original problem. Usually all that's required to resolve the original problem is to fully install Wabi (and install patch 101168 on Solaris 2.2 only). Q: What does the message "device not ready: abort, retry, or ignore" from Wabi mean if the floppy drive is being managed by Volume Manager? A: If the floppy drive is being managed by Volume Manager, this message means the floppy drive was not given to Wabi. Most likely the Volume Manager gave the floppy drive to some other process or processes instead. To find out why Volume Manager didn't give the floppy drive to Wabi and which process it did give the floppy drive to, enable the first level of Volume Manager debug output. Detailed directions on how to enable the first level of Volume Manager debug output by editing /etc/vold.conf and sending a signal to vold are in a Q&A below. Q: I asked Wabi to look at the floppy before I inserted a floppy in the drive. When it said "device not ready: abort, retry, or ignore?" I realized what had happened and inserted the floppy. But now no matter how many times I click on Retry Wabi won't access the floppy. What should I do? A: Click on Abort, then start again at the beginning of looking at the floppy. In Wabi 1.x the Retry logic doesn't fully communicate with the Volume Manager. So once you try to access an empty floppy drive from Wabi on a system where the Volume Manager is managing the floppy drive, that operation will never succeed. Start a new operation. 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. But you will probably not be able to access the floppy from Wabi. Every time you try you'll be informed "device not ready -- abort, retry, or ignore?". When Wabi's interaction with the Volume Manager is "fully installed", you should see: - an entry for Wabi in file /etc/rmmount.conf - a library whose name includes "wabi" installed under /usr/lib/rmmount - a kernel driver for Wabi o initially present under /usr/kernel/drv o active once Wabi has been executed (use `/usr/sbin/modinfo | egrep wabi` to check) Q: How can I access the floppy drive from Wabi 1.1 running under Solaris 2.4? A: If you have the proper Wabi kernel driver for Solaris 2.4 Wabi's access to the floppy drive will be the same as it is under earlier releases of Solaris with the Volume Manager. (A Wabi kernel driver for use with Solaris 2.4 should be available as a patch to Wabi in July 1994.) If you do not yet have a Wabi kernel driver for Solaris 2.4, then you must either disable Volume Manager's management of the floppy drive, or else forego access to the floppy drive from within Wabi. 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 From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: patches to Wabi Keywords: 0 enter 2 spreadsheet extended zero floating point X-Applies-To: Sun X-Classification: X-Source-Info: File--wabpat.txt Version--1.3 Date--94/07/19 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 (A Wabi 1.x Knowledge Base Item) Subject: X display types Keywords: truecolor pseudocolor true pseudo color graphics accelerator 24 24bit default visual X-Applies-To: X-Classification: X-Source-Info: File--x24bit.txt Version--1.6 Date--94/07/19 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 "X Window System Error: BadMatch (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 (A Wabi 1.x Knowledge Base Item) Subject: library problems on x86 Keywords: libm libXext x86 Solaris 2.1 2.4 libm.so.1 libXext.so.0 math library wabifs ld.so.1 ldd not found dynamic program loader X-Applies-To: Solaris x86 X-Classification: X-Source-Info: File--x86lnk.txt Version--1.5 Date--94/08/17 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 and unpatched Wabi 1.1 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.x 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: What's a way to fix this problem? A: Install either patch 101966 to Wabi 1.1, or Wabi 1.1b. Either will fix this problem. Q: I must continue to use unpatched Wabi 1.x. How can I make the library available to Wabi and check that it's right? 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 unpatched 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. The environment variable will not be set 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: What's a way to fix this problem? A: Install either patch 101966 to Wabi 1.1, or Wabi 1.1b. Either will fix this problem. Q: I must continue to use unpatched Wabi 1.x. Is there a way I can work around this problem, for example by setting this environment variable? A: Yes. For both Wabi 1.0 and unpatched Wabi 1.1, this environment variable needs to be set in the parent process that will launch Wabi. If you're launching Wabi from your root window, a place to set it is in your openwin startup script. If you're launching Wabi from a cmdtool, a 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)". From wabi1.0-questions@east.sun.com (A Wabi 1.x Knowledge Base Item) Subject: X11 and Wabi coexistence Keywords: X11 model focus window manager X-Applies-To: X-Classification: X-Source-Info: File--xw_win.txt Version--1.7 Date--94/08/22 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. Q: Why does the type of keyboard input focus model used by "real Windows" affect apps running under Wabi? Why can't those apps just follow the instructions given to them by the window manager they're running under? A: In MS-Windows, unlike X11, there is no separate window manager. Window handling logic is embedded inside each application. Often but not always the embedded window handling logic is in the form of default routines supplied by MS and called by the apps. Here's a concrete illustration of what this means. MS-Windows-based apps don't receive events like SET_FOCUS. Rather, they receive events like LEFT_MOUSE_CLICK. Often the processing of these events involves the app posting a second event message to itself. This second event message is something like SET_FOCUS. The app is used to having complete control over whether or not this second event is posted. The app may not correctly handle receiving such an event unexpectedly. Q: How can I minimize the confusion caused by having different windows on my desktop handle input focus differently? A: 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. Subject: Supported Windows Applications X-Classification: ==================================================================== Wabi 1.x Supported Windows Applications Last Updated 94/09/06 (Revision 1.18) Windows Applications PCDI-Certified To Run Under Wabi 1.x -------------------------------------------------------- (PCDI is Personal Computer Desktop Integration, the part of Sun Microsystems that develops 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 [** These two apps require installation of Microsoft Windows 3.1.] {Note: Only the exact version listed has been tested and PCDI-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.}