DOS ain't dead

> If, say, a DOS EXE > 4GB is seen as multiple files, how would it be
> executed in Windows?

an error is reported, sort of "invalid .EXE", of course. Not a problem at all.

> Might it be best to accept a max. size of (4G-1) bytes as the price of
> being able to use files in multiple OSes?

No. Even without FAT32+ DOS is missing an API to position at file offsets > 4 GB. With NTFS4DOS, the Paragon drivers or similar things such large files are accessible for DOS apps. So the "API extension" part of FAT32+ is important, even if FAT32+ itself might be crappy.

btw: IMO it might be a good idea to redesign even the API part of FAT32+, since the API extension has been placed into DOS' LFN function group (int 21h, ax=7142h), where it doesn't belong at all. A better place possibly would have been the FAT32 extensions (int 21h, ax=73xxh). And in the FAT32+ concept, the API needs a pointer to a 64bit value, which makes such a call unnecessary complicated for DOS extended programs. A simple int 21h call with the offset hold in registers (SI:DI:DX:CX? or maybe just DI:DX:CX?) would have been preferable.

---
MS-DOS forever!

> I've already reached 1 TB in my PC. In another
> year, we'll be at 2 TB and the file system will have reached its limit.
> It doesn't handle corruption well at all. Etc.

That's the problem FAT+ suposed to solve. Yes it is a hack and it is FAT with all its weaknesses, but that is what we've got. It was simple to implement. Whole new file system would be much more difficult to do. So unless you are gona do it, we are stuck with FAT.

About backward compatibility: if FAT+ is so uncompatible, all it takes is to give it a new partition ID number.

> So --- we're already adding support for a new filesystem. Why not do it
> right?

Who is "we"? Who adds support for a new file system in DOS? I'm not aware of such efforts. There's no risk (or chance) that FreeDOS will get anything in this direction in the foreseeable future. It doesn't even have a FAT32 capable CHKDSK!

There is a FAT32+ implementation in EDR-DOS WIP versions AFAIK. That's good, it's a nice toy for DOS fanatics or those who know exactly what they are doing. What I don't want is this toy being advertised as a safe DOS extension, intended for all DOS users.

---
MS-DOS forever!

> 1. The "massive data losses" on FAT+ >=4 GiB files in Windoze doesn't occur
> at all. Actually they seem to be excellently protected ... neither
> opening nor kick out is possible, and without being even able to open such
> a file you can't brew an incomplete / truncated copy. Also the XP's
> scandisk [...]

There's no program called scandisk in Windows XP. chkdsk (started from command line) however seems to work fine on both NTFS and FAT partitions.

> This is almost an non-issue
> however, compared to installing MS-DOS on a HD with [...]

I'm really not interested in what the old MS-DOS installation program does.

> 2. SEEKERR exposes still buggy handling of FAT+ in EDR-DOS ... this
> might make Udo desperate or does it even make some
> enemies of him happy ?

The tests performed by SEEKERR are insufficient. It should return C=0, C=1 or C=U (unchanged). (Of course it requires two DOS calls to determine if the CF is unchanged.)

This EDR-DOS bug doesn't relate to FAT+ at all. FAT+ is the filesystem part, 21.7142 is an interface (which could be used for non-FAT+ filesystems as well).

> 3. SEEKBACK is a very interesting test showing that seeks back are
> unusably slow on FAT filesystem: 5 to 10 times slower with caching HD and
> 15 to 20 times slower with a non-caching HD. The reason for the
> effect isn't unknown, it's the poor FAT "design". BTW, I of course
> didn't use Jack's 12-Jan-09
> UIDE [...]

How could you? It's embargoed.

> And finally, inside NTVDM, the performance is pretended to be
> much faster, [...]

How do they "pretend" it's much faster? Either it is or it isn't faster. Pretending something implies that it isn't true.

> This
> shows that Windoze caches the complete FAT area used by a file just at
> occasion of opening (and explains why FAT+ files are protected that
> well), as well as any data being read from a file - this costs only 2 +
> 1.6 MiB of RAM. This "design" fault of course is fixed in my coming DOS
> filesystem.

Caching the whole FAT is no design fault, it's how the FAT filesystem was designed (back when the FAT was always small enough that MS-DOS 1.x could hold it in real-mode memory). The design fault is that the FAT later grew so large. (And that MS-DOS supported more than two FAT drives...)

