Bugfix: DRL error 200 (TPascal CRT timing). Unfixed bug: CSAP dirsorter

Hi, remember when I mentioned
DRL100
the cool coloured sorting directory lister with selectable amount of
columns and a pager? Found on: http://www.simtel.net/pub/msdos/ ->
Directory Tools (or similar, see my old mail).

It turned out that it does not run if your PC is faster than 200 MHz,
but gives a "runtime error 200" instead. This is because it has been
compiled with an old version of Turbo Pascal or Borland Pascal. When
DRL tries to initialize the delay loop (this happens in all Pascal
programs that use the screen library (CRT)...) and overflows! The
solution is to binary-patch the program (or recompile with a newer
compiler, I think 7.01 is the first to fix this, but it is not free).

There are at least 3 patches available:
CRTFIX - outdated, http://www.simtel.net/pub/msdos/turbopas/
BPPATCH - modifies the delay loop to use 32bit counters, by a PC magazine:
          ftp://ftp.heise.de/pub/ct/ctsi/bppatch.zip
TPPATCH - simply clips/saturizes on init, so your program will run too fast
          if it uses sleep() but will not crash:
          http://www.brain.uni-freiburg.de/~klaus/pascal/runerr200/tppatch.zip
I found those links on:
http://www.brain.uni-freiburg.de/~klaus/pascal/runerr200/
by searching Google for "turbo pascal error 200" - as DRL comes with the
Pascal source code, and as my programs run too fast, too, this was an
obvious choice :-). My PC is too slow to overflow the counter, but too
fast to allow unpatched programs to get sleep() right, if you want to know.



So this should fix one of Georges problems.
The next problem: His KT133 Athlon chipset seems to be unsupported by
UMBPCI and all the likes of it. Is there another UMB enabler he could try?
Otherwise he would use DR DOS emm386 (he needs VCPI, so FreeDOS emm386 is
not an option, and he sure does not want to use MS DOS emm386), I guess.

The next problem is that Turbo C++ TC (the IDE) crashes when it tries to
use DPMI. Probably the built-in DPMI host (DPMI=ON) of DR DOS emm386 will
help, but running DR DOS emm386 in that mode makes some lowlevel device
drivers crash, especially when loaded -after- emm386.

Final serious problem is that CSAP crashes most of the time with FreeDOS.
Anybody knows more? -> http://members.cox.net/dos/dir1.htm
I have read the code: It uses absread() and abswrite() (CSAP is an
open source freeware directory sorter for FAT16). This will FAIL when
CSAP is compiled with Turbo C 2.0x or Turbo C++ 1.0x, when trying to
access partitions > 32 MB. The reason is that those old Borland
compilers do not handle the new > 32 MB calling style of absread and
abswrite correctly. Maybe somebody could add the diskio.c + bigdisk.asm
style that is used in my UNDELETE tool to CSAP and then replace all
absread / abswrite by new_absread / new_abswrite with a text editor?
This would allow us to recompile CSAP with our free compilers (the ones
mentioned above) but would also introduce the need to have NASM to do so.

PS: I have played with CSAP in xDOSEMU (using a diskimage):
C:\HOME\RAMDISK\CSAP>csap -f -r -p d:\
C-Sort And Pack [CSAP]: Version 4.2.3: Date: July 21, 1995 [Compact Model]
    use "CSAP -H" or "CSAP ?" for help.

Sorting: D:\
    Location: 000DH-002CH
    0 Erased entries removed
    0 Unused entries Zeroed
Sorting: D:\BAR
Abnormal program termination
(bar is one of foo, foo\baz, bar test directories, and -f -r -p is the
mode that causes least changes to the directories...)
My undelete tool says: FOO and BAR are in clusters 39 and 40.
They contain empty files (touch...) which are in clusters 0 (hey, did
not know DOS could do this). BAZ is in cluster 41.
Hm. When I give CSAP non-empty files/directories, it fails even worse.
According to my undelete tool in dirsave mode, the filesystem did not
get harmed. Phew. By the way, it is 8 sec/clust, 2 fat, max. cluster
number 2024, 6 sec/fat, 512 root dir ents, first data sec 45.
A tiny little 8 MB freedos FAT image and CSAP still does not get it!
Sigh. Maybe YOU out there can sort it out.

Eric