A crash was introduced by the prior commit, ee255d2. I
tested that the kernel still did build with gcc, but I
failed to test whether it also still runs. Turns out that
apparently changing the pointers to static made it so gcc
put the structure into the init data segment and
implicitly called memcpy to put it on the stack. That's
wrong, however. We depend on #define to convert all calls
in init to the init text copies of memcpy etc. The
implicit call by gcc however attempts to call the HMA text
copy of memcpy which happens to be at another offset.
The fix is to make the entire array of structs static so
that memory for it is allocated only in the init data
segment, not on the stack. This seems to work for both
gcc and OpenWatcom (no warnings, it builds, it runs).
CONFIG takes precedence and is by default initialised
to the empty string, that is, skipped. ALTCONFIG is
used to specify the 'alternative' filename and defaults
to fdconfig.sys. Finally, OLDCONFIG defaults to the
config.sys filename.
The protocol for this extension is based on what lDebug
already does given the PROTOCOL=FREEDOS with the switch
CMDLINE=1 (which was originally defined for the lDOS and
RxDOS load protocols). Therefore the stack frame mirrors
that of the lDOS protocol.
Also adds a CheckDebugger byte to the CONFIG block and
support for reading and writing this setting in the
SYS CONFIG program. Default is 0 (no check assume absent).
Here we depend on the signal instruction that is patched
by exeflat to indicate whether we were compressed. This
replaces the prior check that detected the UPX help data
solely by checking the CONFIG signature at 05E2h.
This commit does not change the behaviour of the code
as it already did the right thing. However, it notes
that that should happen. (This is DR DOS compatible.
For example, SHSUCDX depends on DR DOS setting this
segment so that it can keep track of the DOS DS
across it being relocated. We do not yet relocate it
but keeping a reference here is still useful.)
Fixes problem with GCC-ia16 compiled share not allowing open of files.
It seems that the TCC 2.01 compiled version was fortunate in that DS
happened to be correct when the interrupt was called, but this was
not the case for the GCC ia16 compiled version.
It's an analogue of this patch by @stsp for FDPP.
https://github.com/dosemu2/fdpp/commit/5b52510b
Delete and Rename should not be able to remove an open file,
so check share's open file table first. Behaviour is now identical
to MS-DOS 6.22.
Note: Uses a new subfunction of the FreeDOS share multiplex
interrupt int2f/0x10a6 called is_file_open()
A similar patch was applied to FDPP at
https://github.com/dosemu2/fdpp/commit/691721f1
Fixes dosemu2 tests:
test_fat_ds3_share_open_rename_fcb
test_fat_ds3_share_open_rename_ds2
test_fat_ds3_share_open_delete_ds2
test_fat_ds3_share_open_delete_fcb
original commit notes 'Fix an error at opening a character device prefixed with invalid drive letter (e.g. "@:NUL") (some application use it for opening character device driver)', need to test case but breaks TRUENAME asis
