Op 29-1-2012 17:52, Jack schreef:

> What UIDE will NOT permit is handling any BIOS units flagged as being
> "removeable"!!   One CANNOT be certain all DOS variants will handle a
> "media change" (new disk) within their Int 13h coding, which was done
> at a time when Int 13h hard-disks really were "HARD"!   As I will NOT
> have UIDE get "blamed" for an older DOS system failing to "flush" its
> disk buffers on media-changes, UIDE will NOT handle "removeable" hard
> disk drives!   That includes USB types!

It's a good protection method indeed. I don't think anyone actually 
removes USB storage disks in DOS, sounds way too suicidal with regard to 
bootsector/MBR and data contents on the device itself.

I've used MEMDISK's disk-hiding capacibilities, but still not dare 
remove the USB drive (suppose you boot from a flash device in USB1.1 
controller, then load ramdisk, then pause, put flash device in a faster 
non-bootable USB3 port, then continue from pausing, then load USB driver 
to load rest of the USB flash device in a faster way than 150KB/s)


> 1) ASPI is too complex.  Whatever happened to a SIMPLE interface that
>      provides read/write and perhaps format commands only??   All other
>      functions are rarely used by disks and should be diagnostic-only.

Ah yeah, diagnostic software. I never use those I'm afraid, easier to 
start over. I've got no idea how complex ASPI really is, but the API 
seemed doable, it's just that each and every piece of hardware had its 
own specific drivers instead of generic ones.

> 2) ASPI is mainly for SCSI drives, which are expensive, same as their
>      $200+ controller cards.   You get IDE for nothing, last I heard.

IDE is usually onboard indeed, except if going for some add-on card, be 
it a non-raid or raid card. Due to BIOS/DOS, it's often not needed to 
load drivers for the interface and disks, only for CD drives. Your UIDE 
driver does load for interface, not for disks ( I mean partition 
recognition here instead kernel doesn't do it) and at same time also for 
optical drives. It combines [1] and [3] out of the list I made in an 
earlier mail.
I don't think currently any driver exists for IDE harddisk partition 
enumeration as all DOS kernels do that by default at boot-time.

>
> 3) In 1998, I came back to California to take a job at Adaptec, after
>      4 years in Utah, only to find that the man who would have been "my
>      boss" hadn't cleared my paperwork before offering me the job, i.e.
>      I had NO job!!   Absolutely UNETHICAL, and INEXCUSABLE, and I have
>      had nothing to say for that man, nor for Adaptec, from then on!

You mentioned that in years before indeed, I'd consider it a decent 
private reason to never look back at such stuff.

> If the idea of doing drivers for USB is still "open", why NOT write a
> simple Int 13h driver that handles disk reads/writes only, instead of
> "obeying" the full SCSI/ASPI set of rules simply because they ARE the
> so-called "rules"??

Georg created a slightly simplified version of a full implementation. 
The problem with these kinds of things is things can become very 
complicated if doing technical stuff. For example an USB stick connected 
to an USB hub inside a USB keyboard, connected to front USB ports (USB 
hub thus) connected to motherboard port (USB hub) connected to USB 
controller.

Any single USB-stack driver-loading seems to completely override BIOS 
USB emulation on a per-controller or complete basis. Keyboard emulation 
no longer working due to loading an USB storage driver is painful.

> In 1980, an associate of mine "took one look" at a 750K video package
> [done in "C" of course!], and he noted "They've got GUTS calling THAT
> a 'driver'"!!   I have precisely the same feelings about a lot of the
> software for using USB, thus far.

It's not getting easier indeed. I'm noticing the same in the stuff I 
have to implement on the FreeDOS distribution. Boot from an USB 
CD-drive, load DOS USB-storage driver and you're suddenly working from a 
non-accessible drive. Same for a bootdisk in USB floppy drive.

> Something simpler/Better/SMALLER for USB disks and CDs/DVDs really is
> NECESSARY, people!   Until we get it, I plan to avoid all USB devices
> like the PLAGUE!

Let's see what Bret comes up with, I'd be interesting in playing with 
OHCI (as my machine has) instead of UHCI
(unless buying something like a VIA/Intel based controller, as is
[ 
http://eu.startech.com/Cards-Adapters/USB-2/Card/7-Port-PCI-Express-Low-Profile-High-Speed-USB-20-Adapter-Card~PEXUSB7LP
 
] )

If your machine still fits your purposes, by all means stick to it :)

Bernd

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to