The Microsoft MS-DOS 3.3 and 4.0 Programmer's References define bits 4, 8-10, 12, and 15 of INT 21h/AH=44h/AL=00h as reserved and require reserved bits to be zero. Those manuals define bits 11 (open/close support) and 13 (output-until-busy support) for their later DOS versions.
For M15's locked MS-DOS 3.0 target, the version condition matters: Microsoft Press, MS-DOS Encyclopedia, Section V, Function 44h (2.0 and later), lists device bits 8-13 as reserved except bit 14 (IOCTL capability); bits 4 and 15 are also reserved. The 3.3/4 definitions for bits 11 and 13 must not be imported into the DOS 3.0 contract.
The current source appears to expose internal driver/SFT attributes in API-reserved positions:
DeviceOpenSft copies driver attributes into the SFT while masking SFT_MASK (bits 5-6) and SFT_FSHARED.DosDevIOctl AL=00h returns flags & 0xff and ORs in s->sft_dev->dh_attr & 0xff00 for device handles.ATTR_FASTCON is defined as 0x0010 (API bit 4), and ATTR_CHAR is 0x8000 (API bit 15).
Thus the ordinary device-data query can propagate PC-88VA/internal driver attributes into positions that the selected DOS version reserves. The API result should be checked against the versioned DOS device-data word, rather than treated as the driver's attribute word. For M15's DOS 3.0 profile, bits 8-13 must remain zero while bit 14 retains its documented IOCTL meaning. If this path also targets later DOS versions, preserve their version-specific bit 11/13 meanings.
References:
Please confirm the intended versioned DOS-compatible result. If the exposed bits are an intentional extension, identify its versioned contract. Otherwise, please clarify whether the API should filter those driver attributes while preserving the documented device-data fields.
This report is based on public references and source at commit ac16c8a7401526f99787e03babdb2f4223d48fc4; it includes no private media, paths, traces, or runtime-derived values.
The Microsoft MS-DOS 3.3 and 4.0 Programmer's References define bits 4, 8-10, 12, and 15 of INT 21h/AH=44h/AL=00h as reserved and require reserved bits to be zero. Those manuals define bits 11 (open/close support) and 13 (output-until-busy support) for their later DOS versions.
For M15's locked MS-DOS 3.0 target, the version condition matters: Microsoft Press, MS-DOS Encyclopedia, Section V, Function 44h (2.0 and later), lists device bits 8-13 as reserved except bit 14 (IOCTL capability); bits 4 and 15 are also reserved. The 3.3/4 definitions for bits 11 and 13 must not be imported into the DOS 3.0 contract.
The current source appears to expose internal driver/SFT attributes in API-reserved positions:
DeviceOpenSftcopies driver attributes into the SFT while maskingSFT_MASK(bits 5-6) andSFT_FSHARED.DosDevIOctlAL=00h returnsflags & 0xffand ORs ins->sft_dev->dh_attr & 0xff00for device handles.ATTR_FASTCONis defined as0x0010(API bit 4), andATTR_CHARis0x8000(API bit 15).Thus the ordinary device-data query can propagate PC-88VA/internal driver attributes into positions that the selected DOS version reserves. The API result should be checked against the versioned DOS device-data word, rather than treated as the driver's attribute word. For M15's DOS 3.0 profile, bits 8-13 must remain zero while bit 14 retains its documented IOCTL meaning. If this path also targets later DOS versions, preserve their version-specific bit 11/13 meanings.
References:
DosDevIOctlat the pinned component revisionDeviceOpenSftat the pinned component revisionPlease confirm the intended versioned DOS-compatible result. If the exposed bits are an intentional extension, identify its versioned contract. Otherwise, please clarify whether the API should filter those driver attributes while preserving the documented device-data fields.
This report is based on public references and source at commit
ac16c8a7401526f99787e03babdb2f4223d48fc4; it includes no private media, paths, traces, or runtime-derived values.