Message-ID:	<008d01c0e897$6caa9c00$d208e289@mpaul>
From:	"Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To:	<fd-dev AT topica DOT com>
Cc:	<opendos AT delorie DOT com>
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
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
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 <opendos AT delorie DOT com>.
I think, however, the discussion is best placed in
the FreeDOS mailing list at <fd-dev AT topica DOT com>.]

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:<Matthias DOT Paul AT post DOT rwth-aachen DOT de>; mailto:<mpaul AT drdos DOT org>
http://www.uni-bonn.de/uzs180/mpdokeng.html; http://mpaul.drdos.org

- Raw text -