DOS ain't dead

Hi (and sorry to those who might hate this )

Download now

fatplussi2.png

Tested huge file support and the FAT32+ a bit (see shot)

Results:

FAT32+/GetFileSizeEx support in EDR-DOS works almost, except a silly bug that GetFileSizeEx reports the file 1 byte smaller than it actually is ... regrettably Udo had banned me from his forum so he won't find any report there Reading and writing works. For files < 4 GiB seems to work well with "ordinary" read/write (no hack-flag set needed) and ordinary GetFileSize

FreeDOS: Reading and writing 2...4 GiB seems to work (without hack-flag). GetFileSize doesn't (returns with C flag set)

Features of my proggy:

- Create files of any size 1 byte ... 256 GiB (on FreeDOS only up to 4 GiB so far)
- Measure write performance
- Measure read performance
- Mass production of garbage
- Test huge file support of DOS kernels
- HD / storage media wiping (up to 4 GiB free space on FreeDOS only)

Usage:

FATPLUS command filename [amount]

Commands:

C - Create
G - GetFileSize & GetFileSizeEx
R - Read

"amount" is decimal and ignores possible "'" between numbers "1'1'2" -> "112"

Limitations and bugs:

- Source is ugly, not (yet) open, sent to Tom only so far
- Commandline parsing maybe not 100% safe
- Decimal number handling not safe > 10'000'000'000
- No HEX numbers
- Garbage looks good but might be not 100% crypto-safe

I still like the idea of FAT32+. I define DOS by it's features and not by some silly limitations.

I will no longer answer to previous thread, nor to any destructive post in any thread in any forum by anyone. So please waste your time and make yourself important if you think you must do so.

> Hi (and sorry to those who might hate this )

No problem. I like large, hi-res, slow-loading images.

> Download now

Only one question: Download what?

> Features of my proggy:
>
> - Mass production of garbage

Always nice. Who doesn't need more garbage?

> - Garbage looks good but might be not 100% crypto-safe

Do you have an English version of that?

> I still like the idea of FAT32+. I define DOS by it's features and

*its*.

> not by some silly limitations.

But you have said you consider DOS's single-tasking to be an important feature. To everyone else it's a limitation. I'm confused. Please help. Please.

> I will no longer answer to previous thread, nor to any destructive post in any thread in any forum by anyone. So please waste your time and make yourself important if you think you must do so.

From you, that's hugely funny. Thank you for the entertainment.

Thanks for the test! The most important - and expected - result is that Windows obviously has a problem with files > 4 GB on a FAT32 partition. This virtually "kills" FAT32+. It's a hack. Hacks might be useful when IMPLEMENTING something, but they're NEVER useful when DESIGNING something.

> I will no longer answer to previous thread, nor to any destructive post in any
> thread in any forum by anyone. So please waste your time and make yourself
> important if you think you must do so.

Sorry, but without DESTRUCTION live is impossible. Or, in other words: DESTRUCTION is a GOOD thing done by (not so) GOOD guys:

"Thus all the elements which ye Destruction, Sin, or briefly, Evil, name,
As my peculiar element I claim."

---
MS-DOS forever!

> Thanks for the test! The most important

NO.

> - and expected - result is that Windows obviously
> has a problem with files > 4 GB on a FAT32 partition.

YES. Not surprising, nor a fault of DOS or FAT32+

> This virtually "kills" FAT32+.

NO.

1. You could kill "windows" instead.

2. Bad enough that so many people consider DOS GUI development as no-need/obsolete/impossible because some "Windows" don't like it ... if DOS may develop only as far as "Windows" gives permission this to happen -> R.I.P

> It's a hack.

Maybe true. Not the first and not the last hack in the universe

> Hacks might be useful when IMPLEMENTING something,
> but they're NEVER useful when DESIGNING something.

Please point me to the new hack-free filesystem for DOS you just designed

> Sorry, but without DESTRUCTION live is impossible.

Let's open 3rd world war tomorrow

It this maybe related to King Udo's "not very good" performance as forum administrator in the past ? IMHO one should keep his (crappy) admin performance separated from (good) FAT32+ implemented by him as first. You can try to punish King Udo by hating FAT32+ ... same as Jack tried to punish FreeDOS users for some (what was it at all ???)

