Great!
But,hmm, should I move this to the patches forum?
While not a direct patch, it might still fit better in there... thoughts?

Would be best to remove the links that reference usage of files that the op obviously does not own as well as references in the documentation to "archives". 🤣. Everyone knows what you mean, at least you didn't mention "abandonware"

You'd be better off scripting a method for a user to make the game they actually own an "archive" first than using exodos files, TDC or similar if this to be posted here or on the DOSBox sourceforge site.

The script makes assumptions on what is installed on the system which may not be true for all systems so that should be mentioned somewhere.

As far as "different versions of dosbox" as far as these forums are concerned for official support there is just 0.74-3 and earlier and SVN.

I don't see anything different than what a frontend could or should do so not sure what you expect from the official version of DOSBox unless you want DOSBox to offer a frontend or frontend-like functionality across all supported operating systems as well as using EXDOS , TDC or similar files as a reference which likely wouldn't go over well with publishers.

For mounting zip, 7z, etc there likely already is a feature request for it but would have to check.

For those that own the original games the likelyhood of them installing from original media or a backup, configuring the game, verifying the game, compressing the game, veryfying the game are likely minuscule but the feature would be useful for the few that would bother and for exodos and the like.

I also wonder how someone would differentiate between a zip that was intended for mounting and one that was not and how DOSBox would determine the difference without maintaining a database of hashes that dosbox would have to check. More than likely this would be left to the user to figure out similar to how they should know what the error means when they try to load a windows executable in DOSBox.

There is also the issue of poorly configured packages and DOSBox being blamed , of course if they came here they would be turned away for not using the copy of the game they should own.

DosFreak wrote on 2020-02-18, 22:22:

Would be best to remove the links that reference usage of files that the op obviously does not own as well as references in the documentation to "archives". 🤣. Everyone knows what you mean, at least you didn't mention "abandonware"

The reference was to the open-with-dosbox.7z archive.

DosFreak wrote on 2020-02-18, 22:22:

You'd be better off scripting a method for a user to make the game they actually own an "archive" first than using exodos files, TDC or similar if this to be posted here or on the DOSBox sourceforge site.

There is nothing special about zip files used in the demo, they remain unaltered. Any zip file should work.

DosFreak wrote on 2020-02-18, 22:22:

The script makes assumptions on what is installed on the system which may not be true for all systems so that should be mentioned somewhere.

Correct, it needs to be adjusted for your environment.

DosFreak wrote on 2020-02-18, 22:22:

As far as "different versions of dosbox" as far as these forums are concerned for official support there is just 0.74-3 and earlier and SVN.

Precisely the point 😁
The main reason behind this script was to switch between versions for reproducibility.
(overlay feature is not present in the 0.74-3, so this script is useless until this is implemented in 0.75?)

DosFreak wrote on 2020-02-18, 22:22:

I don't see anything different than what a frontend could or should do so not sure what you expect from the official version of DOSBox unless you want DOSBox to offer a frontend or frontend-like functionality across all supported operating systems as well as using EXDOS , TDC or similar files as a reference which likely wouldn't go over well with publishers.

For mounting zip, 7z, etc there likely already is a feature request for it but would have to check.

Correct, mounting support for zip files is what I had in mind.
Also containerization to separate game files and game state (setup/configuration, savegames)
Storing state files in a unique per game folder. ($HOME/.dosbox/gamedata/[game] )

DosFreak wrote on 2020-02-18, 22:22:

For those that own the original games the likelyhood of them installing from original media or a backup, configuring the game, verifying the game, compressing the game, veryfying the game are likely minuscule but the feature would be useful for the few that would bother and for exodos and the like.

If you zip up the game installation folder after you configure it properly there should be no difference.
Just be sure to mount any needed physical or virtual media. I think this would mostly be applicable to installers (disk/cd-rom). I could install eg: Warcraft 2+expansion and put in the required cd-rom(s) when asked.

DosFreak wrote on 2020-02-18, 22:22:

I also wonder how someone would differentiate between a zip that was intended for mounting and one that was not and how DOSBox would determine the difference without maintaining a database of hashes that dosbox would have to check. More than likely this would be left to the user to figure out similar to how they should know what the error means when they try to load a windows executable in DOSBox.

There is also the issue of poorly configured packages and DOSBox being blamed , of course if they came here they would be turned away for not using the copy of the game they should own.

There is nothing special about zip files used in the demo, they remain unaltered. (and do not contain a dosbox config). The basename is used to create a unique directory in $HOME/cache/dosbox/[game] and
$HOME/.dosbox/gamedata/[game]

$HOME/cache/dosbox/[game] is mounted as C drive (this is just the game unpacked, which only happens on firstrun or when you clear the cache folder)

$HOME/.dosbox/gamedata/[game] as the overlay on C drive and holds all changes (savegames,configurations) and the [game] specific dosbox configuration.

Lastly, the script has some options for clearing, editing config files and opening cache and overlay folders, as traversing through folders got cumbersome quickly.

If you have any other questions let me know.

Instead of a .zip file you could just use a FAT disk image, stored as a compressed file on a NTFS (or similar) volume.

Akuma wrote on 2020-02-19, 10:17:

mounting support for zip files is what I had in mind.

An experimental patch was made for it: PhysFS patch

I think some version of it is in the Daum build, but both Daum and the patch are more than a little out of date now. Also, I don't know how well it might co-exist with the more recent drive overlay feature, but it may just do its own thing for written config/save data.

jmarsh wrote on 2020-02-19, 10:37:

Instead of a .zip file you could just use a FAT disk image, stored as a compressed file on a NTFS (or similar) volume.

Sure, but its just not as convenient as zip.
Most people can create a zip, working with a disk image is just an extra obstacle.

Thanks for thinking along though 😁

ripsaw8080 wrote on 2020-02-19, 13:31:

Akuma wrote on 2020-02-19, 10:17:

mounting support for zip files is what I had in mind.

An experimental patch was made for it: PhysFS patch

I think some version of it is in the Daum build, but both Daum and the patch are more than a little out of date now. Also, I don't know how well it might co-exist with the more recent drive overlay feature, but it may just do its own thing for written config/save data.

Nice 😁

Dominus wrote on 2020-02-18, 20:12:

Great!
But,hmm, should I move this to the patches forum?
While not a direct patch, it might still fit better in there... thoughts?

Yeah, in retrospect this is probably (at this point) better off in the development forum.
But I leave that up to you.

New version with installer attached, read the .txt file on how to setup.