OK, thanks. So it's 1.2.x that is used.
But it seems I stated this question too vaguely. What I meant is that it would be interesting to know what backends your libSDL has support for.
I don't even know what backends are possible on Mac, but the error message looks like it could be caused by missing support for X11.
Since libSDL was installed via homebrew, there is no config.log to examine. Maybe the backends can be determined by looking directly at the library files (on Linux, ldd can be used on .so files to see any dependancies - but I don't know what the Mac equivalent is)

mr.cat wrote on 2021-01-31, 17:52:

OK, thanks. So it's 1.2.x that is used. But it seems I stated this question too vaguely. What I meant is that it would be intere […]
Show full quote

OK, thanks. So it's 1.2.x that is used.
But it seems I stated this question too vaguely. What I meant is that it would be interesting to know what backends your libSDL has support for.
I don't even know what backends are possible on Mac, but the error message looks like it could be caused by missing support for X11.
Since libSDL was installed via homebrew, there is no config.log to examine. Maybe the backends can be determined by looking directly at the library files (on Linux, ldd can be used on .so files to see any dependancies - but I don't know what the Mac equivalent is)

On the Mac it is the command otool -L.

If I run that on libSDL.a, I see this:

1Archive : /usr/local/lib/libSDL.a
2/usr/local/lib/libSDL.a(SDL.o):
3/usr/local/lib/libSDL.a(SDL_error.o):
4/usr/local/lib/libSDL.a(SDL_fatal.o):
5/usr/local/lib/libSDL.a(SDL_audio.o):
6/usr/local/lib/libSDL.a(SDL_audiocvt.o):
7/usr/local/lib/libSDL.a(SDL_audiodev.o):
8/usr/local/lib/libSDL.a(SDL_mixer.o):
9/usr/local/lib/libSDL.a(SDL_mixer_MMX.o):
10/usr/local/lib/libSDL.a(SDL_mixer_MMX_VC.o):
11/usr/local/lib/libSDL.a(SDL_mixer_m68k.o):
12/usr/local/lib/libSDL.a(SDL_wave.o):
13/usr/local/lib/libSDL.a(SDL_cdrom.o):
14/usr/local/lib/libSDL.a(SDL_cpuinfo.o):
15/usr/local/lib/libSDL.a(SDL_active.o):
16/usr/local/lib/libSDL.a(SDL_events.o):
17/usr/local/lib/libSDL.a(SDL_expose.o):
18/usr/local/lib/libSDL.a(SDL_keyboard.o):
19/usr/local/lib/libSDL.a(SDL_mouse.o):
20/usr/local/lib/libSDL.a(SDL_quit.o):
21/usr/local/lib/libSDL.a(SDL_resize.o):
22/usr/local/lib/libSDL.a(SDL_rwops.o):
23/usr/local/lib/libSDL.a(SDL_getenv.o):
24/usr/local/lib/libSDL.a(SDL_iconv.o):
25/usr/local/lib/libSDL.a(SDL_malloc.o):
26/usr/local/lib/libSDL.a(SDL_qsort.o):
27/usr/local/lib/libSDL.a(SDL_stdlib.o):
28/usr/local/lib/libSDL.a(SDL_string.o):
29/usr/local/lib/libSDL.a(SDL_thread.o):
30/usr/local/lib/libSDL.a(SDL_timer.o):
31/usr/local/lib/libSDL.a(SDL_RLEaccel.o):
32/usr/local/lib/libSDL.a(SDL_blit.o):
33/usr/local/lib/libSDL.a(SDL_blit_0.o):
34/usr/local/lib/libSDL.a(SDL_blit_1.o):
35/usr/local/lib/libSDL.a(SDL_blit_A.o):
36/usr/local/lib/libSDL.a(SDL_blit_N.o):
37/usr/local/lib/libSDL.a(SDL_bmp.o):
38/usr/local/lib/libSDL.a(SDL_cursor.o):
39/usr/local/lib/libSDL.a(SDL_gamma.o):
40/usr/local/lib/libSDL.a(SDL_pixels.o):
41/usr/local/lib/libSDL.a(SDL_stretch.o):
42/usr/local/lib/libSDL.a(SDL_surface.o):
43/usr/local/lib/libSDL.a(SDL_video.o):
44/usr/local/lib/libSDL.a(SDL_yuv.o):
45/usr/local/lib/libSDL.a(SDL_yuv_mmx.o):
46/usr/local/lib/libSDL.a(SDL_yuv_sw.o):
47/usr/local/lib/libSDL.a(SDL_joystick.o):
48/usr/local/lib/libSDL.a(SDL_nullevents.o):
49/usr/local/lib/libSDL.a(SDL_nullmouse.o):
50/usr/local/lib/libSDL.a(SDL_nullvideo.o):
51/usr/local/lib/libSDL.a(SDL_diskaudio.o):
52/usr/local/lib/libSDL.a(SDL_dummyaudio.o):
53/usr/local/lib/libSDL.a(SDL_sysloadso.o):
54/usr/local/lib/libSDL.a(SDL_QuartzEvents.o):
55/usr/local/lib/libSDL.a(SDL_QuartzGL.o):
56/usr/local/lib/libSDL.a(SDL_QuartzVideo.o):
57/usr/local/lib/libSDL.a(SDL_QuartzWM.o):
58/usr/local/lib/libSDL.a(SDL_QuartzWindow.o):
59/usr/local/lib/libSDL.a(SDL_systhread.o):
60/usr/local/lib/libSDL.a(SDL_syssem.o):

61/usr/local/lib/libSDL.a(SDL_sysmutex.o):
62/usr/local/lib/libSDL.a(SDL_syscond.o):
63/usr/local/lib/libSDL.a(SDL_coreaudio.o):
64/usr/local/lib/libSDL.a(SDL_sysjoystick.o):
65/usr/local/lib/libSDL.a(AudioFilePlayer.o):
66/usr/local/lib/libSDL.a(AudioFileReaderThread.o):
67/usr/local/lib/libSDL.a(CDPlayer.o):
68/usr/local/lib/libSDL.a(SDLOSXCAGuard.o):
69/usr/local/lib/libSDL.a(SDL_syscdrom.o):
70/usr/local/lib/libSDL.a(SDL_systimer.o):

And if I run it on libSDL.dylib, I get this:

1/usr/local/lib/libSDL.dylib:
2	/usr/local/opt/sdl/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
3	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
4	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
5	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 52.0.0)
6	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
7	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
8	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
9	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
10	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
11	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1894.10.126)
12	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
13	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1348.12.4)
14	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.11.0)
15	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
16	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