Funny enough, King Udo implemented FAT32+, and the only who cares and even defends it is the bad guy previously banned from his forum

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> It this maybe related to King Udo's "not very good" performance as forum
> administrator in the past ? IMHO one should keep his (crappy) admin
> performance separated from (good) FAT32+ implemented by him as first. You
> can try to punish King Udo by hating FAT32+ ... same as Jack tried to
> punish FreeDOS users for some (what was it at all ???)
>
> Funny enough, King Udo implemented FAT32+, and the only who cares and even
> defends it is the bad guy previously banned from his forum

FAT32+ is stupid not because Udo may not be a good admin, it's stupid because:

1) It's a hack; it adds yet another layer of crap onto a poor designed specification.

2) It breaks compatibility. It does. There is nothing worth arguing here. Here are some obvious ways in how it breaks compatibility:

a) It requires storing additional data the FAT32 spec does not mention. this means some disk scanners will cause data loss.

b) It's a private specification, so most OSes out there will not be able to copy the files on/off with this method.

c) Existing DOS programs use counters, and many function calls with 32-bit pointers; file seeking, writes, etc. These will break.

3) There are already other file systems out there that are good, have LFN, and don't have these problems! Implemented one of these!

> It's a hack; it adds yet another layer of crap onto a poor designed specification.

There are much worse "layers of crap"

> It breaks compatibility. It does. There is nothing worth arguing here.

NTSC also broke it. Intentionally. It did. Nothing worth arguing here.

> additional data the FAT32 spec does not mention. this means
> some disk scanners will cause data loss.

NOT true. They can "legally" truncate the > 4 GiB files at most. Anyway, old "disk scanners" will cause data loss to LFN's, FAT32 or NTSC or any other non-FAT partitions as well. So, prohibit anything beyond FAT16

> private specification

Lie. It's open. Unlike NTSC for example.

> so most OSes out there will not be able

Most OS'es can't access Loonix filesytems either ... one more shot into the wrong direction

> Existing DOS programs use counters, and many function calls with 32-bit pointers

True but nonsense argument. Most existing Win32 programs used 32-bit counters (or even worse signed) at the time M$ started to push NTSC as well.

> These will break.

Nothing will break. They will keep the limit of 2 GiB or 4 GiB they used to have before.

> other file systems out there that are good, have LFN, and don't have these problems!

More details please

> Implemented one of these!

Bug ? Past ? Or imperative ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> It this maybe related to King Udo's "not very good" performance as forum
> administrator in the past ? IMHO one should keep his (crappy) admin
> performance separated from (good) FAT32+ implemented by him as first.

If you're unable to see the flaws of the FAT32+ "design" or you think that the inevitable data losses are negligible then there's nothing left for discussion. You're doing DOS no favor at all by propagating a thing which has no chance to become a reliable file system.

> You can try to punish King Udo by hating FAT32+ ... same as Jack tried to
> punish FreeDOS users for some (what was it at all ???)

You've reached lucho's level with this kind of "argumentation". Try to calm down!

---
MS-DOS forever!

> There are much worse "layers of crap"

That's not a good engineering answer.

> NTSC also broke it. Intentionally. It did. Nothing worth arguing here.

How does a US video standard get in here?

> > other file systems out there that are good, have LFN, and don't have
> these problems!
>
> More details please

Have you searched? (What you like to ask, rather than answer questions).

> > Implemented one of these!
>
> Bug ? Past ? Or imperative ?

Have mercy - or expect none for yourself.

> the inevitable data losses are negligible

Maybe negligible -> evitable

> then there's nothing left for discussion.



> propagating a thing which has no chance to become a reliable file system.

Still no better competitors visible around.

> Try to calm down!

Me ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Still no better competitors visible around.

Sorry, but we still don't know exactly how bad the situation with Fat32+ is, which is a prerequisite to make it comparable to whatever. You've begun tests, you're inclined, now please continue:

- what does WinXP chkdsk do? Does it truncate the file without user interaction?
- what tells Windows Explorer if you try to copy such a file?
- what are the Linux low-level disk repair tools thinking about Fat32+?

---
MS-DOS forever!

> - what tells Windows Explorer if you try to copy such a file?

No idea ... it's too crappy by design to be worth exploring on HX.

> - what are the Linux low-level disk repair tools thinking about Fat32+?

No idea ... maybe the same as low-level disk repair tools from MS-DOG 5 were thinking about link LFN's ? (I'm not Eep8088, just in case)

> First get all facts!

The time has come to get out

