ML> See a recent post from JdeBP to me for an explanation of how this
 ML> may be done.  I assume that he agrees with me that it is very poor
 ML> practice to play this game.  In any case, "someone else" was not
 ML> running OS/2 Boot Manager :-).  According to a post to Linda from
 ML> John Thompson, recent versions of Windows can also see all primary
 ML> partitions.  (He doesn't know whether this is "a good thing,"
 ML> either.)  But there goes Microsoft again, making up its own rules as
 ML> it goes along :-).

Let me put it this way: I can see no valid reason, from what has been posted
so far, to use the scheme that Linda's guru has used.

However, I should point out, in all fairness, that Microsoft *isn't* making up 
the rules as it goes along and changing the goalposts with new releases of
Windows, at least not in this case.  This particular rule has a very long
pedigree.

As you will no doubt remember, Murray, back in the mists of time, MS/PC-DOS
didn't actually support extended partitions originally.  There was no such
thing as primary partitions.  They were just "partitions", and there was a
maximum of four of them.  And they could only hold up to 32MeB each.  So if
one was rich enough to have a hard disc bigger than 32MeB, one had to have a
second, third, or even a fourth "visible" partition.  The idea of having an
"extended partition", type 05, came along when this scheme proved to be
inadequate.  

The whole notion of extended partitions is an ugly kludge, and also somewhat
wasteful of disc space since because of cylinder alignment requirements the
secondary MBRs that form the linked list of partition "subtables" waste a
whole track each.  It's certainly *not* how one would design a hard disc
partitioning scheme if one were designing it from scratch (rather than trying
to retrofit something decent on top of the old "four partitions" scheme and
retain backwards compatibility).

Given this, I suspect that the concept of having four *visible* (/i.e./ type
0X) primary partitions is a very old one in the DOS world.  It would certainly 
explain why almost all PC operating systems, apart from OS/2, support it.

I still would like to see Daniela Engert, or someone else with a history of
mucking about with the DASD drivers in OS/2 (such as the developer of the
FAT32 installable filesystem driver), fix this problem in OS2DASD.DMD .

 ¯ JdeBP ®

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