DOS ain't dead

What is the feasibility of adding exFAT support to FreeDOS?

> What is the feasibility of adding
> exFAT support to FreeDOS?

Not good, esp. because

1). there are very few kernel developers active (jeremy? bart?)
2). even then, they'd need decent expertise and testing, which has often been lacking, which is why even the FAT32 support only handles max. 2 GB for a single file
3). most importantly, due to same lame reasons as VFAT (LFN), it's patented, which is pretty much a killer against implementing it

But there was some third-party hack, that sorta kinda worked (though I didn't test it), that somebody posted here a while back. You could search for it.

The real question is why you would want it. Obvious answers would be better speed, native LFN support, or bigger files. At one time I thought HPFS (popular on OS/2) would be a fairly decent choice (and finally patent expired), but ext2 is more popular and common (and LTOOLS covers that niche anyways).

EDR-DOS supports FAT+ hacks, which extends beyond silly FAT max. size ranges, so if that floats your boat, you could try that.

> > What is the feasibility of adding
> > exFAT support to
> FreeDOS?

From technical point of view it is feasible. We have even NTFS drivers for DOS and exFAT is much simplier so it could work fairly good in DOS. The main limitation is the consumption of DOS memory - maybe it could entire work in real memory maybe some data would be in extended memory (it could bring some limitations and incompatibilities) but it is possible.

Certain problems could occur which files bigger than 4GB. It would most probably need some patching in DOS kernel because I think only 32-bit counters are used for files. (simple solution fould be, of course, don't support such files)
Another possible problem is nonexistence of compatility layer for 8.3 format which is used in legacy DOS functions. There is no standard how to translate LFNs into short 8.3 form.

Somebody on this list (I think Khursaw) wrote a very minimal exFAT reader for DOS which could be used as a base for driver.

However, as Rugxulo says, the very serious problem is the necesary manpower for it. DOS community is small and difficulty for such task is big.

The patents is not problem at all. But I agree it is a solid excuse and alibism. Software patents were ignored always (remember f.e. GIF patent) and shit happens.

---
DOS-u-akbar!

> There is no standard how to translate LFNs into short 8.3 form.
There is this reference: How Windows Generates 8.3 File Names from Long File Names

The difficulty lies in insuring the result is unique within the directory. This is done by that algorithm by storing the created name in the directory. (Storing the number behind the tilde would theoretically be sufficient.) This is not usable on file systems that do not provide storage for the short names.

One workaround is to define and maintain a file yourself (usually in the root directory, or one in each subdirectory as necessary) that holds short name aliases and their long (real) names. This was used in the other direction (to provide long names on FAT) even before W95 came around with long file names.

Another workaround is to use some value that makes the name unique in the directory as "tilde number". For example, the directory index of the file's name. IIRC that is used by DOSLFN's CD-ROM access. This method is best employed on read-only file systems as otherwise you need low-level hooks to avoid directory entry re-ordering (because it would change the assigned short name). Users want name assignments to persist, both generally (ease of use) and for shorter periods (while the file is opened by a program, it is critical that it persists).

---
l

Thanks for all the above feedback.

> One workaround is to define and maintain a file yourself (usually in the
> root directory, or one in each subdirectory as necessary) that holds short
> name aliases and their long (real) names. This was used in the other
> direction (to provide long names on FAT) even before W95 came around with
> long file names.

If I remember well this approach was used in UMSDOS file system used by early Linux. When I first met Monkey Linux on PC (it was in 1996/97) it used this. Whole distro was 5x 1,44MB ARJ-packed floppies that contained / directory structure but with short names and with special files in every directory. You just unpacked it on your FAT16 8.3 disk under DOS and execute loadlin via linux.bat After boot you had normal Linux filesystem with long names and attributes. It must keep index files in sync. BTW this distro contained also MC, Xserver and Netscape browser :)

---
DOS gives me freedom to unlimited HW access.

I think that best and most probably ONLY working solution how to transparently generate 8+3 names from LFNs is to compute hash-values from LFN names and use it as a part of SFN.

Example: we have file "Glory_for_freedos.txt"
1) by some algorithm compute hash from string "Glory_for_freedos.txt", which will be a two-char number (like 72) or two-char alfanumerical value (like 4K)

2) such value would be added after first five chars of SFN and tilde:
glory~72.txt

NOTES:
a) SFNs will not be generated for files which already match the standard 8+3 scheme
b) SFNs will be used only by legacy DOS functions. LFN functions would, of course, use the native LFN names.
c) it must be specified what to do if hash collision occurs

---
DOS-u-akbar!

> c) it must be specified what to do if hash collision occurs

This is always the most difficult part.

I don't see an advantage in using the LFN's hash value, over the other methods like only cutting the name, or always appending an arbitrary number, or using the directory entry's index. (And yes, all of these have to consider how to avoid or handle collisions too.)

---
l

FWIW, I would like to see the SFN's be persistent (as much as possible, anyway) across reboots and even when copying between different directories, disks, or machines. This should make it much easier for non-LFN-aware programs to be able to consistently use the files.

Unfortunately, this would probably require either storing the SFNs in the directory structure (something similar to what M$ did when they added LFN to FAT), or storing special files on the disk somewhere (something similar to the DESCRIPT.ION files that were becoming pretty popular before M$ did their LFN thing).

> FWIW, I would like to see the SFN's be persistent (as much as possible,
> anyway)

Yes, I agree.
It is the reason why I advocate hashes. They are quite persistent.

---
DOS-u-akbar!

> > FWIW, I would like to see the SFN's be persistent (as much as possible,
> > anyway)
>
> Yes, I agree.
> It is the reason why I advocate hashes. They are quite persistent.

I see. But if collisions occur, then only storing the SFN stays persistent.

---
l

> a) SFNs will not be generated for files which already match the standard
> 8+3 scheme

BTW this behaves differently on Win9x and Win2k/XP and may cause problems. I'm not sure but if file doesn't have LFN entry, Win2k/XP will display it uppercase by default and Win9x lowercase, just want to say this systems behaves little bit different. Why bother with it? I found that some Windows programs (moslty port from *nix) are case sensitive on filenames. I know about few applications that will break if you change its files case from lower to upper. It simply doesn't run - any error displayed. When files renamed back to lower case it works again. I hate this behavior on Windows...

---
DOS gives me freedom to unlimited HW access.

> I found that some Windows programs (mostly port from *nix) are case sensitive on filenames.

It depends. For DBCS (Big5, Shift-JIS, GBK, etc.) the lower byte may consist of A-Z(uppercase) and a-z(lowercase). DBCS-aware applications shouldn't change the case of filename to kernel.

For example, 0xA4 0x50(ñP) in Big5 is mapped to U+5315, 0xA4 0x70(ñp) is mapped to U+5C0F. Some Programs, say Quick View Pro, UPPERCASE the filename, which leads to "File not found" error in result.