OK, yeah to me that looks like there's no X-anything in there. Instead, you have OpenGL (QuartzGL?).
However I can't advise on what the correct action would be. I guess the options are to compile libSDL with X support, or use OpenGL somehow.

mr.cat wrote on 2021-01-31, 19:25:

OK, yeah to me that looks like there's no X-anything in there. Instead, you have OpenGL (QuartzGL?).
However I can't advise on what the correct action would be. I guess the options are to compile libSDL with X support, or use OpenGL somehow.

Yeah, everything I read online says that you do not need to specify X11 support when compiling SDL1/2 because macOS is supposed to handle all the translations to OpenGL automatically.

For the record, when I build SVN using an SDL 1.2.x (Mercurial) static library, and adding the latest 3dfx/Glide patch (download/file.php?id=83117) I actually get the same error as with ECE, being:

1glide.cpp:165:21: error: no member named 'info' in 'SDL_SysWMinfo'
2        hwnd = (HostPt)wmi.info.x11.window;

Also, when I compile the SDL static build, I use parameters that seemingly disable X11 and patch the XQuartz code. If I do not run these commands, the build fails. These commands only work on Mercurial SDL 1.2.x and not on any other build up to and including 1.2.15.

1$ ./configure --prefix=$HOME/Desktop/staticbuild --enable-static --disable-shared --disable-video-x11
2$ perl -p -i -e "/CGDirectPaletteRef palette;/d" ./src/video/quartz/SDL_QuartzVideo.h

So, this problem is not specific to the ECE build and seems common to any build using 3dfx/Glide patches on macOS.