EOD

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> No idea ... maybe the same as low-level disk repair tools from MS-DOG 5
> were thinking about
> link
> LFN's ? (I'm not Eep8088, just in case)

End your discussion if you want, since you're out of any form of valid argument :)

My wording "private specification" was not very clear, and I apologize. I mean that it's a specification created by one person (or two?) with no "community" support. FreeDOS doesn't support it, MS-DOS, Linux, etc.

As far as ms-dos 5 disk scanners go - who gives a shit? That was MS releasing a new version of its OS along with new versions of the scanners.

This is a new "specification" that breaks FAT32, which *many* operating systems recognise and are capable of scanning. Any could break it.

There are very very few DOS users here that are only using DOS (and say arachne or Lynx) - most people are dual booting. They will have problems.

Windows reads/writes FAT32. Linux reads/writes FAT32. FreeBSD reads/writes FAT32. This is a useful feature. One can share files between OSes this way.

Why not have DOS read/write UFS, FFS, ReiserFS or another Unix FS? This would make DOS more useful and powerful. This would be a lot better than having a shitty new spec that no other OSes support.

> > - what tells Windows Explorer if you try to copy such a file?
>
> No idea ... it's too crappy by design to be worth exploring on HX.

Windows Explorer is a good sample for a "user-level" file manager which would have told if such apps report an error if FAT32 files > 4GB are copied or if they silently truncated such files.

btw, I wrote an open source Explorer clone with the very same design. I mention that to make you aware that you are about to loose credit with your kind of "arguments".

> > - what are the Linux low-level disk repair tools thinking about Fat32+?
>
> No idea ... maybe the same as low-level disk repair tools from MS-DOG 5
> were thinking about

And I bet you don't care either. This indeed makes you the preferred tester for FAT32+ compatibility.

> The time has come to get out

Yes, definitely. To extend DOS on such a sensible field reasonable persons with a mind open for criticism are needed. They also must care about Windows and other OSes.

---
MS-DOS forever!

> Why not have DOS read/write UFS, FFS, ReiserFS or another Unix FS? This
> would make DOS more useful and powerful. This would be a lot better than
> having a shitty new spec that no other OSes support.

Support for external file systems is important, but DOS having a native format for files > 4 GB, based on FAT32 and stable for other OSes is not proven yet to be impossible. In such a concept one file > 4 GB will be seen as multiple files in Windows/Linux, all < 4 GB and all of course "perfectly valid".

---
MS-DOS forever!

> ... DOS having a native
> format for files > 4 GB, based on FAT32 and stable for other OSes is not
> proven yet to be impossible. In such a concept one file > 4 GB will be
> seen as multiple files in Windows/Linux, all < 4 GB and all of course
> "perfectly valid".

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

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?

> 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!

> Support for external file systems is important, but DOS having a native
> format for files > 4 GB, based on FAT32 and stable for other OSes is not
> proven yet to be impossible. In such a concept one file > 4 GB will be
> seen as multiple files in Windows/Linux, all < 4 GB and all of course
> "perfectly valid".

The problem here is that you're calling UFS/FFS/etc "external file systems" while not referring to FAT32+ or a new FAT as such. Since old DOSes, other OSes & old tools will not recognize the file system, or will corrupt it, it's pretty much a new or external file system.

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

Why base it off FAT, which is bad by design?

It's not efficient. It gets fragmented horribly. LFN was hacked in. If we're still using 28 bits of the FAT, iirc we're restricting ourselves to 2 TB for partition size. 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.

> 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!

> There's no risk (or chance) that FreeDOS will get anything in
> this direction in the foreseeable future.

I dunno, depends on who's willing and able (not me, sadly).

> It doesn't even have a FAT32 capable CHKDSK!

dosfsck 2.11.DOS3, 8 Aug 2007, FAT32, LFN

> 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.

As opposed to all the other completely stable and perfectly bugless DOS software? Of course, major bugs should be eliminated, but minor stuff may never be. We're used to that by now. (And as already was mentioned, this "hack" is probably easier to implement than, say, ReiserFS.)

---
Know your limits.h

> As opposed to all the other completely stable and perfectly bugless DOS
> software? Of course, major bugs should be eliminated, but minor stuff may
> never be. We're used to that by now. (And as already was mentioned, this
> "hack" is probably easier to implement than, say, ReiserFS.)

Ahh, good idea, add FAT+ because it's easier than doing it the right way.

That's a good way to write software.

