Open Watcom v2: the classic C toolchain, rebuilt continuously

A fork that exists to keep a toolchain alive

This repository is the Open Watcom V2 project, and the repository description says what it holds in one line: the source code repository, the wiki, the latest binary build, and archived builds including all the installers for download.

Open Watcom is the toolchain that produced a great deal of DOS, Windows and OS/2 software, and the v2 fork is the community effort to carry it forward. The project is hosted under the open-watcom organisation on GitHub, and the README is brief about what it is beyond that.

The one paragraph that tells you the most about the project's situation is the note about the official site. The official OpenWatcom site at openwatcom.org is up, but all other services, meaning bugzilla, the wiki, the news server and Perforce, have been down for a long time and it looks like it is dead. So the GitHub repository, the GitHub wiki and the GitHub Actions workflows are effectively the project's infrastructure now, and the discussion has moved to GitHub Discussions, Reddit and Discord.

The primary language is C, the default branch is master, the repository is not archived, and the last push was on 2026-10-15. The licence is the one in the license.txt file at the root, and the repository metadata reports it as a custom licence that GitHub cannot classify.

Four kinds of build artefact, published continuously

The build status table at the top of the README is the most informative part of it, because it describes a release process rather than a project.

There is a CI Build, published to the GitHub release tagged Last-CI-build, driven by the cibuild.yml workflow and the ci-build.yml workflow. There is a Current Release Build, published to the release tagged Current-build, driven by the release.yml workflow. Then there is a dated archive build, the 2026-10-01 Build from the start of October 2026. And finally a Releases Archive that links every GitHub release.

That is a deliberate set of channels, and the naming tells you the intent. Last-CI-build is whatever the continuous integration produced most recently, which is the freshest code and the least tested. Current-build is the artefact the project considers current, which is what a user should install. The dated builds are the archive, which is what you want when a toolchain change broke something and you need to go back.

Two more badges complete the picture. There is a Coverity Scan workflow with its own analysis results link, which is static analysis on a codebase that is mostly decades old, and the kind of thing that surfaces real defects in C. And there is a WikiDocs workflow, which builds the wiki documentation as part of the pipeline rather than by hand.

The project also publishes a Discord and Reddit presence, and the Discord is moderated by the Open Watcom 2.0 GitHub group, with the stated purpose of removing spam and unrelated discussions, and intended for user and developer assistance about version 2.

The source tree is a builder-driven layout

The source tree layout section in the README is a description of a build system that predates most of the conventions a modern developer expects, and reading it tells you what building the toolchain involves.

The root of the source tree is specified by the OWROOT environment variable in setvars, and the documentation is explicit that all relative paths are taken relative to that location. The tree can be placed almost anywhere, although paths containing spaces are discouraged, and the documentation uses the backslash character as the path separator because that is normal for DOS, Windows and OS/2, with a note that a slash should be used on Linux systems.

The directories then divide into phases of the build. The bld directory is the root of the build tree, and each project has a subdirectory under it, for example bld\cg for the code generator, bld\cc for the C compiler and bld\plusplus for the C++ compiler, with projects.txt holding the details. The build directory holds the files used by the building tools, of most interest the *.ctl files, which are scripts for the builder tool, and the make files. build\binbuild is where all the build tools created during phase one are placed.

Then there is docs/ for everything related to documentation, sources and tools, distrib/ for the manifests and scripts used to build the binary distribution packages, contrib/ for third-party source code that is not an integral part of Open Watcom, including several DOS extenders, and rel/, which is the default location where the software that is actually shipped gets copied after it is built.

The rel tree, and how you install from it

The rel directory deserves its own paragraph, because it is the answer to the question every source-only project raises, which is how the binaries reach a user.

The rel directory structure matches the directory structure of the shipping Open Watcom C, C++ and FORTRAN tools, and you install the system by copying the rel directory to your host and then setting several environment variables. The structure is created on the fly during the build, and the location of the rel tree can be changed with the OWRELROOT environment variable.

That is a very 1990s installation model, and it is still the correct one for this toolchain, because the tools are not relocatable in the usual sense. The compiler, the assembler, the linker and the resource compiler all have to find each other and their headers, and the environment variables are how that is communicated. A package manager would have to reproduce the same environment anyway.

The build scripts around it are per platform, and the repository root shows the whole set. There is build.bat, build.cmd and build.sh, clean.bat, clean.cmd and clean.sh, cmnvars.bat, cmnvars.cmd and cmnvars.sh for the environment, setvars.bat, setvars.cmd and setvars.sh, and the packaging scripts zipup.bat, zipup.sh, zipuprel.cmd and zipuprel.sh. There is also buildrex.cmd, together with owconfig.bat and owconfig.vbs.

The tests/ directory at the root holds the test suite, and the documentation for both building and installation lives in the GitHub wiki rather than in the repository.

Documentation, and the state of the wider project

The documentation strategy is a bit unusual and worth understanding before you rely on it.

The build instructions and the installation instructions are both in the GitHub wiki, linked from the README, with the installation page hosted separately at open-watcom.github.io in the wiki documentation site. The README itself is deliberately thin: it points at the wiki for build instructions, lists the build artefacts, and describes the source tree.

That means the repository is the source of truth for the code and the wiki is the source of truth for how to use it, and a contributor changing behaviour has to remember that the documentation lives in two places. The WikiDocs workflow in the build table suggests the wiki content is at least partially generated or published by the pipeline, which reduces that risk.

The community channels are described with some care in the README. The Discord server for Open Watcom 2.0 is moderated by the GitHub group, is intended for user and developer assistance, and can be asked about older versions even though it is primarily for version 2. A second, general Open Watcom Discord exists for the older versions. On Reddit, the discussion is in the OpenWatcom community.

The state of the wider project is the thing the README is most candid about. The official site's bugzilla, wiki, news server and Perforce are down, and the GitHub issue tracker and the Discord are what is left. The project is a fork, so the question of long-term stewardship is a real one, and the answer the repository gives is the CI: as long as the builds keep running, the toolchain keeps existing.

For a user, the practical consequence is that the current-build channel is the thing to install, and the dated archive builds are your way back if a new toolchain release breaks something you depend on.

Editorial conclusion

Adopt Open Watcom v2 if you need the Open Watcom toolchain, either because you are maintaining 16-bit or 32-bit DOS and Windows software, because you want a 32-bit Windows compiler with an open and reproducible build, or because you are studying how a large toolchain is organised. Do not adopt it expecting an actively curated upstream, since the project describes itself as a fork whose purpose is to keep the toolchain alive, and note that the official openwatcom.org site has most of its services down. Before you start, read the Build and Installation pages in the wiki, and expect the build to be scripted rather than a modern package manager, since the tree is driven by setvars, builder scripts and a per-project bld directory.

Frequently asked questions

Official sources

1. Issues
2. open-watcom/open-watcom-v2 on GitHub
3. README
4. Releases