wpunix makes WordPerfect for UNIX run on a modern Linux desktop

Compatibility patches for a 32-bit word processor

wpunix is a set of build scripts and patches to make WordPerfect for UNIX work on modern Linux. That is the whole project, and the README is refreshingly direct about it.

The subject is WordPerfect, a powerful word processor for the terminal. The README points at a wiki with more information and a quick introduction, and at a FAQ covering common questions and problems, which is where the real documentation lives, since the README itself is short.

The feature list is what makes the project interesting. Print previews, an equation editor, mouse support, drop down menus, spelling and grammar checking, a builtin macro editor, and more. The screenshots section shows the default look, interactive equation and graphics editors that can use sixels or ASCII art, and built-in spelling and grammar tools with a comprehensive interactive thesaurus.

That is a substantial piece of software from the era of character terminals, and the point of the project is to keep it usable rather than to replace it. Anyone who has read a 1990s manual or worked with a legacy document format will recognise why that matters: the file formats, the macro language and the keystroke conventions are the artefacts people actually need.

The audience is therefore retrocomputing, terminal enthusiasts and anyone who needs that specific software to keep working on a current system. The repository topics say retrocomputing, terminal, unix and wordperfect, and the repository is not archived, with the last push on 2026-10-10.

The build starts with the original Corel ISO and an md5sum check

The build cannot begin without the original media, and the README says so directly. You need the following file to build this, and it links to a preserved copy on the Internet Archive, with the note that if you just want a deb or rpm to try out, the Releases tab has them.

The integrity check is given as a command:

$ md5sum COREL_WPUNIX_1.iso
036d10f279aecc61704b214e7bd58a6d COREL_WPUNIX_1.iso

Publishing a checksum for an image that has to come from an archive rather than from the vendor is a sensible practice, because the copy you get is not the copy the vendor shipped and there is no other way to tell whether it is intact.

That dependency is also the project's main constraint, and it is worth being clear about it: this repository contains no Corel media. It contains the scripts and patches that make an existing installation work. If you do not have access to the original image, the build is not available to you, and the prebuilt packages in the Releases tab are the only route in.

The README also gives a quick start guide and a complete user manual link, and points out that if you have never used WordPerfect before, the cua keyboard layout might suit you better, because it enables the familiar Ctrl+C for Copy and Ctrl+V for Paste. Enabling it is a wiki page away.

Two shared objects do the compatibility work, and one of them disassembles

The Makefile is short, and it is the clearest description of the architecture.

Two shared libraries are produced. libcompat.so is built from compat.o and linked as a 32-bit shared object with ld -m elf_i386 and sysv hash style. libwppatch.so is built from patch.o together with the interception object, the mapkey object and a static library called libdisasm.a.

That libdisasm.a in the dependency list is the interesting part. The interception layer is built on a disassembly library, which is what you would expect from a project whose job is to hook into a closed 1990s binary and make it talk to a modern operating system. The intercept directory contains hook.o and the static disassembly library, and it is built as its own sub-make, the same pattern as macro and util.

The compiler flags explain the constraints. CFLAGS is set to -fno-stack-protector -m32, so everything is built as 32-bit code with the stack protector disabled, and CPPFLAGS disables _FORTIFY_SOURCE for the same reason: the hardening features of a modern toolchain get in the way of a binary that was not written for them. The build uses bsdtar rather than GNU tar, which the package list explains, and patchelf, which is how you rewrite the ELF headers of the patched binaries.

Two helper tools are built alongside, macro/mactool and util/grsutil, both with their own sub-make, and the top-level target runs bash build8.sh to prepare the tree before the shared objects are assembled into the output directory.

So the mechanism is: take the original program, patch it at the binary level with an interception library that understands its calling conventions, and support it with a compatibility library for the system interfaces it expects from 1990s Linux.

Building for Debian or RPM depends on which 32-bit packages your distro has

The package table is the practical checklist for the build, and it is split by distribution family because the 32-bit development packages are named differently.

