Have you tried using parted? It seems that it can operate over files, so you could:
- Create a disk-image using dd (dd if=/dev/zero of=disk.img bs=4*17*512 count=617 should create a disk image of a 617 track, 4 heads and 17 sectors HDD).
- Use parted mklabel msdos to create a partition table.
- Use parted mkpart to create a partition.
- use parted set to set the boot flag.

Note that there are missing two important steps:
- I don't know if a bootable master boot record is placed when doing the mklabel part . If not, I guess you should use mbr.bin from syslinux-common package (but be careful to NOT truncate your newly created disk image).
- parted won't create a filesystem on your partition, so you'll have to make one. But keep in mind that your filesystem starts where your partition starts (on older systems, it used to be at the first track; on newer systems it is counted by Mb) so you'll have to skip some blocks.

mkfs.fat is not going to work correctly since when used with files (instead of devices) it just makes up the heads/sectors per track, which may be completely different from what you want/what the partition table uses (if you actually put one on the image before trying to add a partition/filesystem; if not, good luck booting it!).

Is providing premade images an option? AFAIR these empty images compress ver nicely...
But I get that scripting everything is better.

This is basically for simplifying the horrible 'readme' that appears when you install the ppa and for making the workflow easier. About 4/5ths of that are me getting lost in explaining how to create a imgfile and fdisk and formatting it with the windows native tools, to the point i forgot about how to explain linux mounting the disk to be able to transfer files (you have to skip the boot sectors).

A archive link with several 0 sized ready to use files in a zip would probably be simpler, but the scale between 'requires a simple 50 mb' and 'requires 5.5 gb (Black Dahlia) or 'requires the maximum 8,4 gb' (nothing yet) has a lot of fixed steps. A not so smart/cautious person that just unzipped the whole dir is setting themselves up for suffering.

There is the concept in linux of 'sparse file' which is a file where the zero ranges are not actually 'filled' in the filesystem (not all filesystems support it but all modern ones do). Zip does not appear to support it, but tar does - https://linuxgazette.net/174/misc/lg/compress … heir_holes.html

I guess what i should do instead is just create a git repo with a readme.mk just linking to a bunch of tgzs of single (already formatted and setup as 'd' ) image 'sparse' files on the range [20mb -8.4gb] and link it there and start writing about the more important process to install games in wine and transfer their files and registry entries to the img the user downloads.

Create equation to given a 'size' by the user calculate the cylinders it will have on the CHS [1-1023, 255, 63] scheme, then fallocate a bunch for a range of increments of 50mb for [50-500]mb then another bunch for increments of 500mb for [1, 8.4] gb and then painstakingly fdisk all of them, reboot and format them 'quick' and hope the 'sparseness' doesn't make them balloon... I may die if i try this. It would be 'tolerable' if i could use mkfs.fat and a script loop. But that goes right back to what jmarsh said of mkfs.fat not respecting the CHS. And if i could do this script, i could do a script in the package to create any size image file, so the git repo wouldn't even be needed.

It's unsettling this is not a solved problem already. Can i mount a sized image file as a block 'device' and use mkfs.fat on it to make it try to respect a CHS instead of assigning one it wants? Edit2: no.

edit: change the link to the correct one.

Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image at variable sizes or simply documenting the procedures in readme or writing up a scripts? Frankly, DOSBox disk image support has been leaving something to desire. QEMU comes with a number of handy tools to deal with disk images and support raw format that can be used by DOSBox. If you only care about Linux, then you can also consider qemu-nbd for mounting disk image with partition and manipulating the filesystems directly without any emulators. Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

My workflow looks like this:

• Create raw image with dd using precise CHS geometry
• Boot from Win98SE.ISO in QEMU with the disk image. Select MS-DOS with CDROM support.
• Inside QEMU, FDISK, reboot QEMU, FORMAT C: /S. XCOPY entire WIN98 folder from CD to disk image.
• On Linux, use parted/fdisk to remove LBA flag. On Windows, boot up a Linux VM on QEMU to do the same.
• Add the disk image to [autoexec] in dosbox.conf and boot it in DOSBox. Start Win98 installation with SETUP /pi /nm.

kjliew wrote on 2020-04-29, 20:08:

Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

MS-SYS to create the proper MBR.
http://ms-sys.sourceforge.net/

Write IO.SYS and MSDOS.SYS (in that order) to the filesystem.

kjliew wrote on 2020-04-29, 20:08:

Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image a […]
Show full quote

Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image at variable sizes or simply documenting the procedures in readme or writing up a scripts? Frankly, DOSBox disk image support has been leaving something to desire. QEMU comes with a number of handy tools to deal with disk images and support raw format that can be used by DOSBox. If you only care about Linux, then you can also consider qemu-nbd for mounting disk image with partition and manipulating the filesystems directly without any emulators. Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

My workflow looks like this:

• Create raw image with dd using precise CHS geometry
• Boot from Win98SE.ISO in QEMU with the disk image. Select MS-DOS with CDROM support.
• Inside QEMU, FDISK, reboot QEMU, FORMAT C: /S. XCOPY entire WIN98 folder from CD to disk image.
• On Linux, use parted/fdisk to remove LBA flag. On Windows, boot up a Linux VM on QEMU to do the same.
• Add the disk image to [autoexec] in dosbox.conf and boot it in DOSBox. Start Win98 installation with SETUP /pi /nm.

I want to avoid the need for the user to boot into windows9x, including to reboot after the format to create a harddrive. I don't necessarily want this to happen for OS install purposes, but it'd be a nice bonus (my-sys looks super useful for that), but the main aim is to create a script for given a number of mb create a drive already fdisked and formated with FAT16 or FAT32 with 1 partition, and output the geometry (for imgmount) and the command to mount it in linux (to copy over files while skipping the MBR), and the image would only vary in cylinders in [0-1023, 240, 63] CHS, and preferably be a sparse file.

The way i use images is to have the OS (FAT16) be separate from the game (FAT32), to share the OS (and manipulate the autostart from dosbox [autoexec]). I only switch the game drive and modify which game is being autostarted (well i also have a copy on write script for the game image and ramdisk the OS image but that is unnecessary detail).

So a bunch of confusing intructions, caculate the cylinders, dd, boot into windows, fdisk, reboot, format, mount drive in linux and copy over game go away and become 'only' the expanded version of the last:

'use script to create drive, mount it in linux with this command that skips the MBR, mount the dir as drive in wine, install game there in windows 95 mode, install whatever no-cd hacks the game has, find the registry entries of the game and export it, umount, mount in dosbox, boot, try game and if it doesn't work import registry entries'.

This is the most important to be able to use games since dosbox windows doesn't have support for external cds passthrough (mounted or with cdemu), and is more than enough work for a hapless user.