DOS ain't dead

> What do all of YOU think??
Firstly a personal "thank you" for your continuing to update your good work.

> Please post your comments here,
> can be positive this is the best-possible UIDE /P upgrade, before
> beginning my driver changes.

I have used your other software but haven't used UIDE. However I have just taken the time to revisit your drivers to re-remind myself. All of your code is extremely well structured, self commenting but also well commented, every byte is there for a valid reason code. Still I can understand where you are coming from with regards size, however I think in this instance overhead increases are not as important vs the useful future looking functionality you are adding to UIDE.

If we were discussing XMGR then I would probably say that size is still an important consideration in relation to embedded setups. However as embedded setups are unlikely to use physical IDE drives then I don't see driver size as a problem there. That all said if size over your improved protected mode functionality is still important to someone then I guess someone could revert to using an earlier version of UIDE with the smaller overheads - so perhaps you could include the earlier version in the distribution also; giving people the option to choose?

Hope this feedback helps. Thanks again for your good work.

I'm ALL for the proposed change. UIDE is wonderful, and enabling a cache of up to 511 MB on all DOS systems is fantastic, even at the cost of 100-kb of low memory. Having the extra speed improvement on protected-mode systems is a good "bonus". This becomes even more advantageous when we realize that most of these old systems will benefit supremely from a large cache, considering the old and slow hard drives likely to be installed in such systems.

Those who want to use /P will, and those who do not need to will not. I think it would truly be the best of both worlds...

With regret, I have decided not to implement the "memory only" UIDE cache,
for the following reasons --

A) My cache-size calculations were based on 13 bytes of data per 64K cache
block, due to using an "old" (discarded) idea. In fact, UIDE needs 14
bytes per 64K cache block. This means a 125-MB cache will take 32K of
upper/DOS memory, 250-MB will take 59K, and 511-MB will take 116K. In
my opinion, this is getting to be rather excessive!

B) A "memory only" UIDE can gain an extra 10% of speed at best, versus the
current UIDE /P cache, whose binary-search table already uses upper- or
DOS memory, and whose other 12 data bytes per cache block now take XMS.
Thus, the current UIDE /P uses only 20K of upper-memory (not 115K!) for
a 500-MB cache, and using 64K it can go up to a 1900-MB cache!

I would rather NOT "burn up" so much upper/DOS memory for only a 10% speed
improvement v.s. the current UIDE /P driver. CPU and memory chips become
faster and faster, while hard-disk and CD/DVD "access times" have remained
more constant (7200 RPM appears to be the limit for a reliable and "quiet"
hard-disk!). Faster CPU/memory chips will ultimately reduce UIDE's speed
losses when using XMS memory to insignificance. As newer hard-disks also
use 32-MB or 64-MB of "on board" cache, I begin to agree with Japheth that
modern DOS systems using such FAST hardware may NOT need a software cache,
nor in any event such large use of DOS upper-memory merely for "speed"!

So for the moment, UIDE will remain as-is, and users can choose either its
"standard" 4-GB cache with XMS for cache tables, or its slightly-faster /P
cache with a binary-search table in upper/DOS memory and a maximum caching
capacity of up to 1900-MB (not just 511-MB!).

As noted to Japheth in private E-Mail, I apologize to all for being a SLOW
thinker, and I will go on trying to think of BETTER improvements for UIDE!

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