Page 1 of 2

fdisk compatibility

Posted: Mon Dec 19, 2005 10:34 am
by octavio
Hello, i have written some programs to format the hard disk
and install my OS ,i have already created the master boot sector, fat32 partitions and booted my OS with succes, but
the problem is that WINXP says that the hard disk is not formated , in another test ,i installed my OS on a HD with
WINDOWS98 without formating ,but replacing the boot sector
of the fat32 partition by my own ,to boot first my OS, when my OS is running ,i load
the boot sector of W98 and the system start booting and shows the logo ,but then it says that it can?t find the file
'himem.sys' and stops with a DOS session, then i type:
'dir himem.sys /s ' and DOS has no problem to find all the files
should i be paranoid or i?m doing something wrong.
In the last test i have created a very small fat32 partition 10MB size at the end of a hard disk ,installed my OS and boot it without problem, then i boot windows XP installed on the same disk ,and it detects the partition but says that is not formatted. ???

Re:fdisk compatibility

Posted: Mon Dec 19, 2005 10:55 am
by nick8325
I've never written a FAT driver myself, but I seem to remember that some versions of Windows are picky about the OS name given in the BPB, and will make sure that it is something like MSWIN4.0.

Also, http://www.ntfs.com/fat-partition-sector.htm mentions a Signature field that has to be 0x28 or 0x29. I wonder if that could be it...

Re:fdisk compatibility

Posted: Tue Dec 20, 2005 12:50 pm
by kataklinger
FAT specification says that Windows itself doesn't check OEM name in BPB (but other tools might do that). I suggest you to read Microsoft FAT Specification. You can download it at http://www.microsoft.com/whdc/system/pl ... atgen.mspx

Information about MBR, partition table, CHS, ATA&ATAPI stuff you can find on http://www.ata-atapi.com/hiw.htm

Re:fdisk compatibility

Posted: Wed Dec 21, 2005 9:42 am
by JAAman
actually i have seen many windows-formated disks which fill the 'OEM name' field with random garbage, so that shouldn't be a problem

Re:fdisk compatibility

Posted: Thu Dec 22, 2005 6:19 am
by octavio
well ,there are many things that can cause the problem
-partitions are not chs aligned because i use lba
-only one fat copy
-chs and other unused fields set to 0
i suppose that some testing is needed ,perhaps some variables are in fact fixed values like the floppy fat 12 format
(dos ignores the bpb)

Re:fdisk compatibility

Posted: Thu Dec 22, 2005 6:31 am
by Kemp
Yes, if you've ignored a lot of the standard then chances are that standards-compliant OSes won't recognise it as valid.

Re:fdisk compatibility

Posted: Thu Dec 22, 2005 10:11 am
by JAAman
dos does not ignore the bpb! if it did that it couldn't tell the difference between different types of disks (even HDDs can use FAT12) however, many dos programs expect certain values to be and hard code them but im not aware of any value that DOS does ignore (except on boot -- the boot sector is hard-coded to certain values, but if you change them your rewriting the bootsector anyway and can easily change the hard-coded values)
though i must say i havent really researched that (though i know it does check many values, including CHS, total, hidden, FAT_size, reserved sectors, serial number, label, -- the only thing it might 'hard-code' would be the FAT_copies, and bytes/sector)

many older programs used to alter the way DOS handles disks (such as the size) by editing the boot sector

Re:fdisk compatibility

Posted: Thu Dec 22, 2005 10:55 am
by kataklinger
Yes it does care about BPB (of course), but it doesnt look OEM name, and other strings I don't remeber the names. Dos uses other fileds (like sector count...) to identify partition type (FAT12/16/32).

Re:fdisk compatibility

Posted: Thu Dec 22, 2005 10:54 pm
by JAAman
i think it relies only on the MBR type field for identifying FAT12/16/32, all three can be used on the same size disks, so it cannot use num_sectors for determining that (i believe it assumes any disk without a MBR is FAT12, and with an MBR it determines the type through that)