I think I have hit a bit of a brick wall at the moment, but will consider it further. Whatever I am doing wrong, they solved it in DOSBox-X. When I used the auto-build script for Mac (either SDL1 or SDL2) I end up with a build that supports 3dfx software emulation. I have not had a chance to test the glide functionality yet, as I only managed to build the libraries and dylibs a few days ago.

If I have any breakthroughs I will report back.

To me it doesn't look like the problem is with SDL, it's the glide code assuming SDL has been built with X11 support. Is it actually meant to support running on macOS?

OK, thank you both for the clarification. I simply wasn't sure how this is supposed to work on macOS.

mr.cat wrote on 2021-02-01, 08:01:

OK, thank you both for the clarification. I simply wasn't sure how this is supposed to work on macOS.

It is not clear if it supposed to / able to work with macOS, at least with standard builds. I have no idea how the DOSBox-X team worked it out, but my focus is to see if it is possible for regular DOSBox or builds that have not been so extensively modified from the main code base.

All I have to go on at the moment is 12 year old threads where Dominus was able to patch something together on very old versions of macOS and DOSBox. I will keep researching, but it may well be impossible without some code rewrites within the patches themselves. OpenGlide does at least install for me, and produces all of the correct libraries on my system, and if it works on Mojave it is likely to continue in Catalina .. not sure about Big Sur, but I have no intention of going there for a long time.

1glide.cpp:165:21: error: no member named 'info' in 'SDL_SysWMinfo'
2        hwnd = (HostPt)wmi.info.x11.window;

If this was the problem, then perhaps you could simply remove the line or assign 'NULL' to the 'hwnd' native handle. Make sure that you also compiled a version of OpenGlide with '--enable-sdl'. IIRC OpenGlide SDL1.2 does not require native window handle. SDL1.2 seems to know how to retrieve and reuse an existing SDL window (which is DOSBox). DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox. If it did, then OpenGlide SDL1.2 will not work if DOSBox uses SDL2 for its window decoration.

kjliew wrote on 2021-02-02, 06:32:

DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox.

It hasn't, it uses 1.2 like SVN still does.

kjliew wrote on 2021-02-02, 06:32:

If this was the problem, then perhaps you could simply remove the line or assign 'NULL' to the 'hwnd' native handle. Make sure that you also compiled a version of OpenGlide with '--enable-sdl'. IIRC OpenGlide SDL1.2 does not require native window handle. SDL1.2 seems to know how to retrieve and reuse an existing SDL window (which is DOSBox). DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox. If it did, then OpenGlide SDL1.2 will not work if DOSBox uses SDL2 for its window decoration.

Thanks, the suggestion to assign NULL to 'hwind' avoids the error.

Running the make command again, resulted in an error about missing 'gl.h' and 'glext.h' files.

I located these in the OpenGL frameworks folder in my library/frameworks folder, but using these spat out way too many errors of all kinds (30+).

I then ran a search on my entire system, and found that I had a "GL" folder under "opt/X11/include/GL".

I copied these files into "usr/local/include/GL", and ran make again. This time there were 10 errors, as below.

