Bootstrapping DOS boot disk - Microsoft Windows

This is a discussion on Bootstrapping DOS boot disk - Microsoft Windows ; RP> But, [MS-DOS] 6.22 and later versions (7.00, 7.10, 8.00) have many RP> benefits: LFN's, VFAT, MSS> What is "VFAT"? FAT with LFNs? Then how is it different from "LFN"s? It's the name of the VxD that incorporates the FAT ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Bootstrapping DOS boot disk

  1. Bootstrapping DOS boot disk

    RP> But, [MS-DOS] 6.22 and later versions (7.00, 7.10, 8.00) have
    many
    RP> benefits: LFN's, VFAT,

    MSS> What is "VFAT"? FAT with LFNs? Then how is it different from
    "LFN"s?

    It's the name of the VxD that incorporates the FAT filesystem driver
    in DOS-Windows 95 et seq.. It isn't a feature of the filesystem, nor
    (contrary to popular misconception, that Linux has helped to spread)
    is it the name of the filesystem type. That is still FAT. It is
    _solely_ the name of the driver module.

    Given that it's a VxD, it isn't part of MS-DOS, as claimed.


  2. Re: Bootstrapping DOS boot disk


    "J de Boyne Pollard" wrote in message
    news:1193775585.301796.78330@t8g2000prg.googlegrou ps.com...
    > RP> But, [MS-DOS] 6.22 and later versions (7.00, 7.10, 8.00) have
    > many
    > RP> benefits: LFN's, VFAT,
    >
    > MSS> What is "VFAT"? FAT with LFNs? Then how is it different from
    > "LFN"s?
    >
    > It's the name of the VxD that incorporates the FAT filesystem driver
    > in DOS-Windows 95 et seq.. It isn't a feature of the filesystem, nor
    > (contrary to popular misconception, that Linux has helped to spread)
    > is it the name of the filesystem type. That is still FAT. It is
    > _solely_ the name of the driver module.
    >
    > Given that it's a VxD, it isn't part of MS-DOS, as claimed.
    >


    Sorry. I've unintentionally listed features available to DOS under Windows
    95/98/SE/ME as DOS features. VFAT are the 32-bit FAT routines used by
    Windows95/98/SE/ME.


    Rod Pemberton


  3. Re: Bootstrapping DOS boot disk

    "J de Boyne Pollard" wrote in message
    news:1193777228.451436.132330@57g2000hsv.googlegro ups.com...
    > RP> But, 6.22 and later versions (7.00, 7.10, 8.00) have
    > RP> many benefits: [...] FAT32, "FAT32X".
    >
    > MSS> What is "FAT32X" and how is it different from FAT32?
    >
    > It isn't.


    Oh, but it is. Both the method used to access the disk and the supported
    disk capacity are different.

    "Two new partition types are defined: 0xB and 0xC. Both indicate FAT32
    volumes; type 0xC indicates a FAT32 partition that requires Extended Int 13h
    support--that is, logical block addressing (LBA)."
    http://www.microsoft.com/whdc/archiv...reinstall.mspx

    "Using the maximum possible values yields:

    512 x 1024 x 256 x 63 (or 512 x 2^24) = 8,455,716,864 bytes or 7.8 GB

    The calculation results in a maximum capacity of slightly less than 8
    gigabytes (GB). Before BIOS INT 13h extensions drive geometry translation
    (also known as logical block addressing , or LBA) were introduced, the
    active, primary partition could not exceed 7.8 GB, regardless of the file
    system used."
    http://www.microsoft.com/technet/pro....mspx?mfr=true


    > It's just a hokey name for a FAT32 volume that happens to
    > live in a type 0x0C partition (as opposed to a type 0x01, 0x04, 0x06,
    > 0x0B, or 0x0E partition). The filesystem type is the same, FAT32, in
    > all cases. A type 0x0C partition is, simply, supposed to be invisible
    > to operating systems that suffer from the 1024 cylinder limitation or
    > that cannot handle partitions greater than or equal to 2GiB in size.
    > Thus it can begin/extend beyond the 1024 cylinder boundary and be
    > larger than 2GiB. This is irrespective of filesystem format. Indeed,
    > depending from its size, such a partition could just as easily be a
    > FAT16 volume, or even a FAT12 volume, as a FAT32 volume.
    >


    True, except that I believe you have the wrong limit for the partition size.

    > http://homepages.tesco.net./~J.deBoy...A/determining-
    > filesystem-type.html#PartitionTypes>
    > http://homepages.tesco.net./~J.deBoy...termining-fat-
    > widths.html>
    >


    "FAT32X" is FAT32 with LBA, i.e., BIOS extended Int 13h support, for hard
    drive capacity larger than 8.4Gb.

    Here a summary of MS filesystems (switch to fixed width font):

    type max.size max.file clusters max.clust MS-DOS ver. Win. ver.
    FAT12 16Mb 2^12 4Kb Ver. 1.00
    FAT16 2Gb 2^16 32Kb Ver. 3.00
    FAT32 127.5Gb 4Gb 2^28 32Kb Ver. 7.10 WIN95B OSR2
    FAT32X * 4Gb 2^28 32Kb Ver. 7.10 WIN95C OSR2.5

    NTFS 256Tb 16Tb(16Eb) 2^32(2^64) 64Kb WinXPpro
    FAT16 4Gb 4Gb 2^16 64Kb
    WinXPpro/WinSrv2003
    FAT32X 32Gb 4Gb 2^28 64Kb
    WinXPpro/Win2K/WinSrv2003

    * 8Tb theoretical, 127.5Gb Win95 & Win98, 2Tb WinME
    Win95 & Win98 are FAT table limited, WinME is partition table limited.
    FAT32X added extended Int 13h BIOS support for drives >8.4Gb, i.e., LBA.

    (The above values came from a number of MS pages - which I didn't keep -
    since it was compiled for personal use.)


    Rod Pemberton


  4. Bootstrapping DOS boot disk

    MSS> What is "FAT32X" and how is it different from FAT32?

    JdeBP> It isn't.

    RP> Oh, but it is. Both the method used to access the disk and the
    supported
    RP> disk capacity are different.

    .... neither of which affect, or indeed are anything to do with, the
    filesystem type. As I said, it's just a hokey name for a FAT32 volume
    that happens to live in a type 0x0C partition (as opposed to living in
    a type 0x01, 0x04, 0x06, 0x0B, or 0x0E partition). The filesystem
    type is the same, FAT32, in all cases.

    http://homepages.tesco.net./~J.deBoy...A/determining-
    filesystem-type.html#PartitionTypes>

    For comparison: One could just as easily put a FAT12 or a FAT16
    volume in such a partition. That doesn't suddenly invent new "FAT12X"
    and "FAT16X" filesystem types, and doesn't magically change anything
    whatsoever in the filesystem format.

    JdeBP> A type 0x0C partition is, simply, supposed to be invisible
    JdeBP> to operating systems that suffer from the 1024 cylinder
    JdeBP> limitation or that cannot handle partitions greater than or
    JdeBP> equal to 2GiB in size. Thus it can begin/extend beyond
    JdeBP> the 1024 cylinder boundary and be larger than 2GiB. This
    JdeBP> is irrespective of filesystem format.

    RP> I believe you have the wrong limit for the partition size.

    It's the correct limit. The 0x0B and 0x0C partition types hide such
    partitions from operating systems that assume that all volumes are
    smaller than 2GiB, as MS-DOS 6.22 and earlier did. The 0x0C partition
    type additionally hides such partitions from operating systems that
    cannot access the parts of the disc that are beyond the 1024 cylinder
    limit. The addition of new partition types by IBM/Microsoft has
    always been motivated by needing to hide partitions from operating
    systems that are incapable ot dealing with them, because of partition
    size or placement limitations in those operating systems.

    http://homepages.tesco.net./~J.deBoy...A/determining-
    filesystem-type.html#PartitionTypes>

    You are conflating the partition size limits and the filesystem format
    limits, in part because you are erroneously thinking that "FAT32X" is
    a distinct filesystem format. As I've said, it isn't. The limits of
    the FAT12, FAT16, and FAT32 filesystem formats are quite distinct from
    the limits on type 0x01, 0x04, 0x05, 0x06, 0x0B, 0x0C, 0x0E, and 0x0F
    partitions (and their variants). These partition types do not imply
    filesystem types.

    RP> Here a summary of MS filesystems (switch to fixed width font):
    [...]

    It's wrong. It's wrong for distinguishing FAT32X, treating it as
    somehow different to FAT32. It's wrong for ignoring the effect of
    cluster sizes on the volume size limits.

    A correct table has to be more complex. In fact it has to be several
    tables. In addition to the aforelinked, read homepages.tesco.net./~J.deBoynePollard/FGA/os2-disc-and-volume-size-
    limits.html#FilesystemLimits>.


  5. Re: Bootstrapping DOS boot disk

    On Nov 2, 12:12 am, J de Boyne Pollard
    wrote:
    > MSS> What is "FAT32X" and how is it different from FAT32?
    >
    > JdeBP> It isn't.
    >
    > RP> Oh, but it is. Both the method used to access the disk and the
    > supported
    > RP> disk capacity are different.
    >
    > ... neither of which affect, or indeed are anything to do with, the
    > filesystem type. As I said, it's just a hokey name for a FAT32 volume
    > that happens to live in a type 0x0C partition (as opposed to living in
    > a type 0x01, 0x04, 0x06, 0x0B, or 0x0E partition). The filesystem
    > type is the same, FAT32, in all cases.
    >
    > http://homepages.tesco.net./~J.deBoy...A/determining-
    > filesystem-type.html#PartitionTypes>
    >
    > For comparison: One could just as easily put a FAT12 or a FAT16
    > volume in such a partition. That doesn't suddenly invent new "FAT12X"
    > and "FAT16X" filesystem types, and doesn't magically change anything
    > whatsoever in the filesystem format.
    >
    > JdeBP> A type 0x0C partition is, simply, supposed to be invisible
    > JdeBP> to operating systems that suffer from the 1024 cylinder
    > JdeBP> limitation or that cannot handle partitions greater than or
    > JdeBP> equal to 2GiB in size. Thus it can begin/extend beyond
    > JdeBP> the 1024 cylinder boundary and be larger than 2GiB. This
    > JdeBP> is irrespective of filesystem format.
    >


    Sorry, but contrary to the above (which seems based on some
    information
    from MonoSoft) FAT32x is *not* formatted the same as FAT32!

    I have a drive in which the last partition straddles the 8G boundary.
    It was
    created and formatted as a FAT32 partition, and so only works OK for
    the
    first part of it, then horrible things happen (in DOS mode) as the CHS
    addressing wraps around (which is to be expected). BTW, in Windoze
    mode,
    all the partition is accessed OK, so this must be using LBA
    regardless.

    So, I should be able to fix this by changing the partition ID to $0C,
    right?
    Wrong! When I do that, no files are found at all, in both DOS and
    Windoze
    modes, and there is reportedly only 30M free space left on the
    partition!

    At the moment, I'm trying to find out why FAT32 and FAT32x differ,
    apart
    from the well-known LBA thing. I've seen something to say the file
    allocation
    table for FAT32x is located at the end of the partition, instead of
    the start,
    but I have yet to confirm this or find if there are any other poorly
    documented
    differences. But clearly there are differences.

    Joe.



  6. Re: Bootstrapping DOS boot disk

    > from the well-known LBA thing. I've seen something to say the file
    > allocation
    > table for FAT32x is located at the end of the partition


    No.

    There is no difference in internal structure of FAT32x vs. FAT32.

    Try using Linux "dd" to copy the partition to another location which will not
    cross 8GB and look at it once more.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com


  7. Re: Bootstrapping DOS boot disk



    Maxim S. Shatskih wrote:
    > > from the well-known LBA thing. I've seen something to say the file
    > > allocation
    > > table for FAT32x is located at the end of the partition

    >
    > No.
    >
    > There is no difference in internal structure of FAT32x vs. FAT32.
    >
    > Try using Linux "dd" to copy the partition to another location which will not
    > cross 8GB and look at it once more.
    >
    > --
    > Maxim Shatskih, Windows DDK MVP
    > StorageCraft Corporation
    > maxim@storagecraft.com
    > http://www.storagecraft.com


    Hi Maxim,

    Last night, I may have found a clue. It appears that the Relative
    Sector field in the partition table is interpreted differently for
    FAT32 (0B) vs. FAT32X (0C) partitions. It appears that for the former,
    it is an absolute LBA value, for the latter, it is relative to the LBA
    of the partition table. Now for the MBR, that amounts to the same
    thing. However for a partition table extension (have I got the
    terminology right?), such LBA values don't correspond! Hence changing
    the partition type in the partition table extension, from FAT32 to
    FAT32X, would have resulted in incorrect LBA addressing. At least
    that's the conclusion I came to last night.

    As for the positioning of the file allocation table for FAT32 vs.
    FAT32X, that's just something I read while searching for some detail
    on this FAT32X stuff. It sounds like a crazy idea, and is probably
    incorrect, but it was the only thing I found on the 'net which might
    have explained why simply changing the partition ID from FAT32 to
    FAT32X made the partition totally "scrambled". Now I have a new
    theory, based on my own experimentation.

    There's still a lot of strange interaction between partition table
    ID's 05 vs. 0F, 0B vs. 0C that I don't yet understand. All the
    documentation I've found on these new LBA versions of the older CHS
    partition ID's is pretty sparse and inadequate. For example, there's
    http://support.microsoft.com/kb/q69912 which provides good
    introductory information, but it's really inadequate, especially since
    there seem to be a lot of quirks involved.

    It is also interesting to see in the above KB article that there's
    also a FAT16X partition ID and that this predates even the FAT32
    partition ID, let alone FAT32X.

    Joe.

  8. Re: Bootstrapping DOS boot disk

    > Last night, I may have found a clue. It appears that the Relative
    > Sector field in the partition table is interpreted differently for
    > FAT32 (0B) vs. FAT32X (0C) partitions. It appears that for the former,
    > it is an absolute LBA value, for the latter, it is relative to the LBA
    > of the partition table.


    All RelativeSector fields in the PT are relative to the PT, for all FS types -
    all FATs, NTFS etc.

    >Now for the MBR, that amounts to the same
    > thing.


    Surely.

    > the partition type in the partition table extension, from FAT32 to
    > FAT32X,


    This field is always relative to the PT.

    > FAT32X, that's just something I read while searching for some detail
    > on this FAT32X stuff.


    Having the FASTFAT source near me, I still do not think that FAT32X exists :-)

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com


  9. Re: Bootstrapping DOS boot disk


    Maxim S. Shatskih wrote:

    >> Last night, I may have found a clue. It appears that the Relative
    >> Sector field in the partition table is interpreted differently for
    >> FAT32 (0B) vs. FAT32X (0C) partitions. It appears that for the former,
    >> it is an absolute LBA value, for the latter, it is relative to the LBA
    >> of the partition table.


    > All RelativeSector fields in the PT are relative to the PT, for all
    > FS types - all FATs, NTFS etc.


    Some time passed since I wrote my FAT-import/export module as extension
    to my volume detector (find all partitions). But I sure have actually
    two different (beside CHS/LBA yet) interpretations of the values found
    at dword[part_entry +08]. The dword at[..+0C] is the size (sectors).
    Types 06,07-NT,0b,0c,0e,16,1b,1c,1e,..82,83 are relative, while
    extended partitions and my own use absolute LBA28 (type 05 0f 4b/0).

    ....
    > Having the FASTFAT source near me, I still do not think that
    > FAT32X exists :-)


    I think to have seen it created by PQmagic.
    My old docs say:

    partition 0C is FAT32X (uses INT13 with LBA extensions)
    0B is FAT32 (win95, uses INT13 by LBA->CHS conversion)

    I think the latter had changed, even it could explain why windoze
    98se/XP-home wont recognize HD-space above 128 GB (CHS-limit=127.5 GB)
    and cannot handle partitions >64GB without additional drivers.

    __
    wolfgang






  10. Re: Bootstrapping DOS boot disk

    > partition 0C is FAT32X (uses INT13 with LBA extensions)
    > 0B is FAT32 (win95, uses INT13 by LBA->CHS conversion)


    In Windows, they are declared as:

    #define PARTITION_FAT32 0x0B // FAT32
    #define PARTITION_FAT32_XINT13 0x0C // FAT32 using extended int13
    services

    OK, probably this is what is called "FAT32X". Anyway in Windows NT they are the
    same :-)

    > I think the latter had changed, even it could explain why windoz
    > 98se/XP-home wont recognize HD-space above 128 GB (CHS-limit=127.5 GB)


    No, 128 GB is the old ATA hardware limit - 32bit LBAs with 512 bytes/sector.
    This is not the CHS limit.

    The CHS limit of base int 13h is 8GB.

    > and cannot handle partitions >64GB without additional drivers.


    XP home? looks like not so.

    It always uses the addressing mode set in the current IDENTIFY data regardless
    of partition type. More so, the disk stack internals in NT are LBA-only - if
    the ATA disk is CHS, then LBA->CHS conversion is done just before programming
    the registers.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com


  11. Re: Bootstrapping DOS boot disk


    wrote in message
    news:07252d59-d5d6-452b-9ad4-0a4a7ff022fc@d21g2000prf.googlegroups.com...
    > Last night, I may have found a clue. It appears that the Relative
    > Sector field in the partition table is interpreted differently for
    > FAT32 (0B) vs. FAT32X (0C) partitions.

    ....
    > There's still a lot of strange interaction between partition table
    > ID's 05 vs. 0F, 0B vs. 0C that I don't yet understand.


    Can you tell us which Windows OS are you using? e.g., Windows ME, etc.


    Rod Pemberton
    (dropped comp.os.msdos.misc)


+ Reply to Thread