RGB Classic Games Forum

Hi all,

I have just put a proposal online for a DOS game package file format, intended to be used for easier distribution of DOS games.

In short, the idea is to .zip up the game's data files along with icons, screenshots, descriptions and other metadata into a single file which can then be loaded directly by an emulator such as DOSBox. The proposal specifies a standard folder structure and file formats to make these packages useful beyond the emulator, by providing information suitable for game collectors to automatically file and categorise each game in their collection.

I would like to ask interested people here to have a read of the proposal and provide any feedback they can, before I put it to the DOSBox developers as an official proposal (which I will probably write myself and submit as a patch, if they have nothing against the idea.)

To give a bit of background, I have had a few requests from people at the KeenWiki to make Keen mods playable online in a browser using em-dosbox. Getting the data files into the Javascript version of DOSBox is somewhat fiddly at the moment, so being able to supply a game package would fix this problem nicely. It would also allow mods to be more easily downloaded, and if any DOSBox front-end authors are so inclined, they could import these new packages and make use of the screenshots, icons and box art contained within. Of course the idea is that DOSBox will be able to load them directly too, without needing a front-end. (I'm thinking along the lines of being able to download a package file and then just double-click on it to play the game, no further installation needed.)

Anyway, all the details are available at the above link, so please have a read of it if you can and let me know what you think. I am most interested in whether you can think of any games that would not work with the proposal in its current state, or would need changes made in order to work properly. I would like to ensure it works with as many games as possible. I'm also interested in whether you think any additional metadata should be included as I feel that part of the proposal does need a little more thought.

Many thanks!

I very certainly like this idea! Your proposal is quite well thought out, and I think it can work very well if it becomes a standard.

However as someone who picked - right here at RGB Classic Games Forum - a kind of obsession with original unmodified shareware/demo/freeware distributions, I'd like to ask: if a particular game comes with an installer, will it be included with the master copy, or will the .dos format replace the original installer? Similarly, if we have a downloadable ZIP archive, will it be included inside the .dos in its entirety or just the files? What about commercial games which were distributed on physical media? Does a .dos distribution preferably include an image of respective media or plain files?

Jesus Christ! Looking at the long list of requirements is tiring. I only got like a quarter way down when I could not read any further. DOSBox is complex enough the way it is.

However one point in favor of your proposed update is that it would potentially make it easy for the end-user. The over-head is put on the programmer and distributor.

I personally like DOSBox 0.74 right now the way it is. However it should be backwards compatible if updates are made. At least have previous versions accessible so that those who want to use the old version could go back and download version 0.74 or whatnot.

MrFlibble wrote:However as someone who picked - right here at RGB Classic Games Forum - a kind of obsession with original unmodified shareware/demo/freeware distributions, I'd like to ask: if a particular game comes with an installer, will it be included with the master copy, or will the .dos format replace the original installer? Similarly, if we have a downloadable ZIP archive, will it be included inside the .dos in its entirety or just the files? What about commercial games which were distributed on physical media? Does a .dos distribution preferably include an image of respective media or plain files?

Glad to hear you like the idea! I am very familiar with your worthy "obsession" and thought long and hard about this when developing the format.

I unfortunately came to the conclusion that this format should not aim to preserve the original state of the game, but it should target a "ready-to-play" configuration (even having config files pre-set so a newly downloaded game can be played immediately.) Because this means a game will have to be repackaged and config files modified for DOSBox to run it, I chose not to target preservation and focus on playability instead. (See the third point the FAQ section.)

My reasoning is that the package format is unlikely to become popular with gamers if you have to run a DOS-based installer for every new game you download. However I must admit, I did not think of including other original .zip and .exe files within the .dos package separately to the playable version of the game.

Since the proposed .dos package is just a .zip file, there would be nothing stopping you from including other files in with it, such as the original installer. If you can come up with a way that this could be made part of the standard, I would be more than happy to include it. This would be a better way of doing things, I just couldn't think of a really nice way to do it. Ideally you'd want to describe it somehow so that a DOSBox frontend could list what was available inside the .dos package, and give you the option of extracting the installer to run it yourself separately.

@MrFlibble: Perhaps as someone with preservation experience, and especially knowing what other people such as yourself would want out of it, you can give me some ideas about how you would want original installers included in the package, and how you would want to list and access them later?

On a related note, I am actually considering - should this standard be accepted - of creating a website where you can upload DOS games and then turn them into packages using a wiki-style interface. So you would see a list of game files, you could change their last-modified times if they are wrong, change package data (categories, credits, screenshots, etc), view the history to see who changed what, just like a wiki. After any change the site will then package up the game with the latest changes into the proposed .dos format suitable for download, or even to play in the browser with em-dosbox. This would provide a 'curated collection' of games, where everything is as correct and (if we can work out how to include original installers) complete as possible thanks to the collaborative effort of those involved.

developertn wrote:However it should be backwards compatible if updates are made. At least have previous versions accessible so that those who want to use the old version could go back and download version 0.74 or whatnot.

Last time I proposed this idea I got some similar reactions, which is the reason for the first FAQ point:

Q: I don't want to have to repackage all my games into .dos files, I like things the way they are!
A: That's great, then nothing will change for you and this proposal won't affect you in any way.

Guess I should put the FAQ first

Malvineous wrote:@MrFlibble: Perhaps as someone with preservation experience, and especially knowing what other people such as yourself would want out of it, you can give me some ideas about how you would want original installers included in the package, and how you would want to list and access them later?

Well, provided that I understood your format suggestions correctly, my idea was that if we have an authentic ZIP archive or an installer, it can be just put into the *.dos file as it is. Because you propose the *.dos file to be "a read-only master copy of the game", and the game needs to be installed locally in order to be played (more on this below), then why not just have DOSBox perform the installation by unzipping the contents from that original ZIP? Even if there's an installer packaged inside a ZIP file (as is the case with Apogee/3D Realms shareware games for example), this can be handled by first unpacking the installer into a temporary folder and then running it. A copy of the Info-ZIP unzip utility can be included with the *.dos file to allow for unpacking archives right within DOSBox.

Certainly this method may make the installation a bit longer, however I guess not by much by modern standards. In case of installer routines that take up a lot of time and/or require the user to configure the game during the installation, I guess a pre-installed copy of the game could be included alongside the installer. The users would then choose at their own option to either use the original installer or get a pre-installed copy right away.

In fact, I think the handling of these operations (expect for the frontend that makes the contents of a *.dos file available to DOSBox I suppose) can be entirely managed via batch files that run inside DOSBox.

I just re-read your proposal and now I understand that I wrongly assumed the game would be installed locally from the read-only *.dos package, as you propose to simply store all files that the game might create or modify into a separate *.sav module.

However, it seems simpler to me to just have local installations of the games. That should not strain any modern machine by much, and will allow to handle original distributions in the manner that I described above.

Moreover, I think that some games might not work properly (if at all) if the game data or executable files are in the read-only state, even if such files are not actually modified when the game is being run. I'm not 100% sure on that but I remember having problems with read-only flags on data files (although this might have been something that was (not) working outside DOSBox).

If the local installation method is used, setting up the game would be as easy as creating this local copy (from either pre-installed files or the original installer routine) and copying into the local game folder a pre-set configuration file(s) that is already supplied with the *.dos distribution and is tailored to the intended DOSBox configuration. If there's a need to reset the game to the factory default state, then a simple batch file can clean up any extra files like saved games and copy the game files from the *.dos distribution anew.

I'm not sure if DOSBox can actually treat a ZIP archive as a disk image. However if *.dos files were indeed ISO images then this system would not even need any external software to work with DOSBox in its current state, as a batch file with all the necessary commands would be sufficient. WinRAR and 7-Zip can view ISO images as archives, thus making it possible for the users or collection curators to access all the data in the distribution without extra effort.

Malvineous wrote:On a related note, I am actually considering - should this standard be accepted - of creating a website where you can upload DOS games and then turn them into packages using a wiki-style interface. So you would see a list of game files, you could change their last-modified times if they are wrong, change package data (categories, credits, screenshots, etc), view the history to see who changed what, just like a wiki. After any change the site will then package up the game with the latest changes into the proposed .dos format suitable for download, or even to play in the browser with em-dosbox. This would provide a 'curated collection' of games, where everything is as correct and (if we can work out how to include original installers) complete as possible thanks to the collaborative effort of those involved.

That sounds like a neat idea as well, although I guess it would be preferable if most of the games converted into this format would be error-free from the start and did not require subsequent corrections from multiple users. I believe such work should be carried out by a more or less tight group of experts and not open to multiple user editing unless absolutely necessary.

Many thanks for your detailed comments!

MrFlibble wrote:Because you propose the *.dos file to be "a read-only master copy of the game", and the game needs to be installed locally in order to be played (more on this below), then why not just have DOSBox perform the installation by unzipping the contents from that original ZIP?

The problem is, this format should be usable on more than just desktop PCs. It should work on phones, tablets, and especially in the browser. I think you would get a lot of complaints from site visitors if you go to a page that says "Play this game in your browser!" and it only comes up with an installer asking you where you want to install it. Then Windows users could rightly assume the game was installed on their real C: drive (not the emulated DOS one) and complain that the installer doesn't work because they can't find the game on their real C: drive, or that they are trying to install the game on their D: drive and the installer says it can't find drive D...

MrFlibble wrote:Even if there's an installer packaged inside a ZIP file (as is the case with Apogee/3D Realms shareware games for example), this can be handled by first unpacking the installer into a temporary folder and then running it. A copy of the Info-ZIP unzip utility can be included with the *.dos file to allow for unpacking archives right within DOSBox.

I am hoping to avoid including external programs in the .dos file, because if you have a collection of a few thousand games, you'll end up with lots of duplicate data if every single .dos file has an unzip utility inside it. If this was the way to go, it would be better to include an unzip utility within DOSBox and make it accessible from the internal Z: drive.

MrFlibble wrote:In case of installer routines that take up a lot of time and/or require the user to configure the game during the installation, I guess a pre-installed copy of the game could be included alongside the installer. The users would then choose at their own option to either use the original installer or get a pre-installed copy right away.

I think it would be best to do this for all games, not just ones deemed to take a long time to install. For all games you can choose to run the game or run the installer. But then if you run the installer from the .dos package directly, the emulated C: drive will be inside the .dos package, so where do you install the game to? I think if you were to run the installer, you'd have to unzip the .dos package and run the install file yourself?

MrFlibble wrote:However, it seems simpler to me to just have local installations of the games. That should not strain any modern machine by much, and will allow to handle original distributions in the manner that I described above.

The problem with this is how do you handle the .dos package being run within a web browser using em-dosbox, the Javascript port of DOSBox? You can't install locally because you don't have (or want) access to the local disk. Having users run installers inside a browser is going to get in the way.

MrFlibble wrote:Moreover, I think that some games might not work properly (if at all) if the game data or executable files are in the read-only state, even if such files are not actually modified when the game is being run. I'm not 100% sure on that but I remember having problems with read-only flags on data files (although this might have been something that was (not) working outside DOSBox).

As far as the game is concerned, nothing will be read only. Every file can be modified, but doing so would cause DOSBox to put the modifications in the .sav file. Saying the .dos file is read-only is just to make it clear that DOSBox won't modify it - it doesn't have to have any read-only attributes set.

MrFlibble wrote:If the local installation method is used, setting up the game would be as easy as creating this local copy (from either pre-installed files or the original installer routine) and copying into the local game folder a pre-set configuration file(s) that is already supplied with the *.dos distribution and is tailored to the intended DOSBox configuration.

The problem is that this isn't actually that easy for many people. For archivists and people who grew up with DOS sure, but for everyone else it's too complicated. That's why one goal with the proposed .dos package is to make it as simple as a .pdf file. You don't need to install a .pdf file to view it, you just click on a link in the browser, or save it on your desktop and double-click on it. I think a .dos package needs to work in the same way by default, to cater for the majority of people who don't care about the technicalities and just want to play the game immediately.

MrFlibble wrote:I'm not sure if DOSBox can actually treat a ZIP archive as a disk image. However if *.dos files were indeed ISO images then this system would not even need any external software to work with DOSBox in its current state, as a batch file with all the necessary commands would be sufficient. WinRAR and 7-Zip can view ISO images as archives, thus making it possible for the users or collection curators to access all the data in the distribution without extra effort.

No, DOSBox can't read .zip files at the moment, so that's something I would have to add. Good point about using ISO images, but that would still need extensive modification as games really would have read-only files if they were running from an emulated CD drive. I think this would probably work for quite a few games (many Apogee games even respect the APOGEECD environment variable to allow saved games to be stored in different locations) but the problem is things like booter games and overlays for running modified games.

MrFlibble wrote:

Malvineous wrote:On a related note, I am actually considering - should this standard be accepted - of creating a website where you can upload DOS games and then turn them into packages using a wiki-style interface.

That sounds like a neat idea as well, although I guess it would be preferable if most of the games converted into this format would be error-free from the start and did not require subsequent corrections from multiple users. I believe such work should be carried out by a more or less tight group of experts and not open to multiple user editing unless absolutely necessary.

A close-knit group would produce the most accurate results, but there are very few people willing to do the work, and many, many DOS games. The proposal includes a revision number in the .dos package, so it would be easy to download newer packages if there are changes. The wiki structure would allow you to revert unwanted changes and perhaps even review changes from new users before they are trusted to make changes on their own. As you can see from projects like Wikipedia, the more people you have involved, the greater the result! I still think a wiki style would work best, but you are right that you would have to be careful about who can make what changes or you would end up with rubbish.

Jesus Christ!hehe

Just a suggestion, right now there seems to be an attempt to keep it broad and to reach as many people as possible. I believe this is a mistake since you want to develop a quality product first. If your product is of high quality then people will come. That is my opinion. However right now you are concentrating on the masses.

Actually let me revise that statement and say that if you tailor it to your audience then it will be more productive than if you mass market it.

It is getting complex. For instance, I personally like WinRAR however people tend to go to ZIP because it is free. RAR formats are rare even though the program that produces RAR is very powerful. Not many people are willing to pay $30 for a program when they are starving.

In other words, people only have so many hours a day to devote to an activity. If you spend your only dollar bill on the starving people then you will get your reward that others will also help you out when you are starving. So be careful what you invest in. Try to make it something that is important.

The problem with something like this is that if you only target a small number of people, you won't get the developer support you need to make it happen. Given that it is possible to support more people by doing some more planning, I believe it is worth it to do more planning up front, then make a better quality product as you suggest. Believe it or not, I am actually concentrating on quality rather than the masses

Both RAR and ZIP are free formats and always have been. WinRAR came along many years after the RAR format was designed and they offered a program that made it easy to use the free RAR format, just like you can pay money for WinZIP to use the ZIP format, but you don't have to if you can't afford it. There are many free programs that work with both RAR and ZIP, so you don't have to pay money to use either formats. People generally choose ZIP over RAR for its widespread support. Every operating system can open ZIP files with no extra software installed, yet if you have a RAR file you need to install a program, either WinRAR or a completely free alternative. In the past when disk space was a premium, RAR was often used because it produced smaller files than ZIP, but these days the difference is small enough that most people just stick with ZIP because it's less hassle for sharing files, especially in a business environment. For those people who do worry about file size, 7-Zip seems to offer better compression than RAR today, and it's also free. This is probably why you don't see RAR much any more.

Malvineous wrote:

MrFlibble wrote:Because you propose the *.dos file to be "a read-only master copy of the game", and the game needs to be installed locally in order to be played (more on this below), then why not just have DOSBox perform the installation by unzipping the contents from that original ZIP?

The problem is, this format should be usable on more than just desktop PCs. It should work on phones, tablets, and especially in the browser. I think you would get a lot of complaints from site visitors if you go to a page that says "Play this game in your browser!" and it only comes up with an installer asking you where you want to install it. Then Windows users could rightly assume the game was installed on their real C: drive (not the emulated DOS one) and complain that the installer doesn't work because they can't find the game on their real C: drive, or that they are trying to install the game on their D: drive and the installer says it can't find drive D...

Frankly I did not think about handhelds and browser-based playing options. I am entirely unfamiliar with how handheld devices work, but I would assume they require some kind of installation as well? Even without a "full" local installation the *.sav file would need to be stored somewhere, right?

BTW, how is this *.sav thing going to work? Will it require modifying the original game? To the best of my knowledge, many DOS games just expect the configuration and/or save game files to be in the same directory as where the game itself is installed. I guess it might be possible in DOSBox to somehow make the game believe that two different locations are in fact one and the same, but I would like to know the actual mechanics you propose (I haven't found an explanation in your document).

As for sites offering to play in your browser, I thought that the games have to be pre-configured somehow by the site administrators before play? So they would go through the installation process before the players access the game?

At any rate, the only solution that would allow a compromise would probably be either (a) to include both the original file and the pre-installed copy, or (b) just run a parallel archival process wherein original distributions are preserved in their unmodified state and derivative *.dos "ready-to-play" packages are produced from such distributions.

Malvineous wrote:I am hoping to avoid including external programs in the .dos file, because if you have a collection of a few thousand games, you'll end up with lots of duplicate data if every single .dos file has an unzip utility inside it. If this was the way to go, it would be better to include an unzip utility within DOSBox and make it accessible from the internal Z: drive.

Well I guess this can work if you convince vanilla DOSBox to include Info-ZIP and this becomes a standard. Otherwise the unzip executable is just a few dozen kebibytes long and shouldn't impact the size of a *.dos distribution.

Malvineous wrote:I think it would be best to do this for all games, not just ones deemed to take a long time to install. For all games you can choose to run the game or run the installer. But then if you run the installer from the .dos package directly, the emulated C: drive will be inside the .dos package, so where do you install the game to? I think if you were to run the installer, you'd have to unzip the .dos package and run the install file yourself?

Well, if the size is not of a problem then that would probably be an optimal solution.

However I'm still unclear on some aspects of how the whole system would work. I've just realized that I'm thinking of the *.dos format basically in terms of a game CD analogy, whereas apparently this is not exactly how you envisage it.

For example you mention above that running a *.dos package would mount its contents as a C: drive, while I had assumed that it would be treated as a CD-ROM or similar read-only device. After all, there are actual DOS games that run off the CD without the need for a HDD installation, storing only modifiable files very similar to what you describe with the *.sav files. Hence I followed this CD analogy.

Malvineous wrote:The problem with this is how do you handle the .dos package being run within a web browser using em-dosbox, the Javascript port of DOSBox? You can't install locally because you don't have (or want) access to the local disk. Having users run installers inside a browser is going to get in the way.

As I mentioned above, I assumed that the site admins would have to somehow pre-configure the games? Again, having the option to either install or run a pre-installed ready-to-play copy should solve this issue I suppose

Malvineous wrote:As far as the game is concerned, nothing will be read only. Every file can be modified, but doing so would cause DOSBox to put the modifications in the .sav file. Saying the .dos file is read-only is just to make it clear that DOSBox won't modify it - it doesn't have to have any read-only attributes set.

Again, I would appreciate if you explained this process in detail. Does DOSBox in its present state already support similar manipulations? Or will this require to modify either DOSBox, the game, or both?

Malvineous wrote:

MrFlibble wrote:If the local installation method is used, setting up the game would be as easy as creating this local copy (from either pre-installed files or the original installer routine) and copying into the local game folder a pre-set configuration file(s) that is already supplied with the *.dos distribution and is tailored to the intended DOSBox configuration.

The problem is that this isn't actually that easy for many people. For archivists and people who grew up with DOS sure, but for everyone else it's too complicated. That's why one goal with the proposed .dos package is to make it as simple as a .pdf file. You don't need to install a .pdf file to view it, you just click on a link in the browser, or save it on your desktop and double-click on it. I think a .dos package needs to work in the same way by default, to cater for the majority of people who don't care about the technicalities and just want to play the game immediately.

When I said "as easy as creating this local copy (from either pre-installed files or the original installer routine) and copying into the local game folder a pre-set configuration file(s) that is already supplied" I meant of course that this would be done automatically when the *.dos package is "activated" by the user. I suppose that a fancy graphical interface can be even set in place that would show a progress bar or something. I did not mean that a user would have to manually to anything except for maybe select a few options presented in a familiar format.

Malvineous wrote:A close-knit group would produce the most accurate results, but there are very few people willing to do the work, and many, many DOS games. The proposal includes a revision number in the .dos package, so it would be easy to download newer packages if there are changes. The wiki structure would allow you to revert unwanted changes and perhaps even review changes from new users before they are trusted to make changes on their own. As you can see from projects like Wikipedia, the more people you have involved, the greater the result! I still think a wiki style would work best, but you are right that you would have to be careful about who can make what changes or you would end up with rubbish.

Well, I wasn't trying to say that some people should be restricted from participating in this activity. It's just that at least for now it seems to me that preparing a distribution is more of a one-time job that should not require further revisions. Of course there are cases when for example we have not yet found an original distribution of a game, but if the game works in this non-original state (e.g. a pre-installed copy when the original distribution was an installer) this should be no problem from the user's perspective at all.

On a side note, Wikipedia works great because there is a dedicated group of moderators and admins who maintain, clean up and constantly improve articles. This is in fact additional effort which could be spared if there was a small group of editors who strictly followed set standards from the start. The problem is that Wikipedia is an endeavour too large to make this effective. Maintaining DOS games on the other hand seems to be on a somewhat smaller scale that could yield results without the need to recruit as many users as possible via an open to all model.

What I would like to clarify as well is how you suppose to treat multiple versions/releases of a game? Will each get a separate package? Or are you just going to stick with the latest known version of a game, assuming that it is also the most appropriate one? Some games are known to differ a lot across versions, with changes affecting levels, graphics, gameplay etc. Admittedly Radix is somewhat of an extreme case here, but this is a question that will need to be addressed at some point.

Thanks again for the thoughtful response!

Firstly, the most important aspect is that this doesn't require any changes to the DOS games. They are completely unaware of the .dos package and run just the same as they normally would. All changes will happen in the emulator, so implementing this will require some new code to be added to DOSBox. I am hoping to make the package flexible enough that you can emulate a CD as you have indicated, however the vast majority of games weren't distributed on CD so for them, running off a .dos image will look just like running off a hard drive or a floppy disk. The important concept to realise is that the game will not be aware of the .dos package. The emulator will make the .dos (and .sav) appear as a hard drive, or a floppy, or a CD, or a combination of the three, so that the game is not aware it is running any differently to normal. Think of the .dos file more like a disk image - the emulator is aware that it is just a 1.44MB file, but the game thinks it's a real disk.

The way the .sav file will work is this. When a DOS game tries to open or create a file, the emulator will first look in the .sav file (which is in .zip format) for a file with that name. If one is found, that will be the file that is read from. If there is no matching file in the .sav then it will fall back to the .dos file, looking for a match there. (And of course if one is still not found there, a "file not found" error will be returned.) Likewise when data is written to a file, it will never go into the .dos file, but it will always be stored in the .sav file under the appropriate filename. If a file is modified (as opposed to being written in full) then the content will be copied from the .dos file into the .sav file, and the small changes made in the .sav. For floppy booter games, which don't use files, the exact same principle will apply except it will be based on disk sectors instead of filenames.

Because of this mechanism, deleting the .sav will not harm the game, but simply return it to its original state. If you wanted to manually "install" the game with your saved games, you would unzip the .dos file into a folder, then unzip the .sav file over the top, and overwrite any existing files. Then you would have a traditional copy of the game with your high scores, saved games, etc.

For handheld devices, the .dos packages could be installed the same way apps on a phone are installed, while the emulator may choose to store .sav files on removable media such as SD cards. The exact location of the respective files is not part of the proposal, as this will be specific to the platform in question. Under Windows with DOSBox, I expect the .dos files will be stored in a location accessible to all users on a PC, while the .sav files will be stored in a user's own profile. This would allow multiple users to log in to a PC and play the same .dos package, but they wouldn't be able to overwrite each others' saved games, as they each have their own unique .sav file.

As for the install aspect, the key is as you say, the site admins would have to "somehow" pre-configure the game. This is why I think the .dos package should be pre-configured by the archivists. The archivists are people such as you and me who properly understand the aspects of the games we are archiving, and are willing to take the time to do it properly. Many site admins (this site excluded of course) are simply about having as many games as possible on the site, and they pay less attention to getting them working correctly and at their best. So I think if you want it done properly, you need to do it in the package format itself when it is created.

For the idea about a web-based collaborative archival process, I think it would be bad to make it public like Wikipedia where anyone can make changes without logging in. But as I have seen from both the Commander Keen wiki and the ModdingWiki that I have run for the last few years, requiring people to log in means you generally only get people who are willing to make constructive contributions. With clear instructions, I think it would work quite well. In most cases it settles down to a small number of "regulars" who maintain the site anyway.

For multiple versions/releases of a game, I am expecting these to be in separate .dos packages. The main reason for this is to make it easier to distribute mods. Using Commander Keen as an example, most of the mods are against a specific version of the game and won't work if the .exe from a different version is used. So for this to work, it would be much simpler to store each version of a game as a separate, independent .dos package. The proposal currently includes a game code and a game version number stored inside the .dos package, so it would be relatively easy for a front-end to display these packages together in the GUI as a single game with multiple versions available. Perhaps we should include a release date as well as the version number so it's clear which version is newer, for those games that use unusual version numbers?

I am not sure how you would handle the case where the same version of a game had two different installers, but typically these have different version numbers or distributors so hopefully putting them in separate .dos files would be acceptable.

Hey Mel, I'm telling ya............ Being a coder seriously for close to a year now I know I want my stuffs to be seen. So I am encouraging you to give it a try. By the way, what packing do you plan to use? I was looking at my WinRAR 3.93 credits by Alexander Roshal and he gives credits for the 7-ZIP format to the people who created 7-ZIP. Since I also have my own compression that I just created you could use that. Of course, I would like credits for it. hehe On this memorial day weekend, I would like to make a suggestion in honour of my real dad. My real dad (Thuy Binh Nguyen) told me many years ago that you cannot take money with you when you die. So I am happy just to have my name recognize for my simple compression routine. For most files, it is not good at compression. However when the files contain a lot of similar characters in a row it does a great job. Let me know what you think!!

Last words for this post anyways, my real mom told me to be kind, warm, and compassionate. So I just wanted to say keep at it. Even if it does not make it, at least you tried. I worked 8 months for almost 8000 downloads from the public. So far my download statistics have plateau so I am not getting any hits lately. However that goes with the business. You are hot once and not so great when people get bored of you? hehe Well, I am not complaining. It was fun while it lasted; Besides, my father just says to do it to prove to yourself you can do it. If people do not see the value in your projects at least you did something that made your feel like you tried to give something to others.

By the way, my real mom (Huong Thi Vu) told me you will get better as you progress through your revisions. So if you do not get a hit now you will get many hits 12 years later. Remember that even doctors have to train for 10 years before actually being able to operate on a live person.

Jesus Christ!hehe

Hey Melvineous,

Well, since I am working on this beta. I am letting you package it up and do a prototype for your proposal. See if you can make it work. This beta needs a speed boost so you need to automatically set it up to go max cycles in DOSBox 0.74. What do you think?

http://www.mediafire.com/download/7bcxc ... sic/e8.rar

Thank you Jesus Christ that my beta is turning out just fine! Blessings to God#!!
Honour my real parents for standing behind me all this time.

Jesus Christ!hehe

Hey Mel,

I just wanted to see how your project is going? You know coming from an outsider perspective DOSBox 0.74 is really a popular format. I don't know if you need to upgrade it however "fans" like to see additions from time to time. So I really think your proposal would work. However - just remember - I like the old version of DOSBox 0.74 since I am so used to it and prefer not to learn that much. Although I will say if there is a DOSBox 0.75 making it compatible with as many DOS apps would be my first bet.

For instance, I test my stuffs on DOSBox 0.74 especially when I am programming with Borland Turbo C 2.01 and Borland Turbo Assembler 4.1. So at the minimum it has to include the capability to run Borland Turbo C 2.01 and Borland Turbo Assembler 4.1 like DOSBox 0.74 does now. Being a developer using these tools that are hard to come by now a days I just can't afford to use anything else.

The main point is keeping DOS compatibility.

So, any news on this project?

BTW, after some thinking I decided that the goals of archiving original distributions and of creating a user-freindly package format do not go very well together, and there is no real reason to force them into a single catch-all type of format. I believe that these two processes - that of archival and of making games available to the userbase - should parallel each other, so that everyone may get what they need.