From gabe@netcom.com Sun Jan 8 02:42:47 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19592; Sun, 8 Jan 1995 02:11:05 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25876; Sun, 8 Jan 95 02:11:41 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07514; Sun, 8 Jan 95 05:11:38 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02569; Sun, 8 Jan 1995 05:11:35 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA05866; Sun, 8 Jan 95 05:11:41 EST Date: Sun, 8 Jan 95 05:11:41 EST Message-Id: <9501081011.AA05866@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 1/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 54887 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 1 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com Subject: Wabi 2.0 Technical Knowledge Base Q&A (FAQ+) Index ==================================================================== Wabi 2.0 Technical Knowledge Base Q&As (Frequently Asked Questions Plus) Last Updated Dec 26 1994 This is all the items in the Q&A section of the Wabi 2.0 Technical 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 - Rev Date information about Wabi - - 94/11/27 patches related to Wabi - - 94/11/27 searching the Q&A portion of the Wabi Knowledge Base - - 94/11/27 address space - - 94/11/27 Wabi 2.0 install answerbook dependencies - - 94/12/16 API - - 94/11/27 obtaining applications - - 94/11/27 application versions - - 94/11/27 Type Managers - - 94/11/27 Wabi 2.0 status - - 94/12/20 bad value error - - 94/11/27 key mappings - - 94/11/27 BackSpace and Delete keys - - 94/11/27 32-bit interfaces and operations - - 94/12/10 install problem--general protection faults in MMSETUP - - 94/12/07 using Wabi and CDE together - Sun Proprietary/Confidential: Internal Use Only - 94/12/16 CD-ROM access - - 94/11/27 color settings - - 94/11/27 colors available to applications - - 94/12/16 colors - - 94/11/29 Corel Draw installation--fonts, and using CD-ROM - - 94/12/07 entering text in CorelDRAW - - 94/11/27 processor type - - 94/11/27 cut copy paste - - 94/11/27 window decoration - - 94/11/27 dynamic link libraries - - 94/11/27 DOS applications - - 94/11/27 DOS partitions - - 94/11/27 drive connections - - 94/11/27 disk configuration checkboxes - - 94/12/20 Wabi and dxlib (BadIDChoice) - - 94/11/27 ejecting floppy disks - - 94/11/27 MS-Word 2.0 equation editor - - 94/11/27 error messages - - 94/11/27 common error messages related to OS version - - 94/11/27 relationship of Wabi to your hostOS - - 94/12/20 font cache - - 94/11/27 font cache build - - 94/11/27 font cache rebuild - - 94/11/28 File Manager - - 94/11/27 file permissions and access checks - - 94/12/19 using floppy diskettes - - 94/11/27 using floppy disk drives on other machines - - 94/12/20 sharing diskette drive between Wabi and SunPC - - 94/11/27 Font Service Protocol Problems in X11R5 - - 94/11/27 default font cache for Solaris 2.4 - - 94/12/16 font server - - 94/11/27 creating folders - - 94/11/27 additional fonts - - 94/11/27 formatting floppy disks - - 94/11/27 floating point - - 94/12/06 floating point precision - - 94/11/27 Wabi User's Guide hardcopy - Sun Proprietary/Confidential: Internal Use Only - 94/12/19 hardware/software requirements - - 94/12/05 icon overlap - - 94/11/27 icons - - 94/11/27 idle looping - - 94/11/27 installing applications under Wabi - - 94/11/27 sharing apps - - 94/12/20 installing MS-Windows - - 94/11/27 interprocess communication - - 94/11/27 iso_8859_1 character set and Wabi's keyboard - - 94/12/19 non-English keyboards - - 94/11/27 window function shortcut keys - - 94/11/27 kernel modules - - 94/12/16 app network/site licenses - - 94/11/27 software installation location - - 94/12/19 launching Wabi apps separately from Unix - - 94/12/20 module loading order - - 94/12/19 monochrome displays - - 94/11/27 Wabi and Motif window manager - - 94/11/27 multimedia - - 94/11/27 networking support - - 94/12/20 hidden files on NFS file servers - - 94/12/20 message: not enough memory - - 94/11/27 administering system memory - - 94/11/27 Novell Netware interoperability - - 94/12/10 ODBC - - 94/11/27 MS-Office - - 94/11/27 OLE/DDE - - 94/11/27 OS patches - - 94/12/05 virtual memory pagesize other than 4KB - - 94/11/27 UFS_HOLE panic - - 94/11/27 Wabi performance - - 94/12/16 Unix processes - - 94/11/27 printer configuration - - 94/12/10 printer drivers - - 94/12/19 printer orientation - - 94/11/27 printer descriptions - - 94/11/27 printer problems - - 94/12/16 printing speed - - 94/11/27 refresh window - - 94/11/27 "root" - - 94/12/19 root menu - - 94/11/27 color schemes - - 94/11/27 serial port use - - 94/11/27 sizing a central Wabi engine configuration - - 94/12/16 Wabi on a server - - 94/11/27 DOS/Windows file sharing and locking - - 94/12/20 Wabi file sharing and locking - - 94/11/27 sharing software with a DOS partition - - 94/12/19 sound - - 94/11/27 available disk space - - 94/11/27 startup group - - 94/11/27 temporary files - - 94/11/27 TrueType fonts - - 94/11/27 UDP checksums for NFS - - 94/11/27 visual basic applications - - 94/12/16 virus protection - - 94/11/27 Visual Basic/Visual C/C++ - - 94/11/27 Volume Manager overview - - 94/11/27 Volume Manager problems - - 94/11/27 patches to Wabi - - 94/12/20 X display types - - 94/11/27 library problems on x86 - - 94/11/27 X11 and Wabi coexistence - - 94/11/27 >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: information about Wabi Keywords: versions Wabi 2.0 Solaris workstation vendor Sun email X-Applies-To: X-Classification: X-Source-Info: Name--1info.txt Number-62010 Version--2.5 Date--94/11/27 Q: What version of Wabi do these items apply to? A: These Q&A items apply to Wabi 2.0 running under Sun's Solaris 2 operating environment. Information about Wabi from UNIX vendors other than Sun, and information about versions of Wabi other than 2.0, 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 an email message and send To: wabi2.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 on Sun platforms? A: For information about Wabi pricing and availability and about future versions of Wabi, ask your Sun representative. You can also ask your Sun representative to obtain Wabi-related materials for you through SunWIN, anonymous FTP, and the Sun-internal Wabi Forum. For technical information about current versions of Wabi, try: o Wabi User's Guide, which is distributed in Answerbook format on the Wabi CD-ROM. With Answerbook, you can read and search the manual on-line, or print it. o Wabi Release Notes, which are included with the Wabi software. Install and start up Wabi, open the Wabi Tools group, and open the icon labeled Wabi Release Notes. The Release Notes include the list of certified applications. Send email to Sun's auto-responders for Wabi information: o For the latest version of the Q&A portion of the Wabi 2.0 Knowledge Base (Frequently Asked Questions) returned in several email messages: To: wabi2.0-questions@East.Sun.COM o For a list of Wabi 2.0 certified Windows application names and versions: To: wabi2.0-apps@East.Sun.COM o To ask a specific question of an automatic program that searches for an answer within the Q & A's : To: wabi-query@East.Sun.COM To discuss Wabi with others or ask specific questions: o Try Usenet news groups comp.sys.sun.apps or comp.unix.solaris. o Access CompuServe, Go SunSoft, and look in the Wabi & PWI section. On CompuServe, you can also view and download Wabi-related files. 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 UNIX 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. Wabi software has been developed for platforms from the following UNIX vendors: SunSoft, IBM, HP, Novell, and SCO. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--3patch.txt Number-62020 Version--2.3 Date--94/11/27 Q: What if my system sometimes hangs or locks up or crashes when I start Wabi? A: Wabi runs into a problem in OpenWindows 3.3 that has extremely varied symptoms, ranging from no symptoms at all to complete system failure. This problem is fixed by patch 101362. 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 (revision -21 or higher) to your OpenWindows. This patch is supplied on the Wabi 2.0 CD-ROM. See the Wabi 2.0 Release Notes for instructions for installing the patch. 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 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: Wabi runs into a problem in OpenWindows 3.3 that has extremely varied symptoms, ranging from no symptoms at all to complete system failure. This problem is fixed by patch 101362. 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 (revision -21 or higher) to your OpenWindows. This patch is supplied on the Wabi 2.0 CD-ROM. See the Wabi 2.0 Release Notes for instructions for installing the patch. 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 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: Wabi runs into a problem in OpenWindows 3.3 that has extremely varied symptoms, ranging from no symptoms at all to complete system failure. This problem is fixed by patch 101362. 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 (revision -21 or higher) to your OpenWindows. This patch is supplied on the Wabi 2.0 CD-ROM. See the Wabi 2.0 Release Notes for instructions for installing the patch. 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 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--5srch.txt Number-62030 Version--2.6 Date--94/11/27 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 2.0 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): 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 2.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. Name 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. Number is a suggested filenumber for this item. It's 5 digits long and is in the range 6nnnn. Both it and the handful of numbers above it are guaranteed to be unique. So it can be used on a FAXback system, even one that requires a number to be reserved for every page of the item. Version indicates how many times this item has been updated. The initial version for Wabi 2.0 is 2.0, the next version is 2.1, and so on. If you find you have two versions of the same item (perhaps because you had archived an older version of the Wabi 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: address space Keywords: simulated address space memory size X-Applies-To: X-Classification: X-Source-Info: Name--adrspc.txt Number-62040 Version--2.3 Date--94/11/27 Q: Do all the applications running under Wabi share a single address space? A: Yes, all applications that you run during a Wabi session on the same display coalesce into one Unix process with a single address space. A Unix `ps` command shows only one Wabi process per user and terminal, no matter how many Windows applications the user is running. Wabi is the same as Microsoft Windows in this regard because some Windows applications take advantage of the single address space to communicate with each other directly through what amounts to shared memory. Q: Do the Windows applications running under Wabi run in "protected mode"? A: Yes. Wabi simulates the same environment that Microsoft Windows 3.1 presents: 16/32-bit protected mode. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi 2.0 install answerbook dependencies Keywords: answerbook dependencies dependency install warning error pkgadd X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--answer.txt Number-62050 Version--2.5 Date--94/12/16 Q: At the beginning of the installation of Wabi 2.0 I get messages complaining about missing packages SUNWalaud SUNWaldcv SUNWolrte SUNWxwplt SUNWxwoft and SUNWxwcft. What should I do? A: These are listed "dependencies" of the Answerbook package. However, the packages are optional, so ignore the error messages. The installation completes correctly and the Answerbook works nornmally despite the error messages. As a general rule when you get WARNING (not FATAL ERROR) messages from pkgadd about dependencies on packages that contain fonts, proceed with the installation anyway. These messages are almost certainly just unintended side effects of a font package reorganization. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: API Keywords: Unix calls direct launches API fork file manager X-Applies-To: X-Classification: X-Source-Info: Name--api.txt Number-62060 Version--2.3 Date--94/11/27 Q: Can applications running under Wabi call any Unix functions directly? A: No. Wabi's purpose is to run shrink-wrapped Windows applications, which do not call Unix functions. Wabi provides only the Microsoft Windows API, not any 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. When you use the desktop tools in Wabi (Windows Program Manager and File Manager, etc.) rather than your Unix desktop tools (X11 root menu, OW File Manager, etc.) you're limited to the Wabi environment. Wabi is not "aware" of the wider world of your workstation, except for the mappings in Configuration Manager (drives, printers, ports). There is one partial exception. The Wabi API call that launches a subtask does a little bit more than the equivalent Windows API call. Like 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. But unlike 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 program from the Microsoft Windows File Manager. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: obtaining applications Keywords: site network license obtain application X-Applies-To: X-Classification: X-Source-Info: Name--apps.txt Number-62070 Version--2.3 Date--94/11/27 Q: Where can I get applications to run under Wabi? A: Purchase individual licenses or network/site licenses for applications from the application vendors just as you would to run the applications under Microsoft Windows. Wabi does not provide any applications or special application licensing arrangements. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: application versions Keywords: certified 2.0 applications versions X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--appver.txt Number-62080 Version--2.5 Date--94/11/27 Q: Will newer versions of certified applications run under Wabi 2.0? In other words, if an application is certified to run under Wabi 2.0, does that mean _any_ version of the application, or only the version listed? A: Only the exact versions listed have been tested and certified to run under Wabi 2.0. To find out about other versions, check the document 'Wabi 2.0 Application-Specific Notes For "Other" Applications'. (That document is included in the response from email To: wabi2.0-apps@east.sun.com.) There's no theoretical reason why a newer version of an application wouldn't run under an older version of Wabi even though it isn't officially certified. Q: Should I try to get the latest version of an application? A: No, check the Wabi 2.0 application information to see which versions are certified, and try to get one of those versions exactly. You can find a list of certified applications and their version numbers in the Wabi User's Guide and the Wabi Release Notes. You can also send email To: wabi2.0-apps@east.sun.com. Q: Will Wabi 2.0 run newer versions of certified applications than Wabi 1.x? A: Yes, Wabi 2.0 is certified compatible with both the newer and the older versions of all 13 applications certified under Wabi 1.x. For example, both WordPerfect 5.2 and 6.0 and Microsoft Word 2.0 and 6.0, are certified to run correctly under Wabi 2.0. In Wabi 2.0, ten additional applications and application suites are certified for a total of 23 applications. Q: I have a newer version of an application. What should I do to get the exact application version I need? A: Have the newer version at hand, especially the purchase and licensing information. 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 newer version but then execute an earlier version? A: Almost certainly not. Most software companies don't care if you use an earlier version 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. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Type Managers Keywords: adobe type manager fonts X-Applies-To: X-Classification: X-Source-Info: Name--atm.txt Number-62090 Version--2.3 Date--94/11/27 Q: Do I need any custom fonts at all on my system? A: Not really. Wabi runs fine without any proprietary fonts available, and all of the certified applications 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 Microsoft Windows on PCs with no changes whatsoever --not even imperceptible changes-- in the documents' appearance. Q: Why do some application 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 PC. To do useful work on a PC you probably need some additional fonts. Wabi can use all the X fonts on your system, so the custom fonts are not necessary. 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 applications that run under it, there's often no need for a custom type system. Don't pay 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. No custom type system -- including Adobe Type Manager -- has yet been tested under Wabi 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. The custom type system may appear to install correctly but then cause an application to have problems later. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi 2.0 status Keywords: available shipping CD coupon 2.0 X-Applies-To: Sun Wabi 2.0 X-Classification: X-Source-Info: Name--avail.txt Number-62100 Version--2.6 Date--94/12/20 Q: When will Wabi 2.0 be available? A: Wabi 2.0 will become generally available in the December 94 timeframe, depending on the distribution channel. Q: If I am a Wabi customer who received Wabi 1.0 and 1.1, will I automatically receive an upgrade to Wabi 2.0? A: No. Wabi 2.0 is being copackaged with Solaris 2.4. If you are a customer who purchases or in some other way receives a valid Solaris 2.4 license after the mid-December period, you will receive Wabi 2.0 copackaged in your Solaris 2.4 media kit. Q: If I already have a copy of Solaris 2.4 shipped before copack- aging of Wabi 2.0 began, am I entitled to a copy of Wabi 2.0? A: Yes. Early shipments of Solaris 2.4 built prior to the copack- aging of Wabi 2.0 CDs contained coupons that could be sent in for Wabi 1.1. These coupons will be fulfilled with Wabi 2.0 product. Q: What if I'm an early Solaris 2.4 customer and I didn't get or don't have a Wabi coupon to send in? A: You are still eligible to receive Wabi 2.0. Either contact your local SunSoft sales office and request a Wabi 2.0 package, or look below for instructions on acquiring Wabi 2.0 over the Internet. Q: If I receive a Solaris 2.4 upgrade kit from SunService, will I also get a copy of Wabi 2.0? A: Yes. Q: How can I get Wabi 2.0 if I'm not purchasing or upgrading to So- laris 2.4? A: Existing and new Wabi users who are not upgrading their Solaris licenses to 2.4 can purchase Wabi 2.0 as an upgrade or new pro- duct from your SunSoft VARs or SunExpress. Q: Can I get a copy of Wabi electronically? A: Yes. From anywhere on the Internet outside Sun use your favorite World Wide Web browser (ex: Mosaic) to look at http://www.sun.com/sunsoft/Products/PC-Integration-products/ Then follow the hypertext link to "Wabi 2.0 Distribution." Or, from anywhere on the Internet outside Sun, use anonymous FTP to look in playground.sun.com:~ftp/pub/wabi Q: What changed between Wabi 1.1 and Wabi 2.0? A: Wabi 2.0 supports more certified applications, has improved performance, and includes some enhancements to Configuration Manager. You can get a list of the new applications by sending email To: wabi2.0-apps@east.sun.com >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--badval.txt Number-62110 Version--2.3 Date--94/11/27 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 application that's using the same X-server. (Frequently mentioned suspects for the "other application" include FrameMaker 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 applications, 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 the Wabi package with pkgrm, then reinstall it with pkgadd. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Wabi 2.0 X-Classification: X-Source-Info: Name--bakde2.txt Number-62120 Version--2.4 Date--94/11/27 Q: Why might Wabi 2.0 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 application. Under Microsoft Windows, modified keystrokes show up as two separate key events, one for the modifier and a second for the key (ex: WM_Keydown Ctrl followed by WM_Keydown E). As a result, Wabi cannot map keystrokes that combine keystroke modifiers onto different keytops than on a PC keyboard. For example, on a PC keyboard the E keytop generates 4 possible combinations: E, Shift-E, Ctrl-E, and Alt-E. Whatever X11 keytop on your system generates E must generate all 4 of these combinations. If you attempt to use X11 to map one of these combinations to a function that's on an entirely different keytop on a PC keyboard, Wabi will ignore the mapping. (ex: if X11 tries to report Ctrl-E as End-Of-Line), Wabi will be unable to handle the mapping. Provided your keyboard is similar to a PC keyboard (lots of keytops, numeric pad, etc.) --which most newer keyboards are-- this will not be a problem. Q: What should I do if I want to run Wabi from an older or smaller keyboard that's not at all similar to a PC keyboard (ex: doesn't have many keytops)? A: Try to use X11 to map the Cursor control & motion and Misc function keys that are missing from your keyboard (or are assigned to Ctrl-* keys) to other keytops. Q: Many of the "widgets" in Wabi have names the same as Motif widgets. Is there any possibility that Wabi will interfere with resources belonging to the Motif widgets? A: In general, no, none of the Wabi widgets with familiar names use familiar X11 resources. So they will neither consume nor confuse nor overwrite nor respond to resources intended for the Motif widgets used by some other processes. However there are some specific problems with Wabi 1.x. For example, resources of the form *XmText.translations: intended for other applications may modify Wabi's behavior incorrectly. This does not occur in Wabi 2.0. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--bakdel.txt Number-62130 Version--2.4 Date--94/11/27 Q: How many "move left" functions are available in most current software? A: Nowadays three different "move left" functions are provided by most applications: Erase (Destructive Backspace) removes the char to the left of cursor and shifts the rest of the line left to fill the gap. Delete (Delete Char) removes the char under the cursor and shifts the rest of of the line left to fill the gap. 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) applications to work together on the same keyboard? A: Ideally all three of these considerations should be met: - Have MS-Windows applications 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 applications continue to work exactly the way you're used to. - Have both existing applications and new MS-Windows applications 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 applications 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 applications work unchanged and have both existing and new applications attach the same functions to keys, then you won't be able to get your MS-Windows applications 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--bit32.txt Number-62140 Version--2.7 Date--94/12/10 Q: Can applications 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 applications to use 32-bit code or 32-bit data objects or both. Applications that use some "386-mode" or "enhanced-mode" instructions run just as well under Wabi as applications that don't. Q: Does Wabi run in 386 "enhanced" mode? And if so, why is there no 386 icon in the control panel? A: Yes, Wabi runs in 386 "enhanced" mode. The absence of the 386 icon from the control panel does not mean that Wabi isn't running in 386 "enhanced" mode. The 386 icon in the control panel in real Windows is used to control the use of memory and swap. Wabi simply uses the memory management provided by the hostOS (e.g., the "hat" layer in Solaris), and does not duplicate administration facilities that the hostOS already has (e.g., sar, swap). There's no need for the 386 icon in the control panel with Wabi. Each item in the MS-Windows control panel is indivisible -- you either get all of it or none of it. The only way Wabi can show you don't need the administrative functions provided by the icon is to omit the icon entirely. Q: Does Wabi's running in 386 "enhanced" mode also mean that it supports Virtual Device Drivers? A: No. Wabi 2.0 does not support Virtual Device Drivers. Q: Will Wabi support 32-bit API applications (e.g., "Chicago apps")? A: Wabi 1.x and Wabi 2.0 support 16-bit API applications only. As 32-bit API applications become popular with PC users and begin shipping in volume, Wabi will offer 32-bit API support. This is an important future direction for Wabi. Q: Why will Wabi wait until 32-bit API applications start shipping in volume to offer 32-bit API support? A: Wabi is an enabler of end-user productivity tools, not a development system. There's little reason to provide 32-bit API support before applications that need it appear in volume. Q: What do the code names Chicago, Cairo, and Daytona refer to? A: All three are future versions of Microsoft Windows. Chicago is the merge of MS-DOS and MS-Windows into one desktop environment. Among other things, it will emphasize support for 32-bit applications. Microsoft has officially named it Windows95. 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 applications. WIN32 is the Windows NT API. It includes additional functionality to support large multi-part applications. It passes arguments as 32-bit values and is available only to 32-bit applications. WIN32s is a subset of WIN32 that's functionally similar to WIN16. It's available now under Windows 3.1 with the inclusion of the WIN32s libraries and virtual device driver. You can think of it as WIN32 "compatibility mode," which enables newer 32-bit applications to run under a 16-bit operating system. 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 multi-threading for use by applications. Q: Can I run 32-bit applications under Wabi by installing WIN32s? A: Not currently. WIN32s is implemented as a set of *.DLLs, which do work under Wabi, and a virtual device driver (VxD), which does not work under Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: install problem--general protection faults in MMSETUP Keywords: ACMSETUP GPF MMSETUP.DLL SYSTEM.INI install MS-Windows X-Applies-To: X-Classification: X-Source-Info: Name--blnkln.txt Number-62150 Version--2.5 Date--94/12/07 Q: Application installation fails when it's almost done with the message "ACMSETUP Caused a General Protection Fault in Module MMSETUP.DLL at 0021:0238." What's wrong, and what should I do about it? A: Make sure there's a blank line at the end of every section in file ~/wabi/windows/system.ini. This is a Microsoft problem that occurs on PCs and Wabi too. Here's the verbatim information from Microsoft: DOCUMENT:Q112038 29-APR-1994 [W_ACME] TITLE :ACMSETUP.EXE Caused a General Protection Fault in MMSETUP.DLL PRODUCT :Microsoft Acme PROD/VER:1.00 OPER/SYS:WINDOWS KEYWORDS: The information in this article applies to: - Microsoft Office Setup for Windows, version 1.0 - Microsoft PowerPoint for Windows, version 4.0 - Microsoft Word for windows, version 6.0a - Microsoft Office for Windows, version 4.2 - Microsoft Windows version 3.1 ----------------------------------------------------------------------- SYMPTOMS ======== The Setup program that is included with PowerPoint version 4.0 for Windows, Word version 6.0a for Windows, and Microsoft Office version 4.2 for Windows, may product the following error message when it updates you system files (at the end of the setup process): ACMSETUP Caused a General Protection Fault in Module MMSETUP.DLL at 0021:0238. CAUSE ===== This problem occurs when both of the following conditions are true: - You are running Microsoft Windows 3.1 -and- - There are sections in the SYSTEM.INI file that are not separated by blank lines. (Normally there are several sections in the SYSTEM.INI and the sections are separated by blank lines. If these lines get deleted or replaced with other entries during the setup of other programs, drivers, or utilities, you may experience this problem.) NOTE: Sometimes it may appear that there is blank line, but the line actually contains one or more spaces. WORKAROUND ========== To work around this problem, do the following: 1. Edit the SYSTEM.INI file and add a blank line between each section. The first line in each section is enclosed in square brackets. The SYSTEM.INI file is a text file and can be edited in any standard text editor (such as Windows Notepad). [[Wabi NOTE-- You can edit the file with a Unix system editor such as `vi`, `emacs`, or `textedit`. Because the file uses the DOS line endings convention, a blank line may appear to Unix editors to contain the single character ^M.]] 2. Quit Windows. NOTE: This step is necessary because the Setup program did not quit normally. If you don't exit windows, you will probably get a sharing violation because the setup files are still in use. 3. Restart Windows. 4. Re-install the program. If you install the program to the same location, you should not have to delete any files before re-installing. STATUS ====== Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge BAse as it becomes available. MORE INFORMATION ================ In some configurations you may also experience a sharing violation when you choose Close to get rid of the GP fault error message. This only occurs on systems where a swap file is being used. You can ignore this message and follow the instructions listed above to resolve the problem. You will not receive the sharing violation at the end of the re-installation of the product. If you don't re-install, you may experience problems using the product because the Setup program was unable to make the necessary changes to your system. Additional reference words: Share 4.00 6.0 6.00 4.20 GPF Acme buglist pp4bug 3.10 ========================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 1994. From gabe@netcom.com Sun Jan 8 02:42:50 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19597; Sun, 8 Jan 1995 02:11:11 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25879; Sun, 8 Jan 95 02:11:46 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07517; Sun, 8 Jan 95 05:11:43 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02572; Sun, 8 Jan 1995 05:11:39 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA05904; Sun, 8 Jan 95 05:11:45 EST Date: Sun, 8 Jan 95 05:11:45 EST Message-Id: <9501081011.AA05904@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 2/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 67755 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 2 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: using Wabi and CDE together Keywords: Common Desktop Environment COSE X-Applies-To: X-Classification: Sun Proprietary/Confidential: Internal Use Only X-Source-Info: Name--cde.txt Number-63060 Version--2.3 Date--94/12/16 Q: Will Wabi run together with CDE? A: The eventual goal is that Wabi and CDE will do more than just work together, they will provide a significantly higher level of desktop integration than does Wabi with OpenWindows 3. In the meantime, in theory Wabi will work even with intermediate versions of CDE. In practice. the interactions between intermediate versions of CDE and Wabi have uncovered some bugs in the Xserver, so you may need to get some patches to make Wabi and CDE work together. Q: What do I need to make Wabi and CDE work together? A: Get current versions of both Wabi (2.0) and CDE (/net/cde-product.eng/export/dist/sparc/latest/Install_Tools/InstallCDE). Get a recent OW jumbo patch, at least 101362-21 or 102057-04. (Note that a preliminary version of 101362-29 did not work correctly. If it wasn't fixed before final release you're better off with a slightly older revision.) Without patches, neither OW3.3 nor OW3.4 will work with both Wabi and CDE. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--cdrom.txt Number-62160 Version--2.3 Date--94/11/27 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 system, then map a Wabi or SunPC drive letter to the mount point. If you're running the Volume Manager, the CD-ROM is mounted automatically when you insert it in the drive. If you're not running the Volume Manager, mount the CD-ROM with this command: mount -F hsfs -o ro /dev/sr0 /cdrom Once mounted in Unix, the CD-ROM shows up as /cdrom/[volume name as seen by filemgr] and you can map a drive to this directory in Wabi and SunPC. For Wabi, use the Wabi Configuration Manager to map N:, for example N: -> /cdrom/[volume name as seen by filemgr] For SunPC, use the following command at the DOS prompt in SunPC to map N:, for example: net use N: /cdrom/[volume name as seen by filemgr] Note that the drive letter you choose must be less than the setting of the LASTDRIVE variable in config.sys. For SunPC LASTDRIVE is set to R: by default, and for Wabi it is set to Z:. Q: What CD-ROM data formats can Wabi access? A: Wabi accesses data files on the CD-ROM through the Unix file system after the CD-ROM 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 CD-ROMs in the Rock Ridge (High Sierra File System +) format. To Wabi under Solaris, the CD-ROM looks like a High Sierra File System (ISO 9660). The Rock Ridge extensions are relevant to Unix, not DOS/Windows/Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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 2.0 X-Classification: X-Source-Info: Name--color1.txt Number-62170 Version--2.5 Date--94/11/27 Q: Is Wabi's use of colors different in Wabi 2.0 than it was in Wabi 1.1? A: No. The color allocation and use part of Wabi was redone for Wabi 1.1, and remains the same in Wabi 2.0. Among other things, the new implementation gives much more control to the user. You can set several settings in win.ini, and make Wabi do almost anything you want with colors. Q: What's the general outline of Wabi's algorithm for colors? A: Wabi creates a color cube in the default colormap, copies over a range of previously allocated cells and the cube from the default map into its private colormap, and then frees 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 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 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 retains more of Wabi's colors in the default colormap, and so reduces color flashing. Setting it higher reduces 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 is more than one hardware colormap in the X-Server for this screen. If there is more than one hardware colormap, 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 windows and non-Wabi windows. 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 applications running under Wabi don't find it necessary to allocate new colors. Set this variable smaller if most colors have already been defined by non-Wabi apps before Wabi starts, or if you'll be manually defining all your colors anyway (ex: through a "paint" program), and so have no use for pre-allocated colors. 4) "RedCubeCount" defines the dimension of the red component of the color cube. After the (7 * solid_count) allocations above, (red_count * green_count * blue_count) allocations are made in the same way. This may result in many of the same colors, so the total number of allocations will be less that ((7 * solid_count) + (red_count * green_count * blue_count)). This variable defaults to 5. It may range from 4 - 9. When Technicolor is 0, the color cube is allocated in the default colormap, then copied to Wabi's private colormap, then depending on the setting of PercentFree some of it may be freed from the default colormap. When Technicolor is 1, this variable is ignored. Set this variable larger to have Wabi pre-allocate more colors so that apps running under Wabi don't find it necessary to allocate new colors. Set this variable smaller if most colors have already been defined by non-Wabi apps before Wabi starts, or if you'll be manually defining all your colors anyway (ex: through a "paint" program), and so have no use for pre-allocated colors. 5) "GreenCubeCount" is the same as "RedCubeCount" above, except for the green component of the cube. 6) "BlueCubeCount" is the same as "RedCubeCount" above, except for the blue component of the cube. Q: How does Wabi process these variables? What has precedence, and when is the default value used? A: The same processing is followed for each variable. First, the variable is set to a default value. Next, if there is a setting for that variable in the [Colormap] section of win.ini, the variable is set to the value specified there. Then if there is a setting in the [foo:0.0] section of win.ini, the variable is set to that value. Finally, the variable is compared to maximum and minimum values and modified if it is found to be out of range. Q: Will I see any of these variables in win.ini? A: You won't see any of these variables in win.ini unless you put them there yourself. Wabi runs with default values for all of these variables. Only if you've explicitly set one of them will you see it in win.ini. Q: What if my X-server provides 24-bit truecolor? A: With a 24-bit truecolor visual, colors are set directly rather than through a colormap. There is no colormap. None of the colormap controlling variables (except perhaps "UseRootWindow") are relevant. So if some future version of Wabi were to be able to use a 24-bit truecolor visual, it would ignore all the colormap controlling variables. The colormap controlling variables apply when Wabi is using an 8-bit pseudocolor visual. Since Wabi 1.1 and Wabi 2.0 use an 8-bit pseudocolor visual even if the X-server also provides 24-bit truecolor, Wabi 1.1 and Wabi 2.0 will always pay attention to the colormap controlling variables. Q: What if Wabi 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 to coexist as much as possible with the existing colormap, thus greatly reducing color flashing. Q: Are there any other possible variables in win.ini that are related to colors? A: Yes. "UseRootWindow" tells whether or not Wabi can draw to and read from the root window. The default value is 1 (yes), unless Wabi's colormap and the default colormap have a different number of entries, in which case the default is 0 (no). The main reason for this is to control whether or not Wabi can do "saveunder" operations to the root window. If Wabi is running with 8-bit color (256 colors) on an X-server that's capable of 24-bit (truecolor) operation, drawing damage may occur after some operations on some X-servers. This variable changes Wabi's behavior in this case, and may reduce the drawing damage. The function of this variable is slightly different in Wabi 2.0 than it was in Wabi 1.1. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: colors available to applications Keywords: colors 256 Palette Manager fixed change definition color dither X-Applies-To: X-Classification: X-Source-Info: Name--color2.txt Number-62180 Version--2.6 Date--94/12/16 Q: How many colors does an application running under Wabi think it has available to it? A: All applications running under Wabi 1.x and 2.0 think they have 256 colors available to them. This is true no matter what kind of X display Wabi is using. Q: When does Wabi define these 256 colors? A: Wabi defines all 256 colors when it first starts up. Q: How does Wabi determine what definitions to use for these 256 colors? A: Wabi allocates some colors for compatibility with other X applications using the same display, and allocates the rest as a "color cube." The "color cube" methodology allocates a wide range of hues and saturations, so no matter what exact color an application asks for, Wabi is able to supply a close match. (The color definition algorithm in Wabi 1.0 sometimes failed to allocate as wide a range of hues and saturations as it could, so that some displayed images looked poor. This problem was fixed in Wabi 1.1. Wabi now always allocates as wide a range of hues and saturations as possible, so that displayed images look much better.) Q: Can applications running under Wabi change these 256 colors? A: No. Wabi 2.0 does not support "Palette Manager" functionality. Applications running under Wabi see the 256 colors as fixed. Wabi presents to the applications running under it the appearance of a display driver that doesn't include Palette Manager hooks. This configuration can also occur under MS-Windows, so applications already know how to deal with it. Q: Why would an application running under Wabi emit a message like "...needs a 256 palettized video driver..."? A: A message like this means the application needs 256 colors simulataneously, and it needs to modify color definitions on the fly. Wabi 2.0 provides 256 colors simultaneously, but does not provide the ability for applications to define colors on the fly. The term "palettized" refers to the application's requirement that the display driver support hooks for the "Palette Manager". The Palette Manager is the portion of MS-Windows that lets applications change color definitions. Q: How often will an application running under Wabi 2.0 receive a WM_PALETTECHANGED message? A: Never. Without Palette Manager functionality, color definitions will never be changed. And since color definitions are never changed WM_PALETTECHANGED will not be posted to applications. Q: What if an application running under Wabi requests a color that isn't closely matched by any of the 256 available colors? A: Wabi may "color dither" to produce a closer match. For example if an application requests a "blue-green" and Wabi doesn't have a close match available, Wabi produces a pattern of "blue" pixels and "green" pixels that appears overall to closely match the color the application requested. This technique is not specific to Wabi. MS-Windows also sometimes does "color dithering." Q: What if an application needs a large number of very similar colors to accurately display a picture (say for example 100 "flesh tones" with nearly the same hue to display a portrait)? A: Without the ability to change color definitions provided by the "Palette Manager" functionality, Wabi will use color dithering heavily. In this situation the image displayed by the application running under Wabi will probably not look as good as the same image displayed by the same application running under MS-Windows on a PC. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: colors Keywords: colors colormap X11 technicolor xray flashing cell dithering X-Applies-To: Wabi 1.1, Wabi 2.0 X-Classification: X-Source-Info: Name--colors.txt Number-62190 Version--2.4 Date--94/11/29 Q: How does Wabi calculate its colormap? A: Wabi sets up all 256 colormap entries each time it starts so it can give colors whenever necessary to applications running under it. Wabi copies the entries that were already in the shared colormap when it was started (unless Technicolor=1). Then Wabi fills out the rest of the colormap with a wide spectrum of colors in the form of a color cube plus additional entries. 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 Microsoft Windows sometimes do this when an application asks for a specific color that isn't available. 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, you can see the pixels of the second color. Q: Why do the colors on my screen sometimes change when I move the mouse? A: This is a typical X Window behavior, commonly called "color flashing," "X-ray colors," "technicolor," or "fruit salad." Here's why it happens. The X-server has one palette of 256 colors, but several applications each want their own palette of colors, totaling more than 256. The X-server tries to satisfy each application's color requirements by storing away multiple 256-color palettes in memory, 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 from one window to another, the X-server swaps different 256-color palettes into the hardware, resulting in the flashing you see. This is the default behavior of most X servers, including OpenWindows. You can modify and control the "color focus" behavior in OpenWindows to change this. See the olwm man page 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: You can minimize color flashing, or you can have all the colors you want whenever you want, but you may not be able to have it both ways at the same time. You may have to decide which matters most. If you want to display a near-true-color picture with an application running under Wabi, you may have to put up with the color flashing. If you want to eliminate color flashing, you may not get the exact colors you request. In Wabi 1.1 and Wabi 2.0, use the colormap control variables in win.ini to control how Wabi makes its colormap. The variables are described in another Q and in the Wabi 2.0 User's Guide. Another way to make Wabi behave as you'd like is to control how full the colormap is when you start Wabi. Make your tradeoff as follows: o If you want the most accurate Wabi colors, the colormap should be relatively empty when Wabi starts, so start Wabi before you start any other applications on your desktop. o If you want to minimize color flashing, the colormap should be filled with colors allocated by the other X applications you use, so start all the desktop applications you want to use before you start Wabi. Q: How can I minimize color flashing, even if I can't eliminate it altogether? A: Here are a couple hints that may help if you've already tuned the variables in win.ini and the Wabi startup sequence and find you still have some color flashing. o Use a plain color or simple tiled pattern as your Unix windows background rather than a "true color" photograph. o If you're running both SunPC and Wabi, start SunPC before Wabi instead of launching it through Wabi. 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, try these solutions: o Maximize all Wabi windows to full screen size when you use them. Since no other windows are visible, there's no way to accidentally activate a different window and induce color flashing. Maximizing also makes the window easier to read and less distracting, so you might want to do it even if you don't have color flashing. o Modify the behavior of your window manager. If you're using the OpenWindows window manager and have already set it to use click-to-type focus, you can reduce the amount of color flashing by entering 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Corel Draw installation--fonts, and using CD-ROM Keywords: CD-ROM setup setup2 X-Applies-To: X-Classification: X-Source-Info: Name--corfnt.txt Number-62200 Version--2.4 Date--94/12/07 Q: Do I have to do anything special to install from CD-ROM? A: Use Tools:ConfigurationManager:Drives to map a drive letter to the CD-ROM mount directory in your Unix file system. On PCs the CD-ROM drive is always just a drive letter, such as I:. In Wabi, the CD-ROM is a drive letter plus a directory, such as I:\cdrom. Application installation programs are only tested by application vendors in a PC environment and may have latent bugs. Because your CD-ROM is a subdirectory rather than a drive letter, the application 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. 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: Near the end of the Corel installation I get an error message about "out of string space". What should I do? A: Rerun the setup program 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. Microsoft Windows also can't install all the fonts that come with Corel at one time. In fact, Wabi may be able to install more fonts than Windows. If you were doing a custom install to install only fonts, restart the setup program, click for Fonts and Symbols, and explicitly add the fonts you want and delete the ones you 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 for Fonts and Symbols and explicitly add the fonts you want and delete the ones you don't want. Q: About 20% of the way through the initial installation of Corel I get an error message mentioning the name of a font file. What should I do? A: Start Corel's installation program through the File->Run menu option of Program Manager. Do not double-click on the installation program in File Manager or use File Manager's File->Run menu option. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: entering text in CorelDRAW Keywords: Corel DRAW text fonts colors X-Applies-To: X-Classification: X-Source-Info: Name--cortxt.txt Number-62210 Version--2.3 Date--94/11/27 Q: I can't enter text into CorelDRAW. What might be the problem? A: You probably need to double-install CorelDRAW as explained in 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 Enter 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: processor type Keywords: 80386 80486 80586 extended standard CPU X-Applies-To: X-Classification: X-Source-Info: Name--cputyp.txt Number-62230 Version--2.3 Date--94/11/27 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 tells the application 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 Wabi says "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. 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 applications permission to use "enhanced" mode extensions, and 2) always saying 80386 rather than 80486 or 80586 has no impact on performance or functionality. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: cut copy paste Keywords: cut copy paste clipboard images X-Applies-To: X-Classification: X-Source-Info: Name--cutpst.txt Number-62240 Version--2.3 Date--94/11/27 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 (e.g., 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 (e.g., VK_* symbols) for these functions. The keyboard events appear to the applications 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 applications to assign Cut to Shift-Delete, Copy to Ctlr-Insert, and Paste to Shift-Insert. But it's not universal. Most applications, especially ones from Microsoft, 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 applications process them. Q: Can I cut and 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 Windows clipboard viewer in Wabi shows you what's currently on the clipboard as though it were stored in native Windows format. You can cut and paste from one X application to another, from one Windows application to another, and between X applications and Windows applications. If you're using OpenWindows and cannot cut from a Windows application and paste to an X application, you may be inadvertantly erasing the clipboard before you paste into the X application. In Wabi 1.x, you must click inside the destination X window rather than the title bar because clicking on the title bar erases the clipboard. In Wabi 2.0, the clipboard behavior was modified so that you must click on the title bar to select the destination window before pasting into it. This means you must set the insertion point in the destination window before copying the text in the Windows application window. If you click inside the destination window before you paste, the clipboard is erased. 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, you can cut and paste any type of material from any application to any other application. The clipboard uses ICCCM-compliant selection type tags and can contain any type of material. In practice, it only works if both source and destination applications are Windows-based. Most current X applications only know how to cut and paste text. If they're asked to cut an image, they either ignore the request or put the image on the clipboard in a format Windows applications don't understand. If the clipboard contains an image in a format they don't understand, they ignore the material. To work around this problem with deficient X applications, use something like OpenWindows 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: window decoration Keywords: borders decoration window manager X11 X-Applies-To: X-Classification: X-Source-Info: Name--decor.txt Number-62250 Version--2.3 Date--94/11/27 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: Windows applications expect their window borders to be intimately and quickly accessible, and 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: Windows applications expect similar window system functionality and timing whether they're running under Microsoft 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 Microsoft Windows -- and no more. Change the size of fonts, borders, etc. of Wabi windows the same way you would under Windows. Most of these settings are not visible through a GUI, so you'll have to get a book on Microsoft Windows to find out what the parameters are, and then manually edit the appropriate file. 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 thick). 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--dlls.txt Number-62260 Version--2.3 Date--94/11/27 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 application references it? A: Wabi looks for DLLs in the same places in the same order as 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 is a list of directories in DOS format, separated with semicolons. It should look similar to the following: PATH=C:\WINDOWS;H:\APPS\DLL;H:\ (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 application wanted to load, and not the one it couldn't find. If this happens, there are two error messages and the first one is meaningful. Q: How does Wabi support DLLs? A: Wabi has several ways of supporting DLLs, and uses whichever way is appropriate for each DLL. A few core DLLs are implemented inside "wabiprog" itself. They appear to applications to retain their identity even though they aren't contained in a separate file under Wabi. Where performance is critical, Wabi may provide a "native" version of a DLL. These DLLs appear to applications to have all the same entry points and functionality as the x86 version. They are compiled into native (usually RISC) opcodes. If a DLL isn't available otherwise, Wabi can execute the actual x86 DLL, the same one that would be executed on a PC. Wabi does this the same way it executes stretches of application 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 applications work under Wabi. Most other DLLs do too. 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 application 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 application. 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: Microsoft Windows is mainly comprised of several DLLs. The core of Windows 3.1 is the three DLLs: KERNEL.DLL, USER.DLL, and GDI.DLL. The Unix executable "wabiprog" in Wabi 2.0 internally duplicates all three of these core DLLs. Q: What other DLLs are implemented internally in wabiprog? A: The wabiprog program contains enough of many other DLLs to implement the Windows API and get common applications 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 Windows API functions and get common applications to work: KEYBOARD.DLL, SYSTEM.DLL, SOUND.DLL, TOOLHELP.DLL, DISPLAY.DLL, and MOUSE.DLL. Q: Are there any DLLs in Wabi 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. A separate file PWI.DLL provides some additional host-OS links called internally by Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: DOS applications Keywords: DOS emulator PIF icon launch X-Applies-To: X-Classification: X-Source-Info: Name--dosapp.txt Number-62270 Version--2.3 Date--94/11/27 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 application? A: Wabi supports launching of all the common DOS emulators, which enable you to run DOS-based applications. To create an icon for a DOS-based application, just pull down File->New, check Program Item, enter the requested information, and click OK. You don't need a "PIF editor" to create icons for DOS-based applications. 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 online help and Wabi 2.0 User's Guide explain the format to use for the DOS emulator command line, so you should look there for a full description. Here's a brief description of what should be in the command field in the DOS Emulator Connection dialog box: The first item must be a Unix path to a valid executable file for the DOS emulator. 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? A: No. Although Wabi can launch a DOS emulator, Wabi does not include a DOS emulator. Q: Do I need a DOS emulator to make Wabi function? A: No. Wabi does not use DOS. Wabi's ability to launch a DOS emulator is a convenience for users who want to run DOS applications. 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 application and the application 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's PIF Editor? A: Wabi doesn't need a PIF editor so it does not include one. When you start a DOS application, Wabi automatically launches a DOS emulator (if one is installed), which then runs the DOS application. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: DOS partitions Keywords: mount DOS disk partition files X-Applies-To: Solaris x86 X-Classification: X-Source-Info: Name--dosdsk.txt Number-62280 Version--2.3 Date--94/11/27 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 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 are 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. Then Wabi does not lock any files, but tells applications 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 do I sometimes get a "system panic" on my x86 system when I'm running Wabi? A: There is a generic problem in Solaris 2.1 x86 that can cause a system 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 application to stumble over this bug in Solaris 2.1 x86. This is fixed in Solaris 2.4 for x86. For more information, refer to Solaris bug number 1162032. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--drives.txt Number-62290 Version--2.3 Date--94/11/27 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 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: disk configuration checkboxes Keywords: drive letter sharing enabled network drive checkbox configuration disk X-Applies-To: Wabi 2.x X-Classification: X-Source-Info: Name--dskcfg.txt Number-63160 Version--2.1 Date--94/12/20 Q: What does the "Network Drive" checkbox in WabiTools:ConfigMan:Drives do? A: Wabi remembers the setting of this checkbox for each drive letter, and passes the information to an application that asks. The setting of this checkbox doesn't affect the operation of Wabi itself at all. Many applications then use this information to optimize their search for a file, control their use of "file sharing" options, and so on. For example many applications assume there can't possibly be any file sharing conflicts with files stored on non-network drives. Exactly what each application does and does not do with this information is up to the application. This variability in application behavior is the same under Wabi as it is under MS-Windows. Q: How should the "Network Drive" checkbox in WabiTools:ConfigMan:Drives be set? A: The "Network Drive" box should generally be checked the same way it would be on a PC running MS-Windows, which is "no" on drive C:, "yes" on all other drive letters that refer to hard disks. Wabi helps you do this. If you check "Network Drive" on drive C:, you'll find next time you open ConfigMan:Drives that Wabi has discarded the check for you. Q: Without the "Network Drive" box being checked for C:, is it possible that files stored on C: will be corrupted if more than one system accesses them at the same time. A: No shared files should be stored on C:. Each user's C: drive should contain only per-user files. If you find files that are supposed to be shared stored on a C: drive, something about the software installation didn't work right. Q: What does the "Sharing Enabled" checkbox in WabiTools:ConfigMan:Drives do? A: A check in this box turns on "file sharing" functionality for this drive letter. The "file sharing" functionality provided by Wabi is the same as would be provided by SHARE.EXE or VSHARE.EXE under MS-Windows. Q: How should the "Sharing Enabled" checkbox in WabiTools:ConfigMan:Drives be set? A: The "Sharing Enabled" box should generally be checked the same way it would be on a PC running MS-Windows. If there are shared files that might be accessed by more than one system stored on the drive letter, the box should be checked. Q: What possible reasons are there for not checking the "Sharing Enabled" box? A: First, "file sharing" may degrade performance of file opens and closes. So if you want peak performance and aren't worried about the possibility of file corruption, leave the box unchecked. Second, if a system crashes sometimes a file accessed with "file sharing" enabled will become inaccessible to all users. This situation, which is called a "stale share", may require administrator intervention. And third, users may think something is wrong when "file sharing" legitimately denies them access to a file that's already in use. It may be easier administratively to arrange your drive letters to minimize the risk of file corruption than it is to educate your user community about the dangers of simultaneous file access. Users mis-concluding that something is wrong may happen for example in an environment that's used PC-NFS heavily but did not specify the "/ms" flag on "net use" commands. (The default on the PC-NFS "net use" command is no file sharing for that drive letter.) Since they've never seen "file sharing" in action before, the first time they see "file access denied" they may think something is wrong. In fact the access denial is legitimately trying to protect them from two users writing to the same file at the same time. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi and dxlib (BadIDChoice) Keywords: window bad choice BadIDChoice invalid resource dxlib performance X11 direct XID X-Applies-To: Sun Wabi 2.0 X-Classification: X-Source-Info: Name--dxlib.txt Number-62300 Version--2.3 Date--94/11/27 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. It also 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 applications. 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 is /opt/SUNWdxlib. You can invoke dxlib explicitly for one X application with the command /opt/SUNWdxlib/bin/dxlib myapp where myapp is the command you normally use to start your application, including arguments. You can invoke dxlib automatically for all X applications by prepending /opt/SUNWdxlib/lib/dxlib/SunOS5.x to your LD_LIBRARY_PATH environment variable. You can exclude use of dxlib for a particular application even if LD_LIBRARY_PATH includes dxlib by setting DIRECTX_DISABLE to a non-zero value in your environment before starting the application. Q: Can Wabi use dxlib? A: Wabi 1.x makes a wide variety of seldom-used X11 calls that are not supported by dxlib, so it cannot work with dxlib. Wabi 2.0 avoids some of this calls but still does not work with current implementations of 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 when there's a problem with Wabi attempting to use dxlib. Q: Is there a patch to fix this problem? A: Not currently. There is no patch to dxlib for Solaris 2.3. And patch 101920-01 to dxlib for Solaris 2.4 does not completely fix this problem. Even if you're running Wabi 2.0 and even if you have patch 101920-01 to dxlib installed, Wabi will not work with dxlib. 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. To find out if dxlib is enabled for your entire desktop, enter one of these commands, and look for a reference to lib/dxlib echo $LD_LIBRARY_PATH ldd /opt/SUNWwabi/bin/wabiprog One way to disable use of dxlib by Wabi is to set environment variable DIRECTX_DISABLE to any non-zero value in the environment Wabi will be started from. If this method does not solve the problem, you may need to remove the dxlib entry from your LD_LIBRARY_PATH. 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` disables it. Q: Can I disable Wabi's use of dxlib by setting environment variable DIRECTX_DISABLE just before starting Wabi? A: Although this should work, it has been reported that for some reason it does not. You may need to remove the dxlib entry from your LD_LIBRARY_PATH. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--eject.txt Number-62310 Version--2.3 Date--94/11/27 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 press Meta, then press 'E' (lowercase), then release 'E' and release Meta. Shift+Meta+E means press both Shift and Meta, then press 'E', then release 'E' and Meta and Shift. Q: Which key is the Meta key? A: The SPARCstation keyboards have two Meta keys located on either side of the space bar and 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. This problem commonly occurs if your desktop window manager is configured for focus-follows-mouse. You start loading a diskette, then move the mouse to a different window to do some other work in the meantime. When Wabi opens a dialog box asking for the next diskette, you press Meta+E and nothing happens. You must explicitly click on a Wabi window so its title bar changes to the "active" color before you press Meta+E. After the diskette is ejected and you insert the next diskette and begin loading it, you can move the mouse back to the other window and continue with your other work. If Meta+E still does not work, try Shift+Meta+E. Some X systems may be set up so the window manager "consumes" Meta+E and the keystroke never gets through to Wabi. Shift+Meta+E should get past these systems, and will be handled by Wabi the same way as Meta+E. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: MS-Word 2.0 equation editor Keywords: fonts display garbled equation editor word fences extra X-Applies-To: X-Classification: X-Source-Info: Name--eqn.txt Number-62320 Version--2.4 Date--94/11/27 Q: What if the MS-Word 2.0 equation editor doesn't seem to work quite right? A: You will probably want to run MS-Word 6.0 under Wabi 2.0. If you must run MS-Word 2.0, and have trouble with the equation editor, try it in on a PC before concluding the problem is with Wabi. The equation editor was a relatively new feature in MS-Word 2.0, and doesn't always function like you think it should. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--errmsg.txt Number-62330 Version--2.3 Date--94/11/27 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 "recursive" in an error message mean? A: It means that Wabi encountered a second error while trying to display the first error in a message box. This is very common if the original error has something to do with failure to establish communication between Wabi and the X-server. As a result, the message is meaningless without further context. 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 (e.g., an application's attempt to access a file on a CD-ROM). If it happens occasionally, do the same thing under Windows on a PC and you'll probably find it happening occasionally there too. However, if it happens every time you try to start the application, you can conclude that the application won't run under Wabi. 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 are standard error messages meaning "this should never happen... but if it does, stop immediately." There are hundreds of ASSERT() statements sprinkled throughout parts of the kernel and many modern applications. Every "assertion failure" message is different. The developers 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 situations that "should never happen," there's not much you can do if one appears, unless you can figure out what function is failing and avoid using that function until the problem is fixed. If you see an assertion failure message, copy it exactly and include it when you report the problem. Q: It's nice to know that users are never supposed to get an "assertion failure" message. But I see them anyway. Why? A: For the same reason you sometimes see a "panic" message even though they're never supposed to happen. Most likely either something is very wrong, or Wabi's error recovery failed to expect your situation. 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 Windows would issue a similar message in a similar situation. Respond to it the same way you would respond to the message from Windows. If you see this message, it's quite likely that Wabi has become unstable 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, answer "no" and, if possible, 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 application running under Wabi. The Wabi startup script checks that there's adequate free swap space available when you start Wabi, but this is no guarantee, especially if you are running several applications simultaneously If you see this message, use Solaris administration tools (e.g., mkfile, swap -a, edit /etc/dfs/dfstab) to increase your system's swap space. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--errors.txt Number-62340 Version--2.3 Date--94/11/27 Q: When might I get a message about missing the Wabi locking driver wabi.sparc.5.x.o? A: You'll get this message if Wabi can't find a kernel driver to match your version of Solaris. The message comes from the wabiload program, which runs when you install Wabi, and when you run the clientinstall program to enable a workstation to run Wabi from a server. Wabi won't be able to find the correct kernel driver if: - you installed Wabi on a pre-release version of Solaris - you installed the wrong Wabi package for your operating system (e.g., the x86 package on a SPARC system) - 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 >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: relationship of Wabi to your hostOS Keywords: extend access protocol hardware driver netware X-Applies-To: X-Classification: X-Source-Info: Name--extend.txt Number-63150 Version--2.1 Date--94/12/20 Q: Can Wabi do anything that the hostOS can't do? A: Wabi accepts whatever functionality your hostOS provides. Wabi 2.0 can't do anything that your hostOS can't do. Wabi's support of CD-ROM formats is exactly the same as your hostOS's. Wabi's access to hardware goes through your hostOS's device drivers. Wabi's file permission checks are those of your hostOS. And so on. Some future Wabi could in theory layer support on top of your hostOS to provide something that's not provided directly by your hostOS. For example some future Wabi could add an upper layer of a network protocol stack to the basic networking facilities provided by your hostOS. For another example some future Wabi could add support for sound files in MS-Windows format to the basic speaker facilities provided by your hostOS. Q: If I add some software to my system to extend it, do I need to use Wabi to test the extensions? A: No. Extensions to your hostOS should appear directly in the native hostOS interface. For example if you extend your hostOS to access files on a NetWare server you will be able to see those files with an `ls` command without ever starting Wabi. Q: If some future Wabi provided some support that wasn't directly available from the hostOS, could Wabi reflect that support back through the hostOS to make it available to non-Wabi processes? A: Probably not. By default any layered support that some future Wabi might provide would be available only to Wabi applications. Reflecting any such layered support back through the hostOS to make it available to non-Wabi processes would require additional extraordinary implementation. Q: So is it fair to say that Wabi is not a way to extend my hostOS? A: Wabi lets you run MS-Windows-based applications on your Unix workstation, and thus is a significant extension of your hostOS. Wabi does not extend the functionality of your hostOS in any other way. From gabe@netcom.com Sun Jan 8 02:42:54 1995 Return-Path: Received: from Sun.COM by netcom2.netcom.com (8.6.9/Netcom) id CAA17353; Sun, 8 Jan 1995 02:11:56 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25882; Sun, 8 Jan 95 02:11:50 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07520; Sun, 8 Jan 95 05:11:47 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02576; Sun, 8 Jan 1995 05:11:43 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA05938; Sun, 8 Jan 95 05:11:49 EST Date: Sun, 8 Jan 95 05:11:49 EST Message-Id: <9501081011.AA05938@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 3/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 62027 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 3 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: font cache Keywords: xlsfonts font metrics cache rebuild rebuilt build X-Applies-To: X-Classification: X-Source-Info: Name--fch1gn.txt Number-62350 Version--2.3 Date--94/11/27 Q: What's the purpose of the font cache? A: Wabi needs a detailed font information from the X server all the time. Wabi uses its font cache to avoid the constant overhead of making a round-trip call to the X-server every time it needs some information. The font cache contains font information collected from the X server and stored locally. Wabi ships with font caches for several X servers, which are satisfactory most of the time. However, Wabi can also create a font cache specific to the X server it's using and save it for re-use. It is stored in a file named ~/wabi/fc/0.fc The Wabi 2.0 User's Guide discusses the font cache in detail. 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 application. Without a font cache, Wabi would be unusable. Wabi uses an existing font cache rather than building a new one if possible. 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. You can disable the Wabi font server, however. The font cache and the font server are different features of Wabi's font handling. Q: Why is the font cache sometimes rebuilt? A: Wabi may detect that the X-server's list of available fonts has changed in some way. If so, Wabi discards the information previously collected from the X-server and asks for new information. This process is called "rebuilding the font cache." It takes only a minute or so. Q: How can I make Wabi 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: Replace the existing font cache file with one of zero length. If you just delete the file, Wabi may not build a new font cache. Wabi may use a default font cache that doesn't include the new fonts in your X server's list of fonts. To make a zero-length file: 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 symbolic link 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 link yet leave the actual data file untouched. You can abort Wabi, fix the font path, recreate the symbolic link, 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 X Window 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 each time I switch X servers? 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: font cache build Keywords: xlsfonts font metrics cache build default X-Applies-To: X-Classification: X-Source-Info: Name--fch2bd.txt Number-62360 Version--2.3 Date--94/11/27 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, if none of the default font caches provided with Wabi are suitable for your site, you can have Wabi create a new font cache that you can use as the default for your site. The procedure is included in the Wabi 2.0 User's Guide. Briefly, here's how to do it: 1. Login as a representative user using your site's standard windowing setup, and start Wabi. Wabi spends a few minutes creating a font cache file. For example, if you login as user "jane" on system "sneezy," Wabi creates the file called ~jane/wabi/fc/sneezy0.fc. 2. Become superuser. 3. Copy the .fc file into the lib subdirectory within Wabi's system directory (/opt/SUNWwabi/lib, if you installed Wabi in the default location). Use a meaningful name for the file (e.g., department.dflt.fc). For example, if your organization name is "Widgets Inc," your copy command could be as follows: cp ~jane/wabi/fc/sneezy0.fc /opt/SUNWwabi/lib/widget_1.dflt.fc 4. Modify the file /opt/SUNWwabi/lib/fontconfig to change the name of the default font cache. Find the line for your X server, and replace the last item on the line with the name of the font cache file you copied into the lib subdirectory. Enter just the name of the font cache file, not the full path to it. If you're not sure which line in this file is for your X server, you can determine the vendor and version of your X server with the following command: xdpyinfo | grep '^vendor' If you have just a few Wabi "central engines," you can add the new default font cache and fontconfig files to 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 two files. Note that in Wabi 1.x, the default font cache was specified in the /opt/SUNWwabi/bin/wabi startup script and some of the information in the fontconfig file was contained instead in a file called /opt/SUNWwabi/lib/wabifs.displays. If you had previously made changes in wabifs.displays or the wabi script in Wabi 1.x, you should make all the changes in the fontconfig file as explained above. Q: What default font caches come with Wabi 2.0 for Solaris? A: Wabi 2.0 provides font caches that match the OpenWindows versions included with Solaris 1.0, Solaris 2.1, 2.2, 2.3, and 2.4. Wabi can be displayed on all of these Solaris versions, although running Wabi is only supported on Solaris 2.3 and 2.4 for SPARC and Solaris 2.1 and 2.4 for x86. Q: Why does building the font cache take a few minutes? 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 small number of scalable fonts and fast font scaling (e.g., 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 mistaken 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 constrained the mouse to stay within the message box while it's building a font cache. Wabi 1.1 and 2.0 do not constrain the mouse to stay within the message box while they're building a font cache. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: font cache rebuild Keywords: xlsfonts font metrics cache rebuild X-Applies-To: X-Classification: X-Source-Info: Name--fch3rb.txt Number-62370 Version--2.4 Date--94/11/28 Q: Why does Wabi sometimes rebuild my font cache when I haven't added fonts or changed my font path? A: Wabi is detecting that the beginning of your X server's font path has changed. Many things other than an explicit action by you will change your X server's font path. For example, many X11 applications change the X server's font path when they come up. Q: When exactly is the font cache rebuilt? A: The font cache is rebuilt if the beginning of your X server's current font path does not match the beginning of the font path stored in the current font cache. The current font cache is either one Wabi built previously and stored in file 0.fc in your directory ~/wabi/fc, or a default font cache stored in Wabi's system directory ($WABIHOME, which is usually /opt/SUNWwabi). 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 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 X application adds a directory to the front of the X server's font path when it starts up. Many applications transparently change the font path, but usually they append to it, and Wabi doesn't notice the change. The X server's font path is reset each time your window system is restarted. If an application is started before Wabi, and it prepends something to the font path, Wabi sees the font path is changed and rebuilds your font cache. If Wabi is started before the other application, Wabi will not rebuild the font cache. 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 applications 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 <<-EOF $0 about to start $WABIHOME/bin/wabiprog with arguments $* from directory `pwd` on $HOSTNAME on `date` for $USERNAME according to current path-- wabi is `which wabi` wabiprog is `which wabiprog` current working directory is and includes-- `pwd` `ls -l` according to "who", all users are-- `who` according to "who -a", all users are-- `who -a` ${USERNAME}s home directory and shell are-- `egrep $USERNAME /etc/passwd` `ypmatch $USERNAME passwd` just before start of wabiprog, environment includes-- HOME=$HOME WABIHOME=$WABIHOME WABIDIR=$WABIDIR DISPLAY=$DISPLAY OPENWINHOME=$OPENWINHOME FONTPATH=$FONTPATH INITIAL_DIR=$INITIAL_DIR just before start of wabiprog, actual X-server settings are-- `/usr/openwin/bin/xset -q` relevant Unix processes are-- `ps -ef | egrep $$` relevant file system locations of HOME, WABIDIR/fc, and WABIHOME are-- `$DF $HOME $WABIDIR/fc $WABIHOME` EOF ------ end code fragment to use for debugging --------- Q: Is the order of directories in the X-server's font path important? A: It could be. The X server searches through this path until it finds the required font just like a Unix shell searches through your PATH until it finds the program you want to execute. If the same font name exists in two different directories, the X server will always use the first one found. Changing the order of entries in the font path may change the behavior of the X-server. To Wabi, only the beginning of the path is important. If there is any change to the beginning of the path, which may happen if the font path is reordered, Wabi will rebuild your font cache. To minimize problems with font path order, additional paths should always be appended to the end of the font path (never added to the front of the font path). Most applications that modify the font path already obey this rule. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: File Manager Keywords: file manager update display new change directory refresh X-Applies-To: X-Classification: X-Source-Info: Name--filmgr.txt Number-62380 Version--2.3 Date--94/11/27 Q: Why isn't Microsoft Windows File Manager's display automatically updated when I add or delete a file or directory? A: The Windows File Manager behaves the same under Wabi as it does in Windows on a PC. It refreshes its display when you switch to a different drive or directory. Q: How can I manually update the Windows File Manager's display? A: Use File Manager's Window -> Refresh menu bar command, or press the F5 key. This makes File Manager recheck and redisplay the disk's contents. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: file permissions and access checks Keywords: setuid file permission root X-Applies-To: X-Classification: X-Source-Info: Name--filper.txt Number-63090 Version--2.1 Date--94/12/19 Q: Does Wabi do anything additional to or different from the hostOS when checking file access permissions? A: No. Access to a file under Wabi follows the same rules as access to that file directly from the hostOS. Q: Does Wabi run "setuid root" to access files? A: No. Wabi runs under the userid of the user that started it. Wabi does not "setuid" to any other user id. Q: Does any part of Wabi have "root access" to the machine, and if so why? A: Wabi's "kernel driver" becomes part of the hostOS and so effectively runs as "root". Wabi's "kernel driver" contains two functions, inter-process communication between Wabi and the Volume Manager, and part of the implementation of "file sharing". Both functions reside in the kernel as an implementation technique, not to circumvent or reimplement any aspect of system security. Q: But if Wabi doesn't have "root access" to the machine, then Wabi can't directly access any hardware. Is this really true? A: Yes, it's correct that Wabi has no special privileges to directly access any hardware. All of Wabi's accesses to devices are through the usual hostOS mechanisms (ex: /dev/cua/*) used by other processes, and use the usual hostOS permissions checks like other processes. Q: If an application under Wabi reports problems accessing a file, how can I debug the problem? A: You can debug these problems directly from a Unix shell without involving Wabi at all. Use the usual Unix tools such as `id`, `ls -l ...`, and `touch ...`. Q: Are there any cases where Wabi will behave differently than the hostOS file permissions would suggest? A: The only case where Wabi may not behave exactly the way the usual Unix tools would suggest is if "file locking" or "file sharing" has been applied to the file. The common Unix tools for testing and displaying file permissions do not check for "file locks" or "file shares". Occasionally, usually because of a "stale share", an application running under Wabi will report that it's unable to access a file even though according to the file permissions access should be granted. Q: Do I need to make all files created by one Wabi user world-writable so that other Wabi users can edit them? A: No, you do not need to do any "chmod" to any file created by Wabi. If an application supports multiple users editing a file you will be asked for file permissions when you first create the file, and your answers will be used to set the hostOS file permissions. Q: Why would I have trouble with access to Wabi files that are stored on an NFS file server? A: If all the machines on your network know all the same usernames and userids then access to files stored on an NFS file server will be exactly the same as access to files stored on a local disk. But if some usernames are not known to some of the machines, or if the same username is associated with different userids on different machines, you may have trouble accessing files. This requirement that all machines know the usernames of all users that may share files is generic to NFS; it's not something specific to Wabi. Another possible cause of problems accessing files stored on an NFS file server is if either the original creator or the current updater of the file is running as "root." Most NFS file servers translate username "root" into username "nobody" before calculating file access permissions. Most NFS file servers do this because their administrators don't want anyone who happens to be able to become "root" on a client system to act as "root" on the file server too. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: using floppy diskettes Keywords: floppy disk diskette Drives configure device ready install application X-Applies-To: Sun Solaris X-Classification: X-Source-Info: Name--floppy.txt Number-62390 Version--2.3 Date--94/11/27 Q: If an applicatiom or install procedure says "drive not ready" when I attempt to access a diskette, what are the most likely problems? A: Diskette problems are usually one of - incomplete configuration of the Volume Manager, or unexpected interaction between the Volume Manager and Wabi - ownership of the diskette drive by another application, such as File Manager, SunPC, or Mac Application Environment - physical problem with the media, such as diskette not fully seated in the drive, or damaged diskette - diskette wasn't seated in drive when operation was begun Q: Could it help to reconfigure Wabi's drive A: to map to a different device name? A: Almost certainly not. The default device names you see in WabiTools:ConfigurationManager:Diskettes are correct for almost all Solaris systems. If Wabi has a problem accessing the diskette drive, changing the Unix device name is much more likely to obscure or confuse the original problem than it is to solve it. Q: If I see an icon labelled A: in MS-FileManager, does it mean the diskette drive is correctly configured and accessible? A: No. The appearance of icons for diskette drives in Windows applications may be triggered by static configuration information which is only minimally verified. It's possible for an icon to appear for the diskette drive even though the diskette drive is unusable from within Wabi. Q: The only time I use the diskette drive under Wabi is when installing an application. I find using it even for this purpose inconvenient. Is there some way I can install an application without accessing the diskette drive from Wabi? A: Yes. You can copy the installation diskettes to your hard drive once, then install the application from the hard drive with no manual intervention. Detailed instructions on how to do this are included in instructions on how to install applications under Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: using floppy disk drives on other machines Keywords: floppy disk diskette remote file copy Xterminal X-terminal X-Applies-To: Sun Solaris X-Classification: X-Source-Info: Name--flpoth.txt Number-62400 Version--2.4 Date--94/12/20 Q: If I'm using an X-terminal that doesn't have a diskette drive, can I still use diskettes? A: Yes. Wabi's mapping of A: and B: to diskette drives always refers to the machine where Wabi is running rather than the machine where it is being displayed. If you have an X-terminal on your desk, Wabi is probably running on a server in a closet. Your A: drive refers to the diskette drive on the server. Q: Can I make Wabi access the diskette drive on some other machine? A: No, Solaris 2 doesn't currently support having one machine access a DOS diskette in the drive on a different machine. That's what the NOTES section of `man mount_pcfs` means when it says "pcfs is currently not NFS mountable. Trying to mount a pcfs file system through NFS will fail with an EACCES error." Wabi does not provide any functionality beyond what its host operating system provides. Q: How can I install applications onto a machine that doesn't have a diskette drive, such as an SS1000 used as a central Wabi engine? A: Go to a machine that has a diskette drive and copy all the installation diskettes to a single newly-created subdirectory that's available to others on the network. Then go to the machine that has no diskette drive, start Wabi, map a Wabi drive letter to the location you just copied the diskette contents to, and install the application. Copying all the installation diskettes to a single newly-created subdirectory will look something like this: # with Volume Manager handling the floppy drive # diskhost% cd /files/wabi diskhost% mkdir winapp.dsk diskhost% volcheck diskhost% cp -r /floppy/floppy0/* . diskhost% eject # repeat for each diskette # # without Volume Manager handling the floppy drive # diskhost% cd /files/wabi diskhost% mkdir winapp.dsk diskhost% mount -F pcfs /dev/diskette /pcfs diskhost% cp -r /pcfs/* . diskhost% eject # repeat for each diskette # Mapping a drive letter to the location of the diskette contents will look something like this: In Unix-- wabihost% cd /files1/maint wabihost% mkdir install.dsk wabihost% mount -F nfs diskhost:/files/wabi/winapp.dsk /files1/maint/install.dsk In Wabi: Open WabiTools:ConfigurationManager:Drives Connect I: -> /files1/maint/install.dsk If your system runs an automounter to access other systems, it's even easier. You don't need to do anything in Unix. Inside Wabi, just map I: -> /net/diskhost/files1/maint/install.dsk During installation when the application prompts for the location of installation files, replace 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 displaying its windows back to my machine with X? A: If you're executing Wabi remotely on some other machine and displaying its windows back to your machine, there's no way to map any drive letter (A: or B: or any other) directly to the diskette drive on your machine. However, you could use diskettes indirectly by copying all the files on a diskette to a location on disk where Wabi can access them. You work on the files on disk, and when you're finished, copy the changed files from the hard disk to the diskette. Here's an example of how to do this: Setup a "diskette directory" and connect a Wabi drive to it: In Unix: mkdir /files/diskette rm -rf /files/diskette/* In Wabi: Open WabiTools:ConfigurationManager:Drives Select drive X: Select /files/diskette Choose Connect Choose OK To copy the contents of a diskette to a hard disk: In Unix: mount -F pcfs /dev/diskette /pcfs cp -r /pcfs/* /files/diskette eject umount /pcfs To work from the hard disk copy of the diskette: In Wabi: read and write files as usual, except specify X: instead of A: To save the diskette files back to diskette when you're done working: In Unix: mount -F pcfs /dev/diskette /pcfs cp -r /files/diskette/* /pcfs eject umount /pcfs >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: sharing diskette drive between Wabi and SunPC Keywords: floppy disk drive diskette Wabi SunPC attach detach active use X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--flpshr.txt Number-62410 Version--2.4 Date--94/11/27 Q: Can both Wabi and SunPC share use of the diskette drive? A: Yes, Wabi and SunPC can share the diskette 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 diskette drive "attached" at the same time, but with some simple user actions, either process can use the drive. Q: How do I get SunPC to attach and detach the diskette drive? A: SunPC "attaches" the diskette 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 diskette. The SunPC user ejects the diskette using either the Operations menu, the Popup menu, or the Meta-E key. In SunPC, ejecting the diskette does not release the drive. Note that for SunPC to operate correctly with the diskette, volmgr diskette management must be turned off. Q: How to I get Wabi to use and release the diskette drive? A: Wabi does not have an attach/release mechanism. Wabi accesses the diskette if it is not controlled by another process. Once Wabi has accessed the diskette it keeps control of it until you eject the diskette using Meta-E. However, if you do not access the diskette after a certain period (30 seconds by default), Wabi releases it automatically. As long as no other process attaches the drive in the meantime, Wabi can access the drive again whenever a diskette is in the drive. Q: Is the Wabi 2.0 mechanism for releasing the diskette drive any different than it was in Wabi 1.x? A: Yes. New in Wabi 2.0 is the automatic release of the diskette drive after a period of inactivity, which is 30 seconds by default. You can change this period in Wabi's Configuration Manager tool. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--fntbug.txt Number-62420 Version--2.3 Date--94/11/27 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/fontconfig). ($WABIHOME is probably /opt/SUNWwabi.) Change 'Y' to 'N' on the line that describes your X-server. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: default font cache for Solaris 2.4 Keywords: Solaris 2.4 font path default cache file X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--fntlst.txt Number-62430 Version--2.5 Date--94/12/16 Q: The list of fonts given by `xlsfonts` is much much longer than the list presented by most applications running under Wabi. Why is that? A: `xlsfonts` lists the X11 fonts available on your system, while each app running under Wabi lists the fonts it's making available to you. There are three reasons why the lists are quite different. First, MS-Windows-based applications always present one entry for the entire font face while `xlsfonts` may list a separate entry for each font size and style such as normal, bold, or italic. Second, most MS-Windows-based applications filter the list of fonts down to manageable size. Some applications only list fonts known to be printable on your current printer as well as displayable on your system. Some applications only list fonts they consider well-known. Some applications only list the fonts that are explicitly mentioned in some *.INI file. And third, MS-Windows-based applications prefer to use fonts that they know are well supported by the Operating System, such as TrueType fonts which are well supported under MS-Windows. Q: I have a large number of X11 fonts available on my system. Will all those fonts be available to applications running under Wabi? A: Probably not. Since many MS-Windows-based applications ignore most or all available X11 fonts in favor of TrueType or MS-Windows bitmapped fonts anyway, having a large number of X11 fonts available on your system seldom translates into having those fonts available through applications under Wabi. Q: An X11 font that used to be available through one of my applications running under Wabi under Solaris 2.3 is no longer listed as available after I upgraded my system to Solaris 2.4. What can I do? A: Solaris 2.4 systems may contain any of 3 levels of fonts, depending on the amount of disk space on the system. Solaris 2.4 system installation can install the required X fonts, the common X fonts, or a full set of X fonts. In all 3 cases the font path is the same, so all these systems look the same to Wabi. The default font cache file supplied with Wabi 2.0 for OpenWindows 3.4 matches the X server if the lowest level of fonts (the required fonts) was installed so it doesn't contain information about fonts that your system may not have. This means that if your system has more than the lowest level of fonts, Wabi won't know about them. If you know you have more fonts on your system, and some of them used to be available through applications running under Wabi, you can make Wabi build a font cache file that matches your X11 system. Stop Wabi, execute the following commands in a shell window, then restart Wabi. Wabi will take a few minutes to start up the first time, and will start up promptly and work correctly from then on. cd ~/wabi/fc rm 0.fc touch 0.fc >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: font server Keywords: wabifs font server X11R5 TrueType displays X-Applies-To: X-Classification: X-Source-Info: Name--fntsvr.txt Number-62440 Version--2.3 Date--94/11/27 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 using 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 just sends 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 knows 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. This makes 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. There's no easy way for Wabi to find out whether 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/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. 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/fontconfig that describes your X-server. To get the information to enter, use the command 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, a `Y' as the third field, and "" 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: Can I make my system not use a separate font server process? A: You can disable Wabi's use of a separate font server process. To tell Wabi not to use a separate font service process with your X-server even though it usually would, edit file $WABIHOME/lib/fontconfig. Find the line that describes your X-server, and change the Y in the third field to an N. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: creating folders Keywords: directories folders create delete file manager mkdir rmdir rm X-Applies-To: X-Classification: X-Source-Info: Name--folder.txt Number-62450 Version--2.3 Date--94/11/27 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 maximum 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 which files will be used only by Wabi applications, which files will be used only by Unix applications, 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: additional fonts Keywords: Adobe Type Manager PC fonts X X11 default extra additional installation TrueType Type1 X-Applies-To: X-Classification: X-Source-Info: Name--fonts.txt Number-62460 Version--2.3 Date--94/11/27 Q: At the end of the installation of several applications, a message suggests we install the Adobe Type Manager. Is this recommended under Wabi? A: No, you do not need additional fonts to run applications usefully under Wabi. Wabi gives applications access to all the fonts in your X server (typically at least 10 typefaces) even if you have no PC fonts and no PC font manager installed. This is dramatically different from the situation under Microsoft Windows, where you get only a handful of typefaces by default (Times, Courier, Helvetica, Symbols). Defaults and suggestions provided by installation programs for Windows applications assume you're installing under Windows on a PC. They're often inappropriate for installing the application under Wabi. Q: Is Adobe Type Manager even supported under Wabi? A: No, Adobe Type Manager is not certified to run under Wabi, and may cause problems if it's installed and run. Q: Can I use Adobe Type 1 fonts under Wabi? A: Wabi's font server can handle Adobe Type 1 fonts, but you should consider other options first. If you want the font to be available to all applications on your desktop (not just applications running under Wabi), see if you can install the font directly into your X server. If the font appears in the list of available X fonts, Wabi and all other applications will be able to use it like any other X font. If you only need the font to be available to applications running under Wabi, consider obtaining it in TrueType format rather than Type 1 format. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: formatting floppy disks Keywords: format floppy disk diskette MS-Windows fdformat X-Applies-To: Wabi 2.0 on Sun Solaris/SunOS X-Classification: X-Source-Info: Name--format.txt Number-62470 Version--2.3 Date--94/11/27 Q: How can I format a DOS diskette for use with Wabi? A: Wabi doesn't support formatting of diskettes through File Manager, which is the way you'd do it under Microsoft Windows. You must either buy pre-formatted diskettes, or have an adminstrator pre-format batches of them, or add a command to Wabi. Q: How would an administrator pre-format a batch of diskettes? A: Format diskettes through Unix rather than through Wabi. Use `fdformat -t dos` from a Unix command window. See the Unix man page for fdformat for more information. Note that if Wabi has recently used the diskette drive, you may get a "device busy" message when you use the fdformat command. If this happens, make sure Wabi is not accessing the diskette drive (e.g., don't have the A: drive open in Windows File Manager), and then wait 30 seconds for Wabi to release control of the drive before trying the command again. Q: How would I add a command to Wabi to format DOS diskettes? A: Create a file called format.exe containing these lines: #!/bin/sh /usr/bin/fdformat -eft dos >/dev/console 2>&1 Run command in Program Manager. This is not quite the same as formatting through File Manager under Windows on a PC, but it works. Note that your Unix console window will display any error and status messages from the command. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: floating point Keywords: coprocessor x87 floating point math emulator inline RISC x86 X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--fp.txt Number-62480 Version--2.4 Date--94/12/06 Q: How are floating point operations handled when Wabi runs on x86 hardware? A: The application asks at load time (or run time depending on how the application was compiled and linked) if the system has a floating point coprocessor. Wabi answers with the actual capabilities of the hardware. Since Solaris 2 for x86 requires a floating point coprocessor, the answer given by Wabi under Solaris 2 is always "yes, a floating point coprocessor is present." Application execution proceeds just as it would under MS-Windows. Typically this means floating point opcodes are passed directly to the machine's floating point hardware. Q: How are floating point operations handled when Wabi runs on RISC hardware? A: The application asks at load time (or run time depending on how the application was compiled and linked) if the system has a floating point coprocessor. Wabi answers "yes, a floating point coprocessor is present" since Wabi will translate floating point opcodes the same as any other opcode. Application execution proceeds just as it would under MS-Windows on hardware with a floating point coprocessor. In most cases an application's floating point operation request is passed through unchanged to the RISC hardware's FPU. As long as the application 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: Has Wabi always handled floating point operations this way when run on RISC hardware? A: No. Some earlier versions of Wabi relied on trapping of floating point opcodes into WIN87EM.DLL. When asked if the system has a floating point coprocessor some earlier versions of Wabi answered "no" when running on RISC hardware. Q: What about applications that *require* that an 80x87 floating point coprocessor be present before they will run? A: The vast majority of applications follow the recommended build procedure to run either with or without a floating point coprocessor. Under MS-Windows, these applications run whether or not the system has a floating point coprocessor. They just run faster if a floating point coprocessor is present. These applications run fine under Wabi. A few applications that think they will run unacceptably slowly without a floating point coprocessor *insist* that a math coprocessor be present. Usually these applications are built with /FPc87 or /FPi87. These applications also run fine under Wabi. Q: Performance of a very math-intensive application under Wabi on SPARC seems to be much slower than on a DX-33. Is this expected? A: Wabi excels with display-intensive applications. 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 applications do not perform as well under Wabi. If you need serious number crunching power, consider running the number crunching application native. The combination of the interaction of two operating systems (Solaris and Wabi) with block translation of integer, control, and floating point opcodes may make Wabi on a RISC machine run compute-intensive applications slower than they run under Windows on a PC. 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, floating point intensive applications would be much slower. Q: Which floating point build option should I use to build an application to run under Wabi as well as under "real Windows"? A: Use the same build option you'd use to build an application to run under Windows on machines both with and without a floating point coprocessor. /FPi87 and /FPc87 will restrict your application to running only on machines that have or say they have an Intel-style floating point coprocessor. Such applications will run fine under Wabi on any hardware, but may not run on all systems under "real Windows". >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--fpieee.txt Number-62490 Version--2.3 Date--94/11/27 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 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 application *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 could be made to use the Windows win87em.dll instead of the SPARC FPU. However, doing this would degrade performance significantly since all floating point operations would be simulated in software using only integer operations, so we don't recommend it. You can start Wabi with a -softfpu switch to make it use the win87em.dll. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi User's Guide hardcopy Keywords: copy center document number hardcopy X-Applies-To: X-Classification: Sun Proprietary/Confidential: Internal Use Only X-Source-Info: Name--hardoc.txt Number-63130 Version--2.2 Date--94/12/19 Q: How can I get a hardcopy of the Wabi 2.0 User's Guide? A: One way for Sun employees to get a hardcopy of the Wabi 2.0 User's Guide is to order part number 802-2527-01 from copyrequest@sun. Q: Is a printable PostScript version of the entire Wabi 2.0 User's Guide available electronically? A: Yes. You can use either Mosaic or anonymous FTP to get the Wabi 2.0 User's Guide from the same location that supplies Wabi software. Once you have these PostScript files you can print them. Q: Can't I just print the Answerbook files? A: Yes, you can print Answerbook files without using or even having Answerbook software. Answerbook files are printable PostScript files with comments heavily interspersed. A PostScript printer will ignore all of the comments, so you can simply print Answerbook files. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: hardware/software requirements Keywords: SPARC x86 SunOS4 Solaris ow3_u1 X-Applies-To: X-Classification: X-Source-Info: Name--hs_req.txt Number-62500 Version--2.4 Date--94/12/05 Q: What are the hardware/OS requirements of Wabi 2.0? 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.4 or 2.3, or an Intel machine running Solaris 2.4 or 2.1. You can run this version of Wabi even if your desktop machines are running Solaris 1. Run Wabi under Solaris 2.3 or 2.4 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 configuration, consider using x86 hardware running Solaris 2 for 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 applications but showed up when it was driven by complex applications 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 SunSoft 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 adequately run the OS, the window system, and common Unix-based applications. If the performance of Unix-based applications such as Mail Tool isn't up to your standards, the performance of Windows-based applications running under Wabi won't be either. For SPARC systems running Solaris 2 you should have at least 32MB. For Intel systems running Solaris 2 you should have at least 16MB and preferably 24MB. Q: How do I find out how much RAM my system has installed? A: On any Solaris 2 system you can execute `prtconf` to find out how much RAM your system has installed as well as many other things about your system. Your site may also provide other tools, such as `whatami` or `wsinfo` that display how much RAM your system has installed. From gabe@netcom.com Sun Jan 8 02:42:58 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19614; Sun, 8 Jan 1995 02:11:27 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25897; Sun, 8 Jan 95 02:11:58 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07523; Sun, 8 Jan 95 05:11:53 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02579; Sun, 8 Jan 1995 05:11:48 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA05969; Sun, 8 Jan 95 05:11:53 EST Date: Sun, 8 Jan 95 05:11:53 EST Message-Id: <9501081011.AA05969@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 4/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 107103 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 4 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: icon overlap Keywords: SunOS4 Solaris OpenWindows X-Applies-To: X-Classification: X-Source-Info: Name--icnovr.txt Number-62510 Version--2.3 Date--94/11/27 Q: How do I keep OpenWindows icons and Wabi icons from overlapping each other on my screen? A: From the OpenWindows root menu select Properties..., go to the Miscellaneous category, and select "bottom" "left" or "right" (but not "top") for Icon 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 OpenWindows application is Closed, its icon is placed at the top, bottom, left, or right edge of your screen depending on the OpenWindows property setting. When a Wabi group is Minimized, its icon is placed within the Program Manager window. When an individual Wabi application or file is Minimized, its icon is 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: icons Keywords: icons groups desktop X-Applies-To: X-Classification: X-Source-Info: Name--icons.txt Number-62520 Version--2.3 Date--94/11/27 Q: When I copy an application to Wabi, why doesn't the application show up on my Windows desktop immediately? A: The Microsoft Windows desktop is similar to the OpenWindows desktop in that you can have executables available yet not have desktop icons for them. (And icons in MS-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. To start a Wabi application without an icon, use the File->Run command in Program Manager, and type in the path and name of the application you want to run. 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 Program 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 with a .GRP extension. 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 Program Manager? A: Program 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 Program 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: idle looping Keywords: shared central Wabi engine share spin idle loop CPU use poll busy X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--idloop.txt Number-62530 Version--2.4 Date--94/11/27 Q: Why do a few Windows applications seem to use a lot of CPU time, even when they aren't doing much of anything? A: When Microsoft Word is idle, it 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 whenever 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 behave the same way under Windows on a PC, but you don't see it so easily without monitoring utilities like perfmeter or vmstat. (Also, under Windows it matters less because it's unlikely there's any other important processing happening on the system.) Q: Will the next release of these ill-behaved applications behave better? A: Almost certainly yes. We expect the misbehavior of these applications to be corrected in the near future. It's becoming widely known that these applications interfere with power-saving technology (e.g., they prevent laptop PCs from going into standby mode to conserve their batteries when idle). So there's pressure on the ISVs to modify these applications. Even if the application misbehavior is not corrected, Wabi 2.0 will detect this situation and handle it gracefully. Q: If idle users leave one of these ill-behaved applications up, they load the CPU of my central Wabi engine so much that the performance seen by other Wabi users is degraded. What can I do about this? A: You don't need to do anything. Wabi 2.0 detects idle loops in ill-behaved applications and throttles back their use of the CPU if other processes need to use the CPU. Q: If Wabi 2.0 can detect idle loops in ill-behaved apps, why does the CPU usage sometimes go to 100% anyway? A: Since it can't be certain that an application is in an idle loop, Wabi 2.0 throttles back the application only if some other process needs the CPU. If no other process needs the CPU Wabi 2.0 will let the application running under it consume all 100% of the CPU even though the application appears to be in an idle loop. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: installing applications under Wabi Keywords: install application run compression speed C: share X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--insapp.txt Number-62540 Version--2.3 Date--94/11/27 Q: Where can I get more information about the process of installing applications? A: Start with each application's own installation instructions for the specific commands needed. Next be sure to check the Wabi 2.0 Release Notes (in the Wabi Tools group) for any special installation procedures for particular applications. Chapter 8, "Installing and Using Microsoft Windows Applications" in the Wabi 2.0 User's Guide contains detailed information about how to install an application. You may also want to refer to a recent version of the certified application notes by sending email To: wabi2.0-apps@east.sun.com Q: Why might application 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, applications should be installed through the File->Run menu option of Program Manager. Avoid double-clicking on the SETUP.EXE (or INSTALL.EXE) program in the Windows File Manager. Q: Where should I install applications? On my C: drive? A: Most application installation procedures, when they sense a "standalone" environment, suggest a location on your C: drive. Change this default location to some other drive, for example G:. Installing applications 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 applications that must access a simulated hard drive for their copy protection scheme to work. Q: What if installation of an application fails? Does that mean it definitely will not work under Wabi? A: No. Many applications run fine under Wabi although their installation procedure will not run under Wabi. If installation under Wabi fails, install the application on a real PC. Then copy the entire application (typically the entire contents of a subdirectory tree, an {application}.ini file in C:\WINDOWS, an {application}.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 I should copy? 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 application 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 some application installs take so long, especially since a few standalone application installs and most node/client application installs complete 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 a "standard" compression algorithm that Wabi provides itself -- -- these are the packages that install quickly. Unfortunately most packages use compression algorithms which Wabi doesn't provide itself. In these cases Wabi has to execute the decompression code as Intel opcodes. Q: What can I do to make application installation easier? A: Here's some things to try: 1) Investigate to see if the application 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. 2) 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 application once. Most of the qualified applications provide a "shared" or "server/client" or "network" install option. It should work under Wabi 2.0. Use it. 3) See if the ISV supplies the application on a CD-ROM as well as on diskettes. Wabi installs applications 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. 4) 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. This is useful if many users will be installing standalone copies of the application and the application itself doesn't provide either a "partial" install mechanism or a "shared/server" install mechanism [points 1) and 2) above]. It's less useful, or even harmful, if the application provides either of these options. For example some application install programs wll only present their shared/server install option if they're being run from physical floppies. They won't present their shared/server install option if they're being run from a diskette image created in this way. Most applications 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 application 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 ... Q: Many application installation programs take over the whole screen when they're installing the application. 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: Some 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. This is seldom an issue any longer. Current versions of some applications provide an install option to control whether *.DLLs are stored with the application's executables or in C:\windows\system. And since all Wabi 2.0 systems will have MS-Windows installed, applications won't ever need to install *.DLLs that are usually though of as part of "real Windows". >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: sharing apps Keywords: share shared sharing network networked .INI .DLL one single copy app application X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--insash.txt Number-62550 Version--2.7 Date--94/12/20 Q: When Wabi is run, it creates $HOME/wabi for each user and maps it to C: for that user. Does that mean that all software installed through Wabi is installed on a per-user basis? Or can I install an application once in a shared/server/network configuration and have other users mount and use it? A: This depends on the application. As the Windows market matures, most high-volume applications are making LVEU (Large Volume End User) installations easier. If an application provides a way to use it in a network configuration, you can use it that way under Wabi 2.0. Q: Can I use an application's shared/server/network installation option to install the application in such a way that several users or systems can share one copy of it? A: Yes. Wabi 2.0 fully supports file sharing, file locking, and all of the different ways an application may ask if a drive is a "network" drive. So all application "network install" options and shared/server/network runtime behaviors will work under Wabi 2.0. Q: The application's documentation mentions a shared/server/network install option or configuration. Can I just follow those directions under Wabi? A: Yes. Under Wabi 2.0 you should simply follow the application's directions. For example for MS-Office run "setup /n". Trying some other way to set up an application for shared/server/network operation is difficult, unnecessary, and can lead to subtle undetected problems that result in data loss several days or weeks later. A shared/server/network application installation should be done the same way under Wabi as it would be on a PC running MS-Windows. Wabi doesn't do anything differently or additionally. If your procedure for installing and configuring a shared/server/network application wouldn't work under MS-Windows, then it won't work under Wabi either. Q: Can I install a private copy of an application then later convert it to a shared/server/network configuration that can be accessed by multiple users? A: Not easily. If you intend for an application to be shared by several users you should do a shared/server/network installation right from the start. Since each application implements its shared/server/network configuration support a little differently, trying to convert an existing application installation to a shared/server/network configuration is very error prone. Q: How do I access the application's shared/server/network installation option? A: This differs from one application to another. Some applications require you to specify a command line parameter when starting their installation program (e.g. "setup /n"). Some applications automatically present their shared/server/network installation option whenever it seems to be appropriate, for example when network drives are present. (Sometimes when this happens the appearance of the installation program on your screen will be so different you'll think you're running a different program.) Very ew applications have two separate installation programs, one for private installation and the other for shared/server/network installation. Q: Do I need to get a different ("network aware") version of the application in order to do a shared/server/network installation? A: Almost certainly not. All applications that we know of include whatever network support they have right in the standard version of the application. Although several years ago there may have been separate "network aware" versions of many applications, such versions don't exist any more. Q: Although the application's documentation mentions a shared/server/network install option, I don't see it when I try to install the application under Wabi. What should I do? A: First, use WabiTools:ConfigMan:Drives to check both the "Network Drive" and "Sharing" boxes on all drive letters the application install will reference. Many application installation programs if they don't sense any network drives won't mention their shared/server/network installation option. Second, try running the install using the actual floppy disks or CD-ROM. Some application install programs detect what kind of device they were loaded from and don't present the shared/server/network install option unless they're being run from a physical floppy. Copying the application install diskettes to a hard drive, which we suggest as a way to speed up application installs, can confuse some application install programs to the point where they won't present their shared/server/network install option. Do the shared/server/network install of these applications from the physical floppies. The slowness of the application install shouldn't be a concern since you only have to do the shared/server/network install one time to support many users. Q: The application's installation program provides a "network" option but it doesn't seem to have anything to do with multiple users sharing one server copy of the application. What is this option? A: Many applications also provide an installation option that decompresses all their files and "stages" them to a hard disk so that individual users can later install a private copy of that application without having to obtain the floppy disks. If an option like this is available it's probably called a "network" option even though it has nothing to do with shared/server use of the application. Ignore this option and continue to look for one that explicitly refers to application sharing. Q: Do I need to install Windows for Workgroups rather than regular MS-Windows in order to share an application? A: No. Wabi 2.0 fully supports shared/server/network application installation and use with only regular MS-Windows 3.1 or 3.11 present. You do not need Windows for Workgroups. In fact, you should not install Windows for Workgroups. Not only is there no reason to do so, Windows for Workgroups is incompatible with Wabi 2.0 and attempts to install it will cause problems. Q: What userid should I run Wabi as when I install the shared/server part of the application? A: Set up a Unix login ID for the Wabi administrator that's different from the login ID of any end user. Login, start Wabi, and do the shared/server/network application installation as that userid. Q: What drive letter should I install an application on? A: If anyone other than yourself might ever use the application, you should install it somewhere other than on C:. If you're using a drive letter you haven't used before use WabiTools:ConfigMan:Drives to define a mapping for the drive letter. Q: Can I install the application through a temporary drive letter and then define the real drive letter for users to use later? A: Choose the final drive letter for users to use before you begin. And install the server/network part of the application through that same drive letter. Applications may embed drive letter information in their *.INI files in such a way that they will not run from a drive letter other than the one the server/network part was installed into. Q: Can I install an application on C: and then later set up access to it through a different drive letter for shared/server/network use? A: Probably not. First, the application will remember you originally installed it on C: and will not work properly when accessed through some other drive letter. And second, since the application wasn't originally installed in a shared/server/network configuration it may not ever work in that configuration. Q: Why do most application install programs default to installing the application on C:? A: Most of the time, applications are still installed on standalone systems (PCs). The C: is a good guess for the install location on standalone systems. That's why many application installation programs supply C: as a default. Once you select a shared/server/network application configuration many application installation programs will realize that C: is not appropriate and will stop supplying it as the default drive letter. Q: How much disk space do I need on that drive letter? A: You need enough disk space to install all the shared/server/network files needed by the application. It's not unusual for one application to require several tens of megabytes or for an application suite to require over a hundred megabytes of space. Q: When I install MS-Office in a shared/server/network configuration I get a message about "write access to the shared Windows directory," What should I do? A: You can ignore this message. Despite what this warning seems to imply, you can have either shared MS-Office or shared MS-Windows without having the other. To say it another way, despite what this warning seems to imply you can have shared MS-Office without having shared MS-Windows. (This warning message is so often misunderstood even in the real PC world that Microsoft has produced a tech note about it.) The kernel of truth behind this message is that MS-Office would like to "extend" MS-Windows itself and so would like to install some files into C:\windows\system and have these files be accessible to all users. But there are other ways to make these files accessible to all users than having all users share a single copy of C:\windows\system. Q: What things should I consider if I try to have several users share one copy of an application? A: If material on shared/server/network use is included in the application's documentation, the ISV has already thought about all these issues. Everything should work correctly all by itself. If something doesn't work, or if you want to understand more about what's going on, here's a list of issues that someone had to think about when preparing an application for shared/server/network use: 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 the same time. For this reason the application will arrange at some time --maybe server install time, maybe client install time, maybe runtime-- for each user to have their own *.INI file. 3) Some applications may 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. For this reason the application will probably install DLLs into the same directory as the application executable instead of into C:\windows. That way all users can see and share a single copy. Since the directory where a *.EXE file was found is included on the search path for *.DLLs requested by that executable, all users that can start the application will automatically be able to find the needed *.DLLs. 4) Applications that don't do any record/file locking shouldn't be shared. Applications that are intended for shared use will do record/file locking as needed. 5) An application may require that file sharing be turned on. If so, use WabiTools:ConfigurationManager:Drives and check the Sharing box for whichever drive(s) the application requires. This will probably be either the drive where the application executable resides, or the drive where data manipulated by the application resides, or possibly both. Q: Is there a way I can get a quick idea for how difficult it would be to make an application work in a shared/server/network configuration under Wabi? A: Look through the application's documentation. If the documentation includes a chapter or an appendix or a separate book on the subject then the ISV has thought about it, and all you need to do is follow the application's directions. If however there's no documentation on the subject, then the ISV hasn't thought about it, and it will be virtually impossible for you to do. Q: Is there a way I can check whether or not an application I think I've installed in a shared/server/network configuration will actually work correctly if used by several users? A: Yes. Mount the file system containing the application "read-only". Start Wabi as a different userid than the one you used when installing the application, and start the application. 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 application's windows. Quit the application. Restart the application 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 application will work correctly for multiple users. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: installing MS-Windows Keywords: MS-Windows install under merge applets games starting non windows program X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--inswin.txt Number-62560 Version--2.12 Date--94/11/27 Q: Does Wabi 2.0 require you to install Microsoft Windows? A: Yes. Wabi 2.0 provides the core functionality of Microsoft Windows (all of KERNEL.DLL, USER.DLL, GDI.DLL, WIN87EM.DLL, and WINMEN32.DLL; CONFIG.EXE and APPMAN.EXE; and parts of KEYBOARD.DLL, SYSTEM.DLL, SOUND.DLL, TOOLHELP.DLL, DISPLAY.DLL, MOUSE.DLL, and MMSYSTEM.DLL.). Wabi 2.0 requires that you install Windows to provide the non-core functionality. Q: Why must Microsoft Windows be installed with Wabi 2.0? A: SunSoft requires users to install Microsoft Windows with Wabi 2.0 to ensure that all of the certified applications will execute properly in the Wabi environment. Some of the applications certified to run under Wabi require the presence of certain Dynamically Linked Libraries (DLLs) that no longer ship with the applications themselves. Instead, such applications rely on DLLs provided by Microsoft Windows. To meet our customer requirements, SunSoft has chosen to invest its engineering resources in improving performance and creating new functionality for Wabi rather than replicating all of the DLLs in MS Windows. This decision has enabled the Wabi development team to concentrate on delivering a high quality product and will permit ongoing development to focus on new features and enhancements. Please note that although the applets (accessory programs) that ship with Microsoft Windows will run under Wabi, the presence of MS Windows does not otherwise affect the number of applications that are able to run under Wabi. 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 parts of MS-Windows are "merged" into Wabi. Wabi 2.0 supplies a complete set of configuration tools. Most of the Windows configuration tools are at best duplicates that are irrelevant to the Wabi environment. Wabi omits as many duplicate, meaningless, misleading, 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 MS-Windows? A: No, there must be a separate copy of the windows directory for each user. MS-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 small in comparison to the amount of disk space that would be required to give a separate copy of applications to each user. Wabi 2.0 allows users to share a copy of an application whenever that application has a shared install option. Thus Wabi 2.0 can save a large amount of disk space per user (possibly 100MB !) compared to Wabi 1.x. 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: Is it theoretically possible for several users or systems to share all of one copy of MS-Windows? A: Not really. Some parts of MS-Windows, analogous to the parts of Solaris stored under /usr, can be shared. But other parts, analogous to the parts of Solaris stored under / (root partition), cannot be shared. Trying to share all of MS-Windows is like trying to have two systems run the same Solaris kernel. Q: If it's not really possible for several users or systems to share all of one copy of MS-Windows, why does MS-Windows support a "shared install" option? A: The "shared install" option really shares only the parts of MS-Windows that are sharable, not the whole thing. Even with the "shared install" option selected each user is given their own copy of many files. Q: Does the user's copy of the windows directory need to be stored on a local disk? A: No. $HOME/wabi/windows can be NFS-mounted from a remote file server. All that Wabi needs is for $HOME/wabi/windows to not be shared by another user. Q: Can the user's copy of the windows directory be used by both DOS/Windows and Solaris/Wabi on the same x86 system? A: Yes, $HOME/wabi/windows can point at the windows directory in a DOS/Windows partition that isn't currently booted. All that Wabi needs is for $HOME/wabi/windows to not be shared by another user. 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, Windows Install expects a German version of MS-Windows. The only time you might have a problem with this is if you've installed Wabi onto a file server configured for one locale (e.g., USEnglish), and are mounting it from your workstation which is configured for a different locale (e.g., German). When you run "Windows Install" from your workstation, Wabi compares the locale of the file server (USEnglish) to 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, the directory /opt/SUNWwabi/lib/locale//wabi (with being equal to the locale setting Wabi's using) exists and is readable. Also, be sure that the configured locale of your workstation matches the locale of the MS-Windows diskettes you're supplying to the Windows Install program. See the International Settings chapter in the Wabi 2.0 User's Guide for more information on locale setting. Q: Can I install Windows-for-Workgroups rather than MS-Windows? A: No. Windows-for-Workgroups is internally different enough from MS-Windows that Wabi can't make use of it. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: interprocess communication Keywords: shared files tooltalk DDE OLE OLE2 X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--ipc.txt Number-62570 Version--2.4 Date--94/11/27 Q: Is it possible for a Wabi application to communicate with a Unix application? A: Yes. One way for a Wabi application and a Unix application to communicate is through shared files. This was possible even with Wabi 1.x. Have one application open a file, write a "work request," and close the file. Have the other application open the file, see a change, consume the "work request," close the file, and perform the request. This method may be sufficient if the level of interaction needed isn't very high. A more powerful way for a Wabi application and a Unix application to communicate is through sockets. This is a new capability in Wabi 2.0. Since Wabi 2.0 includes the WinSock API (internally, not as a .DLL), the Wabi application and the Unix application can use sockets to access what amounts to a TCP pipe between the two applications. Performance will be good, reliability is guaranteed (this is TCP), and it will handle much finer grained interactions than the shared file approach. An advantage of communicating through sockets is that it works the same whether the applications are on the same machine or are on different machines. Q: Might some future version of Wabi support any other interprocess communication techniques? A: Yes. A future version of Wabi may include an OLE<->ToolTalk translation. With the OLE<->ToolTalk approach, and possibly a bit of development on the Unix side, you'll be able to implement the same sorts of things you can with ToolTalk between two applications under OpenWindows, or with OLE between two applications on a PC. The definition of an OLE<->ToolTalk translation will wait until COSE is better defined and until many of the significant technical obstacles to OLE<->ToolTalk interoperability are resolved. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: iso_8859_1 character set and Wabi's keyboard Keywords: iso_8859_1 LANG WABI_KEYB locale X-Applies-To: X-Classification: X-Source-Info: Name--iso.txt Number-63120 Version--2.1 Date--94/12/19 Q: What should I do when Wabi says 'The read of the keytable file "/opt/SUNWwabi/lib/locale/iso_8859_1/wabi/wabi_kb" failed'? A: Set the WABI_KEYB environment variable to whichever supported locale in /opt/SUNWwabi/lib/locale matches your keyboard. Alternatively, create a symlink from "iso_8859_1" to either "en_uk" or "en_us" in /opt/SUNWwabi/lib/locale. Q: When will this problem show up? A: When your system's LANG environment variable is set to "iso_8859_1." Q: Why does this problem occur? A: Wabi assumes that the value of the LANG environment variable corresponds to the locale of your keyboard. But this assumption is not always valid. Q: What's the relationship between the LANG and WABI_KEYB environment variables? A: If neither is set, Wabi defaults to the 'C' locale. If only LANG is set Wabi uses it as the locale of your keyboard. If WABI_KEYB is set, Wabi uses it as the locale of your keyboard. This is true even if LANG is also set -- in other words WABI_KEYB overrides LANG. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: non-English keyboards Keywords: dead keys accents WABI_KEYB LANG alt-graph X-Applies-To: X-Classification: X-Source-Info: Name--keyb.txt Number-62580 Version--2.3 Date--94/11/27 Q: I have a non-English keyboard. It works fine with the OpenWindows DeskSet tools and other X applications. But inside Wabi neither the dead keys nor the Alt Graph Shift work. What should I do? A: In the environment where you start Wabi, set environment variable WABI_KEYB for the language of your keyboard. Values for this variable are the same as for the environment variable LANG, and are similar to the values for the DOS KEYB setting used for MS-Windows. See the International Settings chapter of the Wabi 2.0 User's Guide for a list of acceptable values for WABI_KEYB. 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. Q: Do I have to set WABI_KEYB in Wabi 2.0 like I did in Wabi 1.x? A: Yes. Wabi 2.0 still requires you to explicitly set environment variable WABI_KEYB even though the rest of your desktop may auto-configure itself to match your keyboard type. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--keymap.txt Number-62590 Version--2.3 Date--94/11/27 Q: How do I Maximize, Minimize, re-order, or Close the windows of applications running under Wabi? A: You do these things the same way you would in Windows. Click on the buttons in the top right corner of the application's window frame to minimize and maximize, or use the menu opened by clicking the top left Wabi logo in each window frame, or use the Window menu in Program Manager to rearrange windows. The keyboard shortcut keys labeled Front and Open may not work the way they do with X applications. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--knlmod.txt Number-62600 Version--2.6 Date--94/12/16 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. 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. 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 then stays resident in the kernel until the kernel decides that it's 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 for Wabi. First, it aids the interface between Wabi and the Volume Manager. And second, it helps Wabi implement "file sharing." Q: How does Wabi's kernel module aid the interface between Wabi and the Volume Manager? A: Wabi's kernel driver provides stable storage for some data needed for communication between Wabi and the Volume Manager. While there are other ways to implement this, for example with files under /tmp, the kernel module is the simplest and most reliable way. Q: How does Wabi's kernel module help implement "file sharing?" A: Wabi's kernel driver gives wabiprog direct access to the network file handle of any file. For files being accessed over NFS, this is the "magic cookie" that was provided by the file server where the file resides. For local files that have been exported for possible NFS access by a remote system, this is the "magic cookie" that would be provided to a remote system. And for local files that have not been exported, this is the "magic cookie" that would be constructed by NFS if the file were exported. Wabi needs this "magic cookie" so it can build RPC requests to the remote lock daemon and thus fully implement "file sharing." Wabi has to build the RPC requests itself because the kernel does not provide client-side access to file sharing functionality. fcntl() provides access only to file locking functionality, not file sharing functionality. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--licens.txt Number-62610 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: software installation location Keywords: default pkgadd opt /opt X-Applies-To: Sun Wabi X-Classification: X-Source-Info: Name--locate.txt Number-63110 Version--2.1 Date--94/12/19 Q: Where is Wabi software installed by default? A: Under /opt. Q: Does Wabi software have to be installed under /opt? A: No. Installation of the Wabi software package is just like installation of any other software package. The default basedir /opt is coded into the package ans is assumed in the documentation, but doesn't absolutely have to be used. Q: Do I have to repartition my disk if /opt is a small partition without enough room for Wabi software (or just a directory and not a disk parition at all? A: No, you don't have to repartition your disk. Create a symlink /opt/SUNWwabi->[elsewhere] before you install the Wabi package. The Wabi software will appear to be under the default location /opt as expected, but will actually be stored in some other location where there's plenty of space. Q: What are the advantages and disadvantages of creating a symlink to force software to be installed at a different location? A: One advantage is that the software appears to be in the default location even though it's really stored elsewhere. So all programs and procedures that look in the default location will find it. Another advantage is that the product documentation makes sense exactly as is. The only disadvantage is that if you install multiple versions of a package onto the same machine at the same time by manipulating the symlink, the "pkgadd" database may get confused about what software is installed where. Q: Is there any other way to install a package to a location other than its default basedir? A: Yes. Add the "-a none" paramemter when executing pkgadd (`pkgadd -a none -d ...`). This will force pkgadd to ignore all defaults. When pkgadd asks you for the "basedir", enter the location where you want the software installed. Q: What are the advantages and disadvantages of using "-a none" to force software to be installed at a different location? A: The advantage is that the "pkgadd" database will contain the actual location of the software and so will exactly match your machine. One disadvantage is that the product documentation won't quite match your system. Another disadvantage is that it may be more difficult for a serice person to understand your system configuration over the telephone. Q: Which method should I use to install Wabi software to a location other than the default /opt? A: We recommend you use the symlink method. Create a symlink /opt/SUNWwabi->[elsewhere] then proceed with the software installation. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: launching Wabi apps separately from Unix Keywords: minus s coalesce address space DDE OLE OLE2 process ps X-Applies-To: X-Classification: X-Source-Info: Name--minuss.txt Number-63140 Version--2.1 Date--94/12/20 Q: When two Wabi applications are launched separately directly from the Unix command line, what happens to the Wabi processes? In other words, if I "wabi -s " and then "wabi -s " do I get two separate copies of Wabi? A: The two Wabi's will recognize each other and coalesce into a single process. This happens when the second Wabi is started. It happens so quickly that you may only ever see a single Wabi process. When the two Wabi processes coalesce the parameters of each one are combined and all executed by the single remaining Wabi process. So for example if two Wabi's each had a "-s " parameter, the single remaining Wabi process would have two applications. Q: Does "coalesce" just mean that the two Wabi processes will share one set of executable code pages in memory? A: "Coalesce" means much more than just sharing RAM. The two Wabi's will literally become one process. The `ps` command will show only one Wabi. Q: After the two Wabi's coalesce, do they share a single address space? A: Yes. What was originally two Wabi processes will share a single address space. So the applications that were running under each of the Wabi's will be aware of each other and will be able to communicate with each other through shared memory. Q: If all the Wabi's share a single address space, does this mean it's possible to do DDE/OLE/OLE2 between applications that were launched separately as "wabi -s " and "wabi -s "? A: Yes. Applications will behave exactly the same way whether they were launched separately from what were initially separate Wabi's, or launched from the same Wabi. You can do all the same DDE/OLE/OLE2 operations between applications launched with "-s" as you can between those applications when they are both launched from a single copy of Wabi. Q: Has Wabi always behaved this way? A: Yes, all released versions of Wabi have always behaved this way. Wabi has behaved this way ever since Wabi 1.0. Some pre-1.0-FCS versions of Wabi did not have this behavior. So if you tested a very early version of Wabi a long time ago you may have seen different behavior. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: module loading order Keywords: Quicken 4.0 DLL EXE X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--modord.txt Number-63100 Version--2.1 Date--94/12/19 Q: Can I get Quicken 4.0 to run under Wabi 2.0? A: Reports are that although it's not on the PCDI-certified list, Quicken 4.0 will install and run under Wabi 2.0. Both when you install Quicken 4.0 and when you run Quicken 4.0 you should setenv WABIMODORDER 1 before you start Wabi. Q: Should I set WABIMODORDER only when running Quicken 4.0, or can I set it all the time? A: You can set it all the time. All applications will work correctly with WABIMODORDER set. You can put "setenv WABIMODORDER 1" right into your Wabi startup command so that it's always executed. Q: Will I have to set WABIMODORDER in the next release of Wabi? A: No, the next release of Wabi will behave as if WABIMODORDER was always set. If you do set WABIMODORDER, it won't hurt anything as the next release of Wabi will simply ignore it. Q: What does WABIMODORDER do? A: It reverses the order in which a .EXE and a .DLL file with the same base name will be loaded. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--mono.txt Number-62620 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--motif.txt Number-62630 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: multimedia Keywords: sound video extensions multimedia API X-Applies-To: X-Classification: X-Source-Info: Name--multim.txt Number-62640 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: networking support Keywords: 2.0 WinSock Windows Sockets NetBIOS SPX IPX Novell Netware PC-NFS PCNFS Pro TCP/IP X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--netwrk.txt Number-62650 Version--2.8 Date--94/12/20 Q: What are some of the ways Wabi supports networking in addition to providing a networking API to applications running under it? 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 Microsoft Windows file and record locking options are fully supported, via RPCs to a remote lock daemon when necessary. Q: Can Wabi 2.0 support applications which make TCP/IP socket calls? A: Wabi 2.0 supports the WinSock networking API to the extent necessary to support the certified applications. The Lotus Notes 3.0c client is the only application certified under Wabi 2.0 that uses the WinSock networking API. Q: Do I need to install any additional software to get networking support under Wabi? A: No, you do not need to (and in fact should not) install under Wabi any networking software package such as PC-NFS or PC-NFS Pro or any networking software file such as WINSOCK.DLL, either from Sun or from a third party. Support for network drives and network printers has been built right into Wabi since Wabi 1.0. And the WinSock API is built right into Wabi 2.0. Q: Do I need to install any additional software to get the Lotus Notes client to work under Wabi 2.0? A: No. All the software you need to run the Lotus Notes 3.0c client is built right into Wabi 2.0. If you are having a problem getting the Lotus Notes client to run, check your installation and configuration. Q: What is WinSock? A: WinSock (Windows Sockets) is an extension of the familiar Unix sockets networking API to make it usable under the tasking model of MS-Windows. The initial version of WinSock provides access only to TCP/IP networking. (Extensions to WinSock for items such as telephony have been proposed.) The same extensions to sockets needed under MS-Windows are also needed under Wabi, for the same reason. Q: If Wabi 2.0 provides the WinSock networking API, why don't I see a file named WINSOCK.DLL? A: Remember that the functionality and the implementation are separate issues. The fact that you don't see a separate file with the name you expect doesn't mean the functionality isn't there. Wabi provides the functionality of the WinSock API standard. The way Wabi does this is quite different from implementations under DOS/Windows. Wabi implements this functionality as an integral part of the wabiprog executable, and does not distribute it in a separate files. Q: Does Wabi 2.0 fully support WinSock? If not, how is this "partial" support defined? A: In Wabi, support is specified in terms of what applications we've tested and certified to run correctly rather than in terms of functionality blocks. The question "how is partial support defined" doesn't make sense in this context. Here's the operational definition of what is and isn't supported: If a bug in Wabi's WinSock manifests itself as misbehavior of a certified application, we'll fix it. But if a bug in Wabi's WinSock does not manifest itself as misbehavior of a certified application, we're not committed to fixing it. To put it another way, although Wabi's WinSock support was developed and tested to the extent necessary to get the networked programs on the "PCDI-certified" list to work, there's no guarantee that _all_ of WinSock will work correctly. Q: Is the WinSock support in Wabi 2.0 somehow embedded as support only for specific applications? A: No, WinSock is not implemented in a way that restricts its use to particular applications. Use of WinSock is available to all applications. However only WinSock problems that can be demonstrated using a certified application will be given priority. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: hidden files on NFS file servers Keywords: HP HP-UX hidden file NFS Context Dependent File facility CDF installation failure WABI_NOHIDDEN X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--nohid.txt Number--63170 Version--2.1 Date--94/12/20 Q: What can I do if my home directory is on an HP-UX fileserver and my application installations are failing? A: Setenv WABI_NOHIDDEN 1 in the environment you're going to start Wabi from before you start it. Q: Why are my application installations failing? And how will setting environment variable WABI_NOHIDDEN change the situation? A: HP-UX has a feature called the Context Dependent File facility (CDF) that allows a given file to appear to have different contents for different processes. When a process examines a Context Dependent File, HP-UX compares the different versions of the files with the context words associated with that process to determine which version to present. Unfortunately, this facility is unintentionally activated whenever Wabi or PC-NFS sets the DOS "hidden" bit on a directory. As the process does not have a matching context, the directory becomes "hidden" and inaccessible. This has been shown to cause problems for some application installation programs, as they store auxiliary files in a temporary directory; they set the DOS hidden bit on this directory, and then fail when they can no longer access their contents. Q: Will I lose any functionality if I set WABI_NOHIDDEN? A: Files that MS-Windows-based applications intended to be "hidden" will be visible to you. File access by applications though will not be affected, so the impact is only cosmetic. Q: Will this continue to be a problem in the future? A: No. The Context Dependent File facility is being removed from HP-UX 10.0. Q: Can this problem affect me even if my system is not running HP-UX? A: Yes. This problem may affect any Wabi user whose home directory is stored on an NFS file server running HP-UX, even if their desktop system is running some other Unix variant such as Solaris. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--nomem.txt Number-62660 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: administering system memory Keywords: memory swap RAM resources malloc sar config.sys X-Applies-To: X-Classification: X-Source-Info: Name--nomem2.txt Number-62670 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Novell Netware interoperability Keywords: Novell Netware NFS NLM IPX client vnode network API X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--novell.txt Number-62680 Version--2.6 Date--94/12/10 Q: Can Wabi access files that are stored on a Novell server? A: Yes, Wabi can access the files if the Novell server exports them through its NFS NLM, or if the host OS provides a type "netware" file system. Either method allows Solaris to mount the files as if they were stored on another Solaris machine. Wabi is then 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 include both an IPX/SPX streams drivers and an additional kind of file system. If your system has devices named something like /dev/ipx and /dev/spx, it has IPX/SPX streams drivers. If your system has either additional parameter values on the `mount` command or an entirely new "mount-like" command, it has software that provides the additional kind of file system. 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: Is the IPX/SPX streams driver package available from SunSoft sufficient to allow Wabi to access files stored on a Novell file server? A: No, you need not only IPX/SPX streams drivers but also an additional kind of file system. Having the IPX/SPX streams driver package available from SunSoft is only half a solution. To see Novell files from Wabi you must also either add Solaris software that provides an additional kind of file system, or run the NFS NLM on the Novell file server. Q: How can I tell if a software package includes not only IPX/SPX streams drivers but also the additional kind of file system? A: Look in the software package's documentation for either the word "vnode" or a description of additional parameter values on the `mount` command or a description of an entirely new "mount-like" 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 can I tell whether or not Wabi will be able to see files on a Netware file server without actually starting up Wabi? A: Go to a Unix command line prompt (e.g., in a `cmdtool`) and execute the `ls` command in the place where you expect the files on the Novell server to appear. If you can see the files from the hostOS (e.g., Solaris), you will also be able to access them from Wabi. 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 can then map a drive letter to the mount point in the Unix directory tree and see the files. Every file system type supported by the host OS (hsfs, ufs, nfs, nw, 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 applications running under Wabi. Q: What's the advantage of having files available to the entire system rather than just to applications 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 applications, 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: There are two ways for Wabi to access files on a Novell file server: additional software on the Novell file server system and additional software in the hostOS on the client system where Wabi is running. Is one preferred over the other? A: Both work equally well, Wabi has no preference. Both provide the same functionality. In fact an end user probably won't be able to tell which is being used. You can either install the NFS NLM on the Novell file server, or install IPX/SPX streams drivers and an additional file system type on the client hostOS. Your choice will probably depend on price, availability, administrative concerns, hardware configuration, and actual performance of the available software. There's no fundamental reason why one approach would perform better than the other. Yet actual performance of specific implementations can differ significantly. Q: Can Wabi execute programs that are stored on a Novell server? A: Yes, 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 applications 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, applications 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 application, direct printout to LPT1 to use a Unix printer, or to LPT2 to use a Novell printer. Q: Does Wabi 1.x support the NetWare API calls? A: No, Wabi 1.x does not support any networking API, not WinSock nor NetBIOS nor the NetWare API. Note there's no connection between being able to access files that are stored on a Novell server and supporting the NetWare API. Q: Does Wabi 2.0 support the NetWare API calls? A: No, although it does support parts of some networking APIs, Wabi 2.0 does not support any of the NetWare API calls. Access to files and execution of program stored on a Novell server is the same in Wabi 2.0 as in Wabi 1.x. Note there's no connection between being able to access files that are stored on a Novell server and supporting the NetWare API. Q: Is the NetWare Client one of the certified applications for Wabi 2.0? A: No, the NetWare Client is not one of the certified applications for Wabi 2.0. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: ODBC Keywords: ODBC SLQ driver DLL database access DBMS client server X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--odbc.txt Number-62690 Version--2.4 Date--94/11/27 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 2.0 support ODBC? A: Because of the wide variety and immaturity of ODBC implementations, it's not possible to state categorically either that Wabi 2.0 does support ODBC or that it doesn't. To determine whether or not a specific configuration will run under Wabi 2.0, ask these questions: 1) Will Wabi 2.0 support an ODBC Driver Manager? An ODBC Driver Manager, which will be implemented as a *.DLL, will almost certainly run under Wabi 2.0. No specific capabilities are needed beyond driver loading and unloading, something that Wabi already does to support printing. 2) Will Wabi 2.0 support an implementation of the ODBC API? The implementation of the ODBC API will probably reside in the same *.DLL as the ODBC Driver Manager. Such a *.DLL should execute correctly under Wabi. 3) Will Wabi 2.0 support the network API that a particular ODBC driver needs? Wabi 2.0 will support all API calls in the WinSock network API that are used by any certified application. If a particular ODBC driver can use this network API, it should execute correctly under Wabi 2.0. Q: How do I find out about the availability of and requirements of ODBC drivers to access particular database servers? A: Ask the database ISV. Q: How do I find out whether or not an app can use ODBC? A: See the app's documentation. Q: How do I configure an app to use ODBC? A: See the app's documentation. Don't be too surprised if configuring an app to use ODBC turns out to be either moderately difficult or poorly documented. Q: What should I watch out for? A: The ODBC spec provides for three levels of conformance and five levels of transaction isolation. Different database systems may exhibit very different performance characteristics, and even return different answers, when presented with the same SQL query. And successive versions of an ODBC driver may differ significantly in performance and correctness. So just knowing that an app can talk to ODBC, and that a database provides an ODBC driver, is not enough to say for sure that particular app will work well with that particular database. This issue of compatibility is outside the scope of Wabi itself. Nevertheless it's something you should be aware of. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: MS-Office Keywords: bundle MS-Office SHARE.EXE MS-Word6.0 X-Applies-To: X-Classification: X-Source-Info: Name--office.txt Number-62700 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: OLE/DDE Keywords: DDE OLE OLE2 DLL object linking embedding dynamic data exchange X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--oledde.txt Number-62710 Version--2.5 Date--94/11/27 Q: Does Wabi support DDE/OLE (Dynamic Data Exchange / Object Linking and Embedding)? A: Yes, DDE/OLE works between supported windows applications running under any version of Wabi. 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 2.0 include all the parts that are necessary for DDE/OLE? A: Yes. Wabi 2.0 includes its own DDE/OLE *.DLLs. So DDE/OLE will work without having to get the *.DLLs as part of osme other software package. Q: Does Wabi support OLE2? A: Like DDE/OLE, OLE2 works between supported windows applications running under Wabi. To make this happen Wabi 2.0 depends on having the OLE2 *.DLLs loaded. Q: Does Wabi 2.0 include all the parts that are necessary for OLE2? A: Wabi 2.0 relies on the OLE2 *.DLLs being provided outside Wabi itself. OLE2 doesn't come with MS-Windows 3.1 either. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: OS patches Keywords: Solaris 2.1 2.2 2.3 2.4 x86 OpenWindows 3.2 3.3 ZX Leo panic UFS_HOLE WinSock QuattroPro serial comm port cua dev permissions cgsix cgfourteen GX freeze X-Applies-To: Sun Wabi 2.0 X-Classification: X-Source-Info: Name--os_pat.txt Number-62720 Version--2.7 Date--94/12/05 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 (version -21 or higher) "OpenWindows 3.3: Patch to fix several misc. Window Server bugs" on machines that might display Wabi windows. 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: Should I install patch 101196-01 to Solaris 2.1 x86 to improve serial communications under Wabi? A: Although patch 101196-01 is listed as essential for Wabi with serial communications, the patch is in fact non-functional. The only way to get the asy driver to work properly is to use Solaris 2.4 x86. Q: What kernel patches should I install when running Wabi under Solaris 2.2? A: Install the Solaris 2.2 Kernel Jumbo Patch 100999. Although there are no "known" bugs in the 2.2 kernel that Wabi reliably triggers, this patch also includes the lockd fixes that are essential for correct operation of Wabi file locking and sharing. Q: What OpeWwindows patches should I install when running Wabi under Solaris 2.2? A: Install the OpenWindows 3.2 Jumbo Patch 101265. It's wise to install this patch even though there are no "known" bugs in OpenWindows 3.2 triggered by Wabi. Q: What other patches should I consider when running Wabi under Solaris 2.2? A: You need not consider any other patches when running Wabi under Solaris 2.2. Q: What patches should I install when running Wabi under Solaris 2.3 SPARC? A: Install patch 101331 (version -03 or higher) which fixes some problems with the package utilities so you can successfully install other patches. Install the Solaris 2.3 SPARC Kernel Jumbo Patch 101318 (version -54 or higher). This patch fixes a large number of kernel failures that can produce any number of interesting system crashes/lockups. Version -54 or higher is required to fix a socket bug that can kill Lotus Notes. Version -45 or higher fixes the "panic ... UFS_HOLE" that would occur when you tried to install Quattro Pro to a local disk. Install the OpenWindows 3.3 Xserver patch 101362-21 (or higher rev). This fixes several problems that can cause Wabi or an X11R5-based Xserver to hang, especially doing things with fonts or if you're using some CDE software. Install the OpenWindows 3.3 libXt patch (any version). This fixes a UEA when installing Lotus Notes. Install SS10/SS600 Model 51 problems patch 101406 (any version). When installed with 101318, this patch fixes another range of system crashes, including the "system_adaptive_exit" panics. Q: What other patches should I consider when running Wabi under Solaris 2.3 SPARC? A: If you have a ZX (Leo) frame buffer, consider obtaining and installing patch 101284 (version -06 or higher) 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. If you have a cgsix frame buffer, obtain and install patch 101493 (any version) to the cgsix (GX) driver. Without this patch, under heavy load your system may freeze so that even the mouse pointer won't move and L1-A is not recognized. Since Wabi can cause heavy system load you may see these system freezes when you run Wabi even though you never saw them before. If you are experimenting with WinSock support in Wabi 2.0, consider obtaining and installing patch 101429 (version -02 or higher) to OpenWindows 3.3. The equivalent patch for OpenWindows 3.2 is 101189 (version -01 or higher). Q: What patches should I install when running Wabi under Solaris 2.3 x86? A: Install the Solaris 2.3 x86 Kernel Jumbo Patch 101945 (version -02 or higher). And install patch 101907 (version -03 or higher) to the Volume Manager. Q: What patches should I install when running Wabi under Solaris 2.4 SPARC? A: Install Kernel Jumbo Patch 101946 (version -02 or higher). This fixes a problem that will cause a TCP error when attempting to run Lotus Notes. And install the OpenWindows 3.4 Jumbo Patch 102057 (version -04 or higher). This fixes some problems that can cause Wabi or the Xserver to hang, especially if you're running some CDE software. Q: What patches should I install when running Wabi under Solaris 2.4 x86? A: Install patch 101946 (version -02 or higher) to fix a problem that will cause a TCP error when attempting to run Lotus Notes. Q: Should I do anything else to my Solaris 2.4 system to run Wabi? A: Check the permissions on /dev/cua/[ab]. If the permissions are -rw------ and you intend to access a serial communications port from Wabi, for example to run PROCOMM or Terminal, chmod the devices to have permissions -rw-rw-rw. Q: In ConfigurationManager:Ports the list of options for the device driver for the serial ports (Port COM1, COM2, COM3, or COM4 -- Connect...) is empty. This happens even though the Advanced... sub dialog box says the device directory is /dev/cua and the device file patterns is [a-z] and `ls` shows that these devices do exist. What should I do? A: An empty list of options for the device driver probably indicates the permissions on the devices wouldn't allow Wabi to use them. Most likely this is caused by the permissions on the serial devices being set inappropriately in Solaris 2.4. To fix this: /* stop Wabi su cd /dev/cua chmod a+rw [a-z]* exit /* start Wabi Q: What else should I do to my Solaris 2.4 system to run Wabi? A: Yes, you may need to disable Volume Managers handling of the floppy. There is a problem in Volume Manager on Solaris 2.4 that causes Wabi to sometimes say "device not ready" when there's nothing wrong with the floppy drive. There is also a problem in Volume Manager on Solaris 2.4 that causes Wabi to be unable to use the second floppy drive. These problems may be fixed by a later version of patch 101907 for SPARC or 101908 for x86. Version 101907-02 for SPARC (101908-03 for x86) does not completely fix all these problems. Q: How can I tell what patches I have installed on my system already? A: As an ordinary user, run the command `showrev -p` at a shell prompt. From gabe@netcom.com Sun Jan 8 02:43:11 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19645; Sun, 8 Jan 1995 02:11:38 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25898; Sun, 8 Jan 95 02:12:00 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07524; Sun, 8 Jan 95 05:11:57 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02582; Sun, 8 Jan 1995 05:11:53 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA06008; Sun, 8 Jan 95 05:11:58 EST Date: Sun, 8 Jan 95 05:11:58 EST Message-Id: <9501081011.AA06008@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 5/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 58778 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 5 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--pagsiz.txt Number-62730 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--panic.txt Number-62740 Version--2.3 Date--94/11/27 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: You are probably encountering a known Solaris 2.x/SunOS 5.x kernel problem. This bug can be fixed by a patch to Solaris 2.3 and is fully fixed in Solaris 2.4. Either obtain and apply patch 101318-45 (or later rev) to SunOS 5.3, or upgrade to Solaris 2.4. A workaround until you get the problem in SunOS fixed is to install the application to an NFS-mounted remote file system rather than to a local hard disk. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi performance Keywords: tuning Wabi configuration parameters swap fast performance virtual memory X-Applies-To: X-Classification: X-Source-Info: Name--perf.txt Number-62750 Version--2.6 Date--94/12/16 Q: What can I do to make sure Wabi runs as fast as it should? A: First make exactly the same performance tuning checks and changes with Wabi that you would make with any other UNIX application. 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 SCSI cable that's too long). 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... Next be sure Wabi's font server is engaged. `ps` should show the same number of "wabifs" as "wabiprog", each "wabifs" should be the child of a "wabiprog", no Wabi process should be , and the "wabifs" process should use CPU time whenever you do something in Wabi. If Wabi's font server has been configured out, or is present but not actually running, performance of some operations such as scrolling through a document presented in a TrueType font can take 4 times longer than it should. 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 maximum 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: Neither Sun Wabi 1.x nor Sun Wabi 2.0 can take advantage of any hardware acceleration. In particular neither Sun Wabi 1.x nor Sun Wabi 2.0 will take advantage of the SunPC 486 SBus card. Recently software technology has improved so much and RISC speeds shot up so fast that current hardware accelerator designs don't offer the performance advantage they did just a year or two ago. Even if Wabi took advantage of it, adding something like the existing 486 SBus accelerator card wouldn't improve performance very much if at all. Q: Can Wabi run on a SPARCstation 5 or a SPARCstation Voyager? A: Yes. These machines use the MicroSPARC-II chip set, which has a 24KB primary cache (three times larger than MicroSPARC-I). Wabi performance on them is quite good. Q: Can Wabi run on a SPARCstation-Classic or SPARCstation-LX? A: Given sufficient RAM and sufficient swap, Wabi will execute on these machines that use the MicroSPARC-I chip set. However, these low-end machines often have a small disk, which leads the Solaris install program to allocate only a small amount of swap space, which can cause a variety of failures in applications running under Wabi. In addition, because of the small primary cache size in the MicroSPARC-I chip set (6KB for data, 2KB for instructions), Wabi peformance on these machines may be unacceptable. Adding more RAM doesn't compensate for the small primary cache, so it won't improve Wabi's performance on these machines. One solution is to use the Classic/LX as a display port into the network, and execute Wabi somewhere else. To do this, `rlogin` to a larger machine, setenv DISPLAY back to the Classic/LX, and run Wabi on the remote machine. Doing this distributes the compute half of Wabi and the display half of Wabi between the two machines. MicroSPARC-I's 8KB primary cache is sufficient to run the display half of Wabi with good performance. Q: Will Wabi 2.0 run faster on a SPARC-Classic or SPARC-LX than Wabi 1.x did? A: The question of Wabi performance on a Classic/LX is unchanged from Wabi 1.x to Wabi 2.0. Wabi 2.0 doesn't compensate for the small cache in the MicroSPARC-I chipset (which is used in the SS-Classic and SS-LX). Most of the performance enhancements in Wabi 2.0 trade more memory usage for less CPU requirement. They get faster execution at the cost of higher memory usage, and sometimes also larger working set size (which may make the effects of a small cache even more noticeable). Q: Can Wabi support power users who are used to running MS-Windows applications on high-end x86 machines (486-50, Pentium CPU, etc.)? A: Wabi 2.0 performance may not satisfy users accustomed to running on high-end x86 machines. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Unix processes Keywords: coalesce combine process userid share memory address space X-Applies-To: X-Classification: X-Source-Info: Name--proces.txt Number-62760 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--prtcfg.txt Number-62770 Version--2.4 Date--94/12/10 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. Applications 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 Microsoft Windows does. Wabi lets the applications 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 passes that information along to the applications. If you haven't selected a printer driver that matches your printer, your application may not be told that the printer has multiple paper trays. Most applications 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 applications talk directly to the printer. Q: Does Wabi support all paper sizes, or only US sizes? A: Applications running under Wabi will support all the same paper sizes they would support under Windows when driving the same printer. This typically includes all common European paper sizes. Default settings in many applications and in Wabi are such that often only a limited number of paper size choices appear initially. This does not mean that other paper sizes aren't supported. Q: My application doesn't list the paper sizes I expect (e.g., 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. Applications rely on the information they receive from the printer driver to find out your printer's capabilities. If you're using a printer driver that doesn't match your printer well (e.g., "Adobe Default Printer"), applications may think the printer has only one paper tray or supports only one size of paper (probably US/Letter). Q: Why would the list of paper sizes available in an application running under Windows be different from the list in that same application running under Wabi? A: Applications list only the paper sizes actually supported by the current printer. Probably Windows has been configured to use a specific printer driver that exactly matches the printer, while Wabi is still configured to use the "default" printer driver. Wabi's "default" printer driver is a bootstrap. Q: What's the initial printer driver configuration in Wabi for? A: The initial printer driver in Wabi was chosen to make it very likely that you will be able to print something right out of the box without changing the configuration. The initial printer driver in Wabi 2.0 will print something on virtually any PostScript printer. The initial printer driver probably does not accurately describe all the capabilities of your actual printer, such as other paper sizes, sheet feeders, envelope feeders, special fonts, color, fancy graphics, etc. Once you get Wabi and some applications up and running, you should change the printer driver to the one that best describes your actual printer. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: printer drivers Keywords: PCL PostScript printer driver install SPARCprinter NeWSprint Generic Text X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--prtdvr.txt Number-62780 Version--2.9 Date--94/12/19 Q: What's a printer driver? A: In MS-Windows terminology a printer driver is a combination of some executable code and a detailed description of a printer. Each piece of executable code may support tens or even hundreds of different kinds of printers by being combined with different printer descriptions. For example the piece of executable code in Wabi that drives Postscript printers comes with about 200 different printer descriptions. So you see about 200 different "printer drivers" available in Tools:ConfigMan:Printers even though there's only one piece of executable code. Q: What kinds of printers does Wabi include drivers for? A: Sun Wabi 1.x included code to drive PostScript printers. Sun Wabi 2.0 includes in addition code to drive Epson printers and code to drive PCL (e.g., HP) printers. Q: Does Wabi support any printer drivers other than the ones that come with it? A: Yes. Wabi supports the PostScript printer driver and the Generic/Text printer driver that come with MS-Windows. The PostScript printer driver is another driver that drives most PostScript printers and can be used instead of the Adobe driver provided with Wabi if you prefer. The Generic/Text driver will drive most character printers. When you Install Windows, these printer drivers will be copied onto your system and will show up in the WabiTools:ConfigMan:Printers list of available printer drivers. Q: Can Wabi 2.0 fully utilize an Epson printer's capabilities, including multiple fonts and rudimentary graphics? A: Yes. Wabi 2.0 includes executable code specifically to drive Epson printers. This code knows exactly what printer it's talking to and will fully utilize the printer's capabilities. Wabi 1.x could drive an Epson printer using the Generic/Text printer, but this did not allow the use of multiple fonts or any graphics at all. Q: Where can I find out more about printer drivers? A: You'll find quite a bit of information in the online help for the printer driver. To see it, under Wabi go to WabiTools:ConfigurationManager:Printers:Setup:Help. Q: What support do I need from my hostOS to use a printer from Wabi? A: The printer must be known to your hostOS and able to accept spooled output in the printer's native format without further filtering. Under Solaris 2.x it's sufficient to run Admintool:Printtool and, if the printer isn't already known on your system, add it using default values. Q: Do I need a special terminfo entry for a printer in my hostOS to use it from Wabi? A: No. All you have to do is configure the `lp` subsystem to pass output to the printer without "filtering" it. If you can access the printer from `lp` at all, your configuration is probably good enough. 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: What if Wabi doesn't provide a printer description file for the printer I'm using? A: Usually all you need to do is find a printer description that closely matches the functionality of your printer even it doesn't match the model name. If you really need to copy a printer description from another system or even create one, you can. Q: Can I copy an entire printer driver, both executable code and printer description file or files, from a Windows PC to Wabi? A: It depends. If the executable code part of the printer driver on your PC is supported by Wabi, 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 executable code part of the printer driver on your PC is not the exact version of one that Wabi supports, it's not supported under Wabi and may not work correctly under Wabi. Even if the printer name and printer description file are identical to ones that already exist on the Wabi system, if the executable code is different it may not work 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 provides support for the several hundred printers shown in the Available Printer Drivers panel in the Printer Settings dialog box. No matter what printer you've got, at least one of these available drivers will match it very closely if not exactly. After you install Microsoft 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 2.0 print to my HP PCL printer? A: Yes, Wabi 2.0 can either drive your HP PCL 5 printer directly as a PCL printer, or drive it indirectly as a PostScript printer if it has a PostScript cartridge in it. 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. With Wabi 1.x sometimes the output would be PostScript rather than ASCII because of a bug. The workaround was to stop Wabi, manually edit ~/wabi/windows/win.ini and change "adobeps" to "tty" on all the lines that mention "Generic", and restart Wabi. 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. The SPARCprinter will work with most PostScript printer drivers, but may not render fonts as well or have the correct margins as it would if you had configured exactly the right printer description. Q: What Wabi printer driver best matches the SPARCprinter? A: In Wabi 2.0, use the "SPARCprinter" entry. (This printer description assumes you've got the standard set of fonts in /usr/openwin/lib/fonts, and that you don't need to print other fonts.) In Wabi 1.x, the best match to the SPARCprinter's capabilities is the "Apple LaserWriter Plus v42.2". 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 application 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 application. Most often you do need to have a color printer driver configured to edit in color. Typically applications ask about the printer's capabilities, and if told by the driver that the printer can't print in color, give you a grayscale palette instead of a color palette. Q: What executable code does Wabi 2.0 use to drive Postscript printers? A: Wabi 2.0 uses the Adobe Version 2.x printer driver to drive PostScript printers. This is the same code that's been available for Windows on PCs since fall 1993. Since you've installed MS-Windows under Wabi 2.0 the Microsoft PostScript printer driver is also available to you. Q: How can I use the Microsoft PostScript printer driver code rather than the Adobe PostScript printer driver code? A: In Wabi 2.0, if you are dealing with a suspected compatibility issue and want your printout to go through Microsoft's PSCRIPT.DRV code rather than Adobe's ADOBEPS.DRV code, select the printer driver named "Postscript Printer." This printer driver is listed as available as soon as you install MS-Windows. You can install it from either WabiTools:ConfigMan:Printers or Main:ControlPanel:Printers. Once it's installed you can select it from within the application. 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 (e.g., 2.1) and the MS-Windows version number (e.g., 3.1). >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: printer orientation Keywords: portrait landscape option X-Applies-To: X-Classification: X-Source-Info: Name--prtori.txt Number-62790 Version--2.2 Date--94/11/27 Q: Does the "orientation" option in the printer setup (Tools:ConfigMan:Printers:Setup) work? A: Yes. But in most cases this option is overridden by more specific option settings inside apps. So it may appear to not work. Q: What specifically does this option do? A: This option provides a "starting" value for page orientation. And it provides a fallback default in case an app forgets to specify page orientation (this hardly ever happens though). Q: What is the point of having an "orientation" option in Tools:ConfigMan:Printers:Setup if it doesn't do much? A: "real Windows" provides this option. So Wabi provides it too. Q: Isn't it a bit silly to provide an option setting that's hardly ever used and hardly ever does what it seems to say it does? A: One could argue that, yes. But "real Windows" does it so Wabi has to do the same. Besides, folks who come from the "real Windows" world are already so used to this they'll never think twice about it. Q: No matter what I set either this option to or the more specific option inside my app, the printout always comes out with portrait orientation. How can I allow my app to switch back and forth between portrait orientation and landscape orientation? A: There seems to be an interaction between certain printer drivers and this option. Try switching to a different printer driver. For example, if you haven't yet selected a particular printer driver and are still using the "Adobe Generic Postscript" printer driver you may not be able to print with landscape orientation. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: printer descriptions Keywords: ppd file X-Applies-To: X-Classification: X-Source-Info: Name--prtppd.txt Number-62800 Version--2.2 Date--94/11/27 Q: None of the printer description files provided by Wabi match the printer I'm using well enough. What should I do? A: Try to find a *.PPD file that matches the printer, and use it. Maybe there's one on another system. Or maybe you received one along with the printer. If you can't find a suitable *.PPD file, you can create your own. Q: Can I copy a printer description file from another system or from a diskette that came with the printer? And if so, how do I make the new printer description file appear in the list of available printer drivers in Tools:ConfigMan:Printers? A: To add a new printer description file (that works with an existing piece of executable code) to the list displayed by Tools:ConfigMan:Printers, add three lines to $WABIHOME/printers/oemsetup.ini. /* at the end of the [printer list] section add a line using the next number in sequence, for example */ printer_197=QMS-PS 2200 w/ fonts added,adobeps.drv /* in the [ppd list] section add a line that names the printer description file, for example */ QMS-PS 2200 w/ fonts added=CUSTOM01.PPD /* in the [driver list] section add a line that names the executable code, for example */ QMS-PS 2200 w/ fonts added=adobeps.drv Q: I have a custom printer that doesn't exactly match any of the printer descriptions supplied with Wabi. How can I create a new printer description file? A: First copy an existing printer description file that's close to what you want and modify it slightly to reflect its newness. Say for example you've added some fonts to a QMS 2000. % su # cd $WABIHOME/printers # cp q2200523.ppd custom01.ppd # vi custom01.ppd /* change PCFilename: to the name of the file you just created */ /* change NickName: to what you want to appear in the list of available printer drivers */ Then modify the printer description file further to describe what's different about this printer. You may be able to delete a few lines if you started with a printer description that's a superset of what your printer can actually do. Or you may need to add a few lines to describe additional capabilities. You can probably copy lines from other printer description files in this same directory. You may for example want to add a line that describes another paper tray, or add some lines that describe additional fonts you want to treat as "built in". Q: After I create a new printer description, how do I get Wabi to use it? A: First add it to the list of available printers in Tools:ConfigMan:Printers by editing $WABIHOME/printers/oemsetup.ini as described above. Then run Wabi and use Tools:ConfigMan:Printers to the new printer. Now you should see the new printer capabilities from within the app. (Be sure the app has the new printer selected. Sometimes an app will retain the previous printer setting or use the previous default printer until you explicitly change its printer setting.) Q: The first time I installed a newly created *.PPD file, it worked fine. But later when I needed to make some additional changes I found that even though I de-installed the printer driver modified the *.PPD file then re-installed the printer driver, Wabi never noticed the additional changes What should I do? A: MS-Windows/Wabi caches a copy of the *.PPD --even for "un-installed" printers-- in C:\WINDOWS\SYSTEM. You may need to delete that file to make your re-installation get your newly modified *.PPD. Q: Even though it's all editable ASCII and seems to use meaningful words, a *.PPD file looks intimidating. How can I find out the complete exact syntax of every line in this file? A: To get a complete description of a *.PPD file for a PostScript printer under MS-Windows/Wabi, use anonymous FTP to access "ftp.adobe.com", cd to pub/adobe/DeveloperSupport/TechNotes, and look at the files named 5003.PPD_Spec_v4.2*. This is a large document (over 150 pages). Q: I obtained a special font and added into my printer and created a new *.PPD that lists the new font. But my app running under Wabi still doesn't display the printer icon next to this font when it lists available fonts. Is there something else I need to do? A: The printer driver needs to be able to find the "font metrics" for every font listed in a *.PPD. If the "font metrics" can't be found, the listing of that font in a *.PPD will be ignored. All the metrics for all the fonts mentioned in any of the pre-supplied PPDs are already available in a single combined file /opt/SUNWwabi/printers/fonts.mfm. If the ones you add are mentioned in this file, they'll work by themselves. But if the new fonts are not mentioned you'll need to get them in somehow before you can use them. Scan through the documents and files provided by your font supplier looking for a reference to "metrics" or a file whose extension includes the letters "fm". One thing to watch out for is that if you create a new ppd install it de-install it modify it install it again you'll see the old/unmodified description. That's because Windows/Wabi caches a copy of the *.PPD --even for "un-installed" printers-- in C:\WINDOWS\SYSTEM. You may need to delete that file to make your re-installation get your newly modified *.PPD. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: printer problems Keywords: diagnose printer problems print file spool debug generic swap space tmp temp diff X-Applies-To: X-Classification: X-Source-Info: Name--prtprb.txt Number-62810 Version--2.6 Date--94/12/16 Q: Why might it appear that Wabi could not print to PostScript printers other than Sun's NewsPrint printers? A: Wabi 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. If they are, the problem may be that the output of the Adobe 2.1 printer driver is incompatible with older versions of TranScript software. Q: I can't print PowerPoint presentations to a SPARCprinter. What should I do? A: Be sure you've installed patch 101678-09 (or later revision) to your SPARCprinter software. It doesn't matter whether the PowerPoint print operation was done under Wabi or under MS-Windows. Both ways the PostScript output generated will not be interpreted correctly by SPARCprinter software that doesn't have patch 101678 installed. Q: Why would it appear that printing works from Windows on a PC but not from Wabi? A: Check the name and version of the printer driver the PC is using. (Open Control Panel's Printers icon, select the printer driver, choose Setup, and choose About in the Setup dialog.) If the PC is using a Microsoft driver while Wabi is using an Adobe driver the two printer drivers are probably emitting very different PostScript even though they both intend to generate the same result. Your printer probably understands one dialect of PostScript but not the other. Check with your printer vendor to see if you need a patch to your printer to make it understand the dialect of PostScript emitted by the Adobe driver. If both the PC and Wabi are using an Adobe printer driver but the PC is using a different version of the driver than Wabi, you're not comparing apples to apples. The problem might be 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 PC then retest. On both the Wabi system and the PC, print to a file. The two files should be identical, except perhaps for the ^D at the top of the file produced on the PC. (The ^D allows the file to be included inside some other document.) Almost certainly the file generated on the PC still won't print. This demonstrates that the problem is not with Wabi. More importantly, it allows you to take a simple test case involving only a PC to your printer vendor when you contact them for help. Q: Why might PostScript files generated from the same input on different systems be very different? Shouldn't equivalent PostScript files be the same? A: PostScript is a computer programming language. PostScript output is really a program that tells the printer how to draw on a page to produce the desired output. As with any other computer programming language, very different programs can produce identical output. The fact that the Unix `diff` program lists even hundreds of lines of differences between two PostScript output files generated from the same input does not show that something is wrong. Unless both output files were generated by exactly the same version of exactly the same printer driver code, expect there to be significant differences in the PostScript source code. Q: How can I test various printer combinations without having to start Wabi, bring up an application, and open a document and format it for printing every time? A: Start Wabi and the application, and open 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, but 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 Wabi 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 enter 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 application and print something. The application 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 Configuration Manager: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 applications but not others? A: Printing can work from some applications 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: What should I do if 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: Upgrade your Wabi software. There was a subtle problem with font metrics in Wabi 1.0 that sometimes caused a string of characters to seem a different length than it really was. This problem was most evident with MS-Word when using a TrueType font. The root problem was with rounding the width of a character (e.g. is that 3.499 twips or 3.5 twips?). This problem was fixed in Wabi 1.1. Q: Why might Configuration Manager: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. Configuration Manager: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 applications that were started after Wabi. Large print jobs may also 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. On most Sun systems, /tmp is implemented as part of swap rather than as a separate file system on the physical disk. In this case, the amount of space applications 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. Also since swap and /tmp share the same space, a large amount of swap space listed as available may be used up by /tmp files and be unavailable as swap space only a few seconds later. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: printing speed Keywords: printing speed document justify margin X-Applies-To: X-Classification: X-Source-Info: Name--prtspd.txt Number-62820 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: refresh window Keywords: refresh window minimize close open X-Applies-To: X-Classification: X-Source-Info: Name--refrsh.txt Number-62830 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: "root" Keywords: userid run root guest demo system maintenance X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--root.txt Number-62840 Version--2.5 Date--94/12/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. 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. And it will work with either Wabi 1.1 or Wabi 2.0. 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. Q: If Wabi does not want to be "root" when it's executed, why does it need to be "root" when it's installed? A: Like any other software package, Wabi installation manipulates files in "reserved" disk partitions (/var, /etc, /opt, etc.). The hostOS allows only "root" to manipulate files in these areas. Also Wabi installs a "kernel driver" into the hostOS. This is effectively a kernel modification, and so requires the installer to be "root". >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: root menu Keywords: launching individual applications root menu X-Applies-To: Sun OpenWindows X-Classification: X-Source-Info: Name--rtmenu.txt Number-62850 Version--2.2 Date--94/11/27 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 gabe@netcom.com Sun Jan 8 02:43:17 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19620; Sun, 8 Jan 1995 02:11:30 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25905; Sun, 8 Jan 95 02:12:04 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07529; Sun, 8 Jan 95 05:12:00 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02585; Sun, 8 Jan 1995 05:11:57 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA06046; Sun, 8 Jan 95 05:12:03 EST Date: Sun, 8 Jan 95 05:12:03 EST Message-Id: <9501081012.AA06046@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 6/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 56558 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 6 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: color schemes Keywords: control panel color scheme X-Applies-To: X-Classification: X-Source-Info: Name--scheme.txt Number-62860 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--serial.txt Number-62870 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--serve2.txt Number-62880 Version--2.4 Date--94/12/16 Q: How much memory do I need in an X-terminal to run Wabi on it? A: The answer varies tremendously depending on which applications you're running under Wabi. Applications that use a very large number of fonts simultaneously will require more memory in the X-terminal. Applications 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: Does the amount of memory in the X-terminals have any effect on performance? A: No. X-terminals use physical memory rather than the virtual memory used by workstations. 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 has 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 application that's almost purely display-intensive, doing virtually no computation other than that required to generate the display. Most common productivity applications --word processors, spreadsheets, etc.-- do more non-display computation. 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 applications. 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 applications is 4 moderately active users per 50MHz SPARC CPU, assuming the CPUs aren't also trying to perform other significant work (such as NIS service) at the same time. For example, a 4-way SS1000 could support up to 16 simultaneously active Wabi users. Also consider 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, a SPARC CPU could support 4/20% = 20 active users. However, 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: 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 at least 32MB (48MB suggested) for Solaris, daemons, occasional Unix use, and 1 copy of Wabi. You should have another 6-8MB for each additional active Wabi user. With Solaris x86, you should have 24MB for Solaris, daemons, occasional Unix use, and 1 copy of Wabi. You should have another 4-6MB for each additional 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 SPARCs on the desktops and excellent Wabi performance. In practice, though, x86 hardware may have two disadvantages. First, good multi-processor x86 systems may not be easily available. 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. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Wabi on a server Keywords: server NFS central Wabi engine DISPLAY mount wabiload rmmount Volume Manager X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--server.txt Number-62890 Version--2.3 Date--94/11/27 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's A: refer to the floppy drive on your desktop machine. Wabi'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...", stop what you're doing, become "root", run $WABIHOME/bin/clientinstall (or in some cases just $WABIHOME/drvr/wabiload), then try again to start 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: For Wabi 2.0, simply as root on the client execute $WABIHOME/bin/clientinstall. This script will do everything necessary to set up the client machine to run Wabi. An alternate procedure is to (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. The procedure is even simpler for Wabi 2.0 and does not require a CD drive. Simply as root on the client execute $WABIHOME/bin/clientinstall. This script will do everything necessary to set up the client machine to run Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: DOS/Windows file sharing and locking Keywords: lockd NFS lock SHARE.EXE share flock install locking sharing X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--share.txt Number-62900 Version--2.6 Date--94/12/20 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 file SHARE.EXE (or file 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 make use of a separate file if it existed.) Q: What does the "Sharing Enabled" checkbox in WabiTools:ConfigMan:Drives do? A: Wabi's "Sharing Enabled" checkbox enables exactly the same file sharing functionality as running SHARE.EXE or VSHARE.EXE under MS-Windows. Anything you read in either MS-Windows documentation or application documentation about the functionality of "file sharing" also applies to Wabi. Q: What's the definitive reference for "file sharing" functionality? A: The definitive reference for "file sharing" functionality is the pages that describe the DOS file open() call in the DOS Technical Reference Manual for DOS 3.1 and above. Wabi's implementation of "file sharing" follows the X/Open NFS specification which in turn follows this specification provided by Microsoft. Q: Isn't "file sharing" just "file locking" specifying whole files instead of byte ranges? A: No. "File sharing" has several additional parameters that specify in more detail than "file locking" what access this and other processes can have to a file. There is no exact analogue of "file sharing" in traditional Unix. "File sharing" is a separate part of the NFS lockd RPC protocol. And "file sharing" is implemented separately from "file locking" in the reference NFS lock daemon. Q: Does "file sharing" simply forbid a second access to a file that one application already has open? A: "File sharing" provides a large number of combinations. Its most frequent uses are to disallow write access if there is already a read access, and to disallow all access if there is already a write access. But it can be used many other ways. Each application may specify any one of five sharing modes (Deny-None, Deny-Read, Deny-Write, Deny-All, and Compatibility) along with any one of three access modes (Read-Only, Write-Only, or Read-Write). Q: If applications running under Wabi reference the same file through two different drive letters both of which have Sharing checked, will Wabi's "file sharing" implementation figure out that both accesses are really to the same file? A: Yes. Wabi's implementation of "file sharing" relies on the unique "network file handle" of each file and so will work even if the same file is accessed through two different drive letters. Thus Wabi's "file sharing" will work correctly even if some drive letter mappings overlap. (An example of overlapping drive letter mappings is D: mapped to /foo/bar and E: mapped to /foo/bar/baz.) For ease of administration, though, we recommend that you set up your drive letter mappings so they do not overlap. Q: If applications running under Wabi reference the same file through two different drive letters, only one of which has the "Sharing Enabled" box checked, what will happen? A: The file access that goes through the drive letter without the "Sharing Enabled" box checked will neither be aware of the other access nor make its own access known to others. So both accesses will succeed and there may be a risk of file corruption. 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: It seems at first glance that this is a way to test for the presence of file locking/sharing functionality. In fact it's common to find code something like this: union _REGS inregs, outregs; inregs.x.ax = 0x1000; _int86 (0x2f, &inregs, &outregs); if (outregs.h.al == 0xff) ... But this test doesn't provide a usefully correct answer in many situations. Application programmers really shouldn't use it. This method always returns true in enhanced mode Microsoft Windows version 3.0 even if SHARE.EXE is not loaded. Under Wabi 2.0 this method always returns 0xFF. (It returned "false" under Wabi 1.x.) 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. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--shrlck.txt Number-62910 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: sharing software with a DOS partition Keywords: mount export share partition pcfs X-Applies-To: X-Classification: X-Source-Info: Name--shrprt.txt Number-63080 Version--2.1 Date--94/12/19 Q: I have an x86 machine with two disk partitions, one for Solaris and the other for DOS/Windows. Can Wabi under this Solaris x86 access and share files in the DOS/Windows partition? A: Yes. Solarix x86 can access and share files in a DOS/Windows disk partition on the same machine. And since Solaris x86 can access and share the files, so can Wabi running under it. Q: Why would I want both OSs on my multi-bootable machine to share a single copy of many MS-Windows and application files? A: One reason you may wish to do this is to save disk space since you don't need to store multiple copies of these files. A second reason is that you can work on application data files without ever having to copy a file, no matter which OS you have booted. A third reason is you have the option of always having the same configuration for any application regardless of which OS you have booted or when or where from you last changed application configuration. Q: Do I have to have a single configuration file for both OSs if I share any files? A: No. If you wish you can share some files between OSs yet keep independent copies of others (e.g. *.INI). Q: How can I share files in a way that provides "similar" file and path names? A: Here's an example with C:. You can substitute other drive letters and other disk partition numbers. In the root directory of your Solaris disk, mkdir C: In the Solaris configuration file /etc/vfstab, add mount -F pcfs -o rw /dev/dsk/c0t0d0p0:1 /C: Now any reference from the Solaris system to "/C:/foo/bar" will access the same file the DOS/Windows system accesses as "C:\foo\bar". Q: How can I set up Wabi to transparently access a whole group of files in the DOS/Windows partition as though they were in the Solaris partition? A: Create symbolic links from the Solaris partition to the DOS/Windows partition. Make the symlinks point from the locations where Wabi and the applications running under it expect to find the files to the locations where the files are actually stored. For example, assuming you've made a directory and mounted the other disk partition as above, some possible symbolic links would look like this: ls -l $HOME/wabi/windows clock.exe -> /C:/windows/clock.exe clock.ini (a real file allows independent configurations) notepad.hlp -> /C:/windows/notepad.hlp pbrush.dll -> /C:/windows/pbrush.dll Q: Is there any risk of simultaneous updates damaging files? A: No. Since there is only one machine sharing the two disk partitions, only one OS will be running at a time. So you don't have to worry about simultaneous updates to files. Q: Does Wabi's "file sharing" support apply to files that are really stored on the DOS/Windows disk partition? A: This is a function of the hostOS, not of Wabi. Currently the "pcfs" file system type that Solaris uses to access a DOS/Windows disk partition does not support file locking or sharing. So currently you should un-check the "sharing" box in WabiTools:ConfigMan:Drives for the drive letter you use to access these files. As soon as support for file locking and sharing appears in the "pcfs" file system type used by Solaris, all of Wabi's "file locking" and "file sharing" functionality will extend to these files. Q: Will this work with applications that insist that "file locking" be supported on their data files? A: Currently applications such as Excel that always lock a whole file as part of opening it will not be able to access files stored on the DOS/Windows partition. These applications need support for "file locking" and "file sharing" to be added to the "pcfs" file type in Solaris. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: sound Keywords: soundblaster multimedia x86 risc wav au sound X-Applies-To: X-Classification: X-Source-Info: Name--sound.txt Number-62920 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: available disk space Keywords: bytes available overhead root ratio free total disk space newfs tunefs minfree metadisk X-Applies-To: Wabi 2.0 X-Classification: X-Source-Info: Name--space.txt Number-62930 Version--2.3 Date--94/11/27 Q: Does Wabi 2.0 calculate available disk space correctly on very large disk partitions -- for example a 4GB metadisk? A: Yes. The problem where earlier versions of Wabi would oncorrectly report free disk space as 0 bytes on very large disk partitions has been fixed in Wabi 2.0. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: startup group Keywords: startup program group initial X-Applies-To: X-Classification: X-Source-Info: Name--start.txt Number-62940 Version--2.2 Date--94/11/27 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 gabe@netcom.com Sun Jan 8 02:43:23 1995 Return-Path: Received: from Sun.COM by mail2.netcom.com (8.6.9/Netcom) id CAA19648; Sun, 8 Jan 1995 02:11:38 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25923; Sun, 8 Jan 95 02:12:07 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07532; Sun, 8 Jan 95 05:12:05 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02588; Sun, 8 Jan 1995 05:12:01 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA06082; Sun, 8 Jan 95 05:12:07 EST Date: Sun, 8 Jan 95 05:12:07 EST Message-Id: <9501081012.AA06082@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 7/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 46556 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 7 OF 8 << <<<<<< << >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--tmpfil.txt Number-62950 Version--2.2 Date--94/11/27 Q: Where do MS-Windows-based apps store their temp files? A: Most MS-Windows-based apps follow the MS-Windows convention for wher to store their temp files --even though in theory each app is free to store its temp files wherever it likes. The MS-Windows convention is that temp files are stored under a system-wide common location that defaults to C:\tmp. Q: What's the corresponding location in Wabi? A: C:\tmp under Wabi maps to the Unix location $HOME/wabi/tmp. Q: How can one override the default location in "real Windows"? A: In C:\AUTOEXEC.BAT, set environment variable TEMP (or TMP) to the full path to the desired storage location. Q: How can one override the default location in Wabi? A: Stop Wabi and in Unix cd $HOME/wabi mv tmp tmp.old ln -s tmp The next time you start Wabi temp files will be stored in . Q: Why might I want to override the default location where temp files are stored? A: The most common reasons for wanting to override this location are storage management and performance. If your home directory doesn't have much space, you may want to override this location to reduce the amount of disk space Wabi uses in your home directory. If your home directory is accessed over the network, you may want to override this location to point it to the local machine instead and so eliminate some network traffic. Q: Can I tell Wabi to write its temp files in the same place my host OS (ex: Solaris) writes its temp files? A: Yes. For example if your host OS follows the usual Unix convention of writing temp files under /tmp, stop Wabi and in Unix cd $HOME/wabi mv tmp tmp.old ln -s /tmp tmp The next time you start Wabi, its temp files will get all the advantages your host OS provides to temp files. For example, if you've optimized /tmp by using a "tempfs" type file system and having lots of RAM in your system, you can make those performance advantages available to apps running under Wabi too. This is analogous to instructing "real Windows" to place temp files in a location you've set up as a ramdisk. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: TrueType fonts Keywords: TrueType fonts type manager X-Applies-To: X-Classification: X-Source-Info: Name--trutyp.txt Number-62960 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: UDP checksums for NFS Keywords: possible file corruption UDP checksums NFS x86 X-Applies-To: X-Classification: X-Source-Info: Name--udpchk.txt Number-62970 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: visual basic applications Keywords: visual basic mmsystem timer version excel project word winword X-Applies-To: X-Classification: X-Source-Info: Name--vbamsg.txt Number-63070 Version--2.2 Date--94/12/16 Q: When I attempt to install an application such as MS-Project 4.0, I receive the error message "could not initialize visual basic for applications, because the timer driver is not installed properly." The Help system says in addition "need mmsystem.dll, timer.drv, vtdapi.386." What should I do? A: Upgrade to Wabi 2.0. Newer versions of several applications will cause these messages if you attempt to install or run them under Wabi 1.x. The list of certified applications for each release of Wabi includes version numbers as well as application names. Do not assume just because an application name is listed that a version that is not listed will install and run correctly under Wabi. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: virus protection Keywords: virus boot sector windows apps Unix Solaris Wabi scanner X-Applies-To: X-Classification: X-Source-Info: Name--virus.txt Number-62980 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--visdev.txt Number-62990 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: Volume Manager overview Keywords: SPARC Solaris Volume Manager CD CD-ROM floppy disk X-Applies-To: Sun Solaris, Wabi 2.0 X-Classification: X-Source-Info: Name--volmg2.txt Number-63000 Version--2.2 Date--94/11/27 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. If you're running Solaris 2.4, there's a problem in Volume Manager that will prevent it from working correctly with Wabi. Either get a later revision of patch 101907 (rev -02 will not fix the problem), or else disable Volume Manager's handling of the floppy drive. (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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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, Wabi 2.0 X-Classification: X-Source-Info: Name--volmgr.txt Number-63010 Version--2.3 Date--94/11/27 Q: Wabi will not interoperate with Volume Manager under Solaris 2.4. No matter what I do Wabi sometimes reports "device not ready" when I try to access the floppy drive from Wabi? What should I do? A: If you're running Solaris 2.4, you may need to disable the Volume Manager's handling of the floppy drive. This is true whether you're running Wabi 1.x or Wabi 2.0. There is a problem in Volume manager that shows up only after repeated use of the floppy drive. Patch 102077-01 fixes this problem. This problem is not fixed by 101907-02. 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: 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 an additional step. Until you perform this additional step, 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: If I've mounted Wabi from a file server, what additional step do I need to do to "fully install" it on my system? A: As root, run $WABIHOME/bin/clientinstall. This script will perform all the steps that would have been performed by the "postinstall script" if you had installed Wabi directly onto your system rather than onto a file server. 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: patches to Wabi Keywords: jumbo kernel driver Solaris 2.4 2.5 panic revision version X-Applies-To: Sun X-Classification: X-Source-Info: Name--wabpat.txt Number-63020 Version--2.3 Date--94/12/20 Q: What was the problem with floating point? A: An error in the SPARC version of Wabi 1.0 could cause a load of a floating point extended zero to get two instead. This problem was fixed in Wabi 1.1. Q: Is a patch available for this problem? A: You should simply upgrade to a later version of Wabi than Wabi 1.0. Q: Wabi 2.0 comes with kernel drivers for Solaris SPARC versions 2.2, 2.3, and 2.4, and for Solaris x86 versions 2.1 and 2.4. But I'm running a pre-release version of Solaris 2.5. What can I do? A: Don't attempt to use one of the other kernel drivers, as doing so could cause your system's kernel to panic(). A Wabi kernel driver that matches Solaris 2.5 is not currently available. For now you will have to run without Wabi's kernel driver. Q: What is the impact of running Wabi without its kernel driver? A: First, you will get a Warning: message every time you start Wabi. Just ignore it. Second, Wabi's "file sharing" functionality will be disabled. You may not receive any notice if two applications access the same file at the same time. So we recommend that if you run Wabi without its kernel driver you do not use it for production and you do not access files anywhere other than on your local disk. And third, the interface between Wabi and the Volume Manager will not work properly. As a result, if the Volume Manager is handling the floppy drive, Wabi will not be able to access floppy disks. Q: Wabi 1.1 did not come with kernel drivers for Solaris 2.4. I've upgraded to Solaris 2.4, but haven't upgraded to Wabi 2.0 yet. Is there some way I can get Wabi 1.1 to work under Solaris 2.4? A: Yes. You can get Wabi kenel drivers that match Solaris 2.4 either from the Wabi 2.0 distribution or from the Wabi 1.1 "jumbo patch". Q: What's the current revision of the Wabi 1.1 "jumbo patch"? A: As of September 1994 the current revision of both the SPARC and x86 patches to Wabi 1.1 is -03. Q: Can I use a later revision of the patch? A: If you find a later revision, by all means use it. Sun patches are "cumulative", which means a larger -NN revision will fix all the problems a smaller -NN revision fixed. Q: Can I use an earlier revision of the patch? A: Maybe. 101858-01 and 101966-02 were never released because of clerical errors. 101858-02 and 101966-01 include a Wabi kernel driver for Solaris 2.4 that won't panic() your system and will work right in most cases. The later revision 101858-03/101966-03 contains a Wabi kernel driver for Solaris 2.4 that will work right in all cases. The later revision is preferable. >From wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--x24bit.txt Number-63030 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 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: Name--x86lnk.txt Number-63040 Version--2.2 Date--94/11/27 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 wabi2.0-questions@east.sun.com (A Wabi 2.0 Knowledge Base Item) Subject: X11 and Wabi coexistence Keywords: X11 model focus window manager X-Applies-To: X-Classification: X-Source-Info: Name--xw_win.txt Number-63050 Version--2.2 Date--94/11/27 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. From gabe@netcom.com Sun Jan 8 02:43:27 1995 Return-Path: Received: from Sun.COM by netcom2.netcom.com (8.6.9/Netcom) id CAA17334; Sun, 8 Jan 1995 02:11:48 -0800 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25929; Sun, 8 Jan 95 02:12:09 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA07535; Sun, 8 Jan 95 05:12:08 EST Received: from spiral.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA02591; Sun, 8 Jan 1995 05:12:06 +0500 Received: by spiral.East.Sun.COM (4.1/SMI-4.1) id AA06122; Sun, 8 Jan 95 05:12:12 EST Date: Sun, 8 Jan 95 05:12:12 EST Message-Id: <9501081012.AA06122@spiral.East.Sun.COM> To: gabe@netcom.com From: wabi2.0-questions@suneast.East.Sun.COM Precedence: Bulk Subject: 8/8 Q&A Portion of Wabi 2.0 Knowledge Base [FAQ] Content-Length: 3172 Thank you for contacting . The entire Q&A section of the current Wabi 2.0 Technical Knowledge Base [FAQ] is being sent back to you by an automatic email responder as a set of large files. The Technical Knowledge Base changes frequently, so contact this address again to obtain a fresh if your existing copy is more than a couple weeks old. The file is marked with the date of the most recent change to the Knowledge Base, near the top just below the title. You may also find it helpful to check: - the Wabi 1.0 Technical Knowledge Base (some items are relevant to Wabi 2.0) - the Wabi 2.0 manuals (contain much more operational info than the Wabi 1.x version did) - the Wabi 2.0 README (per-app info that was known at the time of distribution) If your email included a contribution to the Knowledge Base, it will be processed soon. You will not receive any other confirmation. If you contributed, thank you! If your email request contained a subject or any content other than a contribution to the Knowledge Base, it will be ignored. If you want to find out which applications run under Wabi, send email To: wabi2.0-apps@East.Sun.COM Thanks! -Wabi Sustaining Engineering PS. If you want to get information about the older version Wabi 1.x send email To: wabi1.0-questions@East.Sun.COM (or To: wabi1.1-questions@East.Sun.COM) To: wabi1.0-apps@East.Sun.COM (or To: wabi1.1-apps@East.Sun.COM) >> >>>>> >> SPLIT FOR EMAIL TRANSMISSION - PART 8 OF 8 << <<<<<< << Subject: Supported Windows Applications X-Classification: X-Source-Info: Name--list Number-64010 Version--1.18 Date--94/12/09 ==================================================================== Windows Applications That Are PCDI-Certified To Run Under Wabi 2.0 (PCDI is Personal Computer Desktop Integration, the part of Sun Microsystems that develops Wabi.) Last Updated 94/12/09 (Revision 1.18) Individual Applications * Microsoft Excel 5.0 (or 4.0) * Microsoft Word for Windows 6.0 (or 2.0) * Lotus 1-2-3(R) for Windows 4.0 (or 1.1) * WordPerfect(R) for Windows 6.0a (or 5.2) * Microsoft PowerPoint(R) 4.0 (or 3.0) * Microsoft Project 3.0 or 4.0 * Harvard Graphics(R) for Windows 2.0 (or 1.0) * CorelDRAW(R) 4.0 (or 3.0) * Lotus AmiPro(R) 3.01 (or 3.0) * Aldus PageMaker(R) 5.0 (or 4.0) * Microsoft Windows 3.1.1 (or 3.1) * Borland Paradox(R) for Windows 4.5 (or V1.0) * Borland Quattro(R) Pro For Windows 5.0 (or V1.0) * PROCOMM PLUS(R) for Windows 1.02 (or 1.0) * Lotus Approach(tm) 2.1 * Lotus Freelance Graphics(R) 2.01 * Lotus Organizer(tm) 1.1 * Lotus cc:Mail(tm) Client 2.0 * Lotus Notes(R) Client 3.0c * Microsoft Mail Client 3.2 * Microsoft Access(R) 2.0 * Intuit(tm) Quicken(R) 3.0 Suites (All applications are included in list above) * Microsoft Office 4.3 (including unified install) * Lotus SmartSuite(R) 2.0 ==================================================================== [Although informal experience indicates many additional applications will run correctly under Wabi 2.0, PCDI suggests that you consider a DOS/PC emulator product such as SunPC to run non-certified applications.]