Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

thoughts about systematic testing (Announce)

posted by tom Homepage, Germany (West), 12.04.2022, 19:18

> > The real question is why it's so slow (the RAM drive in particular).
>
> Perhaps it's not related to doslfn at all. It might be a BIOS bug, setting
> up memory beyond 4GB as "uncachable" via MTRRs. I remember that, when
> HimemSX was introduced, another member of this forum (Zyzzle?) had such
> problems.

he should start without CONFIG.SYS and AUTOEXEC.BAT (and the guarantee that no offenders are lurking in his system)

compare apples to apples.
have a batchfile to *consistently* create a directory with known size(see below) and known content. size, because a directory that once held Japhets 10000 files and at least 20000 directories will never shrink again.
huge directories are a problem for the way COMMAND generates long filenames.
when iterating over short filenames DOS knows where exactly to look for the next filename, and the sector is most often already in a buffer. to translate this short name into a long name it always starts at the beginning of the directory, and iterates on average half of the entire directory (which is clearly suboptimal).




now see what the times are for the USB drive, and if they are significantly different from WITH config/autoexec. if so, find the culprit.

then compare himemX (4 GB only) and himemsx (but also 4 GB).
are there significant differences? there shouldn't, but it's possible.

compare doslfn and doslfnMS. there shouldn't be a difference.

last, but not least: why is this interesting at all? in all cases, real people are looking longer at the directory listing than it took to print it. even on a IBM PC with 360K floppies.

 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 388 users online (0 registered, 388 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum