Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FAT+/FAT/patents (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 24.01.2009, 13:59

> 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 :lol: 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

Post reply
 

Complete thread:

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