Provide Makefiles for Alternative Compilers such as Open Watcom,and DJGPP

[boeckmann]

I made the makefile for Watcom C in my forked repository to make it compile. I have to make some further adjustments to the code to make it fully workable. Are you guys interested in importing it?

[PerditionC]

Yes

[PerditionC]

Thank you, I'm just short on time currently, but I will look into merging any changes submitted. If you want to continue working on it I can give you access to the repository.

[boeckmann]

I definitely want to continue working on it. I would like to remove some bugs I found and reported to the FreeDOS gitlab repository. But Jerome advised me to better work on this upstream repository.

As a preparation I started to port the code to Watcom C and wrote a few compatibility functions to make it compile. The source now compiles with Borland C 3.1 and Open Watcom 1.9. This should not have introduced any new bugs when compiling with the Borland Tools, but I have to test the Watcom binary to make sure it works correct.

But here is the thing: As the very first step I processed the source once with clang-format to make it more readable. I found many different misaligned curly braces etc. that made the source harder than nessassary to read. I am sure that it had no impact on the output, because I compared the binary checksums from before and after the reformat. It is the very first commit in my watcom branch so that my later changes can be followed by inspecting the diffs.

But I do not know if you're ok with importing it because of the reformat which results in a huge diff. If not that is no problem. I can redo my changes for the current master without reformat. But all in all I think the code base benefits from it.

[boeckmann]

As a short summary of the "problems" I encountered when porting the software:

• The mixture of output functions (printf, cprintf etc.) makes problems with output buffering under Watcom C. I therefore disabled buffering for stdout when compiling with Watcom C directly after entering main via setbuf call.
• cprintf under Watcom does not support colored output. So I changed all calls to cprintf to Color_Print, implemented Color_Print to use cprintf under Borland and wrote an own implementation for Watcom. There are also functions that can do that in the Watcom C Lib (graph.h), but that pulls in another 25kb of code so I decided against it.
• textcolor function is missing under Watcom. I reimplemented it together with Color_Print.
• searchpath is missing under Watcom. I reimplemented it as a stub which only works for the current directory but will replace it with a "full" implementation in the next days.
• smartmbr prototype had to be declared as __cdecl

The rest was fairly straight forward and I encountered only a few compilation errors and warnings.

The makefile to build with Watcom makefile.wat. I also made makefile.bcc to compile with Borland C 3.1 (I do not have Turbo C).

I am using the medium memory model (multiple code segments, single data segment) because I got errors under Watcom C when compiling with small memory model, perhaps because the code already exceeds the 64kb code boundary.

The executable size of the Borland and Watcom binaries are comparable (have not turned on optimization flags yet in the Watcom makefile).

[PerditionC]

I'm fine with the reformatting. I actually want to do that to some other program sources.

[PerditionC]

As you proceed and test, consider replacing the Borland specific functions with yours or other cross compiler implementations unless those are written using watcom specific functionality.

[boeckmann]

I found one bug in the Watcom binary after the merge, but somehow my Github fork got out-of-sync after the merge so I deleted it. Is it possible to get push rights to some branch of this repository for continuing work? I think that would be easier for me.

[boeckmann]

That is implemented for. Source compiles with Watcom C1.9, Borland C++ 3.1 and Turbo C++ 3.0.

[boeckmann]

fixed