> dosfsck 2.11.DOS3, 8 Aug 2007, FAT32, LFN

Thanks for this hint! Does it work for you in EDR-DOS? It reports "General problems" when I tell it to check a FAT32 disk with 6 GB. No problems with FreeDOS.

> As opposed to all the other completely stable and perfectly bugless DOS
> software? Of course, major bugs should be eliminated, but minor stuff may
> never be. We're used to that by now. (And as already was mentioned, this
> "hack" is probably easier to implement than, say, ReiserFS.)

Thanks for this hint! Your contributions are welcome as always, Rugxulo!

---
MS-DOS forever!

> > dosfsck 2.11.DOS3, 8 Aug 2007, FAT32, LFN
>
> Thanks for this hint! Does it work for you in EDR-DOS? It reports "General
> problems" when I tell it to check a FAT32 disk with 6 GB. No problems with
> FreeDOS.

I haven't tested under EDR-DOS. It may be Eric's DOSFSCK's bug or even a bug in EDR-DOS if it doesn't work for you. (Previously, in a fairly recent old version, it accidentally didn't even work in MS-DOS 6.22 because of a faulty check.)

Please report this issue via e-mail to both Eric Auer and Udo Kuhnt. I don't have lots of FAT32 partitions (mostly FAT16), so I haven't really done any testing on FAT32, just FYI.

---
Know your limits.h

> Why not have DOS read/write UFS, FFS, ReiserFS or another Unix FS? This
> would make DOS more useful and powerful. This would be a lot better than
> having a shitty new spec that no other OSes support.

What about HPFS? At least OS/2 used it, Linux can read/write it, and FreeBSD can at least read it.

Heck, even DOS can supposedly read it (Veit K.'s newer IHPFS or older original, GPL). There's even an old shareware read-only TSR tool called AMOS by (surprise surprise!) Allan Mertner (VPC dude)! Maybe one of those two (or both?) could help FreeDOS? (Or maybe Allan could open source a write-enabled AMOS if he's low on time??) However, AMOS seems to truncate HPFS names to 8.3 equivalents, which I guess is easier than trying to support LFNs in pure DOS.

N.B. I didn't test any of these, just thinking outloud. At least IMHO it's not too horrible an idea (already halfway done, in a way).

EDIT: Forgot link. Also found an old DOS shareware read/write (!) driver (HPFS Access).

Japheth wrote:

> Hacks might be useful when IMPLEMENTING something,
> but they're NEVER useful when DESIGNING something.

Right, but does anything exist that was DESIGNED for DOS within last 10 years or ever ?

> If you're unable to see the flaws of the FAT32+ "design"

Recheck the NTLFN / VFAT "design" 1st

> Windows Explorer is a good sample for a "user-level" file manager

Maybe true, but off topic, unrelated and irrelevant here

> make you aware that you are about to loose credit with your kind of "arguments".

Please finalize your "argument" now: to respect the overall credit preservation law, someone must gain credit this way, but who ? The president of the DOS filesystem enhancement committee, Steve ? Your twin friends Lucho+Iucho ?

> To extend DOS on such a sensible field reasonable persons with a mind
> open for criticism are needed.

Sure. I failed, so what better guys did you get since then ? Steve ? Your twin friends Lucho+Iucho ?

> They also must care about Windows and other OSes.

Sure. Cripple DOS for favor of Windows.

> Support for external file systems is important

... or somewhat useful at least ...

> but DOS having a native format for files > 4 GB

is a must

Steve wrote:

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

Not 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?

For you, YES.

Japheth wrote:

> 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

YES.

> even if FAT32+ itself might be crappy.

Maybe true, still less crappy than VFAT/NTLFN or NTSC4DOS hacks.

> based on FAT32

Why base on silly FAT28 at all ?

> and stable for other OSes is not proven yet to be impossible.

COOL.

> In such a concept one file > 4 GB will be seen as multiple files
> in Windows/Linux, all < 4 GB and all of course "perfectly valid".

Do you intend to delete the VFAT/NTLFN hack then ? Or do you have space for both at same time ?

> 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.

All points right, all points fixed by me (not yet released, thus).

sol wrote:

> So --- we're already adding support for a new filesystem.
> Why not do it right?
> Why base it off FAT, which is bad by design?

Right. So what did you get in the meantime ?

> It's not efficient. It gets fragmented horribly. LFN was hacked in.
> If we're still using 28 bits of the FAT, iirc we're restricting
> ourselves to 2 TB for partition size.

Right. I fixed all those (not yet released, thus).

Japheth wrote:

Who is "we"? Who adds support for a new file system in DOS?

Me.

> 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.

IIRC FreeDOS 1.1 is scheduled for beginning of 2008

> safe DOS extension, intended for all DOS users.

How many people do you see at risk ?

sol wrote:

> Ahh, good idea, add FAT+ because it's easier than doing it the right way.
> That's a good way to write software.

Right. Any examples ? Good and bad ? Let's see how many of yours are good and how many evil.

> What about HPFS? At least OS/2 used it, Linux can read/write it,
> and FreeBSD can at least read it.

No thanks. 20 years old junk, HFFS (Heavy Fragmentation File System), 2 GiB file, 2 TiB volume size limit, many flaws, no features, designed for OS/2 , ... ... Please see the top argument of Japheth !!!

So, DOS filesystem enhancement committee president Steve and vice-presidents Japheth and sol, please report what you got

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

If you believe that you have something of value to supply, do it please! Just troll noise probably isn't regarded as "valuable" by some members ...

---
MS-DOS forever!

> > 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.
>
> IIRC FreeDOS 1.1 is scheduled for beginning of 2008

But no file system work has been done. This is strictly a minor upgrade / maintenance release. (And I think you meant 2009, but even that is highly optimistic.)

> > What about HPFS? At least OS/2 used it, Linux can read/write it,
> > and FreeBSD can at least read it.
>
> No thanks. 20 years old junk, HFFS (Heavy Fragmentation File
> System), 2 GiB file, 2 TiB volume size limit, many flaws, no features,
> designed for OS/2 , ... ... Please see the top argument of
> Japheth !!!

Okay, it's true, in hindsight, I don't think I thought it through enough.

PROs:
a). HPFS already exists and has some partial 3rd-party DOS support
b). supposedly faster with less fragmentation than FAT
c). native LFNs (up to 256 chars)
d). patent is almost expired (Nov. 2009)
e). no worries about full 100% incompatibility with other OSes
f). no need to invent your own (possibly quite tough)

