Could you add the minimal patches to support the maximum hdd images in dos

[i30817]

https://www.vogons.org/viewtopic.php?f=41&t=34642#p674876

These are the minimal (and very unlikely to get broken) patches to support the largest possible DOS size for hdd images, which upstream doesn't support because they decided to limit those ints to 32bits instead of 64bits for some reason.

The explanation of what the patches do is in the link but to repeat it, one changes the max size of a hdd mount by changing the bit size of a variable, the other changes the default autodetect of hdd mounts to support the max size possible for them if they were FAT16 (note, you can always not use the autodetect by specifying the geometry manually during mount, which is what i always do to be safe to defaults changes).

I said 'FAT16' because you can only mount FAT32 raw iirc (windows manages it, not dosbox shell, which can't read FAT32), so a FAT32 mount larger than the FAT16 max should always use the -size setting to be 'correct'.

What does this affect? Users will need to use C/255/63 (cylinders/headers/sectors) instead of C/16/63 when making their FAT16 images if they want to autodetect them. That patch can be skipped if that is unacceptable, since specifying the geometry manually is a good idea anyway.

Note: unlike the more complex patch to support larger images, these patches don't add imgmake or change the code more extensively. This means they should break a lot less (and i've noticed that on my ppa buildbot).

The disadvantage is that making the image is a more complex process for the users, but they needed to rawmount/fdisk the image anyway to use it with windows because i haven't found a 'simple' linux (or portable) command to create a FAT (16 or 32) formatted and fdisk'ed image ready to use from the host OS. And imgmake certainly doesn't.

mkfs.fat from the package dosfstools comes close but it doesn't appear to have a single liner to do it or a easy way to get the imgmount parameters.

What happens is that i create a non bootable image with dd with a weird calculation¹ and then keep the values used on that weird calculation to pass to imgmount -size with a raw drive letter² for windows to fdisk and then reboot with a normal drive letter³ without the -fs none (if fat 16, otherwise keep the raw mount). It's user unfriendly to say the least.

¹ dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]` (with C between 0-1023)

² imgmount 3 dsk.img -size 512,63,255,1023 -fs none (max size, 8.4 gb, so its going to be a FAT32 image after windows fdisk)

³ imgmount c dsk.img -size 512,63,8,731 (for if a fdisked fat16 image, i use this to hold windows 95 and be able to place files on the autostart dir from the dosbox shell)

[i30817]

Some irrelevant developments to this:

I've been trying to make a script that replaces imgmake with the extra features of being already formatted, mountable, bootable and cloneable (to shrink/increase the size of a image).

I've basically failed at the second. It's kind of weird, even using the 'non-free' version of ms-sys (which replicates the effect of 'sys c:' and 'fdisk /MBR' on a windows bootdisk) i can't make it work (and i tried the same with the native tools ofc).

Transferring files with clone, creating a new img that just needs a dosbox mount and keeping the windows attributes works though so the tool is already useful... just not for copying over the working Win95 OS and booting it.

It's very frustrating being so near and crashing and burning for ineffable reasons. I've been reduced to having the wikipedia fat page on one side and the vbindiff of the two images (the clone and the original working) and working through the at the fat16 filesystem offset to see the changes in the stucture. They all appear correct (with the ms-sys utility), so the problem is likely in what's pointed to, maybe the filesystem needs certain files to come at the first sectors...