In an earlier change, I removed appending newline outside of batch mode
in DOS shell code - that made DOSBox behave less like MS-DOS and more
like modern shells, that do not try to compensate for buggy
applications.
However, we should recognize that DOSBox (unlike e.g. FreeDOS) is designed
to run legacy applications, which might make assumptions about DOS
implementation. Some examples:
- PC Player Benchmark assumes, that help commands are displayed exactly
at 80x25 terminal and formats the output to fill the whole screen
(scrolling past DOS4GW messages).
- Quake and other ID games print shareware information on exit, but do
it via a direct memory dump (not interrupts to print DOS text), and
follow up with setting cursor exactly at line 22 (which is partly
written already), expecting shell to inject newline.
- PCC Compiler prints status message on exit without newline, depending
on MS-DOS shell behaviour.
- TEXTUTIL set of external commands do not print nothing to standard
output, and are designed to clear the screen, therefore writing a
newline after .COM commands would be a mistake.
Therefore we want to inject this newline, but not in every case.
New implementation reuses a static variable used by Program base class
(for purpose of translating UNIX newlines to DOS newlines) for detection
if it's appropriate to inject an additional newline or not.
Injecting the newline happens in function displaying the DOS prompt (so
we don't need to write additonal logic for separately handling batch
mode). When starting a non-COM, non-internal command the static variable
is set to the state indicating that next DOS prompt should inject the
newline.
Fixes: #208
a956f14de1