Prior to this commit the first cluster specified from the last
compared directory entry would be used if the file is not found.
Fix the wrong (boot.asm) or missing (oemboot.asm) jump to the
error handler so that on file not found an error is displayed.
Reference: https://sourceforge.net/p/freedos/bugs/97/
"Bugs in FAT12/16 boot sector loaders if file not found"
This commit fixes the most crucial bug of this 2012-09-27 report.
After comparison with DR-DOS 7.01 and MS-DOS 6.22 over at Dosemu2 it
was seen that rmdir of a directory having the _A_RDONLY bit set should
succeed. This patch makes that change.
For reference the test report can be found in the fdpp issue
https://github.com/dosemu2/fdpp/issues/161. An identical patch has
been applied there.
Reference: https://hg.ulukai.org/ecm/instsect/file/33218c729b43/instsect.asm#l1257
lDOS's instsect recently started to default to checking
the filesystem ID string in order to validate that the
boot sector loader to write matches the detected FS.
Using the /S=filename option or building instsect to
include the FreeDOS kernel's loaders would require use
of the /SN switch without this commit.
In addition, boot.asm and oemboot.asm are made to check
that exactly one of the ISFAT12 and ISFAT16 defs is
defined so as to select the FS. Prior to this commit
using both or neither def would silently result in a
broken loader.
Reference: https://www.bttr-software.de/forum/forum_entry.php?id=16934
The SBC188 video ROM-BIOS handling returns with al=0Ah (LF)
upon interrupt 10h function 0Eh calls that scroll the screen.
This made the FAT12 boot loader crash when booting FreeDOS
off a 1440 KiB diskette. While a fix is expected from their
side too, hardening the loader too is the right thing to do.
With the way this fix is implemented by this commit, it only
needs one additional byte for the loader. The error message
changes from "Error!." to just "Error!", other than
that the behaviour is the same.
The FAT32 loaders already used zero-terminated strings and
thus were not affected by the dependence.
correct I186 and I386 macros definition to work with all Open Watcom toolchain versions
command line definition macro has "1" value but in header file it is defined as blank value
anyway I86/I186/I386 macros usage is not transparent, it is definition duplicity in header file and on command line
it is wrong solution even if it works on most of compilers (command line macro re-definition is hidden)
Watcom compiler is downloaded and extracted if necessary. On Travis this
will be always, but if you build locally multiple times using
./travis_build, it will use the previous watcom installation.
[fixes#18]
