I don't care much for zip files tbh. To have the ability to use them is a bonus that comes with this patch, personally.
Though using a non-compressed zip doesn't add to the loading times, and gives a single file easier to move around.

To quote myself from the other thread,

jarreboum wrote:

It's very useful to have in a multi user environment, without having to worry of one user corrupting or deleting the saves and configurations from another. I simply keep the games read-only in /usr/local/share/games/dosbox and the modifications in ~/.dosbox/saves, mount them together and everybody is happy.

I have several users here, some being quite young, and I don't have to worry about one deleting the save of another.
Plus in association with a custom launch script for each game makes deployment stupid easy too.

[edit] current thread with current patch Re: PhysFS patch

jarreboum wrote:

I have several users here, some being quite young, and I don't have to worry about one deleting the save of another.
Plus in association with a custom launch script for each game makes deployment stupid easy too.

"Deploying" games to multiple users? There you have your piracy! 😉

IIRC, if you store your games in Program Files (Which most people aren't going to do) and let the VirtualStore handle it then the saved games would be in the virtualstore for that profile.

Only issues with that is that some file extensions aren't allowed to be used with virtualstore but I don't think saves would be affected there and the list of games affected is pretty low.
Most users don't know how to setup the permissions correctly which is why you usually see all the bitching about people having issues with their games in Program Files while I've never had such issues.

Yesterplay80 wrote:

"Deploying" games to multiple users? There you have your piracy! 😉

Damn, you got me!

DosFreak wrote:

IIRC, if you store your games in Program Files (Which most people aren't going to do) and let the VirtualStore handle it then the saved games would be in the virtualstore for that profile.

The problem with such a solution is that it's OS dependent. For a program like DOSBox that can be built for pretty much every OS under the sun, it's not a good solution. The main problem really is that every game store their user data in a different way. If it was uniform, a script to copy and replace could be written easily and let to the user to deal with. I would argue that to give the user a simple way to save their data, while maybe not essential to the project, would be darn convenient.

You could also argue that the patch is already out there so why the hell not.

Reminds me of the nuclear arms race....

I can guarantee that the main concern is primarily adding too much extra crap to DOSBox. Game packaging is a minor concern compared to a working non-buggy DOSBox.

I think since Jason Scott put up the DOS game rips up on the Internet Archive already pre-packaged then it doesn't really matter if DOSBox has the patch.

We've had these discussions since DOSBox was released on Sourceforge. I think the only way you're going to see non-essential patches in the official release of DOSBox is:

More maintainers.
Nightly automatic binary straight from the devs released public. (not a 3rd party site). AFAIK, this is still private.
Seperate thread for nightly release issues
Go through all the patches and rate them on if actually worth integrating or not. What percentage of GAMING userbase would use? How much DOSBox code would need to change to implement?
etc

DosFreak wrote:

You could also argue that the patch is already out there so why the hell not.

Except I didn't 😉

You're right in that avoiding clutter is definitely important. I have no strong opinion on whether to include such patches into the mainline or to keep them separate and let forks do it. While I do feel the convenience it brings is important, there are a thousands other things to consider, like clutter and, well, the code itself (which according to other users isn't that great to begin with).

The problem with these patches in general, is that they are not accessible to the general user who can't compile. They rely on someone doing it for them, hence me begging in this thread 😀

To carry on with the off-topic of "what to do with patches":
Another solution for this plethora of patches would be to give DOSBox a modular system. The patch would compile into a single file, that you would place in a specific folder in the DOSBox installation directory. That way everybody can pick and choose whichever they like better for their use, and you can keep the main software as minimalist as possible.

And that introduces a support nightmare. You would in essence have many different versions of DOSBox and often people asking for help would fail to mention that they are using some of their "plugins".

collector wrote:

And that introduces a support nightmare. You would in essence have many different versions of DOSBox and often people asking for help would fail to mention that they are using some of their "plugins".

I don't know, plenty of softwares seem to manage fine. In any case, that was just a passing suggestion.

As always, adding such patches isn't done with just the patch. Someone needs to maintain that part of the software and deal with the fallout when the patch introduces problems down the road.
But whatever, I'm done arguing and should just handle it like the developers handle these discussions;)

James-F wrote:

Always run "config -wc" to have the latest commands show in the configuration file.

What is that—a command-line parameter to DOSBox? I am tidying-up the config-file hints for my patch and should like to see what it looks like after my updates. What exactly shall I run on the command line? I have tried

1dosbox -resetconf

but to no avail.

You start dosbox and you have a z: drive, it is always with the PATH= variable so you can type the commands anywhere,
In this drive you have all the .com files like: intro, mem, mixer, mount, config, etc...
With CONFIG you can change dosbox parameters from a running DOSBox session.

https://www.dosbox.com/wiki/CONFIG

I have various batch filse to change the cycles to 386, 486, Pentium, using the config command within dosbox.

1config -set "cpu cycles=10000"

https://www.dosbox.com/wiki/Performance

Here are all the commands:
https://www.dosbox.com/wiki/Commands

Thank you, James-F. How strange that the wc command should only be available from within DOSBox whereas it affects an outside entity—the configuration file.

Almost any command available within is also available without: dosbox.exe -c "config -wc" -c "exit"

It's all documented in the README, of course.

ripsaw8080 wrote:

Almost any command available within is also available without: dosbox.exe -c "config -wc" -c "exit"

It's all documented in the README, of course.

Pray pardon my lack of patience, ripsaw8080.

Did you get the Fluidsynth driver working in the end? The one linked here - Fluidsynth soundfont patch - tries to patch files that no-longer exist in SVN. Oddly enough the earlier patch does apply fine but seems to ignore settings as it complains about JACK despite the fact the audio driver is set to Pulse.

EDIT: Nevermind, bloodbat's patch applies just fine. That said, it doesn't seem to "work" as when you try and use it, you get:

MIDI: Can't find device:fluidsynth, finding default handler.
ALSA:Invalid alsa port pulseaudi

... which obviously shouldn't happen.

EDIT2: I just realise what's happening. I have two patches that are conflicting with each other. Whoops.

Enverex wrote:

Did you get the Fluidsynth driver working in the end?

Nope. And tbh I stopped bothering the moment I found out that by using an alternative midi driver made MIDI sound better even with vanilla DOSBox. So why go through the hassle of implementing one in DOSBox, maybe breaking other things?

A quick update of my regular SVN builds: I decided to change the name for my enhanced build to "DOSBox Enhanced Community Edition" (ECE) to make it clearer that it's not my work but that of many others here in the forum. I also changed th spalsh screen showing the new name, but that's just cosmetics.

Maybe a little more interesting: I started building the vanilla SVN under Linux. So far it looks good, but I only have Linux running in a VM using VirtualBox. So I couldn't test everything, for example OpenGL output. Anyone willing to check out my Linux build on a physical Linux PC?

And btw.: I would really like to add my builds to the SVN wiki, so that other people looking for newer versione of DOSBox can find them there. Any chance?

Hi,
"SVN Builds for Mac OS w/functional ne2000 ethernet passthrough via WiFi"

What more DosLynx needs in DOSBox is:
‘NE2000 Ethernet Passthrough’:

http://users.ohiohills.com/fmacall/

The dosbox.com DOSBox 0.74 don't seem to be offered with that.
Their focus is old DOS games, which don't need Ethernet communications.

The Hal Megabuild 6 DOSBOX versions are dated.  But, have been found to work well in Linux and Windows wired connection.  But, not with a Windows WiFi connection.  The W(in)PCap documentation claims that is due to a limitation in windows.  These are discussed at arcor.de .  See URL.

http://home.arcor.de/h-a-l-9000/megabuild.html

Also given, there is a link to a Megabuild 6 DOSBox version made for the Intel based Mac, which has been tried and can NOT connect.
Even the NE2000 Ethernet Patch documentation claims builds on Mac do NOT work!
Perhaps this link sheds some light on the Mac problem:

https://stackoverflow.com/questions/15039551/ … n-mac-os-x-in-c

Q: Is there any chance updating MB6, to restore functional ‘NE2000 Ethernet Passthrough’ on the Intel OS X MacBook Pro Maverick via WiFi?

https://support.apple.com/kb/sp690?locale=en_US

1C:\DLX>ne2000.com 0x60 3
2Packet driver for NE2000, version 11.4.3
3Paeket driver skeleton copyright 1988-93, Crynwr Software.
4This program is freely copyable: source must be available: NO WARRANTY.
5See the file COPYING.DOC for details: send FAX to +1-315-268-9201 for a copy.
6
7System: [345]86 processor, ISA bus, Two 8259s
8Packet driver software interrupt is 0x60 (96)
9Interrupt number 0x3 (3)
10I/O port 0x300 (768)
11
12My Ethernet address is FF:FF:FF:FF:FF:FF
13
14C:\DLX>mount c programs

Yours,
nahum

Yesterplay80 wrote:

Enverex wrote:

Did you get the Fluidsynth driver working in the end?

Nope.

Just as an update, I did get this working in the end. Ended up managing to combine Fluidsynth, Munt32, Glide, OpenGL shaders and a quicker startup patch together successfully to current SVN.

Enverex wrote:

Yesterplay80 wrote:

Just as an update, I did get this working in the end. Ended up managing to combine Fluidsynth, Munt32, Glide, OpenGL shaders and a quicker startup patch together successfully to current SVN.

How did you get FluidSynth working after all? And what exactly does the quicker startup patch do?

nahum wrote:

Hi,
"SVN Builds for Intel Mac OS w/functional ne2000 ethernet passthrough via WiFi"

Hi,
No response from Daum Developer, giving thread post credence;
There appears to be a renewed interest in MegaBuilds and this one peaked my interest,
since it was reported functional on the same platform as mine, Intel OS X Maverick:

DOSBox SVN Daum build for Intel OS X

http://ykhwong.x-y.net

I just tried to launch it and this error was trapped:

1     
2MacBook-Pro:$ /Users/mac/Desktop/20150125_i386/dosbox ; exit;
3dyld: Library not loaded: /opt/local/lib/libSDL-1.2.0.dylib
4 Referenced from: /Users/mac/Desktop/20150125_i386/dosbox
5 Reason: image not found
6Trace/BPT trap: 5
7logout
8[Process completed]
9 

**Supported platforms: Intel OS X (Confirmed to work on Intel OS X Mavericks)
Q: Can this missing dependency be installed and how?
nahum