Actually, I know that is impossible to drag, drop and play a DOS game like a console emulator. I just think it's cool to drag, drop, write "<nameOfExecutable>" ("cd <dir>" maybe ?) and play. That's one of the reasons I tell the "create a zip temp dir" idea. It could work like a "unzip;run dosbox mounted on the dir;zipit again" BAT file, but having it natively is better, specially for "read-only" games.

BTW, I think old games are more cool than todays' games. Games like TRON 2.0, Quake 3 and others are fun, but they are unplayable in two or three years (I can't play DN3D anymore 😒 ). Games like sokoban and karateka (or even DN1 e DN2) I will play my whole life. And what about that 5/10 pixel tall pictures that you treat like persons or space fleets ? 😀

PS: I can only thanks sokoban and karateka creators. Their games bring me to the world of computers in 1991/1992. Using an 8MHz computer with 712kb memory and 32Mb HD was very cool. Playing 4 color (4 tones of green) games, programming in BASIC and destroying my DOS directory using DEBUG are some of the happiest moments of my live... 😁 Jeez, I really miss the Norton Disk Editor... 😀

Oh, another thing about zip support. You do realise every time a zip is changed or updated, the whole archive is written out again.

Yeah, it might be better to handle compression as part of the file system, rather than as a .ZIP file, so this can be avoided. Simply using a ZIP file would be a bad solution.

Whats "very cool" about it? Is it that hard for you to extract a zip?

Again, extraction is easy. Its applying the relevant changes to the file system back to the zip file (and reconciling any changes with other games that may access the same files).

How about this scheme:
1.
All files being accessed in the zip are decompressed to memory and changes to their contents are kept there.

2.
Whenever a file is opened a counter is incremented, and when it is closed the counter is decremented. When the counter hits zero you can write the new zip as no programs are currently accessing the zip.

(the final file closing would usually be the executable)

Obviously this would be time consuming when dealing with larger zips, but most older dos games/programs are below 10megs anyway.

If you avoid the tar.gz method and instead compress each file individually within the zip archive then you "just" have to recompress the changed files and copy the remaining files from the original zip into the new zip.

Again, pointless. DOS games are small. Get over ZIP support already!

You seem to focus only on the space-saving aspect of zip-support, which is, of course, one of its benefits. However, this is not at all why I suggested adding this support.

My main concern is usability, that is, you should only be presented with things/files that are relevant to you in your host operating system. When I have a directory containing a game which I play solely from within DosBox, then there's absolutely no reason why the contents of the directory is visible in the host os. At that stage I only need to know the name of the game/program and be able to move it around.

If you read between the lines, then really what I'm suggesting is a virtual harddrive file format for DosBox. To make it easier for other operating systems to exchange data with this format one could use zip-archives, hence the suggestion.

Now you may say, why the hell do we need a virtual harddrive when the current file systems are similar to the ones used in dos. Well, that may be the case at the moment, but who knows how filesystems will look like in the future. I understand that the next generation of Windows will use a completely different system for organizing files - instead of directories you will use meta-data to categorize files. This, I presume, will collide with the way we currently "trust" that the host operating system uses file grouping concepts similar to directories.

Long post, sorry, but I hope you understand now that space-saving is absolutely not the main focus.

If you want a virtual hard drive, try BOCHS. Usability with DOSBox couldn't be simpler. Exchanging archives through your system and the virtual hard drive using zip format? What the hell are you talking about? The same folder in your normal windows file system is used in DOSBox. What could be simpler than that?

GET OVER IT ALREADY.

(sigh)

1.
I'm not saying that the current file system isn't usable. What I'm saying is that if the file system isn't abstracted to a virtual harddrive then it might become a problem when the modern file systems begin to differ from what we're used to (i.e. no folders). The current system is convenient, but too much responsibility is placed on the file system of the host operating system - it must be similar to the dos file system.

