Threads like these pop up from time to time, more so in the last year. Short answer : It takes a while, people have their own personal lives getting in the way of side projects like DOSBox.

Just use the SVN builds.

rebe wrote:

Unfortunately the latest release of dosbox has a bug that bugs Wine users:

https://bugs.winehq.org/show_bug.cgi?id=18118

That report just refers to 0.74 not including "the fix" without clearly explaining what the problem is and why it affects multiple games.

sorry, but this is just stupid in that context (NOT calling rebe stupid, mind you). Using WINE to run the Windows version of Dosbox instead of running a native Dosbox build...
But yes, you will likely be better off running an SVN built, be it native or in Wine (which I think is stupid).
And word of advice, when you ask about why there is no new version of any open source software, please assume that you are not the first to ask that, so use the search...

Is that what they are really doing? The DOSBox page on WINE's sight refers to the DOSBox version that ships with Debian and Ubuntu. https://wiki.winehq.org/DOSBox

It's what I can gather from the bug report

Dominus wrote:

sorry, but this is just stupid in that context (NOT calling rebe stupid, mind you). Using WINE to run the Windows version of Dosbox instead of running a native Dosbox build...
But yes, you will likely be better off running an SVN built, be it native or in Wine (which I think is stupid).
And word of advice, when you ask about why there is no new version of any open source software, please assume that you are not the first to ask that, so use the search...

64-bit builds of DosBox don't support 80-bit FPU precision, which results in graphical glitches in Carmageddon. An easy way to get around this is by running a 32-bit Windows copy of DosBox in WINE. This might affect other games too, I dunno, but I've generally had better luck running alternative DosBox builds under WINE than running them natively.

well, with a little tinkering you can have 32bit Dosbox in most OS and that's what I'm recommending.
Alternative builds can be tricky when the code has not been properly maintained and breaks on building on anything other than Windows. But that is not the problem with the bug report mentioned.

More frequent updates wouldn't hurt for PR purposes.

Dominus wrote:

It's what I can gather from the bug report

Then that is really silly. It is using WINE to run the Win installer that is not much more than a self extractor packed with DOSBox 0.65. It then uses WINE to run the included Win32 DOSBox 0.65. It is a poorly packaged game. It seems that all that is necessary is to extract the "Sid Meier's Railroad Tycoon" folder from $COMMONFILES\2K Games\" and copy the base files from the installer into it. Then start RDX2.BAT in the user's native DOSBox. So you are right, Dominus, it is stupid.

After reading more in depth, it is a bit different. The original bug report in 2009 was indeed just about using the bundled Dosbox 0.65. Eventually it became partly about Wine using the native DOSBox which is not correctly working in all cases.

The point is as follows as I can see it: WINE forwards to Dosbox to handle dos executables. As you can see e.g. in
https://bugs.winehq.org/show_bug.cgi?id=7848
the issue is:
"I downloaded and tested the 4 apps from comment 4 in 1.7.50, and Wine successfully starts all of them in DOSBox svn r3932. My guess is that they probably won't work when run from Wine with DOSBox 0.74, which is what is still packaged by most distros."

or Bug 18118 Multiple DOS apps/games fail to start in DOSBox when started from Wine (need DOSBox > 0.74)

this is related to https://wiki.winehq.org/DOSBox

"Since 0.75 is still not released, we rely on packagers to include the two patches mentioned below, for example since October 2015 Debian and Ubuntu ships them in their dosbox 0.74-4.1 "

With the patches to dosbox being:
DOSBox commit for changing the Z-Drive r3736
DOSBox commit for Wine style name mangling r3743

This is part of trunk. As you see debian distributions ship patched versions of 0.74 upstream code.

You might be more successful getting the packagers to include the two patches than getting the Dosbox devs to release a new version for those unable to spend half an hour to roll their own SVN built of Dosbox