Did you ever take a care about FAT filesystem? Did you experienced over new one that Windows'95 brings? I played with old FAT a long time ago, I did a lots of work with it, like disk recoveries, crashed disks, etc, even repairing disk by phone (filling in all numbers computed in head for partition and boot by talking via phone). I wrote several FAT emulators r/w (guess for what reasons ;-), some recovery utilities, disk swapping tools (changing internal dos/windows stuff for swapping disks, booting from non-primary partitions, etc), on-fly mounting an unmounting disk utils for dos/win. I would say I was quite familiar with FAT.

But things getting changed. I've installed a new Windows on my computer some time ago (you have to do so in current contitions), swapped to FAT32. It is slower a bit, but functional. Before I have my old (today I would say "really old") 1GB disk partitioned into 128MB partitions for having 2kB clusters. I used to have lots of small files, and not to have a big space wasting I had many logical disks on that disk. With FAT32 all these things are forgotten. But even in that time I never checked new disk structures.

But nice spring evening comes, and CIH does its job. Not on my disk, of'coz as I play with viruses for more than 8 years. I don't have any active virii on my computer - for that reasons I use best avir 'round the globe - hiew ;-). Well but friend of mine called me that his office disk crashed (and even his cheef's disk and others as well) and asked me for help. "CIH" - my first idea was. Of course I was right. Moreover, he wasn't the only one who asked me for help at that time. And I get experienced with FAT32 immediately.

Well, let's have a look what is changed under FAT32. Of course, cluster numbers are 32bit. What an advantage. However, as upper 4 bits of cluster number are reserved, gives at maximum 268,435,456 clusters. This makes FAT very long, and slows down a DOS a lot, because it can't load all data into its buffers at once and forgots first entries it loads - and it has to load it again, forgetting newer entries, then to load newer once again: if you are familiar with caching algorhitms of victims - it is a classical example of fifo-bug. I'll divide my tour into some logical sections, covering what is new in all structures. Most of changes are determined by need of accessing big disks. Really big disks. It has something to deal with int13 address-space, bioses, and so on.

Partition table
There are two main changes. At first, the code itself is changed for supporting a new accessing methods of huge disks. You have to think about of adressing space for accessing sectors on disc. May be some of you remember how the limit of 512MB was famousely broken. Maximum coordinates some time ago were:

- 6 bits for sector number (starting from 1) - max 63 sectors
- 6 bits for head number (starting from 0) - max 64 heads
  however this is slightly implementation dependent. In general description whole DH register used with 13/02 (int 13, ah=02) should contain head number which allows 256 heads, but Award BIOS uses highest two bits of DH for highest track bits, and Ami as well as far as I know.
- 12 bits for cylinder (starting from 0) - max 4096 cyls (or tracks)
  which also performs some kind of incompatibility, as original documentation refers 10 bits for tracks (max 1024) - CH plus 2 highest bits in CL, but most bioses I know uses also highest two bits of DH as additional bits.

However, thinking about maximum 6/6/12 bits or 6/8/10 bits leads to same results. But some of the BIOSes (IBM based) supports only 4 bits for head, and, of course 10 bits for track. In result it is 63*16*1024 sectors (each 512 bytes) which is nearly the famouse 512MB limit.
Those disks in old times uses disk managers in order to overcome this limit under all bioses (usualy emulates int13 call using controller commands performing LBA accessing). LBA introduced in that time means Logical Block Adress - avoiding old geometry adressing (track/head/sector) with logical sector number.
Well, 512mb limit is over, but there is another limit - given by maximum accessible number of 3 bytes use for old-style access 63*64*4096 - an 8GB limit. By the way - MS-DOS (and Win95/98 as well, as it still relies on old dos routines) has trouble using head 255, and disks must be mapped as maximum 255 tracks (0..254 which can be handles by msdos). Here you can see, how big is Microsoft's influence to hw manufactures - due to bug in very old OS the still presents hw which overcomes these problems. Moreover - none of disks I seen within last 2 years uses real geometry but instead of it they use internal translation of geometry from logical that is indicated to bios and dos, into physical. Well, it is unbelieveable that todays disk has 255 surfaces which means 128 physical magnetic disks with surfaces on both sides - how you can fit it into disk package aprox inch of height? ;-)
Well, back to 8GB limit of old style adressing (which must be there, otherwise DOS - and its graphical frontend called Windows can't be started). This can't be simply bypassed this way by increasing some bits. A new routines for reading must be introduced. Have a look on current partition table code and read: A old routines 13/02 are still there, but preferable it uses new EDD functions (Enhanced Disk Drive - originaly found in Phonenix BIOS, but available in AWARD as well). It is detected by calling 13/41, and accessible via 13/42 using qword LBA for adressing sectors.
This qword can't be extracted from old adressing bytes as there isn't enought bits to cover all the needed information. Thats why begining relative sector is used which has dword size. Of course, introduces a new limit of 4G sectors = 2TB. Too bad, isn't it? Disk size is rapidly increasing, hope these structures will be changed within next years.
Also there are four new filesystem codes for partition table entries for FAT32 disks:

`0Bh` - FAT32 (32bit fat, up to 2047GB)
`0Ch` - FAT32x (same as FAT32, but uses LBA-logical block adress for accessing)
`0Eh` - DOSX13 (same as 06h - 16bit fat for larger partitions than 32MB, but with LBA accessing)
`0Fh` - DOSX13x (same as 05h - extended partition, but with LBA accessing)

Logical disc structure
We can now access disk and its sectors. A logical disks follows - organisation is nearly unchaned - for compatibility reasons. A boot sector and reserved sectors take a place, two copies of FAT, and clusters containing directories and files. Now, as in whole FAT32 implementation I can present two news: bad one and good one. Good one is that Microsoft is learning on his old mistakes and corrects them - root directory has no longer fixed position, and is located in separate cluster - so it can be expanded more than limited number of items like in previouse versions was. Bad news is that MS still stays on bad and unreliable filesystem, with slow access, not statisticaly optimized for files typicaly used. Of course, there is NTFS but people still prefer FAT-based filesystems.

Boot sector
Boot sector is no longer a sector. Funny, isn't it? We should better call it boot record (or superblock for linux freaks) because now it is stored in first three sectors. Moreover it is usualy mirrored by default to sectors 6-8 (a hotlink backup of boot sector) but its coordinates are stored in bootsector, so once it lost you generaly can't find a copy :-)
Here are offsets and meaning of values in boot sector(s), presented in linear offset which means offset 0x0200 means sector 1 offset 0x0000. Code is now stored in sectors 0 and 2.