CONs:
a). 2 GB file size max. (although average DOS user doesn't need more)
b). no journaling (so slow disk scan after crash)
c). case sensitive (eh?)
d). creation / access / mod times (which FAT32 has but FD disabled for speed)

So it's no better than FreeDOS' FAT32 support in a. and d. (or c. if you count the hacks, but VFAT is actually patented, sadly). Oh well, just a lame idea I guess. Besides, no response from anyone supporting it.

Anyways, writing / porting a new file system for DOS is a pipe dream. We need to have a poll for what file system would be best: ext2, ext3, ext4, ntfs, hpfs, jfs, other? I guess the real questions are: which is most popular? which is most useful? which is easiest to port? (I would guess ext2, but I really really have no clue, heh.)

> which is easiest to port?

Depends on how you write the driver. Writing a JLM or some sort of DPMI TSR would allow most "modern" file systems (though these with open documentation are easier). Writing Real Mode code would make many file systems at least difficult.

---
l

Japheth wrote:

> If you believe that you have something of value

YES. It's just in a bit early stage.

> Just troll noise probably isn't regarded as "valuable" by some

Good point, although not very new. Last time after you pointed this it was also you who got banned almost immediately, not me.

Rugxulo wrote:

> > IIRC FreeDOS 1.1 is scheduled for beginning of 2008
> But no file system work has been done.
> This is strictly a minor upgrade / maintenance release.

Right.

> And I think you meant 2009, but even that is highly optimistic.

It was indeed 2008

> supposedly faster with less fragmentation than FAT

How big HD's, how much RAM hogged ?

> patent is almost expired (Nov. 2009)

Not sufficient reason to love it

> creation / access / mod times (which FAT32 has but FD disabled for speed)

Thanks God

> Anyways, writing / porting a new file system for DOS is a pipe dream.

OK ...

> We need to have a poll for what file system would be best:
> ext2, ext3, ext4, ntfs, hpfs, jfs, other?
> guess the real questions are: which is most popular?

NTSC (and at same time it sucks most, heh )

> which is most useful?

???

> which is easiest to port?
> guess ext2, but I really really have no clue

Most likely ext2 since oldest, heh

cm wrote:

> Depends on how you write the driver.
> Writing Real Mode code would make many file systems at least difficult.

