On: Fri, 3 Jan 2014 01:45:46 GMT "Bret Johnson" <[email protected]> wrote : >> No such change is needed, large sectors work 'out of the box'. >With all manufacturers and versions of DOS, or just with MS-DOS 7+? Definitely /not just/ MS- DOS 7. Microsoft's DOS kernels were coded to cope with block device sector sizes from 32 to 32,768 bytes, although aberrant sizes probably weren't tested in depth. There may be bugs and corner cases, depending on DOS versions. Some MS documents would state 8,192 bytes for maximum sector size. Perso, I verified support for 4K sectors on MSDOS 5/6/7/8 and even on an obscenely obsolete DOS 3.21, OEM version !
Supported /in the kernel/ does not mean that the /utilities/ (format, etc) work well or at all, whether MS or 3rd party ! >> The (ugly, imo) kernel mod [....] > I totally agree it's ugly, and I wish I knew of another way, > but is the only thing that actually works reliably. It may work "reliably" for you and me, plus a handful of readers of this list, but requiring of your general user, even a moderately geeky type, to go patch IO.SYS is not the most reliable process I can dream of. Not to mention technical difficulties, s.a. the /compressed/ IO.SYS of MS-DOS 8.0, the MS-DOS version people will get from a DOS boot-disk made in Windows XP+. >Even creating an installable device driver with large > sectors only works with MS-DOS 7+; MS-DOS 6 and below > require the kernel patch. This is surprising, you should retry, you may have been mistaken somehow IMHO. . > I've never tried, but PC-DOS may also work with the patch Probably does, because of the common codebase, and presumably also /without/ patching (for CONFIG.SYS device=) >> Aren't you mixing apples with oranges ? ASPI and "int 13" aren't at >> the same protocol level or "layer". > Actually, they are: they both provide the low-level > (sector-level) access to the disk. ASPI is not the level doing disk access, it is a wrapper for DOS around the SCSI protocol. I reiterate : ASPI is no substitute for disk BIOS (int 13h) functions, not the same level. > If you have one you don't need the other -- one doesn't "ride on top" of the > other. If they were different layers, you would > require both of them at the same time. I think I see where the confusion arises, you are having your int 13/AH=51h extension in mind from your USBDRIVE, which indeed roughly corresponds to ASPI over USB. It's NOT 'int 13' thus, it's YOUR EXTENSION overloaded upon int 13, that is roughly at the same protocol level as ASPI. > [...] If you have an > INT 13h interface, though, there's no good reason I can > think of to provide an ASPI interface (which is why I didn't > do it in my driver). Or vice versa... > The reverse is not true, IMO. Why ? > The reason I say is because all of the DOS utilities and > drivers that need low-level access to the disk > (partitioning, formatting, defragging, caching in some > cases, etc.) use INT 13h, not ASPI. Right, disk maintenance utilities will use int 13h. Now we may solve this by implementing int 13 over ASPI, as you conceded above; or MEANWHILE adopt my (lazy) point of view : that any formatting, and if necessary, maintenance, be done under another OS, e;g., under Linux or Windows XP . Cheers... -- Czerno ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
