WP 8.0 for Linux was distributed as a dynamically linked ELF binary, linked against libc5 (C library), libm (the related math library), a set of five X11 libraries for libc5-based software, and ld-linux.so.1.9.* (AKA ld.so 1.9.*), the dynamic-linker software current on Linux at that time. Those old libraries are often omitted from current Linux distributions. In such cases, you need to retrofit those libraries. (You can see the exact library links by running "ldd" = list library dependencies against the WordPerfect "xwp" main executable file.) Specifically: Prior to running the WP 8.0 installer, you must install ld-linux.so.1.9.* (usually in an ld.so package), libc of some version from 5.3.12 through 5.4.46, and libm.so.5.* (both usually in the libc5 package), and a set of X11 backward-compatibility libraries compiled against libc5 (libXt.so.6, libX11.so.6, libXpm.so.4, libSM.so.6, and libICE.so.6). Don't forget to ensure the libraries' directories are listed in /etc/ld.so.conf, and then re-run /sbin/ldconfig.
What binary packages these libs and dynamic loader will occupy differs between distributions. If in doubt, documents linked from http://linux-sxs.org/edit.html may give details for your distribution. (Also, this FAQ's section "After I locate WP 8.0 DPE for Linux, how do I install it, and what can I do to improve and fix it?" has more details and remedies for installation problems.)
You installed Accelerated-X, a proprietary X11 server, and included in your installation its version of the X11 libraries, which were compiled with glibc. You need the more-traditional XFree86 versions of those libraries (libXt.so.6, libX11.so.6, libXpm.so.4, libSM.so.6, and libICE.so.6), specifically ones that were compiled for libc5 X11 clients. Remove Accelerated-X completely, reinstall the XFree86 shared libraries for libc5 clients (which may have any of various package names, such as xlib-compat, oldlibs/xlib6, etc.), and then reinstall the Accelerated-X server only (minimal installation). WordPerfect should then run correctly.
You are running with "libsafe" enabled, a wrapper library that aims to protect system security by blocking library calls that are known to be vulnerable to buffer overflows. Unfortunately, that technique blocks execution of any binary that attempts a dynamic library call to libc5.x. Both the WP 8.x installer and WP 8.0's runtime binary were compiled as libc5 executables.
To confirm that libsafe is the culprit, type "echo $LD_PRELOAD | grep libsafe". You can turn off that setting by typing "unset LD_PRELOAD". Then, remove the libsafe reference in /etc/ld.so.preload, if this exists. You should now be able to successfully run the installer, and can call the main "xwp" binary using a shell script that runs "unset LD_PRELOAD" just prior to executing xwp.
You're probably using one of the personal editions of WP 8.x. Only the server editions include code required to enable support of NFS file locking (which in server editions you can enable via the WPadmin login facility). Otherwise, neither the installer nor the WP program binary will run if any components are on (or will be installed to) any NFS mounted drive, including user settings in users' home directories and temporary files in /tmp.
The third-party Filtrix module, because of a programming oversight concerning date-handling, doesn't work on systems whose current date is set later than September 9, 2001: On attempts to import/export MS-Word files, it fails with error message "Filtrix unable to convert this file". The problem can be fixed by installing a wrapper by Valentijn Sessink, available at http://olivier.pk.wau.nl/~valentyn/wp8fix/.
Note: Reportedly, the Filtrix module will not process MS-Word .doc files that were saved in MS-Word with password-protection applied. This is not a bug: Filtrix never handled such files. (Nor can Filtrix handle MS-Word documents with embedded non-MS-Word COM objects such as spreadsheet tables from MS-Excel.)
Good question. By the time the problem cropped up, Corel had discontinued all involvement in Linux. Just before that, Microsoft Corporation made a major investment in Corel, preventing the latter firm's collapse. It's possible that lack of Linux-competent staffing was an issue, that Corel didn't wish to displease its investor, that the firm perceived inexpensive Linux versions to be impairing sales of its US $500 versions for other Unixes (especially given increasingly common support for Linux-native binaries on those Unixes), or that corporate inertia after liquidating the entire Linux division accounted for this lapse.
Corel's only comment (November 5, 2001) was "The corporation is not prepared to make any comment", and to post a comment on http://linux.corel.com/support/updates.htm#wp8, unchanged since late 2001, that "Corel is currently working with the filter manufacturer to resolve this issue." (That claim was still present when Corel took down the linux.corel.com machine on Feb. 26, 2003.)
You don't. WP is compatible with the "kab" version in KDE 1.1, only, that being the KDE version shipped with CLOS. For unexplained reasons, this feature also doesn't work on Linux 2.4.x kernels.
This is a frequent symptom of colour palette exhaustion. The only real cure is to run X11 at a lower colour depth. 32 bpp will sometimes work where 24 bpp doesn't, but 16 bpp always works (assuming hardware support).
No. WP can use Abobe PostScript Type 1 fonts, and Bitstream fonts, only. The issue is covered comprehensively by Rod Smith, here (including describing a utility for generating PostScript fonts from TrueType ones): http://www.rodsbooks.com/wpfonts/
By default, WP for Linux (uniquely) ignores Linux's system printing facilities, and uses its own print engine and drivers. (The latter are the same as for WP on MS-DOS, giving the program very broad printer support. More are available at http://www.columbia.edu/~em36/wpdos/, which should be reachable as http://www.wpdos.org/.) You need to configure the printing subsystem. As the root user, start xwp with the -admin (or -adm) command-line option, then select and install an appropriate printer driver, using the Add Printer Driver widget. (In such cases but not the Passthru option discussed next, specify "-oraw" in the Lpr options of Select Destination.) Alternatively, select "Passthru Postscript" to hand off jobs to the system printing daemon.
Tests by Valentijn Sessink have confirmed that this process must have something to do with printing: If you rename the wpexc binary, then start WP, printing will malfunction but no other program features will. The fact that it's left running even after you quit WP appears to be a bug. You can safely kill it, when not running WP.