DosFreak wrote:

If/When Dosbox (or a fork) officially supports 9x it would only be using an image as it does currently. Host file access would be via shared folder similar to VirtualPC or NE2000 support. There is no reason to have file system access similar to how DOSBox currently does it for Windows 9x in DOSBox.

*The above statement is my own and not to be taken as anything to do with future plans of DOSBox.

Man, i know dosbox people don't want to do it, that's why i said 'ideally' and peppered the post with 'but this won't happen' asides. I'm pretty certain that until some other project comes up with tested code that does this it will never happen, and maybe not even then. I think the reason that it's so easy to use in dosbox is exactly because they had to reimplement DOS and thought 'why not'. Since they don't intend anything of the sort for windows 95, that's why i think it will never happen here.

All the posts pointing out that 'windows controls the low level geometry so this is impossible' are kinda missing the point too (even if they aren't addressing my post). The idea is to re-implement and stub the lowlevel interfaces uses for this sort of thing so they think they're communicating with the hardware, but are actually being ignored by a emulator. This is why i said 'purists' would give this idea the stink eye, it's not 'exactly' windows like dosbox is not 'exactly' dos. If it can be done just on the hardware emulation side, wonderful, but i suspect it's not so easy, otherwise virtualbox etc, would have already done local mounting of files ages ago. It's probably only their most requested thing. Maybe it can be faked usefully with NFS (network file system) so they don't bother.

What you're suggesting is reimplementing the win9x kernel.
I'm not saying it can't be done (although it's pretty much in that category), it's just that nobody will do it just because it's the "most requested thing" or because mounting image files is supposedly hard.

We aren't actually disagreeing.

BTW for myself it's not that i think mounting images is hard, but because i lose benefits from using a image. Disregarding the image size issue, since i'm playing games on a read only mount using a write dir redirection, using a image has to copy it all to the cache when it is written to, which would get annoying for > 2 gb games (all the - 2 - windows games i tried have less than 2 gb for obvious reasons). Just if you ask in advance 'why make a hdd image read only' having a read-only archive is actually more important for windows games in dosbox than any other sort, with how windows95 can corrupt images if you close dosbox in the middle of a write for any reason. I'm merely making the 'archive' playable, sort of. This motivation might disappear someday if the linux kernel gets a overlay system that is more granular than just 'copy the whole file to the cache if written to' someday.
You also lose deduplication on the compression, which is also sorta disappointing.

Now i know dosbox devs don't care and don't have to care, these are some of my motivations to want not to use images when i can. They're simply not as well integrated with other things. Filesystem transparency is something i want when i can get it. It's also the reason i like dosbox support for mounting dirs as cds.

Most of these issues can be solved with images. I've mentioned qcow2 support - you can have a read-only base image with writable overlay which only contains changed sectors. VHD has differencing disks as well.

All these functions are already established and have supporting tools (merging disks and so on), tested by loads of users using different virtualization products. It's also several orders of magnitude easier to add such support to dosbox, rather than reimplement the Windows kernel.

qcow2 looks interesting. Supposing dosbox gets support for Fat32 and for qcow2 as yet another indirection layer (man that software engineering adage about indirection can solve anything was right) and i can use it with overlayfs externally (which i should) so all the writes get redirected to the smaller file not the big one and that is the one that is cached, i'd be very satisfied with the new status quo.

Why does dosbox need support for fat32?

And you don't need overlayfs, the writes are always going to the overlay image, not the base (the base can be read-only or immutable, if you want to make sure 😀). Also, linux already has an overlay system that is more granular than just 'copy the whole file to the cache if written to'. It's called device-mapper snapshot...the snapshots can even be persistent or in-memory only 😀

To have windows images with > 2 gb (the OP problem). The applications for multicd games and their various no cd full install hacks are obvious, and the reason why this is so asked for. I originally wanted for Black Dahlia, which has a full install hack on the net but when i realized that i had to put cds into multiple drives and install a archaic cd emulator instead of using that, i gave it up as a bad idea. Usability uber alles.

This has nothing to do with dosbox!
If Windows is booted inside dosbox, fat32 works just fine...

gulikoza wrote:

This has nothing to do with dosbox!
If Windows is booted inside dosbox, fat32 works just fine...

But dosbox has to mount the images for windows to see them? I'm pretty sure last time i tried this with a FAT32 image for the game and a FAT16 for windows to boot, it failed. Oh man, i'm going to be feeling so stupid if this actually works. Maybe the limitation was that the image was 2 > gb with the game inside and dosbox refused to mount, i can't remember.

SVN dosbox does not support images larger than 2GB, but there are patches to make that work.

But once image is mounted (you can use -fs none switch) and windows booted, windows is accessing it directly so it can do whatever it wants...

You got a link to that patch? I'm the guy that did one of the dosbox svn ppa around launchpad and if it's 'clean' and applies cleanly i'd want support for that there, and i'd use it myself.
q2cow is pretty cool too.

A patch for mounting hard drive image larger than 2GB - how self-explanatory 😁

I'm bothered by the fragmentation of the dosbox codebase in a lot of patches and compiled versions that people use to get what they want working myself. Did you try to upstream it?

This is the reason why there are still a lot of people using dead and ancient versions like Ykhwong, and it's unhealthy when every other recommendation tells you to install 'ancient version off the net' instead of the latest upstream oh well.

That's certainly a problem in itself. But official goal of DOSBox is to emulate DOS games and DOS has little use for 2GB+ images...

Serious Callers Only wrote:

I'm bothered by the fragmentation of the dosbox codebase in a lot of patches and compiled versions that people use to get what they want working myself. Did you try to upstream it?

This is the reason why there are still a lot of people using dead and ancient versions like Ykhwong, and it's unhealthy when every other recommendation tells you to install 'ancient version off the net' instead of the latest upstream oh well.

But what should be the solution? Accept every patch that someone deems necessary? That is certainly the way to more work for the devs, since the usual way this would go down is that the patcher unloads a patch and then walks away and leaves the fallout to the developers.
You have to honor the goal of DOSBox. And that is playing Dos games. Most patches add nothing towards this goal except for some conveniences (like the save state patch).
Take this patch (upping the disk image size) - it adds nothing to DOSBox' goal. So why should it be included? That people can run Windows 95 in DOSBox! But that is not the goal and adds more distractions.
So you are better off with a fork, in this case the dosbox-x fork that adds CD-Rom support which is much more useful to when you want to run Windows 95. and dosbox-x is the perfect example why it is good to limit your goal. IMO -x adds too much and thus is not perfect for Windows 95 as well 😉

gulikoza wrote:

A patch for mounting hard drive image larger than 2GB - how self-explanatory 😁

Sadly, it doesn't apply cleanly to the dosbox svn tip (this is what i mean with people using ancient versions). I might or might not try to wrangle it into compiling later depending on how hard it turns out to be.

Dominus wrote:

So you are better off with a fork, in this case the dosbox-x fork that adds CD-Rom support which is much more useful to when you want to run Windows 95. and dosbox-x is the perfect example why it is good to limit your goal. IMO -x adds too much and thus is not perfect for Windows 95 as well 😉

I already do limit my goal. My ppa only has mt32 currently because i like having the latest dosbox code. Code compatibility patches for libraries like that, with a author that actively updates the patch for years to the point i only import it, not edit (very much the farthest away you can be from 'merge and leave') should be applied imo. This one is a single utility and a code patch to remove limits that dos doesn't care about, also minimal maintenance and no reason not to be merged . The dosbox project policy is what is causing a great deal of the fragmentation, not only coders overreaching. If people don't see anything wrong with it and prefer playing with multiple forks and executables, so be it, but it doesn't make for great portability or standardization.

This one is a single utility and a code patch to remove limits that dos doesn't care about, also minimal maintenance and no reason not to be merged. The dosbox project policy is what is causing the fragmentation. If people don't see anything wrong with it and prefer playing with multiple forks and executables, so be it.

But what would you suggest is the right way? Generally, not necessarily limited to this patch. Accept every little patch and hope it doesn't break other stuff that only shows up months later?
Where do you set the limit?
Because there will always be the one person that desperately wants this one feature in DOSBox that is only in outdated patches and outdated (or worse, broken) builds. And it will always be just a tiny little patch that will surely have no impact on DOSBox' real goal 😀
I think this policy successfully weeds out what users really need and most importantly which developers really care and update their patch accordingly.

Generally, if a external stable library like mt32emu has a separate patch to compile dosbox with support for it, accept the patch and use the that code as a *library* if installed on the system, much like many other things are optional. Dosbox devs would maintain their usage of the interface (it's a tiny bit of code defining another device), not have to care about the mt32 code, much like they already don't care about soundfonts, distributions would be encouraged to package the library in order to use it on dosbox.

Expanded IMGMOUNT/IMGMAKE can we admit that no one uses the 'raw' ability on dosbox upstream for anything else than mounting windows or freedos images? I mean i haven't seen it used for anything else and i searched. So a patch like this that increases the usability in that case while not really hurting dosbox DOS itself would stop most complainers at minimal pain. It's not like people are asking to rework all the dos commands, just mount raw images which dosbox DOS can't do anything with.

There is a reason there is no mt32-emu support.
Edit: DOSBox doesn't want to support software piracy in any way. As long as the Roland ROMs are required and those legal status not completely clear, the DSOBox devs will (AFAIK) not build in support.

I've been using imgmount for CDs and for booting Dos and Windows 3.11.