Custom Query (69 matches)

I have signals handler set up for some cleanup procedures in FORMAT/SYS/CHKDSK, like remounting the disk, but if I interrupt CHKDSK by Ctrl-Break, I see

^C
External process cancelled by a Ctrl+Break or another process

This is when running from UFAT32.DLL. But if I run the standalone version of CHKDSK, I get:

Signal 4 was received

and it cleanly remounts disk. In UFAT32.DLL case, we have disk in intermediary state (mounted in MOUNT_ACCEPT mode).

The cause, as I suspect, is that CHKDSK is a 32-bit program and sets up 32-bit exception handler, but CHKDSK routine is a 16-bit wrapper around a 32-bit "chkdsk" routine. So, we indeed run 16-bit routine, but an exception handler is 32-bit. This seems to be inconsistent, and thus, the 32-bit exception handler doesn't activate. So, we need a solution for this problem.

We now run into a problem that due other developments to be able to boot from a FAT32 drive. All is working ok till the volume is in dirty state, unlike hpfs, jfs, and others the fat32.ifs driver wont run chkdsk to have a clean state after it. The job to run chkdsk is made by the cachef32 later in the boot process, however in this stage it will run into a "SYS0108 drive is locked by another process" ... so there is no way to have a clean drive in this situation. chkdsk handling needs to be moved to the ifs driver.

The installer replaces (manually) upper-cased lines in x:\CONFIG.SYS by lower-cased lines. Perhaps upper-case the entries, and use a case-insensitive search.

Maybe the installer can aldo detect there's a second copy of UFAT32.DLL in x\ECS\DLL or ArcaOS'es equivalent. As a warning. Or, rather, detect the OS and use the matching DLL directory. There may be sample code in installers of fonts.