these symbols are in LGROUP and generaly cannot be addressed by DGROUP:offset
for Turbo C DGROUP offset overflow because symbols are too far to be addressed by DGROUP offset
- fix issue by renaming header file and symbols which consolidate with standard C time.h
- rename also date.h for consistency
- remove all hacks from make files and from sys.c
now can share new dtime.h with standard C time.h without any collision that any order of internal and standard C header path is possible
getbpb now returns 0 instead of S_DONE in case of an uninitialized
partition, copying the default BPB into the BPB.
The previous return of S_DONE in case of uninitialized partitions
resulted in rp->r_bpptr not getting set in bldbpb. This in
combination with indicating success resulted in garbage returned
via rp->r_bpptr.
The DPB values are now being set to the default BPB ones in media_check
ea951d8136/kernel/fatfs.c (L1728)
via call to bpb_to_dpb in case of an uninitialized partition.
This may have side effects. But because DF_NOACCESS is still set, I
think it is the right way to do it.
The commit also masks high bit of AL for INT25/26 containing the drive
number. Some programs may set the bit according to RBIL:
"examination of CPWIN386.CPL indicates that if this call fails with
error 0408h on an old-style (<32M) call, one should retry the
call with the high bit of the drive number in AL set"
Leaving the bit set may render the given drive number unusable.
It should do no harm to mask it to increase the chance of the operation
to succeed. Also, the AH should be set to zero, because drive is given
only in AL.
When country was converted to a submodule (by me) the production
installation target was hacked onto the kernel subdirectory Makefile
which wasn't ideal. Introduce a production target into the country
Makefile that does the installation. Since we want the submodule to be
buildable standalone, we can't include the variable definitions from the
upper level, such as $(DIRSEP) and $(CP), so the caller has to pass those
in at build time if using the production target.
Tested on Linux (GCC + Watcom) and DOS (Watcom)
Picked from the commit at fe1c4dc7fe
The referenced issue is at https://github.com/dosemu2/fdpp/issues/212
The patch was applied using unix2dos on the patch file
then `patch -p1 --binary` with the patch file as stdin.
The original used a new define for the maximum path length.
As there is no difference to our current SFTMAX define I
changed this hunk to retain the SFTMAX use.
This fixes a bug when eg function 3Dh receives a buffer
that starts with ".\" but the byte in memory before this
buffer happens to be also a dot. I ran into this problem
semi-randomly during building EDR-DOS with the most recent
WarpLink build. If WarpLink was placed somewhat low in the
Low Memory Area then one of its function 3Dh calls would
happen to have a dot before the pathname buffer. (I had to
load lCDebug using the last fit strategy then enter TSR mode,
to catch the bug without the presence of the debugger working
around the occurrence of the bug.)
Original commit Metadata:
From: Stas Sergeev <stsp@users.sourceforge.net>
Date: Wed, 1 Feb 2023 13:01:55 +0500
Subject: [PATCH] truename: fix array overrun [fixes#212]
src[-2] was peeking into a random memory location.
It seems entire truename() is written by some morons... :(
Its completely unreadable and full of bugs.
