If you want to use it, use it. It's up to you really. I think the main issue is that you're not going to get much support if you run into trouble with it. It's essentially a collection of different patches (some of which, like the DOSBox-X additions, are very out of date) possibly modified and applied to an old version of DOSBox. There's no-one to support it or fix problems with it, so if you run into a problem you're likely to just get told to use a current revision or an build that's still actively worked on like ECE. I don't think people hate it, I just don't think anyone wants the hassle of trying to support and troubleshoot problems in something that's old and cobbled together, especially when it's abandoned by its maintainer. In addition, IIRC I found the 2015 builds to have quite a few issues, though I can't remember what they were off the top of my head as I haven't used it in years.

For a build with more features than stock DOSBox there's ECE, for more accuracy but also more complexity and less speed there's DOSBox-X.

What's wrong with official DOSBox SVN?

Since you are well informed that it is an abandoned build, then you are on your own if you insist on using that build. Be grateful to DOSBox developers that they had chosen to open source this piece of gem and let everyone, you and me to study the codes and relive our childhood nostalgia. It is not for them to support every single fork due to open sourcing.

If you had understood this, then you wouldn't have asked such a question in this forum.

SieBoi wrote:

So can anybody tell me what is so wrong with it? Anytime when somebody mentions SVN DAUM on the forum people lose their... well.. Everybody is saying its buggy and abandoned but what is that buggy part?.

My understanding is, too many patches. Save states, for example, is a monster patch that touches pretty much every virtual device in DosBox. Consider that plus all the extra devices Daum had, plus all the UI changes. With all the resultant code paths and potential for clashes, it's no surprise there have been issues.

Daum was an ambitious project with a pretty talented maintainer, but that size of scope is simply too large to sustain without significant re-architecting of the codebase.

Silanda wrote:

If you want to use it, use it. It's up to you really. I think the main issue is that you're not going to get much support if you run into trouble with it. It's essentially a collection of different patches (some of which, like the DOSBox-X additions, are very out of date) possibly modified and applied to an old version of DOSBox. There's no-one to support it or fix problems with it, so if you run into a problem you're likely to just get told to use a current revision or an build that's still actively worked on like ECE. I don't think people hate it, I just don't think anyone wants the hassle of trying to support and troubleshoot problems in something that's old and cobbled together, especially when it's abandoned by its maintainer. In addition, IIRC I found the 2015 builds to have quite a few issues, though I can't remember what they were off the top of my head as I haven't used it in years.

For a build with more features than stock DOSBox there's ECE, for more accuracy but also more complexity and less speed there's DOSBox-X.

I see, thanks for the alternatives, gotta ask though does ECE or X support 16:9? Im really stingy with my black lines 😵

kjliew wrote:

What's wrong with official DOSBox SVN?

Since you are well informed that it is an abandoned build, then you are on your own if you insist on using that build. Be grateful to DOSBox developers that they had chosen to open source this piece of gem and let everyone, you and me to study the codes and relive our childhood nostalgia. It is not for them to support every single fork due to open sourcing.

If you had understood this, then you wouldn't have asked such a question in this forum.

Well im already quite grateful for what dosbox devs did it would be awesome if you answered at least a tiny portion of question instead of antagonizing me 😀

gdjacobs wrote:

SieBoi wrote:

So can anybody tell me what is so wrong with it? Anytime when somebody mentions SVN DAUM on the forum people lose their... well.. Everybody is saying its buggy and abandoned but what is that buggy part?.

My understanding is, too many patches. Save states, for example, is a monster patch that touches pretty much every virtual device in DosBox. Consider that plus all the extra devices Daum had, plus all the UI changes. With all the resultant code paths and potential for clashes, it's no surprise there have been issues.

Daum was an ambitious project with a pretty talented maintainer, but that size of scope is simply too large to sustain without significant re-architecting of the codebase.

Hmm i see. So that's why everybody generally don't want to touch it. Maybe a bit too ambitious for its good. Thank you for the answer.

Also does anyone have an idea on the last two questions. And do you think that i should actually open new threads for those instead of asking here?

