Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

"That Will Be ALL!" For UIDE and USB! (Announce)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 15.06.2010, 22:47

Unfortunately, since Jack has decided to air our "dirty laundry" publicly on this Forum, I feel forced to make an appropriate response. I normally do not use this Forum, and came across this discussion quite by accident.

Jack and I were approached by Laaca, requesting that we attempt to make UIDE & USBDRIVE compatible with one another. 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 by Jack. Jack did offer up some suggestions to "automate" the process as well, none of which would completely alleviate the compatibility problems.

After this, I told Jack that I would like to support UIDE, even if the process is not "automatic", by supporting the external protocol option (/E) of UIDE in the next version of USBDRIVE. 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). One of the input parameters required when calling the external interface is a "Cache Unit Number". 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):

******************************

> I do not, and 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.

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.

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. After a few days with no further response from Jack, I posted a follow-up message in my Forum to Laaca summarizing what had transpired between myself and Jack.

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.

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.

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