`0x0003:` OEM ID (8 chars) usualy "MSWIN4.1" (or 4.0 for Win95)
`0x000B:` bytes per sector (word) always 512 for hard-disks
`0x000D:` sectors per cluster (byte)
`0x000E:` reserved sectors at begining (word) usualy 32 but can vary (with sector 0)
`0x0010:` fat copies (byte) always 2 for hard-disks
`0x0015:` media descriptor (byte) always F8 for hard-disk
`0x0016:` sectors per FAT (word) 0 for FAT32, as FAT can be really long
`0x0018:` sectors per track (word) default contains translation mode values
`0x001a:` sides (word)
`0x001c:` special hidden sectors (dword) usualy 63
`0x0020:` big total number of sectors (dword)
`0x0024:` big total sectors per fat (dword)
`0x0028:` FAT flags (word): 0-based number of Active FAT - i.e. fat beeing in use (bits 0-3) valid only if mirroring (bit 7) is disabled, bit 7 - FAT mirroring enabled, bits 4-6 and 8-15 are reserved. In other words, you can avoid using fat copy that contains physicaly damaged sectors - but someone have to turn it on :)
`0x002a:` filesystem version major (byte)
`0x002b:` filesystem version minor (byte) - 0.0 I saw so far
`0x002c:` first cluster of root directory (dword)
`0x0030:` FS sector number (word) - usualy 1 - where rest of boot record is stored - FileSystem informations (0FFFFh if there is no FSINFO sector, otherwise must be more than zero and less than reserved sector count)
`0x0032:` hotlink - backup bootsector (word) - usualy 6 (same as above: 0FFFFh for no backup, 1..reserved-1 otherwise)
`0x0040:` physical drive number (byte)
`0x0042:` extended boot record signature (byte) - 0x29
`0x0043:` volume serial number (dword)
`0x0047:` volume label (11 chars)
`0x0052:` filesystem ID (8 chars) - "FAT32 "
`0x01fc:` signagture (dword) aa550000
`0x0200:` extended boot signature (dword) - 41615252 "RRaA" (wow! no Mark Zbikowsky and his 'MZ'-everywere anymore, seems Bill employed someone else ;-)
`0x03e4:` FSINFO signature (dword) - 61417272 "rrAa"
`0x03e8:` free cluster count (dword) - as it takes long time to go through whole FAT, number of free clusters is stored here (0FFFFFFFFh if unknown)
`0x03ec:` next free cluster (dword) - to speedup free space lookup
`0x03fc:` FSINFO ending signature (dword) aa550000
`0x05fc:` signature (dword) aa550000

FAT - 32bit File Allocation Table
by skipping reserved sectors (usualy 32) you can reach file allocation table. Rest of reserved area is cleared, only boot sector(s) and its backup can be found there so far. But in future, who knows. Signature itself starts with known F8 FF FF 0F pattern. First cluster can't be used (as from passed), its value in fat is initialized to FF FF FF 07. The rest contains fat data itself, starting for cluster 2 at offset 8 in fat. Principle of fat lookup is same as before, but now uses structured 32bit value: 4+28bits, low 28 bits for cluster number (FFFFFFF for end of chain, FFFFFF8 for bad), upper 4 bits are reserved and Microsoft requires to preserve them when modifying FAT entries. Representation in stored form is, for example, FF FF FF 0F for end-cluster.
FAT can be very long - up to several thousands of sectors, which of course slows down all operations. As caching it takes lots of memory, which is unreal with buffers available under DOS. But this makes disks to surrive CIH's attack, as it destroys first 2000 sectors of disk, but if you have FAT32 (really long), second copy of fat is usualy untouched - all you need to do to repair disk after CIH is to copy second fat into first, construct boot sector (copy from other disk an type-in correct values) and write some numbers into partition table. Resulting few minutes of work - and disk is repaired like nothing happened. With infected files of CIH too, of course ;-)

Directory entries
I will not speak about LFN entries, as they are already well known I think. All I want to describe where the 32bit cluster value is stored. Low part of cluster number is at the original location, word at +1a bytes in directory entry. High word is stored at +14 in this entry. Both of them are real index into fat, like under old fat16/12 system. I also should mention, largest possible file on FAT32 is 4GB minus 2 bytes.

My short description is now over. Are you happy about FAT32 features? Where the hell are features? All is done as usual - Microsoft extends all stuff in order to keep it working, keeping all fears alive. There is no way to relyie on old traditions but MS breaks the limits - just like with dos7 and its graphical interface - keeping all the bugs as tradition that came from win 3.1, old dos, cp/m, etc, etc...

flush