Anybody interested to recompile DRL w/o CRT overflow and LFN (tiny) bug

Hi,
while I have tried to convince George NOT to recompile DRL (the
sorting, colorful, multicolumn, paged DIR), a Pascal program, just
because it contains that "timing loop overflows for > 180 MHz with
a runtime error 200 bug", I found another, more annoying bug in DRL:

D:\FOO>c:ldir
...
YYY     .             5  10.21.2002  04:59  YYY
LANGER~1.             5  10.21.2002  04:59  langerdateiname
SEHRSE~1.NAM          5  10.21.2002  04:59  sehrsehrsehr.langer.datei.name
...

D:\FOO\>drl /u   <-- /u is for "unsorted"
...
Cn                <Vol>  31-
                             D:\FOO\*.*                                        
l                <Vol>   5-Mar-80  00:03:40   737  99.9%  RHSL                 

s                <Vol>   8-Mar-80  00:03:10   737  99.9%  RHSL                 S
EHRSE~1.NAM          5  21-Oct-02  04:59:20     1   0.1%  A                    
...

The rendering of long file names is kind of, you know, not very satisfying.
As any good dirlisting tool for 8.3 names, it should not display any lines
where attributes say "volume label + RHSL" (a marker meaning "long file
name fragment" to modern O/Ses, and meant to be too weird to be displayed for
older tools. The latter is the behaviour I would like from DRL.

So my question:
Do you think it would be an option to recompile with Turbo Pascal 5.5 (free
in the Borland community museum) and then binary-patch it with the tools I
mentioned recently?
Or would you prefer to recompile with a Turbo Pascal > 7.xx that handles
processors > 200 MHz correctly anyway? If yes, I would need a volunteer to
do the compiling, as I only have Turbo Pascal 5.5 (but I can do the binary
patching, even by hand - not the first Pascal program that I would have
"rescued"...).
I would love it if somebody could do the patching and check for general
weirdness in the code, who knows if there are other bugs. Be warned that
the code is very spaghetti-ish. But a good text editor with regexp search
should at least make fixing the attribute-of-LFN-should-cause-hide-from-
listing problem easy.

By the way, a good ALIAS fixes the bug as well:
D:\FOO>drl /u /nrhsda
...
YYY                   5  21-Oct-02  04:59:24     1   0.1%  A
SEHRSE~1.NAM          5  21-Oct-02  04:59:20     1   0.1%  A
...
(I have deleted "langerdateiname" in the meantime, just in case you
were wondering)

So the /NRHSDA option circumvents the bug, at the small prixce that
DRL will not display the volume label anymore.
However, who knows, maybe a clean fix of the problem would be nice as
well :-).

Eric




PS: Just in case you were wondering, my UNDELETE now says:
...
Saving DIR until EOF or count reached...
...
           YYY     .    04:59:24 21.10.2002 @00044, size 0000000005 a
Del/Lost:  ?m?e????.??? 31:63:62 31.15.2107 @00000, size -0000000001 <LONG>
Warning: ClusterHI=ffff
Del/Lost:  ?l?a?n?g.?e? 00:03:10 09.03.1980 @00000, size 0006357102 <LONG>
Warning: ClusterHI=74
UnDelAble: ?ANGER~1.    04:59:20 21.10.2002 @00045, size 0000000005 a
           Cn?a?m?e.??? 31:63:62 31.15.2107 @00000, size -0000000001 <LONG>
Warning: ClusterHI=ffff
           ?l?a?n?g.?e? 00:03:40 05.03.1980 @00000, size 0003014761 <LONG>
Warning: ClusterHI=61
           ?s?e?h?r.?s? 00:03:10 08.03.1980 @00000, size 0003014770 <LONG>
Warning: ClusterHI=73
           SEHRSE~1.NAM 04:59:20 21.10.2002 @00046, size 0000000005 a

As you can see, it flags the entries that are part of LFN as <LONG> but
displays them anyway. I think this is an acceptable choice, as you may want
to undelete entries with strange attributes as well (that look like but are
not long file names). By the way, the "?" is also a feature of UNDELETE, it
avoids printing unprintable characters.