Yes, that would be a good addition. You are correct that one FAT is an extension of the other. It is documented pretty decently in Wikipedia, linked from filesystem/fat32/doc.go. FAT32 Extended BPB includes and extends FAT12/16 Extended BPB, which extends DOS 3.31 BPB, which extends DOS 3.2 BPB, which extends DOS 3.0 BPB. The FSIS is new to FAT32, but a lot of the structures are similar. The reserved sectors and FAT tables can be different in size, if I recall correctly, but that is manageable. If you look at the files in this library implementing fat32, you can see that each substructure exists.

So it should be doable without too much pain.

Do you want to give it a shot?

I'm working through my project now, which has a large chunk of things I need to implement before I need the FAT12/16 support, but I'm definitely interested. Especially seeing how easy the existing API was for FAT32.

Once I finish all my other building blocks, I'll definitely look into contributing it. 👍

@deitch in terms of implementation - how do you feel we should organise the code? Since the fat32 package already has a lot of the building blocks that could be shared between the other FAT types, should we move a lot of the Boot sector/BPB stuff into a common fat package which can be shared between fat32 (and the new fat12, etc packages)?

I have been thinking about it. I don't think it all should be in a single package (directory), as it is less clean than the current structure, which has each filesystem type in its own. Also, when you Disk.GetFilesystem(), it tries each directory, e.g. fat32.Read() and iso9660.Read(), etc. If that is hard, we can change that, e.g. fat32.Read(fat32) or fat32.Read(fat16), etc. Or we can have fat32.Read() have its own internal analyser that figures out, "oh this FAT is fat12" or "this FAT is fat32".

I would not mind moving each one into its own directory without the common fat directory:

|- filesystem
    |- fat12
    |- fat16
    |- fat32

It is not so much common stuff, as it is each one builds on the previous. So fat32 can just use structures from fat12, etc.

I am not 100% sure that this works, though, so it is just a starting thought.