problem is with new files.

Well it's on the to do list with little priority.

Wouldn't creating a new file correspond to adding a file to the existing zip-archive?

I haven't looked at the sources yet so I don't know if you're abstracting interaction with the host file system at the moment. If an abstraction is used then (using zlib?) an extension could translate:

fopen -> uncompress into memory
fread -> read buffer from memory
fwrite -> write into memorybuffer
fclose -> compress into file

If you're abstracting file system interaction then I might take a look at it myself. Being able to zip all my old dos games into a single archive per game and access them in zipped state directly from dosbox ranks high on my list for christmas 😀

Regards,
Allan

DiabloDiab wrote:

Being able to zip all my old dos games into a single archive per game and access them in zipped state directly from dosbox ranks high on my list for christmas 😀

I hope a new hard drive is above it on the list, because clearly you need more space if you can't store a few DOS games uncompressed 😀.

Don't underestimate the "neatness factor" of being able to group all resource files of a specific game into one package in the host file system.

Some older games consists of hundreds of small resource files which are uninteresting to me in the host os. It would be more convenient if they were grouped as a single file in this environment for moving/burning etc.

A neatness thing, but still 😜

I don't mean to be rude ...but what's wrong with each game being in a different directory?
That's good enough for me for moving, burning, whatever...

If you treat an archive as a directory because you don't want to have to deal with all the files contained therein, but then you do stuff within that directory that changes / deletes those files and even creates new ones, don't you lose a lot of the conceptual benefits of archive-as-directory? There are scale issues here as well, playing a game like Ultima8 from a 40MB zip file and having to recompress the zipfile every time you save your game just seems ridiculous.

This and state-saving are two things that seem to make a lot more sense with console and arcade emulators than they do with DOS games. I'd like to see better compatibility and emulation speed for DOSBox a looooong time before support for stuff like this. Just my 2 centimes worth though.

That's the difference between treating the zip file as a directory using on-the-fly compression/decompression vs. the zip-support you'll find in frontends for console emulators etc. What you are describing is the zip-support seen mainly in frontends.

These (usually) decompress the zip file to a temporary folder and access the decompressed files from there (like your Ultima8 example).

I'd rather look at it this way:
1. In my host OS I have all the files for Ultima8 zipped into "ultima8.zip" because all I'm really interested in at this level is the name of the game.
2. Within Dosbox I can enter this zipfile like a normal directory using the "CD" shell command.
3. Once inside I (and programs I execute within the zip file) can access each file of the archive individually. If you do a "DIR" the contents of the archive is listed.
4. When a file is to be opened only this specific file is uncompressed to memory from the archive - not the entire zip. To improve performance a cache can keep the uncompressed files in memory as long as no writing takes place.

I guess you can compare it to the way drivespace used to work in dos.

For iampiti:
Nothing rude in what you are asking/suggesting 😀

However, I still believe that grouping resource files together in single archives in the host os makes them easier to manage in the long run. There's a reason why ID Software groups all of their resource files into pak-files etc.

DiabloDiab: good explanation, that does clear some things up. I'm curious, though, how does writing new files or modifying existing ones work in such a scheme? An uncountable number of old PC games do some form of that, and as far as I know you do need to recompress a ZIP if you want to add a file to it or modify a file within it.

Id Software *does* pack everything together in WADs / PAKs / PK3s, but none of that content is ever meant to be modified / added to - in fact Q3 checks to make sure that game-critical content archives *haven't* been modified to eliminate the most obvious cheats.

Sounds like a pretty good idea to me, as having a zillion and one directories/files can be annoying. Though in dosbox this would look the same either way really. The main benefit to having this would be in the way of saving space.

Changes could be written to a temporary file repacked at exit.

And then if DOSBox dies (for whatever reason) you're left with...what?
I can see this being useful if only because of large block sizes (4kB by default on NTFS) and lots of really small files that games/apps sometimes have (under 1kB).

My idea:

ZIP files are treaten like read-only dirs. If you want a 'read-write zip dir', you must associate it with a temp dir. Maybe something like this:

mount d ultima.zip --write-dir=/tmp/ultima.zip/
('ultima.zip' as 'd:' will have a temp write dir named '/tmp/ultima.zip/')

Any change goes in the dir (create, modify, maybe delete). Then, we got three options to save the changes:

1. Repack at exit
2. Leave it there and re-read the dir next time dosbox run
3. Mix: if dosbox is killed before repacking, it can 'restore' with the temp dir

I don't know if it is a good idea (in the real world 😉 ).

Oh, and BTW, 1k files aren't the only trouble. What about the 5kb, 9kb or even 13kb files with their internal fragmentation ? Only a few file systems can deal with it, and I don't know any that can do it nicely. Of course, we can't forget the huge FAT 32kb-blocks !

And, last but not least, we can't forget the 'easy-to-copy-burn-and-share' power of zipped files ! It could be very cool to download an ancient 1980 classic and run it without even unzipping... 😀

PS: One last line to make some brain exercice: if this feature is REALLY useless, why microsoft put it natively on windows xp ?
PPS: I don't want to discuss if microsoft made it work or not... 😁

What MSFT feature? The explorer has a built-in unzipper, nothing more. There is no transparent usage of compressed folders unless you're using NTFS with XP Pro (and that isn't ZIP.) Same with Microsoft CAB files since Win95.

I just wanted an illustrated example. OK, it's not a complete file system, it's only a cool zip manager, but it works like a folder in many aspects, and is very useful. You can move files between subfoldes, you can add or remove with DnD, etc, with a explorer window - no external shareware programs... 😀

It cannot be more complete because of windows core. Inserting a new FS is really hard. It's not like Linux with a Virtual File System concept.

BTW, did I mention that I don't want to discuss if microsoft made it work ? 😁

I just use the built in NTFS compression to compress the folder I use as my C drive in DOSBox. Works fine for me. Yes, I'm aware of the space wasted due to the cluster sizes, but boo hoo. Like it matters on multi gig drives anyway.

Oh, another thing about zip support. You do realise every time a zip is changed or updated, the whole archive is written out again. And that could be a 10-20 mb or bigger archive. Do you think this is worth saving a few kb? No.

Actually, back in the day I wrote my own program to run games from zips, it would unpack it, run the game, then update it. But that was when I had a 500 mb hard disk!

Well, actually, I'm not thinking only about the space wasted with a lot of little files. There are, at least, two more benefits:

- I think it's very cool to download an old classic and play it without needing to create a dir and extracting the files. It could be just like console's ROMs, or even console's CDs. You open it as a C: drive in DOSBox and execute. That's very useful if you like to download unknown ancient classics, and wants to know if they are good games or good to go to trash;
- What about sorting your game list by size ? This can't be done easily with directories, but it can be done with zips. If you got a lot of games, this can help when you are creating you backups... 😀

Of course, there's a lot of problems about this zip dir approach. It's slow, hard to implement, etc etc. I just think it's something to stay on DOSBox TODO list (with a really low priority 😁 )

This would be a great idea of DOS games worked like console games. They don't, however. There is no standard way to run a particular game. There is no standard directory structure or tree to a particular game. There is no stardard specification to what parts of the file system the game modifies. All these things would need to be taken into account for such a system to work. Again, it seems like a lot more work than is necessary.

Of course, I've always thought that those who use DosBox use it because they used DOS in its original form back during the late 80's/early 90's. DOS worked in a moderately complicated manner, unlike simply sticking in a cartridge into a game system. If one can't understand DOS than most likely you can't understand the historical and technological significance of the games either (Because you weren't there to experience it). A lot of the early PC games have poor graphics and sound compared to today's technology. What's different, however, is the level and depth of game play.