12 warnings generated.
2mv -f .deps/voodoo_emu.Tpo .deps/voodoo_emu.Po
3g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE  -std=c++11 -O3 -mno-ms-bitfields  -MT voodoo_opengl.o -MD -MP -MF .deps/voodoo_opengl.Tpo -c -o voodoo_opengl.o voodoo_opengl.cpp
4In file included from voodoo_opengl.cpp:28:
5In file included from ./voodoo_opengl.h:33:
6In file included from ./voodoo_vogl.h:31:
7/usr/local/include/SDL/SDL_opengl.h:37:9: warning: '__glext_h_' macro redefined [-Wmacro-redefined]
8#define __glext_h_  /* Don't let gl.h include glext.h */
9        ^
10/usr/local/include/GL/glext.h:2:9: note: previous definition is here
11#define __glext_h_ 1
12        ^
13In file included from voodoo_opengl.cpp:28:
14In file included from ./voodoo_opengl.h:33:
15In file included from ./voodoo_vogl.h:31:
16/usr/local/include/SDL/SDL_opengl.h:116:9: warning: 'GL_GLEXT_VERSION' macro redefined [-Wmacro-redefined]
17#define GL_GLEXT_VERSION 29
18        ^
19/usr/local/include/GL/glext.h:56:9: note: previous definition is here
20#define GL_GLEXT_VERSION 20160609
21        ^
22voodoo_opengl.cpp:1054:34: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
23                extra->info->so_shader_program=m_hProgramObject;
24                                               ^~~~~~~~~~~~~~~~
25voodoo_opengl.cpp:1055:33: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
26                extra->info->so_vertex_shader=m_hVertexShader;
27                                              ^~~~~~~~~~~~~~~
28voodoo_opengl.cpp:1056:35: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
29                extra->info->so_fragment_shader=m_hFragmentShader;
30                                                ^~~~~~~~~~~~~~~~~
31voodoo_opengl.cpp:1082:24: error: comparison between pointer and integer ('GLhandleARB' (aka 'void *') and 'UINT32' (aka 'unsigned int'))
32                if (m_hProgramObject != extra->info->so_shader_program) {
33                    ~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
34voodoo_opengl.cpp:1083:26: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
35      (aka 'unsigned int')
36                        glUseProgramObjectARB(extra->info->so_shader_program);
37                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38voodoo_opengl.cpp:1084:36: error: assigning to 'GLhandleARB' (aka 'void *') from incompatible type 'UINT32' (aka 'unsigned int')
39                        m_hProgramObject = extra->info->so_shader_program;
40                                           ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
41voodoo_opengl.cpp:1801:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
42      (aka 'unsigned int')
43                                        if (info->so_vertex_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_vertex_shader);
44                                                                                           ^~~~~~~~~~~~~~~~~~~~~~~
45voodoo_opengl.cpp:1802:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
46      (aka 'unsigned int')
47                                        if (info->so_fragment_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_fragment_shader);
48                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~
49voodoo_opengl.cpp:1803:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
50      (aka 'unsigned int')
51                                        if (info->so_vertex_shader >= 0) glDeleteObjectARB(info->so_vertex_shader);
52                                                                                           ^~~~~~~~~~~~~~~~~~~~~~
53voodoo_opengl.cpp:1804:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
54      (aka 'unsigned int')
55                                        if (info->so_fragment_shader >= 0) glDeleteObjectARB(info->so_fragment_shader);
56                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~~
572 warnings and 10 errors generated.

If the mods want this discussion shifted elsewhere, I am fine with that. I guess it is relevant to any Mac user wanting to successfully compile ECE, which is still my primary goal.

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

mr.cat wrote on 2021-02-02, 16:41:

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing? Could yo […]
Show full quote

Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

1patch -p1 < mmx_20200624.diff
2./autogen.sh -lssp
3./configure LIBS="-Wl,--as-needed -lssp"
4make LIBS="-Wl,--as-needed -lssp"
5make

these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The file cpu.cpp got entries about: if C_MMX - CPU_ARCHTYPE_PMMXSLOW etc. and dosbox.cpp writes:

1	const char* cputype_values[] = { "auto", "386", "386_slow", "486_slow", "pentium_slow", 
2#if C_MMX
3		"pentium_mmx_slow",
4#endif
5		"386_prefetch", 0};

Chuck wrote on 2021-02-03, 10:31:

these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The fil […]
Show full quote

mr.cat wrote on 2021-02-02, 16:41:

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing? Could yo […]
Show full quote

Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

Copy code to clipboard

1patch -p1 < mmx_20200624.diff
2./autogen.sh -lssp
3./configure LIBS="-Wl,--as-needed -lssp"
4make LIBS="-Wl,--as-needed -lssp"
5make

these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The file cpu.cpp got entries about: if C_MMX - CPU_ARCHTYPE_PMMXSLOW etc. and dosbox.cpp writes:

Copy code to clipboard

1	const char* cputype_values[] = { "auto", "386", "386_slow", "486_slow", "pentium_slow", 
2#if C_MMX
3		"pentium_mmx_slow",
4#endif
5		"386_prefetch", 0};

Thanks. I tried this on Linux and this bug is present there too:

"pentium_mmx_slow" is not a valid value for variable: cputype.

Looks like that C_MMX isn't getting set for some reason. You can force it by adding defines, for me the command line I used was:
CPPFLAGS="-I/usr/local/include/openglide/ -DC_FPU=1 -DC_MMX=1" ./configure

That will introduce a new set of errors (undefined references) though...
The Makefile in src/cpu directory needs some patching, as it is missing mmx. Once that is added, the compilation goes through.
The easiest way to do it is to just add mmx.cpp in src/cpu/Makefile.am, and re-run autogen.sh before compilation.

Finally got working DosBox ECE with MMX patch. However i ran the make command 3 times now because of the errors that stops compiler. I do like this: copied sdk2_* files from openglide source code to include folder, then i edit src\cpu\makefile.am and add mmx.cpp entry. The first 2 commands into Msys2:

1patch -p1 < mmx_20200624.diff
2./autogen.sh -lssp

after them i edit the file src\gui\midi_fluidsynth.h deleting: LOG(LOG_MISC,LOG_WARN)("MIDI:fluidsynth: Unknown Command: %08lx", (long)msg) remaining only ; and at the end configure and make:

1CPPFLAGS="-DC_FPU=1 -DC_MMX=1" ./configure LIBS="-Wl,--as-needed -lssp"
2CPPFLAGS="-DC_FPU=1 -DC_MMX=1" make LIBS="-Wl,--as-needed -lssp"
3make LIBS="-Wl,--as-needed -lssp"
4CPPFLAGS="-DC_FPU=1 -DC_MMX=1" make

as far as i know all this steps are needed to get the .exe. I don't know for now if something else doesn't work, but 3d acceleration (voodoo card), mmx, mounting .img files and sound blaster 16 surely works (got no errors from status window). Thanks for the help.

SVN is approaching r4444

please yesterplay, do whatever it takes to release an ECE build based on that...

my OCD demands it! ;D

hey guys, can anyone tell me how to install this on linux? does it have to be installed in the usr/bin or can it be installed in the home directory, or can i just copy the folder in the .dbgl/ . also where is the dosbox.conf with this release? do i need to install the latest version of dosbox and use that config? its a bit confusing because i didn't see a tutorial or a readme with directions.

I normally create a ~/bin directory for such purposes. On some Linux distro's that directory is already in your path.

The possibly tricky thing is that DOSBox ECE is only provided as a 32bit build, so you need to have the necessary 32bit libs installed for it to work.

DOSBox ECE, similar to regular DOSBox and DOSBox SVN puts its config file by default in ~/.dosbox/
The default filename is dosbox-ECE.conf

_Rob wrote on 2021-03-04, 18:13:

I normally create a ~/bin directory for such purposes. On some Linux distro's that directory is already in your path. […]
Show full quote

I normally create a ~/bin directory for such purposes. On some Linux distro's that directory is already in your path.

The possibly tricky thing is that DOSBox ECE is only provided as a 32bit build, so you need to have the necessary 32bit libs installed for it to work.

DOSBox ECE, similar to regular DOSBox and DOSBox SVN puts its config file by default in ~/.dosbox/
The default filename is dosbox-ECE.conf

i have downloaded the linux version of dosbox ece from https://dosboxece.yesterplay.net/, in the archive there is only the dosbox bin, there wasn't a dosbox-ECE.conf, do i need to make my own config file ?

lilkuz2005 wrote on 2021-03-09, 10:35:

_Rob wrote on 2021-03-04, 18:13:

I normally create a ~/bin directory for such purposes. On some Linux distro's that directory is already in your path. […]
Show full quote

I normally create a ~/bin directory for such purposes. On some Linux distro's that directory is already in your path.

The possibly tricky thing is that DOSBox ECE is only provided as a 32bit build, so you need to have the necessary 32bit libs installed for it to work.

DOSBox ECE, similar to regular DOSBox and DOSBox SVN puts its config file by default in ~/.dosbox/
The default filename is dosbox-ECE.conf

i have downloaded the linux version of dosbox ece from https://dosboxece.yesterplay.net/, in the archive there is only the dosbox bin, there wasn't a dosbox-ECE.conf, do i need to make my own config file ?

No need for that. The default conf file is created at first launch in ~/.dosbox.