I was not able to find any specifications on the filesystem
structure of exFAT; without this info it would not be possible to
implement it.

Also, it is safe to assume that despite the name, it is incompatible
with all previous versions of the FAT filesystem whereas FAT+ is at
least downward compatible with FAT since it only uses six additional
bits in the directory entry.

Cluster sizes of 32 MB are probably not the smartest thing to
implement in DOS, either, given the fact that even much smaller
sizes are notorious for wasting a lot of disk space for short files
and many applications have difficulties even with 64 and 128 KB
clusters.

I think interoperability with other OSes is better served by FAT+;
after all, exFAT will only be supported in the latest versions of
Windows and it is unlikely that anyone will be using those along
with DOS, anyway.

I agree. I don't think that it'll gain wide acceptance either. Why should it? NTFS is superior to it anyway. And Windows CE isn't so small that saving a few hundred kilobytes from the file system support if it supports exFAT instead of NTFS would matter.

Where's the technical specification of this newborn Tyrannosaurus Rex?

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

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

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

That's bad news for me and maybe for Udo too. This means that the Linux people neither try to improve FAT, nor even listen to other people's attempts, but just follow the "ingenious" Microsoft inventions like exFAT. It's even less good news for DOS. Don't think that anybody will bother to port the Linux driver to DOS. (In general, good world news have stopped 20 years ago for me. Since then, all world news have been so awful that it's a miracle how we have managed to stay alive for so long hell time. Aargh!)

There is unofficial specification of exFAT:
http://bbs.intohard.com/viewthread.php?tid=56198&page=1&authorid=173869

I forgot to mention another link and some details:

Description mentioned in the previous post:
http://bbs.intohard.com/viewthread.php?tid=56198&page=1&authorid=173869
it contains basic structures of exFAT, and made in two languages (Chinese original and English translation). My impressions about exFAT: it is rather simular to FAT32, the main differences
1) The structures in MBR are not compatible to FAT12/FAT16/FAT32
2) One copy of FAT
3) Cluster bitmap
4) Changed format of directory entries: built-in LFN mechanism, label, FAT and cluster bitmap are files, full UNICODE support

The main advantages are: files larger than 4Gb, increased maximal number of clusters, faster search of free clusters.

It is still rather simple file system and it may be possible to implement it in DOS.

Discussion about exFAT in Russian; contains some attempts to find out the structure of exFAT by reverse engineering
http://forum.ixbt.com/topic.cgi?id=11:39298

Find more exFAT internals and technical details at:
http://shullich.b l o g s p o t.com/

more at rshullic.word press.com

Taxable money can encompass a lot more than just your annual income.Due to the fact you might be no more time a purchaser of the Unofficial Bank of the IRS, open up an account -- personal savings, dollars sector or certificate of deposit -- at an establishment just where your capital will receive you, not the federal government, interest.For occasion, if you have much more than a single job, if your wife or husband functions, or if you itemize deductions, you might want to closely determine your quantity of allowances to assure that you are generating the suitable judgement.Will you owe uncollected social security and Medicare or Railroad retirement (RRTA) tax on ideas you reported to your employer?The amount of payroll tax that an employer owes is dependent on the jurisdiction, and may perhaps be fastened or proportional to the employee’s income.

http://www.dailystrength.org/people/1546717/journal/3706449

> Microsoft in 2006 specified the new filesystem

And the spec can be found at ???

> which is very similar to normal FAT

Bad design.

> but supports huge disks and files.

Maybe, but this is not exclusive at all.

> It would be much better to support this than FAT+ because it is
> supported by somebody else too and not only EDR-DOS

Why not NTSC then ? :-D The time IMHO has come to finally start deleting fine M$ "technology" from DOS in favor of better one originating from DOS community and not depending from M$ ;-)

exFAT is proprietary, just like NTFS. Given their track record, M$ will never freely publish the specs (see the link).

With M$ pushing it, and hardware vendors buying into it (which they always will -- this is M$, after all) exFAT will need to be supported if you want DOS to work with newer hardware. It is a very bad idea to simply ignore exFAT and hope it goes away or that you will never need to deal with it. It really doesn't matter if FAT+ or some other option is "better" or more compatible.

Also, M$ is specifically directing exFAT at portable storage devices (like those that attach through USB ports), since other options (like NTFS) have way too much unnecessary overhead. M$ itself recommends that you NOT use NTFS on portable devices.