> 4. Japheth wrote:
>
> > If there is "something" to come "in a few years", it might not interest
> everyone
>
> sol wrote:
>
> > Add a filesystem that took longer than 10 minutes to design.
>
> But this time sol trashed your rant that well that I can't add any
> arguments anymore.

You could add a filesystem that takes between 11 minutes and 1 year to design. It isn't funny anymore.

> > All of their shit is patented.
> > You might as well stop using Fat12, Fat16 and Fat32.
>
> COOL. But FAT12 and FAT16 patents are definitely expired, if ever existed.

Read Wikipedia on FAT licensing. The patents covered LFN/SFN systems, so if the apply at all they apply for FAT32 and FAT12/FAT16. Well, I don't really care anyway.

> Also, FAT sucks anyway, see above, it was "designed" in a time when neither
> subdirectories nor seeking were needed, and the stuff got just hacked onto
> it, so, YES, stopping using it is a good idea.

Seeking was needed and intended, and it's quite fast when the complete FAT is in memory (as for NTVDM and MS-DOS 1.x). Subdirectories were not intended but their hack is a rather good one. (And with the latest FAT revision the root directory was also moved from it's special location into the normal data area.)

> > How did this dumb thread come back?
>
> I don't know.

You're reviving it regularly.

---
l

> Also the XP's> scandisk seems to support NTSC only so it's impossible to ...

This is nonsense. If you're about to implement your fantastic new file system as thoroughly as you did your tests in WinXP then it will become the "killer" application for DOS which we're all desperately waiting for.

---
MS-DOS forever!

http://support.microsoft.com/kb/955704

Article ID: 955704 - Last Review: January 27, 2009 - Revision: 1.0

Description of the exFAT file system driver update package


This article discusses the key features and benefits of the extended File Allocation Table (exFAT) file system driver for Windows XP. In response to OEM feedback and to Independent Software Vendor (ISV) feedback, Microsoft released the exFAT file system driver for Windows XP on January 27, 2009.

The exFAT file system is the successor to FAT32 in the FAT family of file systems. The exFAT file system is a new file system format that addresses the growing needs of mobile personal storage on different operating systems. The exFAT file system handles large files, such as those that are used for media storage, and it enables seamless interoperability between desktop computers and devices, such as portable media devices. Because of this functionality, you can easily copy files between the desktop and external devices or between the desktop and other operating systems.

After you download the file that is described in the "More Information" section, you will be able to format external media in the exFAT format. Additionally, you will be able to format external media that is larger than 32 GB, and exFAT-formatted media will be recognized on the computer. More improvements of the exFAT file system are described in the "More Information" section.



The exFAT file system incorporates several improvements over FAT32. However, it keeps the simplicity of FAT-based file systems. These improvements include the following key advances:

    * Support for very large files and storage devices
    * Support for performance improvements
    * Support for extensibility features for future innovation
    * Added compatibility for flash media

The exFAT file system driver brings file system support parity to the following operating systems:

    * Windows Vista
    * Windows XP
    * Windows CE

The exFAT file system driver incorporates advanced structures for future scalability. The exFAT file system uses 64 bits to describe file size. This allows for applications that depend on very large files. The exFAT file system also allows for clusters as large as 32MB, effectively enabling very large storage devices. Specifically, exFAT adds the following features:

    * Support for volumes that are larger than 32 GB, the theoretical maximum volume size for FAT32 in Windows XP
          o The theoretical maximum volume size is 64 ZB.
          o The recommended maximum volume size is 512 TB.
    * Support for files that are larger than 4 GB, the theoretical maximum file size for FAT32 in Windows XP
          o The theoretical maximum file size is 64 ZB.
          o The recommended maximum file size is 512 TB.

The exFAT file system driver incorporates the following advanced structures to improve performance:

    * A cluster bitmap for fast allocation
    * A per-file contiguous bit for fast file access
    * Better contiguous on-disk layout (useful for recording movies)
    * Support for Universal Coordinated Time (UTC) time stamps

The exFAT file system driver is designed for extensibility to enable the file system to keep pace with innovations in storage and changes in usage and to enable OEMs and ISVs to add extensions seamlessly. Specifically, exFAT adds the following features:

    * Adds template-based metadata structures to enable custom extensions
    * Enables implementations to persist these extensions without having to know their format

The exFAT file system driver adds increased compatibility with flash media. This includes the following capabilities:

    * Alignment of file system metadata on optimal write boundaries of the device
    * Alignment of the cluster heap on optimal write boundaries of the device