SvarCOM: LOCK and UNLOCK

[roytam1]

I wonder if SvarCOM can have LOCK and UNLOCK commands for MS(PC)-DOS 7?

4DOS implementation for reference: https://github.com/TritonDataCenter/sdcboot/blob/master/freedos/source/fourdos/doscmds.c#L644-L691 https://github.com/TritonDataCenter/sdcboot/blob/master/freedos/source/fourdos/doscmds.c#L1305-L1349

[mateuszviste]

I did not know about these commands until now. What is their usage value? I mean, what practical scenario do they fulfill? Also, is this lock/unlock API supported at all by the SvarDOS kernels (DOS-C and/or EDR-DOS)?

[roytam1]

I mean, what practical scenario do they fulfill?

in MS-DOS 7/8 and PC DOS 7.1, some disk operations are prohibited to prevent extra structures (for example, LFN and FAT32) being corrupted until it is LOCKed.

is this lock/unlock API supported at all by the SvarDOS kernels (DOS-C and/or EDR-DOS)?

EDR-DOS doesn't implement IOCTL 44,0D correctly: https://github.com/roytam1/edrdos/blob/master/DRDOS/IOCTL.A86#L253

in FDOS, it is a stub: https://github.com/FDOS/kernel/blob/master/kernel/ioctl.c#L208

[mateuszviste]

In the meantime I found the same ioctl.c code in FreeDOS as you did. And indeed, in DOS-C this is a no-op, while in EDR it's likely not doing what W95 does. Hence a shell command for this API is useless, as it won't work anyway.

RBIL suggests this is needed under Windows 95 to make the drives writeable because apparently Windows blocks direct I/O by default. This is not the case under SvarDOS/FreeDOS/EDR (and I assume that it is also not the case under MSDOS 7.x outside of Windows) because INT 0x13 is handled by the BIOS directly, without any protected-mode layer. If one would need a similar mechanism in plain DOS, I guess it should be done through some EMM386 extension of sorts.

[ecm-pushbx]

This is not the case under SvarDOS/FreeDOS/EDR (and I assume that it is also not the case under MSDOS 7.x outside of Windows) because INT 0x13 is handled by the BIOS directly,

The drive lock/unlock is implemented for MS-DOS 7.00 and 7.10, even without MSW loaded. The lock status is checked when writing to a drive using int 26h (or the int 21h service 7305h in MS-DOS 7.10). If it isn't locked, DOS will reset the int 9 handler IIRC and display a hang message.

Locking code as an example is in https://hg.pushbx.org/ecm/ldebug/file/4c58abd9b2af/source/ww.asm#l21

The MS-DOS kernel does not implement different lock levels; the lock status is saved as a single bit per drive. There are no services to retrieve the current lock status.

[mateuszviste]

The drive lock/unlock is implemented for MS-DOS 7.00 and 7.10, even without MSW loaded. The lock status is checked when writing to a drive using int 26h (or the int 21h service 7305h in MS-DOS 7.10). If it isn't locked, DOS will reset the int 9 handler IIRC and display a hang message.

Thank you for the extra context. So the RBIL is not entirely accurate when it mentions INT 0x13. Or maybe the INT 0x13 is an extra MSW limitation, and for plain MSDOS 7.x the locking API only impacts INT 26h. In both cases, it is not something handled by either DOS-C nor EDR.