I can see a day coming in the not too distant future when nearly all USB flash drives, cameras, etc. will come formatted natively in exFAT. I can also see a day coming when M$ will not support FAT32, or maybe even FAT16 or FAT12, at all. They've already done things like stopping support of multiple partitions on portable media.

Well, that is the same argument as for NTFS - I don't think DOS
needs either of them.

If Microsoft drops support for FATxx, they will create their own
interoperability nightmare. Not that it matters IMO - Microsoft has
not shown any interest in the PC market for the last ten years, and
they are not likely to change this in the coming decade, either.

I don't think that exFAT is meant to replace FAT32, anyway. With the
increase in cluster size, exFAT is clearly designed for huge static
data files only, unlike FAT32 which was designed to decrease cluster
size to save disk space for small files. Let's see how it fares when
FAT64 is released. ;-)

Only that 64-bit cluster addressing makes no sense with the FAT design. Even with the 28-bit addressing with 32-bit entries (FAT32) the FAT can hold up to 2^28 = 256 bin. mega entries. Such a large FAT would be sized 2^28 * 4 = 1 bin. GB. That's a lot, and I see no reason someone would want such a large FAT. Thanks to the FSINFO structure, cluster allocation and free space calculation would still mostly work in a reasonable time. Don't try defragmentation though.

An actual 32-bit FAT (i.e. 32-bit entries and cluster addressing) would contain up to 2^32 = 4 bin. giga entries and would then take up 2^32 * 4 = 16 bin. GB.

FAT24 with actual 3-byte entries would have been neat, up to 16 bin. mega entries taking up 48 bin. MB. (Of course FAT12-like cross-sector entries would show up again but I don't consider that a serious problem.)

It seems people are often calling exFAT FAT64 now - which is of course even more wrong and misleading than "FAT32" with actual 28-bit cluster addressing.

I don't necessarily think exFAT needs to be implemented natively in any DOS, but should rather be implemented as an IFS/Network driver similar to the way CD's, NTFS, etc. currently are. At least in theory, that would allow any DOS implementation or version to use it.

I do think that hiding your head in the sand and pretending it's _never_ going to be an issue is not very productive for DOS end users, though. I can also understand nobody wanting to address it right now, since it really isn't a problem in today's environment -- but someday soon it will be.

Regarding the licensing/patent stuff, I'm not sure that M$ would even bother coming after anybody in the small DOS community for writing such a driver, especially if it was given away for free. It could even be argued that writing such a driver would actually be helping M$ rather than hurting them.

> I don't necessarily think exFAT needs to be implemented natively in any DOS, but should rather be implemented as an IFS/Network driver similar to
> the way CD's, NTFS, etc. currently are. At least in theory, that would allow any DOS implementation or version to use it.

Okay, that is a different story. Implementing it in the kernel would
probably bog it down, but if someone creates an external driver
similar to the one for NTFS, everyone would be free to use it if he
needs it.

Right now, however, I regard an exFAT driver as just about as
essential as an ext2fs driver. I would rather prefer something like
LTOOLS for copying files to/from exFAT drives.

Regarding FAT64, I think we are still several years away from
reaching the capacity limit of FAT32. The next challenge will
probably be to overcome the 2 TB barrier, which will require careful
design to maintain compatibility. I think I will leave that task for
v7.01.09. :-)

There is already more info about exFAT available.
The Linux alfa sources moved to there:
[url]http://www.munted.org.uk/programming/exfat.tar.bz2[/url]

But I have also found an analysis or description here:
[url]http://www.sans.org/reading_room/whitepapers/forensics/rss/reverse_engineering_the_microsoft_exfat_file_system_33274[/url]

I agree with Bret - sooner or later will the support of exFAT be necessary.
ExFAT is aimed to flash drives. It is cool that Bret's drivers support not only INT21h functions like Georg's drivers but also INT13h so the support is possible.

In the first phase is even the driver not needed.
It will be enough, as a first step, just to add function inro some file commander (like Necromancer's DOS navigator or DOSzip commander) for mounting such drives.

I think, that the external driver will be a reasonable thing: exFAT file system has no short file name support and keeps names of files in UNICODE. Design of directory entries significantly differs from FAT16 and FAT32, and moreover, exFAT doesn't use FAT chains for not fragmented files, so it may be reasonable to not modify the DOS kernel. But the design strongly resembles FAT12/16/32.

P.S. Now I'm trying to implement cross-platform utility for reading files from exFAT partitions.

Do you mean NTFS?
NTSC, named for the National Television System Committee, is the analog television system used in most of North America, South America, Japan, South Korea, Taiwan, Burma, and some Pacific island nations and territories.