VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

First post, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Please post all questions concerning DOSBox ECE in this thread for now on, so we can keep other threads tidy and on topic!

I compiled a build of DOSBox ECE for Linux. Consider it highly experimental, since I only run Linux in a VM, I can't test all the features, because the VM is lacking hardware acceleration. So it would be very nice if someone could run some tests with it. It comes (or should come) with all the features of the Windows build, minus the possibility to select the midi device by name or a part of it. Please download it (link is in my signature), play with it and let me know if something's not working or missing!

Last edited by Yesterplay80 on 2018-12-10, 09:11. Edited 2 times in total.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 1 of 1550, by filipetolhuizen

User metadata
Rank Oldbie
Rank
Oldbie

Hello, any chance you could include the 128mempatch and Pentium_MMX (for CPU/memory hungry games like Blood and Win9x)? Games like MDK would also take benefit from Pentium_MMX. Also the patch to configure video memory size would be good for Build games.

Reply 2 of 1550, by collector

User metadata
Rank l33t
Rank
l33t

More patches for more instabilities? I really hope that ECE does not go too far astray from mainline DOSBox. DOSBox-X would be a better route for Win9x and MMX. I love that ECE has the patches that increase accuracy but does not go down the path of Daum and get broken by needless bells and whistles.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 3 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Generally I'm not a big fan of adding things that only a handful of games can make use of, as collector said every patch that adds a new feature might break others, so I rather concentrate on those that all or at least many games can gain profit from.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 5 of 1550, by collector

User metadata
Rank l33t
Rank
l33t
filipetolhuizen wrote:

The Daum build was working fine just until it merged with doxbox-x.

A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 6 of 1550, by Stiletto

User metadata
Rank l33t++
Rank
l33t++

The MAME world has something they call "MAME Compiler 64" (and a few others). Makes patching and compiling a breeze for n00bs on Windows. I'm not generally a fan, but until the next DOSBox releases, maybe the DOSBox community needs something similar so that they're not dependent as much on packagers, only on patch authors to maintain their preferred patches?

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 7 of 1550, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Such a frontend would be toolchain- and platform-specific, especially since DOSBox, unlike the "MAME World", mercifully does not use its own toolchain that is annoyingly redone every couple of months. Most DOSBox patch authors, including myself, provide a compiled Win32 executable of the latest SVN with that particular patch applied, so compilation is not required when just using one particular patch, at least on the Win32 platform. And when it comes to applying multiple patches, the potential incompatibilities between the several patches cannot be properly sorted out by a frontend anyway, only by a competent human packager.

(And if the "MAME World" is doing something a particular way, my gut reaction is to do avoid doing that at all cost.)

Reply 8 of 1550, by filipetolhuizen

User metadata
Rank Oldbie
Rank
Oldbie
collector wrote:
filipetolhuizen wrote:

The Daum build was working fine just until it merged with doxbox-x.

A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.

I'd love to. I guess I keep asking everyone else because of my programming skills total lack.

Reply 9 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
filipetolhuizen wrote:
collector wrote:
filipetolhuizen wrote:

The Daum build was working fine just until it merged with doxbox-x.

A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.

I'd love to. I guess I keep asking everyone else because of my programming skills total lack.

It's the most easiest part to further your programming knowledge in a couple of steps...
1. follow the guide on how to compile Dosbox yourself (essentially setting up your own development environment)
2. compile Dosbox from SVN and test that
3. learn how to apply a simple patch
4. learn how to apply a more advanced patch and deal with errors when it doesn't apply (with a text editor going through the changes - since the patch is a text file and the source code is made up of text files, it is simple looking at it and finding the pattern where the patch should have applied to)
5. learn how to add mor dependeny libraries to your development environment for patches that require those
6. have no more time to actually play since you are always busy with 4. and 5.and dealing with the fallout of the builds you offered for everyone else 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 10 of 1550, by gandhig

