New version of DRL, the dirlister with color and sorting now online

Hi, after getting the DRL203.ZIP from the author, I have put a copy online
at: http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/

The new version of this program has a few differences from my "1.01" version:
Of course, it uses the CRT unit. MaxFiles is not 2500, was 1500. The color
scheme has been modified a bit (generally more "blue" background). The new
compile uses "Pedt Scragg's new CRT.TPU for hi speed computers", says the
source. GlobDirType is no longer used. Some variables have been removed.
The InCapitals (upcase string) function is Assembly language again (feel
free to plug in my Pascal version from 1.01 if you do not have an asm).
KbIn feels a bit different now. There is no longer a chr(7) beep for an error
(I had added this to 1.01 as 1.00 did feature commented-out CRT beeping in
"Bop" and "Beep"). NameString has been changed to use a string on the local
stack instead of a handed-over string as temporary variable, and * handling
has been removed from it. In SearchRecStrg, L is only word (was longint).
Instead, now Clstrs is longint (was word). Pct := 100 * (FileSize/ClusterBytes);
had a division by 0 security thing in my version, which 2.03 does not have.
However, my division by 0 check was done wrong anyway :-). The new version
displays spaces instead of "0.0.1980 00:00:00" and does something else if the
filename is PATCH.EXE (hu?). The filename ROOT.GHO also causes special
treatment... The TopLine function has been changed quite a bit with respect
to recursive listings, same for BottomLines. SYS is now colored as "executable"
as well. Some smaller bugs concerning confused global vars have been fixed.
The 2.03 version brings back the BUG that the line break after the help
screen is missed (1.01 has this bug fixed). Handling of non-existing drives
looks better i the new 2.03 version, which uses intr($21,Reg) again, while
I would have preferred MsDos(Reg). The attribute display now seems to be
limited to ... no, sorry. Misread that. The one-column "used" display now
looks a bit nicer. Because DRL now does not use ANSI (remember, that was only
a hack by me to avoid CRT), you can only dump black and white listings, either
7bit ASCII or with block graphics chars, to output redirection.
BUT you do not need ANSI loaded now. The screen row counting and
initial color detection iw using intr($10,...) "again", while I was
using access to the BIOS data segment and fixed values. My "hide LFN
paranoia patches" are not in 2.03, but 2.03 still does not display LFN
parts. Probably a problem that is worked around by the 2027rc kernel
anyway, so my LFN paranoia was really not needed. The expansion of
X:\foo\ to x:\foo\*.* probably works better now. The 2.03 DRL interprets
the error code 0 as "clear error flags", 3 is still "no such directory",
15 still "no such drive", 152 "drive not ready" and others still "cannot
read drive". After FindFirst(ThatDrv.Let+':\*.*',VolumeID,SRec);, DRL 2.03
now strips "." from the volume label before displaying it.

As you can see by my technical description, there are no big blinking
changes (however, some buglets which I felt were handled better in my
side-branch 1.01 which is NOT an ancestor of DRL 2.03), but some buxfixes
and code cleanups. If you like ANSI and are really paranoid about LFN getting
mixed into your directory listing due to some over-relaxed (buggy?) kernel, use
my 1.01 version. But if you like generally cleaner code that uses CRT, then
DRL 2.03 is the fix for all those that ran into problems with DRL 1.00 ...
As said, with kernel 2027rc, I could not sense any LFN troubles with 2.03 :-).

The docs are a bit cleaner now, too (hey, typo: "he top and bottom"...),
and of course the version history now lists some 2.xx versions (all 1999,
2.03 is the first compiled with the new version of CRT.TPU - remember that
if you compile with Turbo Pascal FIVE, you should get no runtime error 200/207
anyway, only compiling with version SEVEN needs to be done either with a fixed
CRT unit or with patching the result afterwards. I would be curious to know if
DRL 2.03 works with GHz processors thanks to the new CRT :-). Otherwise, we can
simply recompile it using Turbo Pascal 5.

When you use
upx -v -9 --8086 DRL.EXE
the file will shrink to 17144 (2.03) or 17052 (1.01) bytes, so I can
recommend this. The decompression time should be extremely short, so you
can be happy about the reduced size on disk without getting nervous about
the compressed file. The plain files are 36592 (2.03) or 37120 (1.01) bytes
in size, if you do not want to compress them.

Some interesting effect: A redirector / "network" drive in DOSEMU will
show the pseudo-label "emu/freedos" in all directories, while real labels
will only show up in all directories (hey, why that?) IFF you use the /L
option. Probably a slight misbehaviour of FindFirst in the FreeDOS kernel.

Correction! I have to report a BUG in MS-DOS in combination with DRL 2.03:
If you run DRL 2.03 with default (all) attributes selected with MS DOS 6.xx,
MS DOS will (while behaving exactly as FreeDOS with respect to labels "being
in all directories", so we are bug-compatible to MS DOS :-)) let LFN entries
slip through, which makes the DRL output look "horrible". I recommend that
you use DRL 1.01, but only IF your kernel has the same bug as the MS DOS 6.xx
kernel. DRL 1.01 works around the problem by having 1. some sanity checks to
supress entries with attrib and $0f being $0f (vol+r+h+s is the magic value
for "part of a LFN and not a normal directory entry") and 2. not setting the
search mask to more than $37 unless the user explicitly wants that. However,
FreeDOS 2027 (1.1.27) supresses those not-processable directory entries to
be found anyway, so you can use the otherwise smoother DRL 2.03 instead.

Very simplistic feature comparison:
DRL 1.01: black background, takes special care not to display LFN snippets
          even on buggy/old kernels, uses ANSI, the "total clusters" display
          is broken and there are no nice "no such disk" or "grand totals" disp
DRL 2.03: blue background, uses CRT (does not need ANSI), fixed with respect
          to totals/no such disks but broken LFN blocking may annoy you on
          kernels that do not block LFN entries for you anyway.

Neither of the versions are currently compiled to dump to file with color,
but in DRL 1.01 it is easier to modify the code to dump the ANSI sequences
along with the text :-).

Unless you have some weird problems with CRT (or want to port to Linux :-)),
I recommend that you UPDATE to DRL 2.03 (or possibly 2.04, which could have
some of the remaining bugs, especially LFN risk stuff, fixed...).

Thanks go to R.N.Wisan for the update but also for writing DRL in the first
place. I hope yet another update to 2.04 will come as a bugfix release ;)...

Cheers, Eric