Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

New UIDE Update -- "External Entry" Logic Deleted. (Announce)

posted by Jack E-mail, Fresno, California USA, 18.06.2010, 06:01
(edited by Jack on 18.06.2010, 20:48)

Johnson Lam has posted an updated DRIVERS.ZIP file dated 16-Jun-2010
on his website at <http://johnson.tmfc.net/dos/driver.html>. Each
driver but UIDE is unchanged and is merely re-dated to 16-Jun-2010.

It is now obvious USBDRIVE will never call UIDE for caching. Since
demands for UIDE changes that I view as unnecessary had become quite
insufferable, I decided to accept a suggestion from BTTR post #8103:

UIDE shall now ignore a /E switch, and its "external entry" routines
have now been summarily deleted.

USB drives thus will not be cached, not by UIDE hard-disk logic that
must ignore "removables", nor by UIDE "external entry" logic that is
now gone, per BTTR #8103. UIDE.SYS shall now be 111 bytes smaller!

But for USB units, this change does not affect any UIDE users, as in
fact, no other drivers ever called UIDE's "external entry" routines.
Sad, but I realize how little DOS device-driver work is done, today.

---------------------------

I had hoped that further comment would be unnecessary. However, do
note post #6 in the thread on Bret Johnson's forum at:

<http://bretjohnson.us/forum/viewtopic.php?f=5&t=148&sid=21431a234a9962c79646cb055c8f934c>

That post begins by saying:

> Bad news again. Jack has changed UIDE enough over the last couple
> of weeks that it looks like there is no way to make USBDRIVE
> compatible with it. Even the possibility of loading USBDRIVE
> first and UIDE afterwards is no longer viable.
In fact, I made exactly two changes to UIDE --

In its 10-Jun-2010 release, UIDE now ignores any BIOS drives with a
unit-number of 080h or more (i.e. a HARD disk!) which is flagged as
"removable" by an EDD BIOS "Int 13h AH=048h" request. I have GOOD
reason to believe that the purely HARD-disk logic, that DOS uses to
handle BIOS HARD-disks, never expected a BIOS HARD-disk to CHANGE!!

Since there was the chance USBDRIVE would try to have UIDE handle a
"removable" USB drive using only DOS/UIDE HARD-disk logic, with the
high probability of DATA CORRUPTION as I saw when JAZ/ORB cartridge
drives DID THIS before, such a change to UIDE became NECESSARY!!

Also note in Bret Johnson's BTTR post #8103 the words:

> I stand by my assertion that the UIDE external interface in its
> current state is unusable, and either needs to be fixed or
> eliminated.
So in its 16-Jun-2010 release, UIDE now has NO logic to handle any
"external entry" calls for caching by other drivers.

Not a problem for UIDE users or for other drivers, since none ever
used UIDE for caching. Re: USBDRIVE, I have only this to say --

I was "told" to fix or eliminate UIDE external-entry logic. As I
still believe NO fix is really necessary and only a few "friendly"
E-Mails between those who might use UIDE for caching -- currently,
only HIM and ME!! -- can suffice, I decided to eliminate the logic.

People sometimes GET what their big-mouths ASK FOR!!

If Bret now laments that UIDE can no-longer be used IN ANY WAY for
USBDRIVE caching, he is free to blame ONLY "the man he sees in his
own MIRROR"!!

Note also, in that post on Bret's forum, the words:

> I would think that a DOS-level caching utility (like SMARTDRV)
> would handle removable hard drives OK, or at least better than
> an BIOS-level caching utility (like UIDE). DOS understands
> removable hard drives (DOS is supposed to issue "media change"
> requests to ALL disks at the beginning of each data transfer).
> I've never really experimented with this regarding caching
> utilities, though, so I don't know for sure. If you do some
> experimenting on your own, I would like to know the results.
Thus in other words, he has NO CLUE if a media-change code for a
"removable" HARD disk will in fact work, or NOT!

Thus, I did well to PROTECT my own UIDE from perhaps going "down
the pipes!" and getting blamed for possible DATA CORRUPTION thru
what I considered IMPROPER usage of UIDE's caching by USBDRIVE!!

THAT in fact was the REAL reason for my 16-Jun-2010 UIDE update!

If "He doesn't KNOW!" re: media-change codes, and for USBDRIVE's
using re-entrant Int 13h calls (can overrun the stack!), and for
likely OTHER trouble if I had taken more than 30 minutes looking
through its source, I want UIDE to have ABSOLUTELY NOTHING to do
with USBDRIVE!!

I flatly DO NOT "trust" USBDRIVE, not at ALL!!

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

Post reply
 

Complete thread:

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