For Ubuntu and Debian you need build-essential, gcc-multilib, bsdtar or libarchive-tools, patchelf and rpm2cpio. For Fedora the list is glibc-devel.i686, libgcc.i686, bsdtar, patchelf, glibc-static and glibc-static.i686.

The Debian list is the interesting one, because rpm2cpio appears there and not on Fedora. The original WordPerfect media is shipped as an RPM, so extracting it needs a tool that can unpack RPM archives, and rpm2cpio does that on a Debian system. On Fedora the equivalent tool is built in.

After the packages are in place, the README says to type make to produce a .deb file, or to use the included .spec file to create an .rpm. The Makefile default target is wordperfect8_i386.deb, and the packaging rule uses dpkg-deb with the root-owner-group flag, so the resulting package has correct ownership rather than whatever uid happened to build it.

The fact that a .spec file is checked in for RPM builds and a dpkg-deb invocation for Debian means both packaging paths are supported from one tree, which is convenient for a project whose users are spread across distributions.

Manual installation is two copy commands and one rm

If you do not want a package, the README offers a manual path, and it is short enough to quote in full.

First prepare the files:

$ make wordperfect8_i386

Then install them:

$ sudo cp -r wordperfect8_i386/opt/wp80 /opt
$ sudo cp wordperfect8_i386/usr/bin/wp /usr/bin/

And uninstalling is a single removal, which the README gives inline:

rm -rf /opt/wp80 /usr/bin/wp

The layout tells you what the program expects: a wp80 directory under /opt holding the application and its data, and a single wp executable in /usr/bin that starts it.

Running wp starts WordPerfect. The default keybinding to open the menu is Esc followed by equals, which is the sort of detail that only matters to someone who has used the original, and it is the kind of thing the cua keyboard layout mentioned earlier exists to work around.

One requirement is easy to miss: print previews require a terminal with sixel support, such as XTerm. On a terminal without sixel, the preview feature that the README leads with is simply unavailable, which is a good thing to check before you build on a machine whose terminal is limited.

Where wpunix is the wrong tool

The limits are real and they are the kind that come with preserving commercial software from the 1990s.

The first is the media dependency. The build needs a copy of the original WordPerfect for UNIX installation media, which the README links to an archived item rather than to a vendor download. Without that file the scripts cannot run, and the prebuilt packages in the Releases tab are the alternative. Anyone without access to the original media cannot use this at all.

The second is the licence. The README's Licensing section is two sentences and both are hedged: in theory this is a demonstration copy, but the author has not noticed any limitations. That is not a licence statement, it is an observation. The repository's licence field is not classified, and the COPYING file is present in the tree. If you intend to run this at work, or to redistribute the packages, that question needs an answer from a lawyer rather than from this repository.

The third is platform scope. The build is 32-bit i386 only, the compiler flags are fixed at -m32, and the package lists are for Debian and Fedora. There is no arm64 path, and on a modern distribution the 32-bit development packages are increasingly awkward to install.

The fourth is the release line. The visible releases are v0.10 on 2022-09-19, v0.11 on 2022-10-30 and v0.13 on 2023-01-08, tagged with the WordPerfect version they support. The last push was on 2026-10-10, so the code is being worked on, but no release has been cut since January 2023. Anyone who wants a packaged build today is using a three year old artefact or building from the branch themselves, which is a different proposition from installing a maintained package.

Editorial conclusion

Retrocomputing enthusiasts and documentation teams who need the WordPerfect 8 terminal client on a current Linux machine should build wpunix, because the interception library and the 32-bit compatibility shim do the work that a fresh install cannot, and the result packages like any other application. It is the wrong tool if you do not already have access to the original WordPerfect for UNIX media, since the build cannot start without it, and it is the wrong tool for anyone who needs a supported word processor rather than a preserved one. Before building, verify the ISO against the md5sum the README gives, check that your distribution provides the 32-bit build packages listed for your platform, and read the Licensing section, which is candid that the licence question is unresolved.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. taviso/wpunix on GitHub