User metadata
Rank Member
Rank
Member

Vanilla DOSBox Linux build throws 'error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory'. libasound2 package was showing as already installed.

While trying to run DOSBox ECE under Linux(Ubuntu 16.04 LTS), I'm getting 'error while loading shared libraries: libSDL_sound-1.0.so.1: cannot open shared object file: No such file or directory'. libsdl-sound1.2 (1.0.3-7build1) was not pre-installed. Even after installation the error doesn't go away.

I'm a relatively new linux user. What am I missing?

BTW Windows ECE build works flawlessly, thanks heaps 😀 .

Last edited by gandhig on 2017-02-19, 05:29. Edited 1 time in total.

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 11 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

@yesterplay, make a static build of Dosbox for linux, meaning you compile all dependenies into DOSBox, otherwise you run into these above problems.
Especially with SDL_sound which can be compiled against SDL 1.2x or SDL2 on the other systems and thus might not be compatible.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 12 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

@yesterplay, make a static build of Dosbox for linux, meaning you compile all dependenies into DOSBox, otherwise you run into these above problems.

I thought I'd done that, but it seems I didn't. I'll look into it!

UPDATE: Please check out this binary:

Filename
dosbox.tar.gz
File size
1.21 MiB
Downloads
666 downloads
File license
Fair use/fair dealing exception

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 13 of 1550, by gandhig

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:

UPDATE: Please check out this binary:

dosbox.tar.gz

Still getting the same error. Is it Ok to run the executable from any user folder?

Dosbox SVN r4019 + savestates Build (Alpha)
1st thread & the only one related to the forum(?)...warning about modern-retro combo
Dead, but, Personal Favourite
Replacement for Candy Crush...Train the Brain

Reply 14 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
gandhig wrote:

Still getting the same error. Is it Ok to run the executable from any user folder?

It should be. I'm no Linux pro neither, I installed it only to get DOSBox ECE running. AFAIK it should run from every folder, the problem is that I obviously don't get all the dependent libraries compiled into DOSBox. Does anyone know which switches I have to set when configuring DOSBox?

LIBS="-lasound -lSDL_sound etc."

obviously didn't work.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 15 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

No, those are the dynamic links. You need to exchange this with the path to the *.a files of the libraries. You can try this configure option (along with whatever else you pass to configure)
./configure LDFLAGS="-static"
But I'm not a linux guy and on OS X Ihave to rewrite LIBS= manually to use the static libs (because Apple prevents easy static linking).
If you have to do it manually get the SDL libs stuff via "sdl-config --static-libs" (or similar sdl-config -h should tell you).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 16 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

OK, I tried the following:

Checked out a fresh SVN of DOSBox
ran /autogen.sh
ran ./configure LDFLAGS="-static-libgcc -static-libstdc++ -s"
ran sdl-config --static-libs, which resultetd in the following output:

-L/usr/lib/i386-linux-gnu -lSDL -lpthread -lm -ldl -lasound -lm -ldl -lpthread -lpulse-simple -lpulse -lX11 -lXext -L/usr/lib/i386-linux-gnu -lcaca -lpthread

made the following changes to the file "makefile":

LIBS = /usr/lib/i386-linux-gnu/libSDL.a /usr/lib/libasound.a /usr/lib/i386-linux-gnu/libm.a /usr/lib/i386-linux-gnu/libdl.a /usr/lib/i386-linux-gnu/libpthread.a /usr/lib/i386-linux-gnu/libvorbisfile.a /usr/lib/i386-linux-gnu/libvorbis.a /usr/lib/i386-linux-gnu/libogg.a /usr/lib/i386-linux-gnu/libpng12.a /usr/lib/i386-linux-gnu/libz.a /usr/lib/i386-linux-gnu/libSDL_net.a /usr/lib/i386-linux-gnu/libSDL_sound.a /usr/lib/i386-linux-gnu/libX11.a /usr/lib/i386-linux-gnu/libGL.a 