Most notably slow

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Japheth wrote:
>
> > If you believe that you have something of value
>
> YES. It's just in a bit early stage.

Ok, but then post at least sort of a schedule, so we get an idea what to expect. If there is "something" to come "in a few years", it might not interest everyone .

---
MS-DOS forever!

How did this dumb thread come back?

It's completely stupid to add a third rate hack of a filesystem which will be incorrectly recognized and corrupted by all kinds of other OSes and software.

Add a filesystem that took longer than 10 minutes to design. Implement something that isn't crap - and benefit from the code that already exists. Ext2/3 and UFS have drivers under Windows & Unixes - this "FAT32+" stuff has to be done from scratch and has nothing but drawbacks.

> > Anyways, writing / porting a new file system for DOS is a pipe dream.
>
> OK ...

I didn't mean this as any discouragement or insult, only that few developers are available (if any) who are skilled enough to add this to FreeDOS.

> > which is easiest to port?
> > guess ext2, but I really really have no clue
>
> Most likely ext2 since oldest, heh

It sure is popular in Linux distros, but they'll probably switch to ext4 pretty soon.

> It's completely stupid to add a third rate hack of a filesystem which
> will be incorrectly recognized and corrupted by all kinds of other OSes
> and software.

None of that matters as long as nobody else is writing / porting anything else. Besides, if you only use that particular DOS, there are no incompatibilities!

> Add a filesystem that took longer than 10 minutes to design.
> Implement something that isn't crap - and benefit from the code
> that already exists.

I'm not sure existing *nix/POSIX C code is really directly useful for porting to FreeDOS. It may actually turn out to be easier to roll their own. I mean, it's not like all the *nixes out there agree on sharing a standard file system.

> Ext2/3 and UFS have drivers under Windows & Unixes - this "FAT32+"
> stuff has to be done from scratch and has nothing but drawbacks.

I'm not exactly an advocate of FAT32+ (never tried it), but hey, if it works and nothing else is available, how can we complain?

> Steve wrote:
>
> > If, say, a DOS EXE > 4GB is seen as multiple files,
> > how would it be executed in Windows?
>
> Not at all ?

You don't know for sure?

> > 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?
>
> For you, YES.

Thank you.

> So, DOS filesystem enhancement committee president Steve and
> vice-presidents Japheth and sol, please report what you got

