Speaking of this i've tried to make a way to transfer windows 95 and 98 to a bigger or smaller disk (like certain universities are able to image a OS into a networked machine), but i've failed.

https://gist.github.com/99215a27097594d4e3f50bdc8f8fe8ad

I tried this, using the mtools package and parted, and i previously tried to use the 'non-free' version ms-sys tool (the commented part, of which i tried 2 variants, forcing it on the image file or forcing it on the first partition after mounting which requires sudo) to recreate the MBR, but nothing works.

Do you people have any idea how to work this, specifically clone a existing bootable win95/98 disk image into a larger or smaller new disk image? Normal drives ofc transfer fine with mtools using the trick of placing a 'custom config file' in a environment variable to mount the old image and the new image as mtools 'drives' and copying them over with permissions (this is needed because nuking the actual file is impolite and because there is no way to specify 2 hard disk images as source and destination in the mtools copy command otherwise, though there is a way for the destination hdd image).

I suspect the failure here is because the MBR or first sector must point to a specific hardcoded file or set of files which mtool mcopy doesn't allow to place precisely.

It's already useful, to transfer files to/into a smaller or larger disk image without using dosbox or windows fallible copy tools or using the native linux fat support (which doesn't preserve DOS attributes and requires root and skipping the MBR if any, which is complicated as heck), but it feels incomplete without the capability, though i might just bail out in bootable hard disks if it can't be made to work.

I'd also probably add the capability to copy over a linux dir into a new hard disk image, for the 'install in wine, run in dosbox' usecase to avoid all of the cases where the user has to understand how to natively mount a dosbox image even if i show how.

The script is linux only ofc.

I would probably have (tried) doing it this way with dosbox-x:

• imgmount c old-hdd.img
• imgmake new-hdd.img -t hd -size 32768
• imgmount d new-hdd.img
• xcopy c:. d: /I /S
• boot c:
• press F5 to go directly to DOS.
• sys c: d:

The new-hdd.img in this example would be 32GB in size and automatically use FAT32 because of it. imgmake and xcopy are included with dosbox-x.

And you "should" have a new bootable larger disk.

I tried that approach with the images produced by parted/mformat above. It didn't work. Also to be clear i want a approach that works completely outside dosbox/DOS/Windows and user interaction. Fire and forget and never do that stuff again, preferably without touching sudo. I've 'done it' (the mtools project did it) to non-bootable stuff but not bootable. Even tried to use your way (native OS) format to do the formatting instead of mformat, but didn't really make a difference (maybe it hanged on boot instead of the ms-sys 'didn't find the OS' message, can't quite recall).

Maybe because the windows install i used is one of those 'minimal installs', maybe it's at the cost of not being able to reuse the system files in different drive geometry.

Also ofc the geometry that results from that script is kind of weird. Always less than 1023 cylinders but the rest varies. Basically i depended on 'max sizes' (sectors) to make mformat make a partition that can be interpreted with CHS on mtools/windows. It seems to work without errors (easy to see because copy errors would happen) for the nonbootable disks.

You can script dosbox. Just give it a conf file with an [autoexec] section that does EXIT at the end. Or just use a ton 0f "-c command" options.

Only problem is that it causes the dosbox window to pop up for a moment. On Windows you can use --nogui to suppress it, but not on Linux unfortunately.

You can't script as soon as you require user input. In this case, that 'press f5'. And i'm not going to require something like autokey (not that it would work in wayland, which is my desktop, since its security doesn't allow control of user input iirc).

Besides, i tried the manual step as i said and it didn't work for unknown to me reasons. If you want to try it, switch the 'boot off' flag on the parted part of the script to 'boot on' and try to transfer a windows 95/98 image with the -c flag in the script, then do the sys c: d: thing by mounting both and booting the original in dosbox (or a bootdisk that works and the new). Since all files were copied by mcopy (including system files) and since mcopy preserves attributes, including the system bit, there is no need of that slow internal copy.

IIRC, the mbr wil be installed/overwritten but when the system tries to boot, there is a endless wait as if the system can't find the OS boot files.

Parted by the way would already have installed a mbr. IIRC, If i don't try to use sys c: d:, i get the parted 'can't find the operating system' message, so maybe the error is 'can't find the right OS file to boot windows in the first non-mbr sector' and it happens in all variants (parted mbr, ms-sys non-free mbr, windows 98 dosbox mbr transfer), just with slightly different behavior (endless wait, message).

Though this doesn't explain why even the windows 95 bootdisk sys a: c: doesn't work, since the diskette booted, but suddenly it can't boot the hd after copying the diskette files with sys? As i said, i don't understand it.

We should really take this to the dosbox-x thread. But with the latest dosbox-x release you can now run sys, fdisk and format directly from the integrated DOS. All you need to do is set the right dos version to match that of the sys/fdisk/format utilities. The only known issue at this point, is that you cannot format an image that is not already formatted (blank disk). As such you don't actually need the boot, press f5, sys steps, but can replace them with "set ver 7.1" and running "c:\windows\sys c: d:"