Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Further Comments ... (Announce)

posted by Jack E-mail, Fresno, California USA, 16.06.2010, 01:35
(edited by Jack on 16.06.2010, 04:30)

> ... Jack and I exchanged several e-mails, where I suggested things such
> as making UIDE a TSR (thereby making it removable and installable after
> USBDRIVE without the aid of external programs such as DEVLOAD), adding
> support for AMIS (Alternative Multiplext Interrupt Specification,) or at
> least supporting IISP (IBM Interrupt Sharing Protocol) to allow
> "automated" support for external programs such as USBDRIVE that are
> installed after UIDE. These suggestions were summarily rejected ...
Because I felt they were not necessary, and I in fact SAID SO! That is
NOT a "summary rejection", that is me using my BRAIN to avoid unrequired
GARBAGE, which has never-before been needed in UIDE or in other drivers!
UIDE's external-interface logic can handle calls by USBDRIVE without all
the above suggested changes.

> ... I started to investigate the external option, asking Jack some
> specific questions about exactly how it worked (the formal documentation
> regarding the interface is, to put it politely, sparse).
Because no one, before now, had ever voiced any interest in having UIDE do
caching for another driver's I-O. Few people still do any device-drivers
for DOS, thus "formal" documentation of UIDE's external-interface routines
simply did not seem necessary.

> ... I asked Jack how the Cache Unit Numbers were determined and managed.
> This is his response back to me, and my response back to him (verbatim):
>
> ******************************
>
>> ... The subject of who gets what cache unit-numbers is one I left to
>> users, so they can determine their own "schemes". UIDE only has a
>> "hold" on cache units up to 55 (37h), which are for its own BIOS
>> units and up to 8 CD/DVD drives. Other cache units are "up to you"
>> to specify and manage.
>
> This is a very dangerous road your going down -- this almost guarantees
> data corruption and crashes. The Cache Unit Number is essentially a
> Handle, and it is NEVER a good idea to make a program generate its own
> Handles. If only one external program ever used UIDE, you could get away
> with something like that. With the possibility of more than one (e.g.,
> separate USBDRIVE and USBCDROM programs), that is, frankly, ludicrous. It
> would be possible, I suppose, to develop some sort of external protocol to
> manage the Handle numbers, but that is something UIDE should manage all by
> itself. At a minimum, you need some form of "Get Handle" and "Release
> Handle" calls.
>
> ******************************
>
> Jack's (paraphrased) response to this was that he was personally insulted,
> and never wanted to hear from me again.
In fact, what I actually replied is as follows --

> UIDE provides only the needed cache handling and entry-points for
> such handling. With so little interest in its capabilities till
> now, there was NO reason for me to define more, certainly NOT any
> need for me to manage nor "dictate" cache unit-number values, and
> so I had reasons -- I SAY AGAIN, REASONS!! -- for staying silent.
 >
> You are free to write a "top-level arbiter" for UIDE cache-units.
 >
> Also, I was taught the word "ludicrous" denotes RIDICULOUS to the
> point of being LAUGHABLE.
 >
> You and I will now PART COMPANY. Send me NO MORE such insulting
> damned E-Mails, and expect no more comment or assistance from me!
Do any of the rest of YOU enjoy being labelled LUDICROUS??!! Since
I did not, that in my mind was the END of our E-Mails!!

> I am still willing to make the next version of USBDRIVE compatible with
> the external option of UIDE, but will only do this if Jack fixes the
> external interface so that it manages and provides its internally-used
> Cache Unit (Handle) numbers to external programs. Jack's proposed
> solution of requiring programmers who want to use the external interface
> to (paraphrasing) "negotiate handle numbers amongst themselves via e-mail"
> is simply unacceptable.
As noted above: You are free to write a "top-level arbiter" for UIDE
cache-units. Personally, I still feel that only a few "Friendly" E-Mails
between those driver-writers who must manage cache-unit numbers (currently
only 2 people I know of!!) is acceptable.

> I did send a final follow up e-mail to Jack, in which I apologized and
> suggested that he either fix the external interface or eliminate it
> altogether. I suspect that Jack may have deleted that e-mail without ever
> reading it.
I read it and did not feel it was worth any response.

> I stand by my assertion that the UIDE external interface in its current
> state is unusable, and either needs to be fixed or eliminated. If it is
> fixed, I intend to support it in the next version of USBDRIVE. I also
> stand by my assertion that I did not intend the e-mail as a personal
> insult, and am very sorry that Jack feels that was what I was trying to
> do.
Fine words, AFTER what went before. My Father once taught me there are
not 10 Commandments but 11, the last being "Thou shalt not get CAUGHT!!"

Also note that unless the /E switch is specified when loading UIDE, its
external-entry logic IS eliminated (the pointer to it at driver address
00016h will be zeroed!), and for most users who put most of UIDE in HMA
space, the 48 bytes of related logic are in fact DISCARDED! Given all
that, I also do NOT think it necessary to delete that source code, too!

> P.S. Now that Jack has made changes to UIDE to guarantee that it will
> NEVER automatically work with removable hard drives as required by USBDRIVE
> (or other removable interfaces like Firewire, Bluetooth, PCMCIA, network
> file servers, …), the only way to make UIDE and USBDRIVE compatible is with
> UIDE's (currently broken) external interface. The option of loading
> USBDRIVE first and then installing UIDE with DEVLOAD (or some equivalent)
> afterwards is no longer viable.
The other such drives are ALSO dangerous to use with only HARD DISK logic.
And do NOTE that I said "with only HARD DISK logic", as would get used for
BIOS units numbered 080h and up. That class of logic, and the DOS system
itself, may or may-NOT process a "media change" code for such drives. If
not, as I suspect is true for most DOS systems (if not ALL of them!), data
corruption is GUARANTEED to occur!

I have NO REGRETS re: upgrading UIDE to avoid such cases and so stay SAFE!
I will NOT have UIDE users suffer as I did, in trying to handle JAZ or ORB
"removable" HARD-disk cartridges with DOS! Windows/Unix may handle them,
but DOS is an "older" system that DID NOT handle them properly for me, and
as Gates & Co. have now "walked away" from DOS, it probably STILL does not
handle such units any better with only HARD-disk logic! Those at FreeDOS
can call me "cautious" -- I call it STAYING SAFE!!

If such drives call UIDE using its external-interface logic, and so do NOT
use HARD-disk logic, responsibility for noting a media-change is then ONLY
with the device-driver that issues such calls. It, and not the "regular"
HARD-disk logic in DOS or in UIDE, can deal with a media-change however it
wishes. UIDE thus becomes only an I-O subroutine for the calling driver,
need NOT deal with HARD-disk media-changes, and the calling driver is then
responsible for telling UIDE if-and-when a cache flush is necessary.

That is called "Keeping it SIMPLE!", as I intended for UIDE!

Despite any of the above, I DO NOT consider UIDE's external-entry logic to
be "broken" in any way. It works, every time I test it using UIDE's "old
style" CD/DVD logic that in fact DID call it (UIDE now has faster internal
schemes). If others consider it "broken", they are free NOT to use it at
all, with my absolute BLESSING at this point!!!

---
(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