Message-ID: <008d01c0e897$6caa9c00$d208e289@mpaul> From: "Matthias Paul" To: Cc: Subject: Proposal for new partition type IDs for use with future DOSes Date: Wed, 30 May 2001 01:21:27 +0200 Organization: University of Technology, RWTH Aachen, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id LAA00520 Reply-To: opendos AT delorie DOT com [CC: DR-DOS mailing list . I think, however, the discussion is best placed in the FreeDOS mailing list at .] Dear DOSers, Finally I have put together my draft for a couple of new FAT partition types to be added to FreeDOS, DR-DOS, and possibly other DOSes. Since I am maintaining a list of used partition IDs and are in the process to compile some stuff for RBIL62, I would like to hear your opinion on this proposal. Let me start with a short overview of FAT partition IDs: 01h DOS 2.0+ FAT12 (usually for < 16 Mb) 04h DOS 3.0+ FAT16 (<= 32 Mb) 05h DOS 3.3+ extended partition (EXT DOS) 06h DOS 3.31+ FAT16B (BIGDOS > 32 Mb) 0Bh DOS 7.10+ FAT32 0Ch DOS 7.10+ FAT32X (LBA) 0Eh DOS 7.10+ FAT16X (LBA) 0Fh DOS 7.10+ extended partition (LBA) [A. Partition IDs for "hidden" partitions] For some while now Brian Reifsnyder's FDISK lists a set of new partition IDs for "hidden" partitions. I don't know if they have been reserved "out of a sudden", or if they serve a special purpose already. 8Dh Brian Reifsnyder's FDISK 0.96+ hidden FAT12 90h Brian Reifsnyder's FDISK 0.96+ hidden FAT16 91h Brian Reifsnyder's FDISK 0.96+ hidden extended partition 92h Brian Reifsnyder's FDISK 0.96+ hidden FAT16B 96h Proposal: See 98h. 97h Brian Reifsnyder's FDISK 0.96+ hidden FAT32 98h Datalight ROM-DOS SuperBoot partition 98h Brian Reifsnyder's FDISK 0.96+ hidden FAT32X NOTE: Due to the conflict with Datalight's ROM-DOS I propose to use partition ID 96h instead. Any opinions? 9Ah Brian Reifsnyder's FDISK 0.96+ hidden FAT16X 9Bh Brian Reifsnyder's FDISK 0.96+ hidden extended partition (LBA) IBM and PowerQuest have already established a set of partition IDs for "hidden" partitions. Originally used by the OS/2 and PowerQuest Boot Manager and Partition Magic they have meanwhile evolved into a quasi-standard and are also supported by other partitioning software and boot managers. 11h Boot Manager hidden FAT12 14h Boot Manager hidden FAT16 (<= 32 Mb) 16h Boot Manager hidden FAT16B (> 32 Mb) 1Bh Boot Manager hidden FAT32 1Ch Boot Manager hidden FAT32X (LBA) 1Eh Boot Manager hidden FAT16X (LBA) 1Eh? FAT16 (Windows ME)??? (according to DriveStar 2.00 BETA5) NOTE: Anyone knowing what´s actually up with this one? Well, this question may go mainly to Brian: What are the specific reasons why IDs different from IBM´s/PowerQuest's have been chosen? Compatibility problems? Maybe those IDs are now so much in common use, they can hardly be named "hidden" any more? Or because some of those entries are also in use for other purposes? Anyway, if the new IDs remain listed in FDISK sources, I think they should also be listed in RBIL62 then, so that others will become aware of them and can incorporate them in their software. [Multiple extended partitions and alternative non-LFN partitions] Some months ago we discussed the problem of getting the most out of modern hard disks > 8 Gb without loosing most of the space for use under non-LBA-enabled DOS issues. As a reminder, the problem arose due to Microsoft's half-hearted approach to more carefully define how old and new partition types should be handled (leaving many reasonable scenarios "undefined") and it results in the situation, that you can either - use only the first 8 Gb of the disk under DOS as logical drives in an old type 05h extended partition, but then you will loose the remainder of the free disk space also for other systems (with the exception of OSes which will use LBA-enabled primary partitions - but then, primary partitions are of limited use because of their limited number), - or, if you use the new 0Fh LBA-enabled extended partition type to occupy the whole space of the drive, you will not be able to access any logical drives in that chain with traditional DOS issues (including DR-DOS 7.03 and FreeDOS BETA 6). So these OSes will be limited to as little as one 2 Gb FAT16B primary partition per physical disk then. My suggestion for DR-DOS was to first create a type 05h extended partition to occupy the space up to 8 Gb, then patch the partition ID to C5h (which is normally used by DR DOS 6.0+ for secured extended partitions), and create another type 0Fh extended partition starting above 8 Gb. DR-DOS 7.03 does not recognize the 0Fh extended partition type and treats it as an unknown primary partition. However, it uses the C5h type almost identical to the 05h type, so under DR DOS 6.0+ you will only see the logical drives in the C5h partition chain. MS-DOS 7.10+ treats the C5h partition type as an unknown primary partition type, but recognizes the 0Fh extended partition type, so you will see all the logical drives in this chain then. Some low level disk tools will not be able to handle the C5h type (similar to old tools not being able to handle the 0Fh type), but since they treat it as a primary partition there is no risk for data corruption. In case you need to run such a disk tool on a logical drive in the C5h chain, you will have to temporarily patch the C5h type back to 05h, that's it. All you have to keep in mind is that you must patch the partition back to C5h before you start any disk tool or OS that is aware of the 0Fh type. Otherwise it will see both, a 05h and a 0Fh partition type, a scenario that is unusual but can also happen when you would first create a 0Fh partition using MS-DOS 7.10+ FDISK and later create a 05h partition using for example MS-DOS 7 or 6.22 FDISK. Well written software should be aware of this possibility, take the extended partition that is first listed in the MBR, and ignore any possible following extended partition entries in the MBR (this is not the best possible solution, but this is what the MS-DOS 7.10 kernel does, so we have to remain compatible here as well - BTW. MS-DOS 6.22 also ignores all but the first 05h extended partition record in the MBR in case there would be more than one). The only backdraw of this setup is that non-DR-DOS systems will recognize neither C5h nor 0Fh. On DR-DOS systems users may no longer be able to secure their systems, and after floppy boots they will not see any logical drives in the C5h extended partition (this is a wanted behaviour for LOGIN SECURITY for the C5h partition ID, which, however, is not optimal for our kind of "abuse" of this ID). Well, the basic idea is, that we should introduce something similar to C5h to FreeDOS as well, but we should better avoid this very value for compatiblity with LOGIN SECURITY. Adding support for this is more or less a two-liner in the (non-resident part of the) kernel and in FDISK, and I suggest to use the currently unused partition type F0h for this purpose. While we will thereby opt-out Microsoft's own DOS line it is trivial to retrofit this into DR-DOS or other future DOS incarnations (including IBM's rumored new PC DOS, in case it would actually materialize), Linux, and disk tools. Furthermore, we can thereby define a reasonable default behaviour how F0h-"aware" OSes should treat the case, that they will encounter a F0h *and* a 05h, 0Fh, C5h extended partition at the same time, for example, first log in the logical drives in the F0h partition, (then in the C5h partition), and then in either a 05h or a 0Fh partition, depending on the physical order of the entries of the later two in the MBR. Besides, some may find it desireable to hide partitions away from MS-DOS 7+ for other reasons, including more security from system crashes, to hide classified stuff away from possibly "open" internet applications, or to avoid any pollution of partitions with VFAT long filenames, which are an annoyance to many traditional DOS users. Speaking of new partition types, I also think, we should reserve "alternative" partition IDs which - by definitionem - must not have VFAT LFNs stored on them. This would stop the current problems in the (ab)use of the traditional FAT12, FAT16, and FAT16B partition types. I propose to use F7h..FCh for them. Thereby we could also define (and/or slightly revise) how the LBA and CHS entries in the MBR and EPBRs must be treated and we would have the freedom to think about our own improved (but compatible with non-LFN DOS!) model for long filenames (my proposal is to use something similar to 4DOS DESCRIPT.ION files, or if we would still choose to store the LFNs in the directory entries, we could revise the model so that it remains compatible with DR-DOS passwords and works around the IMHO questionable patents that have been granted to Microsoft on storing long filenames in the FAT filesystem. Similar to my F0h proposal, the introduction of the new IDs would not cost more than a few bytes in the non-resident code of FreeDOS (and DR-DOS) kernel, and could also be added quite easily to other open source OSes such as Linux. For reference here are the special partition types used by (or reserved for) the single-user DR-DOS family: C0h Novell DOS/OpenDOS/DR-OpenDOS/DR-DOS secured partition C1h DR DOS 6.0 secured FAT12 C2h Reserved for DR-DOS 7+ C3h Reserved for DR-DOS 7+ C4h DR DOS 6.0 secured FAT16 (<= 32 Mb) C5h DR DOS 6.0+ secured extended partition C6h DR DOS 6.0 secured FAT16B (BIGDOS > 32 Mb) C8h Reserved for DR-DOS 7+ C9h Reserved for DR-DOS 7+ CAh Reserved for DR-DOS 7+ CBh Reserved for DR-DOS secured FAT32 CCh Reserved for DR-DOS secured FAT32X (LBA) CDh Reserved for DR-DOS 7+ CEh Reserved for DR-DOS secured FAT16X (LBA) CFh Reserved for DR-DOS secured extended partition (LBA) Any here are my proposals for FreeDOS (and other new DOSes): F0h Proposal: Alternative extended partition (CHS < 8,1 Gb) NOTE: This partition type must be expected to coexist with a type 05h, 0Fh, and/or C5h partition type! The default behaviour in this case is still subject to be discussed (see above), but it is not don't-care! F7h Proposal: Alternative SFN FAT12 (no VFAT LFNs allowed!) F8h Proposal: Alternative SFN FAT16 (<= 32 Mb) (no VFAT LFNs!) F9h Proposal: Alternative SFN FAT16B (BIGDOS > 32 Mb) (no VFAT LFNs!) FAh Proposal: Alternative SFN FAT32 (no VFAT LFNs!) FBh Proposal: Alternative SFN FAT16X (LBA) (no VFAT LFNs!) FCh Proposal: Alternative SFN FAT32X (LBA) (no VFAT LFNs!) While all these proposed partition IDs deal with existing filesystems or slight semantic variations of existing ones, I would finally like to announce that a new "generic" partition ID has been reserved for FreeDOS already: From recent correspondence with Andries Brouwer (of CWI), who also maintains a list of existing partition IDs and mentioned that he found another new ID (EDh for my Spryt*x project) listed by PowerQuest, I deduct that they most probably also list the following partition ID now, which I communicated to Bill Felt (of PowerQuest) on 2000-07-12: FDh Reserved for future use by FreeDOS NOTE: This might serve as an escape into a new partitioning scheme, an alternative low-footprint filesystem or be for other special purpose use (Details to be discussed with the FreeDOS developers). The background for this is that the current partitioning scheme with primary partitions and logical drives in extended partitions is reaching its limits, and at some stage soon it might be necessary to break out of the current concept, similar to Microsoft's approach: 42h Windows 2000 (Windows NT 5): Dynamic extended partition NOTE: The inner workings of this partition type are not yet known, however, Windows 2000 will hide and maintain a new kind of partitions behind this partition type. The configuration data for these partitions is stored at the very end of this partition??? or drive??? So much for today... I hope you enjoyed reading this and I appreciate as much feedback on this proposal as possible and would like to learn about your own ideas. Greetings, Matthias -- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany mailto:; mailto: http://www.uni-bonn.de/uzs180/mpdokeng.html; http://mpaul.drdos.org