2.
Adopting an existing file format, such as zip-files, to represent virtual harddrives would make existing apps instantly compatible with these virtual harddrives, making the transition less annoying.

3.
You should learn to give constructive criticism.

I highly doubt directory structures will go away, ever.

Bold statement (640kb is enough for everyone), but you're probably right about that one.

I still believe virtual harddrives (of some form) are the way to go in order to isolate Dosbox data from the host os, but I guess I'm pretty much alone on this one, so I'll back down.

Actually, you are not so alone. I really like your idea.

BTW, if DOSBox will not have it native, what about a "Launcher" program ? It can not only use the "decompress-launch-recompress" idea, but it could manage our games, too (maybe with a nice interface 😀 )... I don't know if I have time to develop such program, but any feedback is welcome. 😁

Go harass the BOCHS authors for better games support then, since they already do the rest of what you want.

It could be a nice idea, but bochs is not an MS-DOS emulator. It is a x86 emulator. You cannot just install bochs, run it and get a DOS prompt like DOSBox. If someone wants to play games on bochs, he will have to install box, install a dos image (note: it's user's responsability to find one and it's users' responsability if it's a legal copy or not 😁) and then install and run the games.

Bochs is not created to archive a resonable FPS. Bochs is not 'game friend' - if you want to play games with it, you are trying to play soccer on a research lab. Bochs is best used as a operating system tester. It's good to test linux on a dos box, it's good to test a linux distro under another linux distro, it's PERFECT to develop and test a bootloader (I have developed one some time ago). It's not a gamer's place and it will never be. Have you ever used bochs ? Have you created image files ? Have you ever tryed to copy files from outside bochs to inside without root privileges ? It's really not something trivial as unzip-use-rezip. BTW, I will never ask them ZIP support because they need low-level disk support, including heads, sectors, MBR, etc.

We are discussing here how to implement a ZIP drive (not ZIP hard disk) support under DOSBox, if it's implementable of course. If you don't like the idea, just don't read the topic and leave us with our dreams... 😀

And round and round we go about this silly topic. I think the reason the hardcore DosBox users are against is because its a bastardization of how DOS and the IBM PC circa 1980-1996 worked. Using a zip file scheme is great for cartridge or ROM based games like MAME or Stella, but strikes me as being completely irrelevant and having the potential for bugs ad infinitum (again, it all goes back to such an idea requiring a very intricate file system monitoring subsystem just to maintain the zip archives) for the PC. Also, I know what you are saying regarding zip archives and game intentification (not unlike what MAME does), but again, there are several times more games, more game versions, and more game file variations than exist within the arcade machine world. Are you willing to catalogue them for us? Also, you're also operating under the assumption that games are always going to be self-contained in single directory trees, though this may not be the case.

If compression is what you want, use NTFS. If a point-and-click game archive is what you want, use the IBM PC emulation offered by MAME. And ultimately, if you really, really want a zip based file-system, write it yourself and make the patch available to others.

No, you really didn't get the idea. Actually, I guess only Qbix got it. I can only read "you can't do this" from other guys. 😀

Let me try to explain based on what you said.

1. It's possible to create a "self-contained-zip-game". And it's simple. Just add an AUTOEXEC.BAT (or something like that) to the file. It's exactly as just having the BAT in an ordinary dir and dragging it on DOSBox icon. BTW, ZIP files can manage comples directory structures.
2. NTFS ? I don't want only compression. And, if I only wanted compression, what about Linux, MacOS, etc etc ?
3. MAME ? Cool, teach me how to play OMF, Bushido, Karateka, etc on them.
4. I don't want a complete virtual ZIP file system. I want a unzip-run-rezip feature.
5. Ah ! The idea to leaving ME the resposability to create a "unzip-run-rezip" program. I really prefer it natively, but I can do something. I just need wxWindows (multiplatform - I program on my Linux box and run on my WinXP box) as interface and zip access and call dosbox using the --exit flag together with -c and an on-the-fly "autoexec.bat". A simple interface "just to work", only temp dir and dosbox path as config. Looks easy. I will try it on my vacant time. 😁

It seems that the devs have most concerns regarding the "rezip" feature. That would go away if zip-files were treated as read-only, right? How about this, then: don't touch the zip file, and store any new/modified files on a normal file directory. It could go this way:

1 - Unzip the file in RAM (won't work for large games)
2 - any file creation will go to a normal dos folder
3 - any modified file will be first copied to the normal folder then modified (will slow down things a bit at first load because of the extra copy)
4 - when restarting, load the zip first and then look at the folder for extra files

Benefits:
- Allows optimal configuration for Dosbox (zips would be preinstalled and preconfigured games).
- Allows creating a database of DOS games, with checksums, etc, for easy preservation of software.
- Installations can be easily be transported between machines as you can easily see what are the modified files (the ones outside the zip)
- the external folder will have the same structure as the zip, generated as needed, but will only contain what's necessary
- It would only require changing the "write" function, and maybe the "file list" options (to pick up external files over zip files if they are the same).

Why it could work:
- usually, modified files are not large.
- the performance hit should go away quickly (when all files are copied)
- eventually, with the game database, we could know what files are written to for each game, removing the "first copy" performance hit

I hope this can satisfy both us hopeful users and concerned devs...
What do you think?

based on point 1 and 4 : from m4c0
e.g only unzip and rezip when done.
supply some dosbox control file.

This control file allready exists dosbox.conf is created for that purpose.
that's why configfiles in localdirectory have priority above systemwide ones (new feature)

only zip and rezip would grant some support for zipping but you would lose your original game if the game changes something.

But to be honest i don't think this is a job for dosbox. More for a frontend. Dosbox doesn't need to be aware of a zip tree (if it does then you get the answer: "very very difficult")

E.G Fronted. select game => unzip game by frontend => start dosbox
on dosbox exit. =>rezip game by frontend.

I still think you're looking at DOS games way too much like console based games. First, your shared zipfile/directory scheme would not work with games that rewrote the executable file as part of the save mechanism (The Starflight series is a particularlly good example). As for the benefits, again, as I said, these are all serious benefits for console emulators, but are nearly inapplicable regarding legacy PC's.

Regarding:
- Allows optimal configuration for Dosbox (zips would be preinstalled and preconfigured games).
- Allows creating a database of DOS games, with checksums, etc, for easy preservation of software.

Are you suggesting that for each dosgame, you're planning to have a different distro and checksum for reconfigured hardware. What if I want a prepackaged version of Xwing that has MT-32 sound, Soundblaster sound effects on PORT 260h, IRQ 5, DMA 1, and set to Slow Computer speed?

I understand that consoles are a different beast, but this is exactly how Amiga and PC98 games are emulated (albeit PC98 does not use zip files, just one self-contained, uncompressed, disk image per game). Some files may not work, but that would be a minority...

For the configuration, you can always have a config set as the default.
Dosbox can adapt to it because in this case it would be run only for this game. You could still manually create your own config if you open Dosbox separately, then it will create files that will be picked up next time you run it, without modifying the original "game image".

But maybe it doesn't need to be so complicated. How about this then:

1 - Load a ZIP as a RAM drive.
2 - Run the game from ZIP's autoexec.bat.
3 - When the emulator is closed, run a diff between the RAM drive contents and the zipfile.
4 - Write modified files to disk.
5 - when doing 1 again, check for files on disk and replace as needed

This should work even for auto-modifying files. The disadvantage, however, is that it slows down shutdown, and that you lose everything if the program crashes. Mmmh... maybe it's better to have a frontend after all... 😉 (with a fronted you just would need to erase unmodified files, then avoid overwriting the existing ones).

Okay now that I have auto-convinced myself 😀, is there a fronted that does something like this? Are there any efforts being done to standardize "game images"?