Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

No "Removable" HARD Disks Supported By UIDE! (Announce)

posted by Jack E-mail, Fresno, California USA, 08.06.2010, 23:57

Re: my ongoing "issues" about UIDE used with USBDRIVE, there is another huge
problem --

Bret Johnson has noted on his forum that he plans a "workaround" for what he
sees as UIDE's problems, in which USBDRIVE will load first, and UIDE will be
loaded afterward by Eric Auer's DEVLOAD or equivalent. UIDE can then "see"
every USB device I-O request and cache them using its "call the BIOS" logic.
"The BIOS" in this case will be USBDRIVE, which will "intercept" and perform
needed I-O, then UIDE will cache the data (if needed) on exit from USBDRIVE.

The problem: USBDRIVE declares all of its drives as "removable" HARD disks,
when an EDD BIOS "Int 13h AH=048h" call is issued!

DOS is an "old" system, designed when a hard-disk really was HARD, and never
"removable"! If a supposed hard-disk were to return a "media change" code,
as diskette drives do when a new one is inserted, I DARE NOT "trust", across
all DOS kernels, that their internal disk buffers (CONFIG.SYS "BUFFERS=" and
"BUFFERSHIGH=") are going to get re-input! There was never any requirement
for HARD disks in a DOS system to cause this, nor even to present any "media
change" codes to the system!

In the past I have owned Iomega JAZ and Castlewood ORB cartridge disks, both
good ideas, but each failed after only 6 months which was "not good"! When
used with V6.22 MS-DOS, in fact I did notice that the only "reliable" way to
make DOS "forget" all data for an unloaded cartridge was to REBOOT!!

Nor are "media changes" a responsibility for UIDE, either. UIDE is not the
"driver" here -- USBDRIVE is!! UIDE merely provides a "caching service" to
USBDRIVE, no-matter which of the two may or may-not load first! So, it is
a responsibility for USBDRIVE to "tell UIDE" when its cache must be flushed,
which UIDE's "external reset" entry-point does permit.

If all USBDRIVE does is to issue Int 13h I-O commands, but NOT "notify" UIDE
that a media-change requires a cache-flush, then "data corruption" far worse
than Bret Johnson ever imagined WILL occur, using his "workaround"!

And "Puh-LEEZE" do NOT ask me to add such media-change logic -- UIDE's SATA/
IDE routines run HARD disks, NOT funny-bunny REMOVABLE "hard" disks, same as
most DOS kernels still expect! I have no wish to "clutter up" UIDE's HARD
disk logic, nor give-up any of its performance, for "removability" BULLSH*T!

To protect against these problems, and the even more-unresolvable one of DOS
flushing its internal hard-disk "buffers", I have decided to change the UIDE
driver so it will NOT "handle" any BIOS unit of 080h or greater (hard disks)
that are flagged "removable" by an "Int 13h AH=048h" call! Any such units
will now be ignored by UIDE's initialization logic, and I-O for them will be
totally "passed" to the next driver in the Int 13h "chain", i.e. NOT cached!

I WILL NOT permit UIDE to get blamed for DOS or other-driver design FAULTS!!

My Thanks to Khusraw for testing the new driver (he has USB units, I do not)
and it will shortly become the "standard" UIDE.

If USBDRIVE desires to call UIDE for caching, using its "external entry" and
"external reset" call points as intended, "fine and dandy", and USBDRIVE can
deal with "removability" issues any way it desires, as it is the only driver
which SHOULD deal with them! But henceforth, UIDE shall support only FIXED
hard-disks in its SATA and IDE disk routines!

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

Post reply
 

Complete thread:

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