Re:fdisk compatibility

Posted: Fri Dec 23, 2005 1:35 am
by Candy
JAAman wrote: i think it relies only on the MBR type field for identifying FAT12/16/32, all three can be used on the same size disks, so it cannot use num_sectors for determining that (i believe it assumes any disk without a MBR is FAT12, and with an MBR it determines the type through that)
From the docs (not directly, but I've read them a long time ago and they really emphasize this): The FAT size is determined by the number of clusters, and the number of clusters alone.

[edit]

Direct quote:
The FAT type?one of FAT12, FAT16, or FAT32?is determined by the count of clusters on the volume and nothing else. The FAT type?one of FAT12, FAT16, or FAT32?is determined by the count of clusters on the volume and nothing else.

Code: Select all

If(CountofClusters < 4085) {
/* Volume is FAT12 */
} else if(CountofClusters < 65525) {
    /* Volume is FAT16 */
} else {
    /* Volume is FAT32 */
}

Re:fdisk compatibility

Posted: Fri Dec 23, 2005 8:53 am
by JAAman
really? thats surprising

however -- there is no 'count of clusters' in the BPB

i guess its calculated at runtime by dividing Total_sectors by Sectors/cluster?

that would work -- it would make the minimum size for FAT32=8MB and FAT16=2MB i guess that would work since the overhead on a disk smaller than those limits would be really bad!

kataklinger said count of sectors and thats what threw me off (i knew that couldn't be right) -- and since there is no count_of_clusters i didn't even think of that

Re:fdisk compatibility

Posted: Fri Dec 23, 2005 9:12 am
by octavio
I found the problem (thanks for the links)
i was using 0 as media descriptor ,now i changed it to 0f0h and it works.I have also added the fsinfo sector and bksectors

The number of clusters is used to determine betwen fat12 and
fat16 but not for fat32 ,y have done multiple fat32 partitions ,one wiht only 7MB in size and windows don?t see any problem, in fact windows is much more tolerant than other
Oses that require cylinder alignement.

Re:fdisk compatibility

Posted: Fri Dec 23, 2005 9:34 am
by Dex4u
From the docs (not directly, but I've read them a long time ago and they really emphasize this): The FAT size is determined by the number of clusters, and the number of clusters alone.
In the book "Dissecting DOS" it says the same.

Re:fdisk compatibility

Posted: Fri Dec 23, 2005 9:50 am
by kataklinger
Yes it's cluster count, not sector count, sorry my mistake ;)

Re:fdisk compatibility

Posted: Sat Dec 24, 2005 8:43 pm
by Billy
I wrote a fat12/16/32 formatting utility that gives no errors in win98/win xp, and let me tell you, if I set the OEM string to anything but MSWIN4.1, it doesn't not work properly! Once I set that string to MSWIN4.1, windows is happy, fdisk see's my partitions, scandisk reports no errors on my drives, and I can copy files to and from my partitions without errors. If you are interested in the code, I use only one FAT table for my partitions rather than the standard 2. Microsofts documentations is not 100% accurate, there are a few things that are incorrent in it, because I went straight by the documentation and ran into a few problems that I have corrected with trial and error. (Aka, I read in a valid formatted disk, and checked what the difference was between my boot sector and the valid one). After all was said and done, a couple of things that Microsoft docs say they don't use in any way, ended up being the culprit's. Like I said though, if you're interested in my formatting utility, let me know, I actually have my MBR installed on my hard-drive, as well as a valid fat32 partition formatted using my formatter. The code is relatively specific to my kernel, since it installs the bootsector and kernel, and points a variable in the bootsector to the first sector of the kernel on the disk. All of that could easily be changed however. Just to reiterate, don't believe everything you read in a microsoft document ;). I also had a problem with the media descriptor, but the only complain I got from that was when I ran scandisk, other than that it worked fine without the correct value.