For a discussion of these types see: Introduction, Partition types.
it supports extendedX partitions (type 0F) and Linux extended partitions (type 8F, even more clueless and useless than the Microsoft invented type 0F !) exactly the same as regular extended partitions (type 05). ExtendedX partitions are common today because of disks larger than 8GiB.
It supports FAT32 partitions (type 0B and 0C) exactly as IFS partitions (type 07, used by HPFS and NTFS). This way FAT32 partitions show up in "correct" order (w.r.t. the disk layout), and are assigned drive letters "as expected". PARTFILT.FLT is no longer necessary to make FAT32 partitions accessable, but Henk Kelder's FAT32.IFS is still required.
It supports FAT16X partitions (type 0E) exactly as big FAT16 (type 06) partitions.
Parameter (the driver supports all parameter the OS2DASD.DMD supports, so take a look at the link too) :
Must be two digits hexadecimal. Supports up to eight additional partition types as specified by by the user. This is meant for making hidden partitions (types 1x) or foreign file systems like Linux's ext2 (type 83) visible to the DASD manager. You have to tell DaniDASD.DMD the additional partition types by means of the parameter.
To summarize the notion of acceptable partition types, have a look at this table:
DASD manager partition types supported extended regular OS2DASD (pre-LVM): 05 01, 04, 06, 07 OS2DASD (LVM): 05, 0F 01, 04, 06, 07, 35, [+ other] DaniDASD: 05, 0F, 8F 01, 04, 06, 07, 0B, 0C, 0E, [+ other]
If an additional partition type is a "hidden" partition (1x), then a matching partition is propagated to its "not-hidden" counterpart (0x) and the acceptance rules above apply.
Overwrites the boot drive letter assignment from fisrt boot stage. Can overcome boot problems which result in "can't operate hard disk" messages. This is common if OS/2 is booted without proper help of OS/2 Bootmanager which is required to notify OS/2 of the *correct* boot drive letter. If there is no boot manager with this capability available (e.g. when booting from removable media), or the boot manager fails to figure out the correct boot drive letter, you can tell DaniDASD.DMD the correct one by means of the parameter.
Example: in a mixed SCSI/EIDE environment with two SCSI adapters and and two different EIDE controllers involved (my current setup at home), the ATAPI ZIP250 drive gets assigned drive letter M:. To boot from this unit I have this line in CONFIG.SYS of the ZIP boot floppy
can create a logical volume map independently from the physical volumes (partitions).
CAUTION when this option is in effect, DaniDASD no longer follows the old OS2DASD rule of accepting only the first acceptable partition in the primary partition table. Instead, the LVM rule of accepting all acceptable primary partitions applies!
After scanning the *fixed* disks for acceptable partitions following the rules above, a logical volume mapping is created from these partitions. This is done by means of a map table. This table lists the partitions which are to be given a drive letter in ascending, consecutive order, starting from drive letter C:. A particular physical partition is indicated by a two-letter code number>. Code "Aa" indicates the first partition on the first disk, "Ab" the second partition on the same disk, "Bc" the third partition on the second disk, and so on. The numbering of disks and partitions is given by the regular scanning order of DaniDASD.
Each entry in the mapping table must be unique, entries without an existing partition are ignored.
creates logical volumes C:..F: from the indicated physical partitions.
CAUTION this does *not* apply to removable media units! Their driveletters *always* follow the fixed disk ones.
NOTE DANIDASD.DMD does not work with OS2LVM.DMD, so use it in NON-LVM Systems only.
NOTE Together with DANIDASD.DMD the use of PARTFILT.FLT is no longer necessary to access FAT32 drives.
TIP You may also need a FAT32 aware FDISK.EXE. It was included in FP10 - FP14 for Warp4
TIP By Daniela Engert: You want to get rid of the LVM layer in WSeB/ACP/MCP/eCS ? I checked that on an old WSeB installation with only compatibility volumes, yesterday. I removed these two lines in CONFIG.SYS
BASEDEV=OS2DASD.DMD // the LVM-aware DASD manager BASEDEV=OS2LVM.DMD // the LVM layer
and added this single line
BASEDEV=DaniDASD.DMD // the non-LVM-aware DASD manager
The system behaved DASD wise like an ordinary Warp4 system afterwards. A Warp 4 OS2DASD.DMD will do as well.
|OS/2 2.x||OS/2 3.0||OS/2 4.0||OS/2 4.5x|