Last week I was prompted to take a look at the Intel Code Builder compiler from 1991, a 32-bit compiler targeting 386 extended DOS and shipping with its own DOS extender. It is what one might call an extremely obscure compiler; it had to compete with established offerings from MetaWare, Watcom, or Zortech, and soon also with the compiler heavyweights Borland and Microsoft.
One of Code Builder’s very few claims to fame is that early alpha releases of id Sofware’s DOOM were built with Intel Code Builder 1.1, before id switched to Watcom compilers for the DOS releases of DOOM.
There should be a file called
XMVM installed with Code Builder, but it’s just not there. Since it is required by default for linking of 32-bit executables, nothing works unless the
/XNOVM switch is passed to the compiler/linker.
The OS/2 Museum happens to have an archive of the Intel 386/486 C Code Builder Kit v1.0 installer which clearly explains why the other copies have no
XMVM file. It is in the installer archive… corrupted, and cannot be uncompressed:
The compiler can be installed, but the
XMVM file will be missing.
But wait! If the XMVM module is linked into executables produced by Code Builder, perhaps there is a way to recover it from Code Builder itself?
My first experiment was to create a dummy text file, name it
XMVM, and see what happens. The hello world program was successfully linked, but all attempts to run it caused hangs or crashes. Which strongly hints that while the linker does not care about the contents of the
XMVM file, it is in fact used at run-time and must be at least somewhat functional. So finding an actual copy would be good.
Sure enough, a closer look at the Code Builder executables shows that several of them (
DB32.EXE) do have XMVM linked in. There is an obvious signature (
XMVM 11-19-90 LVL=0208) indicating XMVM presence. But it’s a lot less obvious what the standalone XMVM file should look like, i.e. where XMVM begins and ends when it resides within a larger executable.
There are some clues offered by the executable format Code Builder uses. It’s somehow related to the format PharLap 386|DOS extender used. PharLap .REX 32-bit executables have an MP or MQ signature; Code Builder itself also produces .REX modules with MQ signature, but internally the DOS extender appears to use MR signature.
Sure enough, before the XMVM signature in a larger .EXE file, there is what looks like it might be a relocation table and an MR signature. And then several kilobytes down, there is an MQ signature followed by a large relocation table, presumably the actual 32-bit executable.
The MR signature is at offset C8B9h (51,385) in the file. Not coincidentally, the
XMLOD file which holds the core of the DOS extender is 51,385 bytes long. We can guess that when binding 32-bit executables, the linker copies out the
XMLOD file, optionally follows it with the
XMVM file, and then writes out the 32-bit .REX module.
XMVM file extracted from Code Builder 1.0 is 9,440 bytes long, i.e. its first byte is at offset C8B9h and the last byte at offset ED98h. Not only does this XMVM not crash, it actually works as a virtual memory manager, supporting paging to a swap file.
Here it is being linked into a hello world program:
In that case, XMVM doesn’t really do much, but without a working copy, the example either won’t link or won’t run. Now, the resulting compiler is still not that useful… but the surgery was a success!
The Intel Code Builder 1.0 compiler is probably an outgrowth of Intel’s earlier iC386 compiler, which I have never seen. Intel combined it with an almost unknown 32-bit DOS extender from IGC. Now, IGC (Intelligent Graphics Corporation) is not an unknown company; in the late 1980s, it marketed a product called VM/386 which was an early hypervisor running multiple DOS virtual machines on a 386 host. But the IGC DOS extender didn’t get far, even though it appears to have been fairly advanced (DPMI, virtual memory, etc.).
It is likely that by bundling the royalty-free DOS/4GW DOS extender with Watcom C/C++, Rational (later Tenberry) and Watcom more or less killed off the DOS extender competition in the early 1990s. While DOS/4GW was limited in comparison to the full DOS/4G product, it could do enough that most developers didn’t need anything more. In the mid-1990s, there was an additional wave of free DOS extenders which made selling a DOS extender a very difficult proposition. Well established products like PharLap’s 386|DOS and later TNT survived, but most commercial DOS extenders (Ergo/Eclipse/A.I. Architects, IGC, FlashTek, Salford SBOS) soon vanished.
It would be nice to compare Code Builder 1.0 with the older iC386, but I failed to find any trace of the latter. It clearly existed as it is mentioned in Intel’s documentation, but that’s about it. The Intel iC386 was probably one of the first 386 C compilers but does not appear to have been used for “normal” application development.