Docker image for Open Watcom and ELKS

[toncho11]

@ghaerr This is just an idea to create a docker Linux image for the Open Watcom compiler on top of ELKS development environment.

1. one can either distribute a small docker file so that others can build an run image locally
2. or build an image and share it on a public repository so others can download and run it

It can contain a few examples on compiling existing applications with OW. Isn't it a good idea to compile edit with large memory model so that bigger files can be edited?

[ghaerr]

@toncho11 - I'm running macOS and can't run Docker images. We already have an ELKS Dockerfile, is this suggestion something that would build OpenWatcom, or just have the OW binaries installed?

ELKS support for OpenWatcom is primarily for those that already have OpenWatcom installed, or have applications already built with OW that want to port them to ELKS. Replacing ia16-elf-gcc with OW at the moment doesn't bring much in new features, as all the ELKS applications are small enough to be built with ia16 (see more on this below).

I think that the OW installation program is pretty straightforward for those that want to install it on their system. These binaries aren't installed in the ELKS subtree, so I'm not sure what the Docker image would be for.

I plan on automatically building the ELKS C library for OpenWatcom, but that isn't currently being done with an ELKS build since OW may not be installed, which would break it.

Isn't it a good idea to compile edit with large memory model so that bigger files can be edited?

Yes, one would think so - but unfortunately with the 8086 segmented architecture, pointers, even in large model, are still limited to a 64k range of memory. In addition, the program's heap (using malloc) is also limited to 64k, just like in small model. So compiling edit in large model doesn't in fact automatically allow bigger files to be edited. In order to do that, one would have to rewrite edit so that it manages separately-allocated 64K chunks of memory, conceptually treated with extra code to allow larger files to be edited.

The limitations of large model and the 8086 real-mode segmented architecture weren't enough to allow "flat" treatment of > 64K memory, and at the time lots of extra code may have been written to get around that. For those older programs already written in OpenWatcom C, we should be able to compile and run them. The other programs got left in the dust when 32-bit "flat" addressing came out, and everyone left en-masse to larger programs, never looking back (except for people like us though :) ).

[toncho11]

I am learning more about the memory management. It seems _dos_allocmem is used for allocating big chunks of memory (300kb) in doomtd3. doomtd3 uses either the built-in function or its own implementation as pointed out here.

The binaries produced by the ELKS OW are very close to 16 bit OS/2, right? So for doomtd3 _dos_allocmem will use its built-in version , but then its implementation uses system call INT 0x21 - 0x48 - Allocate Memory which is only available on DOS and OS/2 I suppose. So this means that it won't work.

So the custom version of _dos_allocmem in doomtd3 must be used and adapted to ELKS. Is that correct? I had a quick look at it, it looks like it needs modification to work as 16 bit and not 32 bit.

[ghaerr]

@toncho11, you should be alright porting doomtd3 to ELKS, as ELKS supports fmemalloc to allocate big chunks of memory, much like _dos_allocmem does. One doesn't have to use OpenWatcom in order to use fmemalloc, either.

The binaries produced by the ELKS OW are very close to 16 bit OS/2, right?

ELKS uses the OS/2 binary format for OpenWatcom executables to run on ELKS, but that's not the same as running an OS/2-format executable built for OS/2. They're entirely incompatible, only the executable format (container) is the same. ELKS doesn't support any DOS- or OS/2-style INT 0x21 functions, and instead has its own set of INT 0x80 OS functions, most of which are in the ELKS C Library for OpenWatcom.

So the custom version of _dos_allocmem in doomtd3 must be used and adapted to ELKS.

No - fmemalloc will work as a direct replacement. Use eman fmemalloc on your host (with ELKS built) to read about it. Porting Doom to ELKS should be possible, there are many versions out there for 16-bit, but all DOS, timer and interrupt routines will have to be refactored.

[toncho11]

@FrenkelS states in FrenkelS/doomtd3#11 (comment) that there are probably no special routines except maybe for:

void I_StartClock(void)
{
	starttime = clock();
}

uint32_t I_EndClock(void)
{
	clock_t endtime = clock();
	return ((endtime - starttime) * TICRATE) / CLOCKS_PER_SEC;
}

which is implemented with clock(), but can be replaced by other routines in ELKS?