Open ssokolow opened 3 years ago
Hi Stephan, thanks for your suggestion.
Supporting multiple compilers is always positive. But in the case of DOS, this is made more difficult by the fact that most low-level features are implemented using Borland's inline assembly or in Turbo Assembler files. So I suspect that DOS support would require rewriting many things from scratch, possibly once per supported compiler.
This project puts the focus on modern systems so that it can be useful to the broadest range of users. Be thankful that it supports DOS at all; I'm pretty sure that many other developers with the same purpose would have dropped DOS support early in the process. DOS users still show up from time to time (#17, #22...), and I am interested in keeping DOS support in good shape. However, I have no evidence that there are enough users out there who are both developing productive applications for DOS and refuse to use Borland C++. So I feel that I have no duty to implement this.
In short: I am not willing to do this just for the fun of it.
I have little experience programming for DOS. If I was expert enough, maybe I would see things differently.
Anyway, if someone else wants to work on it, I'll be glad to help them integrate their solution into the project.
Cheers.
Fair enough.
I do currently have a DOS project I'm working on intermittently (a DOS analogue to Inno Setup) with Open Watcom C/C++ (because ideology), but I have good reasons not to use Turbo Vision for any of the three parts of it:
graph.h
with my own size-optimized int 10h
wrappers and I'm doing the same with splitting the command string from the PSP into argc/argv so the CLI argument parser and control script parser can share size-optimized code wherever possible.)That sounds cool.
Yeah, Turbo Vision is no longer useful in many use cases where 30 years ago it would have been the first choice. For example, the people who opened the DOS issues I mentioned earlier seem to have switched to the graphical fltkal.
Let me ask you something: is there a specific reason why you seem to prefer Open Watcom C/C++ over other cross-compilers such as DJGPP?
nsis
package.)I care deeply about making this project easy for others to hack on once it's in a state I'm ready to git push
(right now, too much of the documentation is a thought experiment, rather than representative of what's been coded) and Open Watcom C/C++ is by far the easiest way for someone on DOS, Windows, or Linux to install a single open-source toolchain that does everything mandatory for the build. (Though, if you want the optional extras, like Doxygen apidoc, splint static analysis, or the auto-formatting for code and Markdown, DOS isn't an option.)
Thanks. This knowledge will come in handy if I ever need to use these tools :).
No problem. The one caution I have is that there's a known bug in the Open Watcom C/C++ installer for Linux.
If it crashes on launch, that means it couldn't find the terminfo definitions. That can be resolved by setting either TERMINFO=/path/to/terminfo
or TERM=vt100
. (Or you can just point unzip
at it and then manually write the owsetenv.sh
file it creates.)
Given that Open Watcom C/C++ (1.9, v2 fork) is open-source and Borland C++ 4.52 is not, would you be willing to consider making Open Watcom an officially supported compiler for building DOS applications?
(Aside from a known bug in the Linux installer which you work around by either setting
TERMINFO=/path/to/terminfo
or settingTERM=vt100
, it's also by far the easiest way to cross-build for DOS from modern OSes.)