1. compatibility issues and it can be set on runtime.
2. c++ and no. Dosbox is NOT a command prompt program, but a full program. It just *looks* like a command prompt program. BUT you can start it from the command prompt

dosbox doesn't use DOS 5.00 or microsoft 6.22

It provides a self-written DOS that is DOS 5.00 compatible.

Qbix wrote:

dosbox doesn't use DOS 5.00 or microsoft 6.22

It provides a self-written DOS that is DOS 5.00 compatible.

Dominus wrote:

1. compatibility issues and it can be set on runtime.
2. c++ and no. Dosbox is NOT a command prompt program, but a full program. It just *looks* like a command prompt program. BUT you can start it from the command prompt

Thank you both of you for the informations.
Also which version of c++ is it?

Silanda thank you Dosbox-x works like wonders for me!

Whats the deal with SDL2 and SDLDRAW versions of DOSBOX-X, also what does the mingw builds do? I have really little info on mingw.

SDL is the library DOSBox uses to interface with the underlying graphics system in a portable way. SDL1.2->SDL2 was a major transition that changed/broke a lot of stuff. MINGW is just another compiler, a port of the GCC to Windows.

From that im asuming sdldraw is just more broken version of original sdl then. And whats the diffirence of non mingw versions then? Is it better to use mingw versions? And since we are on it which compiler does normal dosboxes c++ uses? VS17 did gave me a few errors when i tried to examine it.

Sdl_draw is just a function of SDL.
Mingw is just a compiler (well it is a bit mor complicated, but in a nutshell). People who want to compile Dosbox use a compiler they like to use. Dosbox is just code, it doesn't use a compiler.

Dominus wrote:

Sdl_draw is just a function of SDL.

And is it any means necessary?

Dominus wrote:

Mingw is just a compiler

I know it is but what does it change when you use dosbox-x with it? does it have any advantages?

Dominus wrote:

Dosbox is just code, it doesn't use a compiler.

Wait what do you mean by that? its not turbo or visual or anything? Its just raw c++ inside a notepad or something?

Sorry for the question bombs.

Yes, SDL_draw is necessary, but I have no idea why you are even bringing it up.

Mingw is just another way to compile the sourcecode, it mostly doesn't matter what you use to compile, as long as it works. Mingw works!

And yes the Dosbox source is written in c++. The sourcecode are simple text files with all the programming instructions in it. YOU use a compiler to translate this into a binary (the dosbox.exe) that you can run.

All of this seems to be way over your head, so I think you should just download dosbox-x or snapshot binaries and not worry sbout sourcecode or compiling

Dominus wrote:

Yes, SDL_draw is necessary, but I have no idea why you are even bringing it up.

I was bringing it up because of in dosbox-x folder there are versions called: "mingw", "mingw-lowend", "mingw-sdl2", "mingw-sdldraw", and all these folders had executables inside of them so i just wanted to know what their differences where since there was also non mingw versions simply titled "release" and "release sdl2".

Thanks for all the information!

Best ask that the Dosbox-x dev.
That's an important rule: except for straight Dosbox source snapshots ask the questions on the patched dosbox version where you got them.

I see, ok thank you.

Dominus wrote:

Sdl_draw is just a function of SDL.
People who want to compile Dosbox use a compiler they like to use. Dosbox is just code, it doesn't use a compiler.

So long as everything holds to the same language standard, of course.

SieBoi wrote:

I see, thanks for the alternatives, gotta ask though does ECE or X support 16:9? Im really stingy with my black lines :dead:

What do you mean? How do you want DOSBox to display a standard 4:3 image?

Ant_222 wrote:

SieBoi wrote:

I see, thanks for the alternatives, gotta ask though does ECE or X support 16:9? Im really stingy with my black lines 😵

What do you mean? How do you want DOSBox to display a standard 4:3 image?

As far as i know the non official builds that has a support for opengl or directx lets you make your dosbox real, non stretched (there was a word for this i swear, i forgot) 16:9 (not the graphical programs they are stretched) however without those it can't even stretch to 16:9, that was what i was asking.