I have today experimented with my proposed linux approach of using dd to create a smaller image. Works as intended.
I could create a 17MB image
Then I sysed it and copied the current fdubcd.img-content into that filesystem. Works with mounting from Linux or using a VM with another os. This now shouldn't be booted in the VM just to test it, because the current DOS-boot process of fdubcd will rename the label of that disk-image to RAMDISK and actually write it's whole ramdisk to that disk - which will make it unusable as of the next boot!
As it is done during runtime when this image is loaded the way it currently is (via syslinux, memdisk, etc). So I think there is a behaviour not actually writing to a ramdisk but using the hdd-image as writable image! I do not think that this is really a step forward. DOS should use a "real" ramdisk and leave the boot-image untouched. However, with this behaviour it makes absolutely no sense to shrink the image because then you soon run out of memory. I tried to boot that 17MB image via syslinux and memdisk and it works as the original. Only loading a program like savepart doesn't work, because the disk is too small!
However I am almost sure, that it must be possible to get back to that ramdisk with untouched boot-image, at least I personally would definitely recommend that, no matter if the image is an iso or a hdd-image.
I could create a 17MB image
Code:
dd if=/dev/zero of=my_hdd.img bs=1M count=17
which was partitioned and formated to FAT16 by the current FreeDOS-CD in a VM (qemu) - a 16MB image would have been formated FAT12 and I didn't check how to pass by that fdisk-automatism, since the original is FAT16 anyway. Then I sysed it and copied the current fdubcd.img-content into that filesystem. Works with mounting from Linux or using a VM with another os. This now shouldn't be booted in the VM just to test it, because the current DOS-boot process of fdubcd will rename the label of that disk-image to RAMDISK and actually write it's whole ramdisk to that disk - which will make it unusable as of the next boot!
As it is done during runtime when this image is loaded the way it currently is (via syslinux, memdisk, etc). So I think there is a behaviour not actually writing to a ramdisk but using the hdd-image as writable image! I do not think that this is really a step forward. DOS should use a "real" ramdisk and leave the boot-image untouched. However, with this behaviour it makes absolutely no sense to shrink the image because then you soon run out of memory. I tried to boot that 17MB image via syslinux and memdisk and it works as the original. Only loading a program like savepart doesn't work, because the disk is too small!
However I am almost sure, that it must be possible to get back to that ramdisk with untouched boot-image, at least I personally would definitely recommend that, no matter if the image is an iso or a hdd-image.