DOS ain't dead

My Thanks to my "partner" Johnson Lam, who is going for a vacation in Japan
but took the time to post a new 11-04-2009 DRIVERS.ZIP on his website, with
a corrected UIDE driver. http://johnson.tmfc.net/dos/driver.html

All UIDE issues from 17-Apr-09 thru 19-Oct-09 have an ERROR in their search
logic, which "flushes" their cache with a LONG delay when the cache becomes
full. The error is obvious when using a small 5-Megabyte cache, and I did
not notice this until recently, as I usually run tests using 500-Megabytes.
Not a fatal error (no crashes nor bad disk data), but it does reduce speed.

The 11-04-2009 UIDE driver has been corrected, and any cache size including
only 5-Megabytes will now perform correctly. In fact the 5-MB cache loses
just a "hair" of speed v.s. larger caches, due to discarding and re-reading
directory sectors as may be expected using only 5-MB. A larger cache need
not do this as often, and caches of 40-MB or more should perform very well.

My apologies for this ERROR and for failing to notice it for so long! All
UIDE users should get the 11-04-2009 DRIVERS.ZIP from Johnson's website, to
benefit from UIDE's better performance!

---
(Account disabled on user's request.)

Thanks for update!
In this opportunity I would like to ask what is now the more important part of speed benefit what UIDE gives.
It is the caching or the DMA transfers?
From your changelog it seems like DMA is more or less obsolete. Or am I wrong?

---
DOS-u-akbar!

> Thanks for update!

You are welcome! This update was difficult, VERY frustrating and it took
me 5 days to get a proper solution. But, nice results -- UIDE speed has
improved, and I did NOT need my "emergency plan", which was to put UIDE's
search tables back into normal memory! UIDE still takes only 4864 bytes
of upper-memory, or 992 plus 3824 bytes of HMA space, for any size cache!

> In this opportunity I would like to ask what is now the more important
> part of speed benefit what UIDE gives. It is the caching or the DMA
> transfers? From your changelog it seems like DMA is more or less
> obsolete. Or am I wrong?

Both DMA and caching are important, but in different ways.

I tried UIDE with caching but with my hard-disk run by my BIOS, and I set
the BIOS "VDS services" flag, so the BIOS would not use DMA. 32 seconds
to copy my big WINNT\SYSTEM32 directory, v.s. 5 seconds when UIDE handles
the disk using its own DMA routines.

If I use UIDEJR, i.e. DMA but no caching, copying my WINNT\SYSTEM32 files
takes 13 seconds, v.s. 5 seconds as above.

My conclusion: If one does much file copying, DMA is more important, but
if one does much "repetitive" reading of the same files (compilers, data-
bases, etc.) caching shall obviously become more important.

As I note in the drivers' README file, the best plan is to load RDISK and
put heavily-used files in RAMdisk memory, then load UIDE and let it cache
"ordinary" data files. RDISK uses 752 upper-memory bytes, UIDE uses the
memory noted above, plus the XMS memory needed for both drivers. Rather
a "cheap price", for their HUGE improvement in DOS performance!

---
(Account disabled on user's request.)

> New 11-04-2009 UIDE Available

COOL. I'll test occasionally.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***