First post, by naerbnic
Since a very common usage of DOSBox is to run games, it would make sense to package up games into an easily loadable and configurable format. Perhaps I've not figured out the trick of doing this, but let me get the idea out anyway.
Idea: Create a new package "format" for DOSbox which will easily let users load DOS applications through a single command-line call, or through a simple GUI interface
Mechanics: The package format I have in mind is trivial, and would easily be able to work with the existing DOSbox code.
Create a directory with a name "<appname>.dosbox". For the purposes of this example, we'll use game.dosbox as the directory name. This directory will then contain the following tree:
game.dosbox/
--> configs/
----> default.ini
----> install.ini
----> (etc.)
--> data/
----> (any data the package maker wants)
The .ini files will be standard DOSbox config files. DOSbox can now be called with the command line "DOSbox game.dosbox". When this happens, here is the sequence of operations it performs:
- It sets "data/" as the default working directory, which commands like "mount" can use implicitly (e.g. "mount c foo" will mount the directory game.dosbox/data/foo/ as C: ).
- It loads "configs/default.ini" as per the normal DOSbox config file loader, including any autoconf.bat instructions.
Other config files can be loaded using the syntax "DOSbox game.dosbox <cfgname>". In this case, it looks for "configs/<cfgname>.ini" instead, and runs DOSbox with that.
Some reasons why this is a good idea:
- Allows for games to be individually packaged, and relocatable on a filesystem.
- Gives users a potentially platform-independent way of wrapping their games, minimizing the difficulty of moving it to other computers
- Attaches configuration options (such as memory usage, sound card configurations, etc.) to the particular game, instead of all games, depending on what is actually necessary
- Can potentially give dosbox.com a standard way of providing configurations for particular games, providing the configurations as part of the compatibility table to make individual games run as well as possible
- Simplifies the work for dosbox frontends, and potentially provides a more consistent method of operation for the multitude of existing frontends.
Naturally, this is the simplest version of this idea, and there are a number of possible extensions, of which I'll list some here:
- Include a metadata file inside of the root for purposes of frontends, to allow them to give information such as title, developer, publisher, release date, etc.
- Instead of a directory structure, use an existing packaging format (e.g. zip) to keep the contents of the directory inside a single file. On many platforms, with the addition of shell-level configurations, this should make DOS games double-clickable.
- Create an associated file format which can be copied and distributed without any copyright issues, which provide configurations and instructions to "bake" a particular game into a full package if the user provides their own disk images for the game. This will provide a more user-friendly way of setting a game up without running afoul of copyright laws (if that is ultimately an issue)
- Allow a disk image to be read only, implementing a union file-system on top of the ones mounted as part of the image. These could automatically be placed in a users home directory. This prevents the packages from collecting cruft, and potentially allows them to have the advantage of any other read-only format (e.g. using a CRC or hash to assure that you've created an image correctly)
I'm willing to work on the basics if I can get a few yay's for the idea. Anyone out there like this? Know any reason I shouldn't do this? Is someone working on something similar?
"So...what's it like to be a turtle?"
"It's a lot like being a walking house that eats lettuce."
- naerbnic
