ady wrote:
Victor Chew wrote:
The HDD image is 50MB. FreeDOS + DOSAPPS takes up 13MB. There is no easy way to shrink down the HDD image (eg. to 20MB), or to enlarge it (eg. to 100MB), AFAIK, while maintaining structural consistency.
I'm sorry but, what do you mean with "structural consistency"? Just as we did with the floppy image, which is still 2880KB but with more free space than a typical one, we can use similar techniques now. I have several “uncommon” images, and I have no problems with them as long as they live as ram disks.
But before I get to the hdd image, I need to report my experience with it. I tested ubcd52a2 in a VM with several images connected simultaneously (as if I had more than one cd drive, plus one local HDD). Once in VC, I can see the additional drive letters, but I can't open their contents. This is while booting with isolinux menu. So, what I am doing wrong? I though that "each, any and all" drives would be seen now, but the behavior I see is the same as before. Could someone please point me in the right direction?
Additionally, I shall repeat a report about lower case. All the files in fdubcd must be upper case, including cab files and also their contents.
I'd appreciate some help about VC access to all drives, so I can really test the new fdubcd and report back.
Although there is still no comment to my question about getting access to additional drives, I want to comment on the new memdisk hdd c: drive.
The initial issue for me is that I still can't access more drives than what I was able before (so what's the point in changing it). The second issue is the "shift" on drive letters, that could easily confuse users (generating potential disasters, like wiping the wrong drive).
That leads me to my next question. If fdubcd is not going to be an ISO image (with the floppy image inside), why it has to be a hdd image (with an MBR)? A superfloppy image of about 42MB is capable of containing the current fdubcd, including all the files expanded too. MEMDISK should be capable of booting such superfloppy too, it would waste less space and it would not shift other hdd letters.
@Victor, if necessary, I can provide such empty floppy image, formatted with FAT16, together with the relevant memdisk parameters. It would need the content of fdubcd, patched to be used as (super)floppy instead of hdd. From a certain point of view, we would be going back to use fdubcd.img only, but bigger than 2880KB.
Evidently this only makes sense if someone can explain how (exactly) using a hdd (or fdd for that matter) for fdubcd is better than using the previous ISO image method.