and

SDL_LIBS = -L/usr/lib/i386-linux-gnu -lSDL -lpthread -lm -ldl -lasound -lm -ldl -lpthread -lpulse-simple -lpulse -lX11 -lXext -L/usr/lib/i386-linux-gnu -lcaca -lpthread

Compiled and got a DOSBox binary the same size as before. Running "ldd dosbox" also resulted in the same dependencies as before.

I then changed the SDL_LIBS library list to

SDL_LIBS = -L/usr/lib/i386-linux-gnu/libSDL.a -L/usr/lib/libasound.a -L/usr/lib/i386-linux-gnu/libm.a -L/usr/lib/i386-linux-gnu/libdl.a -L/usr/lib/i386-linux-gnu/libpthread.a -L/usr/lib/i386-linux-gnu/libvorbisfile.a -L/usr/lib/i386-linux-gnu/libvorbis.a -L/usr/lib/i386-linux-gnu/libogg.a -L/usr/lib/i386-linux-gnu/libpng12.a -L/usr/lib/i386-linux-gnu/libz.a -L/usr/lib/i386-linux-gnu/libSDL_net.a -L/usr/lib/i386-linux-gnu/libSDL_sound.a -L/usr/lib/i386-linux-gnu/libX11.a -L/usr/lib/i386-linux-gnu/libXext.a -L/usr/lib/i386-linux-gnu/libGL.a -L/usr/lib/i386-linux-gnu/libcaca.a -lpulse-simple -lpulse

, leaving only the shared libraries for pulseaudio and replacing everything else wth static libraries.

But even now the resulting binary is only 3,7 MB and still has all the dependiencies from the shared libraries:

	linux-gate.so.1 =>  (0xb77c7000)
libSDL_sound-1.0.so.1 => /usr/lib/i386-linux-gnu/libSDL_sound-1.0.so.1 (0xb775f000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xb7649000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb762b000)
libSDL-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 (0xb7589000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb755e000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7543000)
libSDL_net-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL_net-1.2.so.0 (0xb753d000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb73f1000)
libGL.so.1 => /var/lib/VBoxGuestAdditions/lib/libGL.so.1 (0xb730f000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb72ba000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7104000)
/lib/ld-linux.so.2 (0x80027000)
libmikmod.so.3 => /usr/lib/i386-linux-gnu/libmikmod.so.3 (0xb70b9000)
libvorbisfile.so.3 => /usr/lib/i386-linux-gnu/libvorbisfile.so.3 (0xb70ad000)
libFLAC.so.8 => /usr/lib/i386-linux-gnu/libFLAC.so.8 (0xb704d000)
libogg.so.0 => /usr/lib/i386-linux-gnu/libogg.so.0 (0xb7044000)
libspeex.so.1 => /usr/lib/i386-linux-gnu/sse2/libspeex.so.1 (0xb701f000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb701a000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb7010000)
libpulse-simple.so.0 => /usr/lib/i386-linux-gnu/libpulse-simple.so.0 (0xb700a000)
libpulse.so.0 => /usr/lib/i386-linux-gnu/libpulse.so.0 (0xb6fb0000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb6f9b000)
libcaca.so.0 => /usr/lib/i386-linux-gnu/libcaca.so.0 (0xb6ed1000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6eaa000)
VBoxOGLcrutil.so => /usr/lib/i386-linux-gnu/VBoxOGLcrutil.so (0xb6df9000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xb6df5000)
libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb6df1000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6dea000)
libopenal.so.1 => /usr/lib/i386-linux-gnu/libopenal.so.1 (0xb6d72000)
libvorbis.so.0 => /usr/lib/i386-linux-gnu/libvorbis.so.0 (0xb6d46000)
libpulsecommon-8.0.so => /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-8.0.so (0xb6cbe000)
libjson-c.so.2 => /lib/i386-linux-gnu/libjson-c.so.2 (0xb6cb2000)
libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb6c57000)
libslang.so.2 => /lib/i386-linux-gnu/libslang.so.2 (0xb6b2b000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb6af6000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb6ad3000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6acf000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6ac7000)
libsystemd.so.0 => /lib/i386-linux-gnu/libsystemd.so.0 (0xb6a39000)
libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb6a2f000)
libsndfile.so.1 => /usr/lib/i386-linux-gnu/libsndfile.so.1 (0xb69b6000)
libasyncns.so.0 => /usr/lib/i386-linux-gnu/libasyncns.so.0 (0xb69af000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb6988000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb6962000)
libgcrypt.so.20 => /lib/i386-linux-gnu/libgcrypt.so.20 (0xb68b3000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6896000)
libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xb687b000)
libvorbisenc.so.2 => /usr/lib/i386-linux-gnu/libvorbisenc.so.2 (0xb67ee000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb67d5000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6760000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb674a000)

