Common bug: findfirst issue / List of other FreeDOS application bugs

Hi all,

after discussing a bug in FIND with Jim (jhall), I thought it would be
appropriate to do further testing with other programs as well...

The bug: findfirst() in Turbo C uses the semantics of the FCB version,
not the filehandle version, of the DOS API (did not check which int 21
call it actually uses), so it cannot take drive/path, only plain filenames
(with wildcards).

The symptom:
c:\foo> find "test" \autoexec.bat
results in a "file not found" error because findfirst cannot handle the "\",
nor would it be able to handle other path/drive stuff. Actually, find may try
to search autoexec.bat in the current directory instead. As Jim knows about
the bug now, a fix is already underway.

Other probably affected programs:
val (the linker)
edit 0.5
dog (tp has the bug, cp seems buggy as well - version 0.71 tested)
    (other commands may be buggy, too)
??? (you may find others)

Programs with other bugs and buglets:
dmake wants /usr/local/lib/dmake/startup.mk to exist...
unzipsfx cannot open .zip, only zip sfx!?
dosemu command (the plugin/builtin one, 1.0 of dosemu 1.0.2) has copy/xcopy
       with strange actions, hard to explain but feels buggy similar to the
       findfirst bug. Del does not complain if "del nothere.txt" is done in
       case that "nothere.txt" is not here. May have LFN troubles as well.
help   does not like me in dosemu "cannot exec foo" when I set pager=foo, foo
       being the name and path of the pager... Whatever.
htmlhelp, loadhi, te (editor), ted3 (editor, pc-mag), tde (editor, dpmi),
       locate, mode park, ... are generally cool - no error :-).
listxdef and keyman do not detect xkeyb 1.8 inside dosemu 1.0.2
dosemu does not give scankeyb the data it wants.
wcd    crashes dosemu for big trees in redirected drives (current dir being
       readonly, by the way), dosemu 1.0.2, when trying to build an index.
cmd, setlock, protocol do not have any effect that I would understand, so
       they should really implement a better /? option.
freecom goes TSR when invoked with the /? option (should exit after displaying
       the help if you ask me)
join, subst (make a new drive letter from a subtree of another drive) do not
       seem to have any effect (dosemu 1.0.2, kernel 1.1.24)
swsubst is far too complicated in use, uhm... Whatever, join/subst/swsubst
       HOWTO would be nice to have.
move   (version 1.1) cannot rename, destination is always a directory. No
       real problem, there is "ren" as well (I think ren even has destination
       wildcards with pattern matching?! :-)).
tail   erroneously tries to open "files" that are only parts of LFN filenames
       when using tail with wildcards. Version 7.02 - solution would be to
       skip entries with attrib & 15 == 15 (LFN magic attribute).
comp   gives confusing error messages when only 1 file is specified, and the
       /? help is nonexisting and thus miserable.
rerror fails to redirect output in dosemu - did not try in plain DOS yet, but
       the redirection tool that comes with DJGPP does work with dosemu, so...
stamp, touch have a problem with dosemu 1.0.2 kernel 1.1.24, too: They can only
       set but not modify timestamps. Not cross-checked with plain DOS and/or
       newer kernel either.
which  can show several "hits" if arg.{com,exe,bat} is found at several places
       in the PATH (invoke as "which arg"), I hope the -sorting- is the same as
       the search order of DOS when trying to run arg??? Also, does not display
       an error message when it did not find a match, nor has it /? help. The
       error message could be made optional, using a /verbose flag, I think.

I hope some of you can verify my bug-list and add testing with plain DOS and
the current kernel for the "dosemu" type of errors. I think testing one kind
of environment per day is enough, and today I have only tested in dosemu.

Most important would be of course actually fixing the bugs ;-).

By the way, if I leave PAGER unset (default: more), "help" works okay.

Programs tested (note that most do not take filenames as arguments anyway,
so they are no candidates for findfirst bugs):
EXE:
choics, copy, fc, kludge0, nbstat, shsucdx, te, find, help, label, mem,
more, move, replace, sort, swsubst, join, subst, tdsk, xcopy, keyman,
listxdef, xkeyb, xkeybres, pause, du, fdpower (APM for DOS :-)), finger
(checksum tool), bitdisk (ramdisk thing), tail, trch (tr), wcd, htmlhelp,
ptchsize (for command), ctmousde, xmstest, share, scankbd, zip, unzip
(the last 2 use cwsdpmi).
COM:
ted3 (PC-Mag tiny text editor), assign, command, comp, debug, deltree,
exe2bin, hgctest, cmd, sys, loadhi, mode, tree, vol, cal, cmos, dog, dt
(date/time display), head, which, popd, pushd, locate, protocol, rerror,
setlock, stamp, tee (-a option anybody???), touch, attrib, kssf (of command),
vspawn (of command), verify.
Bonus:
dmake, val, lib (make/link/lib - compile tools), zip, zip16, zip16-sm,
zipnote, zipsplit, zip, unzip, unzipsfx, funzip (the last one is for pipes,
basically all zip stuff uses cwsdpmi, apart from *16* versions, I guess!?),
edit (DDJ freedos edit 0.5), notepad, fips/fdisk/fddefrag/fddefrgc/scandisk/
mirror/unformat/format/diskcomp/diskcopy/restorrb all NOT tested (all disk-
tools I mean) as they usually do not take files as arguments, bec (basic),
bwbasic (basic), ospedit (the sound drivers cannot be unloaded!? Very strange
idea to allow a background .wav sound for a text editor anyway...).

Basically, I just went to c:\freedos\bin\ and tried everything there
and "beneath" (in subdirectories). I did not install all packages, so
I did not test the whole FreeDOS collection. Nor did I try c:\bin\*.* ...

Anyway, I think this list contains quite a few fixable bugs. Find, edit
and dog are good examples of tools that you do want to accept paths on
the command line (in double sense in the DOG case) but that did not
reliably do so in the versions that I have just tested. Some of the
dosemu things would be a real improvement if fixed, too. By the way, it
would be great if the DOSEMU plugin command.com could be based on the
FreeCOM / DOG ones, as the 1.0 plugin of dosemu 1.0.2 is very simplistic.

Have fun with my bugs, if possible ;-). Happy DOSing.

Eric

PS: I still got no reply on my "how about doing > 32 MB sector access in
UNDELETE in an asm-free way, as in <some tool, see my mail then>" suggestion.
I mean, would be nice if somebody could tell me if it is supposed to work
like that. If yes, I would change UNDELETE in that way. The tool was CSAP, I
think, which probably goes mad because it miscalculates the "first dir sector"
and "first data sector" values. Would be nice to have feedback on that, too,
because then you could use the calculation in UNDELETE style which work better.
Funny. Take absread from CSAP for UNDELETE, take calculatestuff from UNDELETE
for CSAP... (not sure if it was CSAP - see my other mail for details, sorry).

PPS: Has anybody seen DRL 2.xx online yet? See the old thread on it.