I am not president of the committee. I am not even a member of the committee. I don't know if Japheth and sol are members or vice-presidents of the committee. I don't know if the committee exists. I know nothing (there, I said it - now you don't have to).

Microsoft in 2006 specified the new filesystem which is very similar to normal FAT but supports huge disks and files.
It would be much better to support this than FAT+ because it is supported by somebody else too and not only EDR-DOS

http://en.wikipedia.org/wiki/ExFAT

---
DOS-u-akbar!

> Microsoft in 2006 specified the new filesystem which is very similar to
> normal FAT but supports huge disks and files.
> It would be much better to support this than FAT+ because it is supported
> by somebody else too and not only EDR-DOS
>
> http://en.wikipedia.org/wiki/ExFAT

Do you know any place where I could get more (read: technical) information about it? A brief Google search returned that there doesn't seem to be a Linux driver yet. I agree that FAT+ (like most hacks on top of FAT*) is no optimal solution, but without information neither exFAT is.

* The difference between FAT+ and other hacks like VFAT is that FAT+ isn't yet supported by most drivers.

---
l

> Microsoft in 2006 specified the new filesystem which is very similar to
> normal FAT but supports huge disks and files.
> It would be much better to support this than FAT+ because it is supported
> by somebody else too and not only EDR-DOS
>
> http://en.wikipedia.org/wiki/ExFAT

Almost definitely patented, so not worth anything to us (except heartache).

> Almost definitely patented, so not worth anything to us (except
> heartache).

"The patent office ruled yesterday that patents that cover the File Allocation Table (FAT) file naming system in Windows are valid after completing a re-examination of the patents at the request of both a public interest group and an individual, said Tricia Payer, a spokeswoman for Microsoft's public relations firm, Waggener Edstrom Inc."

All of their shit is patented. You might as well stop using Fat12, Fat16 and Fat32.

> "The patent office ruled yesterday that patents that cover the File
> Allocation Table (FAT) file naming system in Windows are valid after
> completing a re-examination of the patents at the request of both a public
> interest group and an individual, said Tricia Payer, a spokeswoman for
> Microsoft's public relations firm, Waggener Edstrom Inc."
>
> All of their shit is patented. You might as well stop using Fat12, Fat16
> and Fat32.

Not true. FAT12 and FAT12 either were never patented or already expired. FAT32 isn't patented either, only the LFN hack (ironically). And in case you haven't noticed, they have transitioned completely to NTFS with Vista (which cannot boot from FAT as XP could).

> Not true. FAT12 and FAT12 either were never patented or already expired.
> FAT32 isn't patented either, only the LFN hack (ironically). And in case
> you haven't noticed, they have transitioned completely to NTFS with Vista
> (which cannot boot from FAT as XP could).

Actually, the patent covers SFN + LFN co-existing, and covers FAT12 the same as it covers the other FAT systems.

Regardless of what is used to boot Vista, virtually all devices that can be accessed directly in windows are Fatxx; USB flash, SD cards, MP3 players, etc.

FAT is still widely used, and ExFat will likely be used for these devices in the future. It makes sense to continue with it in DOS; support will be added in Linux/BSD, no doubt.

> > Not true. FAT12 and FAT12 either were never patented or already expired.
> > FAT32 isn't patented either, only the LFN hack (ironically). And in
> case
> > you haven't noticed, they have transitioned completely to NTFS with
> Vista
> > (which cannot boot from FAT as XP could).
>
> Actually, the patent covers SFN + LFN co-existing, and covers FAT12 the
> same as it covers the other FAT systems.

Not sure why MS is holding so tightly to such a patent. It's not like LFNs on FAT are a threat to their business. And Linux etc. have had VFAT support for a long time without issues.

> Regardless of what is used to boot Vista, virtually all devices that can
> be accessed directly in windows are Fatxx; USB flash, SD cards, MP3
> players, etc.

FAT is ubiquitous and well-understood, unlike NTFS. And MS does charge like $0.25 or so per storage device that comes with LFN-enabled FAT.

> FAT is still widely used, and ExFat will likely be used for these devices
> in the future. It makes sense to continue with it in DOS; support will be
> added in Linux/BSD, no doubt.

Linux seems less interested in exFAT than BTRFS and ext4 these days. (And still lots of people whining for ZFS.)

It actually makes no sense to continue with it in DOS, especially if it's patented. But we have no FS developers anyways, so it's moot.

> Not sure why MS is holding so tightly to such a patent. It's not like LFNs
> on FAT are a threat to their business. And Linux etc. have had VFAT support
> for a long time without issues.

Because it allows them to charge the fee you mentioned. Everything that decreases profits is a threat to their business.

> Linux seems less interested in exFAT than BTRFS and ext4 these days. (And
> still lots of people whining for ZFS.)

You don't know what you're talking about. Linux would never use exFAT as its primary FS, no, but it will add support for mounting & using exFAT.

> It actually makes no sense to continue with it in DOS, especially if it's
> patented. But we have no FS developers anyways, so it's moot.

I highly doubt there's any difference between adding exFAT support and having FAT32 support.

> > Not sure why MS is holding so tightly to such a patent. It's not like
> LFNs
> > on FAT are a threat to their business. And Linux etc. have had VFAT
> support
> > for a long time without issues.
>
> Because it allows them to charge the fee you mentioned. Everything that
> decreases profits is a threat to their business.

I would rather they patented something entirely new and useful than holding on so strictly to what people are already using and familiar with. But I guess if I had 72,000 mouths to feed too, I'd be a bit clingy also.

> > Linux seems less interested in exFAT than BTRFS and ext4 these days.
> (And
> > still lots of people whining for ZFS.)
>
> You don't know what you're talking about. Linux would never use exFAT as
> its primary FS, no, but it will add support for mounting & using exFAT.

That's not what I meant. And who knows whether they will add it. Maybe patent woes will scare them away.

> > It actually makes no sense to continue with it in DOS, especially if
> it's
> > patented. But we have no FS developers anyways, so it's moot.
>
> I highly doubt there's any difference between adding exFAT support and
> having FAT32 support.

There must be because exFAT supports much bigger file sizes (2^64, aka 16 exbibytes). As the Wikipedia article mentions, exFAT (for example) used 96 KB where NTFS used 47 MB overhead (on a 4 GB flash drive). Quite a difference.

I did some more interesting tests:

http://board.flatassembler.net/topic.php?t=9016
http://board.flatassembler.net/download.php?id=4177

The download contains a Bunch of Tests That Shock (I am aware that a few guys here might hate it again, still, at least, my bunch has no chance to approach the level of evilness provided by the Bunch of Trolls That Ruin )

1. The "massive data losses" on FAT+ >=4 GiB files in Windoze don'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 seems to support NTSC only so it's impossible to "use" it for this purpose. The only way to cause the "badly needed" damage is to copy some other (< 4 GiB) file on same volume and push the RESET button during the action. Then and only then XP launches it's boot-up-only FAT28 scandisk and truncates all FAT+ files. This is almost an non-issue however, compared to installing MS-DOG on a HD with FAT28/NTFS/Raiser partitions, the latter will destroy your MBR, make all your fancy "OS'es" (Windoze 7 Seven, Linu-X64, ...) unbootable and destroy much more data, not only files > 4 GiB.

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

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 nor any other caching addon. Also interesting is, that FreeDOS performs noticeably slower that EDR-DOS, the famous superiority of C compiler-optimized code over manual ASM mess has been proven again And finally, inside NTV- -DM, the performance is pretended to be much better, on 0th run it's much faster than any DOS and same for both directions, on any subsequent attempt both times are ZERO 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

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

5. (oops didn't I promise 4 only ? ) Rugxulo wrote:

> As the Wikipedia article mentions, exFAT (for example) used 96 KB where
> NTFS used 47 MB overhead (on a 4 GB flash drive). Quite a difference

Very complete info ... for what cost ? Also, since there is no EX-FAT spec ...

6. sol wrote:

> Linux would never use exFAT as its primary FS

Maybe a rare case where DOS could learn from the Linux guys ?

> 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. 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

> How did this dumb thread come back?

I don't know.

> Implement something that isn't crap

Examples please.

> and benefit from the code that already exists.

I'm not aware of any usable code.

> drivers under Windows & Unixes - this "FAT32+" stuff has
> to be done from scratch and has nothing but drawbacks.

Oh well.

7. Laaca wrote:

> Microsoft in 2006 specified the new filesystem

Is this relevant for DOS ? And where can I find the spec ?

> http://en.wikipedia.org/wiki/ExFAT

Nothing in

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> 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!

Good news!
The Linux guys work on exFAT support in kernel. Some alfa read-only drivers are already tested.

More info here:
http://www.gossamer-threads.com/lists/linux/kernel/1026144

Download source here:
http://userweb.kernel.org/~hirofumi/exfat/exfat.tar.gz

---
DOS-u-akbar!

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


> http://support.microsoft.com/kb/955704
>
> Article ID: 955704 - Last Review: January 27, 2009 - Revision: 1.0

I made a brief test. Unfortunately, the driver supports the exFAT format for "external" Drives only (removable medias), you cannot format a local HD with exFAT.

---
MS-DOS forever!

> I made a brief test. Unfortunately, the driver supports the exFAT format
> for "external" Drives only (removable medias), you cannot format a local
> HD with exFAT.

Which driver? The Windows one or the alfa(beta) from Linux ?

If I have on mind the from Windows, it is not suprise because it lacks the user rights managment. So Microsoft will not enable to format hard drives to exFAT because he tries to focus on user rights, safety, etc.
But it is not a technical limitation but the "company politics".

BTW:
If I could decide whether in the FreeDOS kernel should be implemented the support of exFAT or NTFS I would choose exFAT due its simplicity, no advanced user rights ans smaller memory footprint.

---
DOS-u-akbar!

> BTW:
> If I could decide whether in the FreeDOS kernel should be implemented the
> support of exFAT or NTFS I would choose exFAT due its simplicity, no
> advanced user rights ans smaller memory footprint.

Are there any plans or is anyone working on ExFAT support for FreeDOS, or any other plain DOS for that manner?

Also, are you saying that ExFAT in XPSP2 can ONLY be used on External media, NOT on internal drives AT ALL? It does seem like a completely artificial limitation.

Maybe Partition Magic and / or Acronis Disk manager for raw DOS does support formatting ExFAT partitions on internal hard drives, and directly from DOS? Can anyone confirm this as true?

> Also, are you saying that ExFAT in XPSP2 can ONLY be used on External
> media, NOT on internal drives AT ALL? It does seem like a completely
> artificial limitation.

It's not strictly artificial. The bootloader would need to be modified to support booting from it. Considering this is not the kind of FS Windows wants to boot on --- they're not about to spend the time to add this option.