DOS ain't dead

Hello,

Jack R. Ellis released a new version of his UIDE/UIDEJR driver. It's a bugfix release and it's recommended to download this version if older versions of these drivers were used.

http://johnson.tmfc.net/dos/

---
MS-DOS forever!

This has been changed:

30-Aug-09   BAD "VDS init" ERROR fixed in UIDE/UIDEJR!   Other drivers 
              unchanged (re-dated only).   Users of UIDE/UIDEJR should
              download the 30-Aug-09 drivers immediately!

---
Forum admin

Now a fresh version from #. september is available.

---
DOS-u-akbar!

> Now a fresh version from #. september is available.

Jack wrote:
As you can see at Johnson's website, I have updated my
drivers twice more. The first was to add a big NOTE:
in their README that FreeDOS users must use JEMM386 or
JEMMEX without UMBPCI, if they want full upper-memory,
as noted by Japheth. FreeDOS does not "add up" the
memory found by multiple managers! The second was to
add XMGR "call" logic for a "protected mode" XMS move,
also from Japheth and same as UIDE does. I FORGOT to
do XMGR as well, when I upgraded UIDE 2 months ago!

If you can, do note these upgrades on your forum, with
my Thanks! "All out of ideas" for my drivers, so I
shall "rest" for a while!

---
Forum admin

I've received another mail from Jack:
Robert and Andreas,

With much regret, I had to update my drivers again. They
are now dated 7-Sep-09, and are available from Johnson Lam
at his http://johnson.tmfc.net/dos/driver.html website.

UIDE must move "reset" data, used to reset its cache, into
XMS memory during its initialization. My error was using
a move "source address" calculated from the driver's code-
segment! This runs fine for "real-mode" UMBPCI but is an
ERROR with "protected-mode" JEMM386 and other EMM drivers!

Though the driver "seemed to work" with JEMM386, it likely
was NOT using all allocated cache memory, due to incorrect
block numbers, and MAY have been corrupting other memory!

UIDE now uses its 32-bit "base address", obtained during a
"VDS lock", in such calculations, and the move "source" is
now correct when using JEMM386.

A "DUMB error!" by me, 5 months ago when I changed UIDE to
have its binary-search table in XMS memory. My apologies
to all.

Best wishes,

Jack R. Ellis

p.s.: The code involved is between symbols "I_RBlB" and
"I_RBlC" in the driver initialization. "VDSAd",
not the CS: register, is now used. J.R.E.

---
Forum admin

> 3-Oct-09 Fixed UIDE handling of cache XMS errors, NOT a big
> problem since XMS memory almost never fails! Minor UIDE/UIDEJR
> size changes. Other drivers unchanged (re-dated only).

Here's Jack's longer version of the latest changes:
The latest 6-Oct-2009 update to UIDE and UIDEJR was required due to a proven
problem in the V7.10 MS-DOS kernel, which many people still use.

Lucho on occasion runs a "DOS Extender". Running it with UIDE gave crashes
that "went away" using the 7-Sep-09 UIDE but "reoccurred" using the 3-Oct-09
UIDE. Both of Lucho's 6K-byte UIDE2 variants from those dates (that he may
put on future "boot" diskettes) worked successfully with his "DOS Extender".
If he also tried the failing 3-Oct-09 UIDE with /R (use no HMA), NO crashes!

In 2007, when UIDE could still put its binary-search table in the HMA, I had
to limit its maximum HMA usage to 9136 bytes, as V7.10 MS-DOS would CRASH if
UIDE used the actual "free HMA" value reported by the kernel! I suspected
Lucho's new crashes were similar, so I asked him to try a test: Re-assemble
the failing 3-Oct-09 UIDE with 16 extra bytes of zeros at its end, making it
EXACTLY the same size as the 7-Sep-09 UIDE, and test it again. NO crashes!

If loading the same driver logic into exactly the same memory addresses, but
with a slightly-larger "final size", gives NO crash (same as using /R), then
I believe Lucho's "DOS Extender" problems ARE NOT caused by UIDE! An ERROR
in the V7.10 MS-DOS kernel, when it reports "free HMA", is likely at fault!

So that UIDE and UIDEJR remain SAFE for all users, including those who still
have V7.10 MS-DOS, I have updated the drivers so they do not "automatically"
use any HMA space. The /R switch is now deleted and the drivers will again
default to loading in upper-memory or 640K "DOS memory".

Those who still want to use the HMA can request this with the new /H switch.
So far, no crashes such as Lucho experienced have been seen on V6.22 MS-DOS,
FreeDOS, nor any other DOS systems now in use. But, Gates & Co.'s wretched
HMA logic may have been "copied" in other DOS kernels! Thus, as I note in
the driver README file, specifying /H shall have to be "at the user's risk!"
from now on.

I am in fact DISGUSTED at having to make this change, but it is required due
to uncorrected Gates & Co. ERRORS, that never-WILL be corrected as they have
totally abandoned all support for MS-DOS!!

---
Forum admin