XMVM Surgery

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 is one poorly preserved archive of Code Builder 1.0 available. As others have noticed, it won’t even build the trivial hello world program that comes with it:

Linker error caused by missing XMVM

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:

XMVM is missing because installer was corrupted

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 (IC32.EXE, IL32.EXE, LIB32.EXE, 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.

The 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:

The results of a successful XMVM surgery

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!

Origins

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.

This entry was posted in 386, Development, Intel, PC history, Software Hacks. Bookmark the permalink.

10 Responses to XMVM Surgery

  1. Fernando says:

    This compiler was not just for DOS but for the operating system from Intel iRMX. If the DOS version disappeared, good look finding the iRMX version.
    I find also a manual and references to a Intel PL/M 386 compiler from the same era that says that is compatible with Intel iC-386. Most probably another software lost to the ages.
    There is a manual of the compiler at Bitsavers in case somebody are curious:
    http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/iRMX/iRMX_III/iRMX_III_V2.2/469163-004_iC-386_Compiler_Users_Guide_Nov95.pdf
    It appears that Intel sold or licensed the iC-386 and PL/M 386 compilers to RadiSys (according to Wikipedia started by ex-employees of Intel), I found a manual to the PL/M Compiler from Radisys and this iC-386 bmanual:
    http://www.nj7p.org/Manuals/PDFs/Intel/Radisys/IC_386.PDF

  2. Michal Necasek says:

    I bet someone still has the DOS version. It’s probably used to maintain some software that controls aircraft or ballistic missiles or something silly like that 🙂

    It appears that the old Intel development tools are or at least were owned by TenAsys.

  3. Michal Necasek says:

    Hmm, perhaps not disappeared completely: https://mark-ogden.uk/files/intel/msdos/ic386/0.2/

  4. Is there specific environment variables to setup with the Intel – C Code Builder 1.0? I never could get it to do much of anything as it seems to want some kind of environment built.

  5. Michal Necasek says:

    The installer adds the BIN directory to the PATH and also sets CBPATH to point to the root of the Code Builder 1.0 installation (i.e. one level above BIN).

    It’s a really weird compiler, and it’s kind of odd that Intel had a 386 compiler (iC386) that hardly anyone used.

  6. Jeffrey H. Johnson says:

    Apparently there was a 16-bit version of Intel Code Builder, which supported 16-bit protected mode and provided a 286 DOS Extender.

    I haven’t looked to see if these versions here support the 286 yet, but if they don’t, I wonder if that might be available somewhere.

  7. Michal Necasek says:

    Any idea what the extender was? It makes some sense because Intel did have a 16-bit x86 compiler, iC-286 (and also iC-86). Adapting 16-bit C compilers to generate protected-mode code was not difficult, if adaptation was even needed.

    The known Code Builder is 32-bit only.

  8. Michal Necasek says:

    Oh, very nice. Thanks!

  9. Michal Necasek says:

    Hmm, the docs include the 286 and 386 compilers, but the disks are iC-86 only. Still good to have though 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.