JDBP>> I suspect that we might be begging Daniela to modify
 JDBP>> Build_Next_VolCB() and Process_Partition() in OS2DASD.DMD .  (-:  

 MR> [...] But I still don't see why it should be done. [...]

The simplest reason is compatibility.  Windows NT, linux, OpenDOS (a.k.a.
DR-DOS), FreeDOS, and at least one other operating system can all recognise
(and assign drive letters to) multiple visible (type 0X) primary partitions. 
In this respect, OS/2 Warp is less flexible than these other five operating
systems.

If it were just FreeDOS, say, that did this, one might argue that OS/2 need
not be compatible with something that is clearly non-standard and specific to
a minority operating system.  But the fact that mainstream commercial
operating systems such as DR-DOS and Windows NT *also* work this way tends to
indicate that it is OS/2 Warp that is non-standard here.

Indeed, based upon the fact that DR-DOS and Windows NT both work this way, and 
the fact that originally PC/MS-DOS didn't support extended partitions and
*everything* had to be a primary partition, there are strong grounds for
believing that MS/PC-DOS *also* accepts and recognises multiple visible
primary partitions.  It certainly would have had to do so in the past, before
extended partitions were invented and people with large hard discs had to use
multiple visible primary partitions to cover discs larger than 32MeB.  I
didn't include PC-DOS and MS-DOS in the list *only* because I don't have hard
evidence, either from experimentation or from inspection of the source code,
that it does support this.  I suspect that PC-DOS and MS-DOS probably should
be included in the list.  This would make OS/2 Warp almost the only operating
system that didn't support this feature, with all of the mainstream commercial 
PC operating systems in the other camp.

It's certainly the logical thing to do.  If I were writing an operating
system, it would be how I would scan and process the partition table in my
code.  The primary MBR frequently has more than one non-zero entry in its
partition table, often more than two non-zero entries.  Having multiple
entries is in no way unusual.  There's really no reason why code that
processes it *should* stop at any point short of examining all four entries in 
the table.  (It is only by convention that secondary MBRs have only two
non-zero entries.  For maximum compatibility one would examine all four
entries in secondary MBRs, too.)

I think that there's actually a very strong case for this being a bug in
OS2DASD.DMD that should be fixed.

Daniela ?

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
114/477
143/1