INT 13h functions are supported for disk images, but the extensions you're looking at are not supported.

mike_canada wrote on 2021-07-26, 21:12:

And if you're thinking I should use file open functions, that won't work because then at the image creation end, I'll have to figure out how to inject the file into the image itself without causing filesystem corruption which I think would be a more difficult task.

Actually, that could be the easier thing to do. Rather than "inject" the file externally you would create it in advance. That way the file is stored at a known location within the image and you can externally modify the sector(s) that comprise it, allowing easy access with the DOS file open and read functions. If there is concern that the file can be of variable length, it should be possible to make the file as large as could ever be needed and simply mark the end of data with an EOF character or so, which is an old standard of DOS files.

ripsaw8080 wrote on 2021-07-27, 13:55:

INT 13h functions are supported for disk images, but the extensions you're looking at are not supported.

In that case, the interrupt call should have returned the carry flag being set instead of cleared when calling those extensions. But it didnt.

What about the basic INT 13 extensions such as Int 13h with AH=02h found here: http://www.ctyme.com/intr/rb-0607.htm

That way the file is stored at a known location within the image and you can externally modify the sector(s) that comprise it, allowing easy access with the DOS file open and read functions.

Can we work out some mathematical formula on this?

Perhaps I could make a giant base image, then inject the configuration into certain bytes of the image that equal valid file space and somehow update the FAT16 table so DOS recognizes the file as a valid uncorrupted file.

I make my images with mkfatimage16 (that comes with dosemu) emulator for Linux, and it sets the partition type to #4 (Fat 16 < 32MB)

mike_canada wrote on 2021-07-27, 21:53:

In that case, the interrupt call should have returned the carry flag being set instead of cleared when calling those extensions. But it didnt.

The carry flag IS set for unhandled functions of INT 13h, such as the function you inquired about; not sure how you came to a different conclusion.

mike_canada wrote on 2021-07-27, 21:53:

What about the basic INT 13 extensions such as Int 13h with AH=02h found here: http://www.ctyme.com/intr/rb-0607.htm

That's an essential function of INT 13h, not really an "extension", so it is indeed supported.

mike_canada wrote on 2021-07-27, 21:53:

Can we work out some mathematical formula on this?

Just search for the contents of the pre-created file within the image, then you know where it is located and can externally modify it in place. The directory entry and FAT chain for the pre-created file would already be established, no need to update them; you only need update the contents of the file.

Well mtools also exists, no need to reinvent the wheel if you don't want to 😁
I've successfully used it for syslinux floppy images but it probably can be used for hd images just as well.

mr.cat wrote on 2021-07-27, 23:41:

Well mtools also exists, no need to reinvent the wheel if you don't want to 😁
I've successfully used it for syslinux floppy images but it probably can be used for hd images just as well.

....except the target OS is 64-bit Windows (specifically Windows 10) But I have a 32-bit computer so I can only make 32-bit programs for that OS. I did use mtools for linux and its not bad for it.

dosbox-x should have more complete int13 support, if you want to give it a try.