Btw, why is there a dependency from libFLAC in vanilla DOSBox?

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 17 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Did you change both makefiles (root and /src)? Did you try with the LDFLAG I wrote (just -static)?
Flac dependency comes from SDL_sound. You need to strip SDL_sound off all dependencies you don't need.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 18 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

Did you change both makefiles (root and /src)? Did you try with the LDFLAG I wrote (just -static)?

No, just the on under root. Now it seems to try to compile using the static libraries but results in a lot of errors, I'll try to use only the static libraries for the SDL stuff for the beginning.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 19 of 1550, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

yes, this seems a bit complicated. it really shouldn't pull in all of the system dlls. Very problematic are the Virtualbox stuff. This shouldn't really be in at all.

As a rough guideline, my OS X patch for the makefiles looks like this

--- ./Makefile 
+++ ./Makefile
139c139
< LIBS = -lSDL_sound -L/opt/i386/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -lpng -lz -lSDL_net -framework OpenGL -framework CoreMIDI -framework AudioUnit -framework AudioToolbox
---
> LIBS = -L/opt/i386/lib /opt/i386/lib/libSDLmain.a /opt/i386/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit -framework CoreMIDI /opt/i386/lib/libpng.a /opt/i386/lib/libz.a /opt/i386/lib/libSDL_net.a /opt/i386/lib/libSDL_sound.a /opt/i386/lib/libogg.a /opt/i386/lib/libvorbis.a /opt/i386/lib/libvorbisfile.a /opt/i386/lib/libvorbisenc.a
155c155
< SDL_LIBS = -L/opt/i386/lib -lSDLmain -lSDL -Wl,-framework,Cocoa
---
> SDL_LIBS = -L/opt/i386/lib /opt/i386/lib/libSDLmain.a /opt/i386/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit

--- ./src/Makefile
+++ ./src/Makefile
143c143
< LIBS = -lSDL_sound -L/opt/i386/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -lpng -lz -lSDL_net -framework OpenGL -framework CoreMIDI -framework AudioUnit -framework AudioToolbox
---
> LIBS = -L/opt/i386/lib /opt/i386/lib/libSDLmain.a /opt/i386/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit -framework CoreMIDI /opt/i386/lib/libpng.a /opt/i386/lib/libz.a /opt/i386/lib/libSDL_net.a /opt/i386/lib/libSDL_sound.a /opt/i386/lib/libogg.a /opt/i386/lib/libvorbis.a /opt/i386/lib/libvorbisfile.a /opt/i386/lib/libvorbisenc.a
159c159
< SDL_LIBS = -L/opt/i386/lib -lSDLmain -lSDL -Wl,-framework,Cocoa
---
> SDL_LIBS = -L/opt/i386/lib /opt/i386/lib/libSDLmain.a /opt/i386/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,IOKit

(all the framework stuff is OS X specific system stuff, so please disregard 😀)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper