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

 DE> What's wrong with the current logic? 

As previously discussed at length in this thread, the current logic fails to
correctly recognise and handle the case where there is more than one type 0x
partition in the primary MBR.  Notice the `found' variable, how it is set, and 
what its effect is, for example.  Compare this code with the code in DR-DOS,
FreeDOS, and linux that I gave pointers to in a previous message.

This may not be a common occurrence when OS/2 is installed onto a blank hard
disc, but given that every other PC operating system appears to support this
situation, and that Windows NT's Disk Administrator allows one to easily
create such configurations (which I suspect is another subtle method of
undermining OS/2, since I'm sure that Microsoft would be aware that OS/2 Warp
doesn't support this configuration), it is certainly one that OS2DASD.DMD
should support.

 DE> And - assuming you have both the tools and the sources available - why 
 DE> don't you just go ahead and try it yourself?

For three reasons:

        1.  I have no history, as far as the public at large is concerned, of
modifying base device drivers.  You have.  People trust you.  And if you don't 
want to do it, the second best choice would be Henk Kelder, who *already has*
produced modified OS2DASD.DMDs before now (to make it recognise type 0B and 0C 
partitions so that his FAT32 IFS driver works).

        2.  I actually *don't* have the source.  I only have what is on the
OS/2 Warp 4 DDK CD-ROM, which is the OS2DASD.DMD source prior to the
modifications made to support removable partitionable media.  Unfortunately,
Henk Kelder appears to be in the same boat, which is why you are the primary
choice, since you have appear to have access to later sources.

        3.  I already have a rather large project on the go right now.  I
don't have the time to invest in setting up and learning to use the arcane
16-bit tools and development environment necessary to build 16-bit OS/2 device 
drivers.  I strongly suspect that the people who are eagerly awaiting the
first release of my project would rather than I concentrated on with it rather 
than take on board yet *another* project, especially this one.  

I've done as much as I can by locating the root cause of the bug in
OS2DASD.DMD, the functions that are involved, and coming up with a general
outline of how it could be fixed.  It's now up to someone else to come along
and modify OS2DASD.DMD, recompile and release it, and take all of the credit
and glory.

 DE> Thinking about improving OS2DASD I'd rather like to support type 0F
 DE> extended partitions to remove the hassles of the MICROS~1
 DE> idiosyncrasies. 

Indeed.  That could very well be done along the way.  It's the same piece of
code that needs altering.  As I said: credit and glory.  Tempted yet ?  (-:

 DE> And, instead of changing the sources, finding a patch to do that is 
 DE> better IMHO because it most likely will work with future fixpacks as
well.

I disagree.  This isn't the sort of change that one can introduce by patching
a few small sequences of machine code.  One has to move a loop from one
function to a completely different one, change the logic of the loop somewhat
so that it doesn't terminate prematurely, and add a new parameter to be passed 
to a function (which involves both changing the two places where the function
is called and changing the internal logic of the function to use the parameter 
as an array index).  The underlying machine code will change significantly. 
This is the sort of patch that can only reasonably done by modifying the
source and recompiling.  One would spend weeks if not months if one approached 
it from the direction of modifying the object code directly.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
143/1