Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

DOS specifications ("standards") (Developers)

posted by awik, 21.11.2020, 16:43

> > 3. MBR amendments to support blocks (sectors) above 4G
>
> GPT is right there. I don't think extending the MBR scheme is going to be
> supported by many implementations.
GPT is baroque -- even its name points this out ("GUID" partition table).

What I had in mind would be almost trivial to implement, and with open source systems, I might even be able to do it myself.

I have two schemes in mind:

(a) add a new signature and/or checksum to the existing MBR format. Perhaps the CHS fields could be used to store the extended LBA fields. Alternatively, some additional space could be reserved.

(b) again, add a signature and/or checksum. Simply use additional sectors/blocks for the extensions. Even with existing disks, there is usually plenty of space before the start of the first partition.

> (For a hack, we could try to support "33 bit LBA" schemes, ie the 32-bit
> fields for start and length are kept, but it is valid for start and length
> to *both* be up to FFFF_FFFFh, so (with 512 B/s) a 2 TiB - 512 B FAT32
> partition may start at sector FFFF_FFFFh. That is, allowing to use nearly 4
> TiB of hard disk space. I'm considering adding that to my early loader
> (iniload), debugger, and kernel. Most difficult would be the boot sector
> loaders due to space being at a premium there.)
That is a reasonable stopgap solution. In fact, it might even be supported already by some systems, depending on whether they truncate the LBA numbers to 32 bits.

> > 4. large file support (llseek, etc.)
>
> > Where it makes sense, existing specifications should be amended, but
> some
> > things may be better to redo from scratch.
>
> There's
> FAT+
> for FAT32 (and big-cluster FAT16) to store files up to 256 GiB - 1 B in
> size. (Up from the prior limit of either (commonly) 2 GiB - 1 B or (if
> using unsigned values) 4 GiB - 1 B). EDR-DOS is the only implementation of
> this yet.
Thanks, that is an interesting alternative. It does seem a bit too much like a hack.

My current idea is inspired by the old Linux UMSDOS. Basically, a specially named (eg. "FAT$EXT$.FS$"; could reasonably be marked as System and Hidden) and formatted (could even be human readable) file to store the additional data. It could exist in every directory where it is needed, or it could be stored in a single file, perhaps in the root directory. This file could also be used as a means to store other additional file properties such as long filenames or crypto-related stuff). In this scheme, large files would be stored as multiple regular files, each up to 2 or 4 GB in length.

For systems that don't support the scheme, command line utilities could be provided to access and manipulate the data file. The large files themselves could be accessed one chunk at a time using existing software.

A TSR could be written to add support for the scheme to existing systems. Alternatively, it could be supported directly through DJGPP and/or DOS extenders.

> And here's
> a
> description of EDR-DOS's llseek function 7142h. This interface, and
> corresponding seek offset and size field extensions in the SFTs, allows
> using 64-bit seeks.
Excellent.

-Albert.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 167 users online (0 registered, 167 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum