VOGONS


First post, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

Does it work? Is there a speed improvement? Main thread about it? Perhaps a sticky? I'm looking but I'm not seeing anything in my search. Would be good to add to the https://www.dosbox.com/wiki/BuildingDOSBox wiki. configure --help just lists the options to disable the x86 or x64 recompiler. Sure, fine, but I want that sweet sweet x64 performance boost if there's one to be had.

Reply 3 of 16, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Well the recompiler has to match the target. If it's compiling as a 32-bit app it uses the x86 recompiler, if it's compiling a 64-bit app it uses the x64 recompiler. You can't build it as a 32-bit app with the x64 recompiler because that just won't work.
Which compiler are you actually using?

Reply 6 of 16, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

There's 64bit mingw: https://sourceforge.net/projects/mingw-w64/ and 64bit msys: https://sourceforge.net/projects/msys2/
but no joy in compiling, doesn't even get past autogen before crapping out, hence asking about anyone having already worked out the process to successfully compile. With x64 recompiler being included I'd imagine someone already has the build environment worked out to get it compiled, but just grabbing and installing 64 bit mingw and msys doesn't do it.

Reply 8 of 16, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

Same result with installer from msys2.org, paths aren't automatically configured correctly, stops from not finding the autogen tools and I'd imagine everything else. You used the mingw installer from the url I posted? All I've done was run the mingw and msys2 installers to get where I'm at, did you take any other steps for mingw & msys to see each other? 64bit compile process definitely needs to be added to the build wiki.

Reply 10 of 16, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Using mingw-w64 w/MSYS 2 is really no different than mingw w/MSYS main difference nowadays is that msys win32 tools are so outdated that you have to compile the latest ver or download them otherwise you'll run into issues when compiling DOSBox. You are better off using mingw or mingw-w64 on Linux and skip MSYS and MSYS2 since there are always issues you'll encounter with them.

I don't recommend using MSYS or MSYS2, use Linux or WSL but if you must the following will provide you with a mingw-w64 w/ MSYS2 environment that will allow you to compile DOSBox for XP+. The version of mingw-w64 provided by the msys2 repo generates binaries that require posix (so XP+) unlike the mingw-w64 provided by Linux repos which don’t.

The official ver of DOSBox iz compiled on Linux so best to stick with what the devs use.

MSYS2
http://www.msys2.org/
msys2-i686-20161025.exe (32bit) (Only use this if you are on a 32bit OS)
or
msys2-x86_64-20161025.exe (64bit)

INSTALL MSYS2

1. Install MSYS2

2.
32bit MSYS2 ONLY
Run rebase: C:\msys32\autorebase.bat
Run MSYS2 C:\msys32\msys2_shell.cmd

64bit
Run MSYS2 C:\msys64\msys2_shell.cmd

3. UPDATE MSYS2
Run "pacman -Syu"
*You may receive error messages about catgets and libcatgets. Remove them.
Close MSYS2 when prompted. May have to end the "terminal" process in Task Manager.
Run MSYS2 C:\msysxx\msys2_shell.cmd
Run "pacman --noconfirm -Syu"
Exit MSYS2

4. Backup the c:\MSYSXX directory

UPDATE AND INSTALL THE TOOLS

1. Open C:\msysxx\msys2_shell.cmd

2. Run the following command in MSYS2:

"pacman -S --needed --noconfirm {libtool,pkg-config,automake-wrapper,autoconf,make,git,svn,mercurial,tar,gdb,patch,libiconv}"

3. INSTALL MINGW-W64
** Launch C:\msysxx\mingw32.exe to install and use 32BIT MINGW
** Launch C:\msysxx\mingw64.exe to install and use 64bit MINGW

1.
Run pacman -S --needed --noconfirm {mingw-w64-i686-clang,mingw-w64-x86_64-clang}
This should get you the latest gcc as well last time I installed it did.


VERIFICATION
Open mingw32.exe or mingw64.exe and type in "g++ -v" and "clang++ -v", if setup properly then the command should work. If not then you did something wrong.
Last edited by DosFreak on 2020-08-18, 04:08. Edited 3 times in total.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 11 of 16, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

The type of shell from mintty decides the code generation. MSYS2 for POSIX (linked with msys-2.0.dll), Mingw-w64 32-bit for native WIN32 code and Mingw-w64 64 bit for native code 64 bit. POSIX packages do not prefix with mingw-w64-{i686,x86_64}. DosFreak's instruction may work, but it is overly complicated. There is no need to switch shell type to install the packages. You can install any packages from any of the code generation in any shell type, so I would just recommend you start with Mingw-w64 64 bit shell to install all the necessary packages to build native WIN64 DOSBox.

You should get a nice GUI prompt for shell type running mintty.

Untitled.png
Filename
Untitled.png
File size
3.59 KiB
Views
399 views
File license
Fair use/fair dealing exception

Reply 12 of 16, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote on 2020-08-18, 03:46:

I don't recommend using MSYS or MSYS2, use Linux or WSL but if you must the following will provide you with a mingw-w64 w/ MSYS2 environment that will allow you to compile DOSBox for XP+. The version of mingw-w64 provided by the msys2 repo requires posix (so XP+) unlike the mingw-w64 provided by Linux repos which don’t.

That wasn't quite true. My DOSBox built with MSYS2/mingw-w64 does not require POSIX. It is linked with msvcrt and DLLs from mingw-w64 DLLs (lib*.dll) and all of them are native WIN64. WSL on Windows 10 does not generate native WIN64 code, which is quite different from using MSYS2/mingw-w64.

MSYS2/Mingw-w64 native codes *officially* do not support XP because current winpthreads requires Windows 7 level of Windows APIs. This can be fixed by downgrading the package or explicitly, statically linked with the older version of winpthreads before it started switching to newer Windows APIs. However, it is unknown if other libraries would break by doing this, so consider this an unsupported hack.

Reply 13 of 16, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2020-08-18, 03:37:

How did you install the installer from msys2.org?

Eh? There's just running the installer as far as I know. I've uninstalled both and reinstalled msys2 so far, following the steps from msys2.org,
running msys2-x86_64-20200720.exe, select and install to path, run msys2 now, pacman -Syu, close and restart, pacman -Su. Contrary to mys2 org's claim of mission accomplished, no, this doesn't produce a finished build environment.
dosfreaks' install steps roughly the same(ps why step 4, backup msysxxx on a fresh install?,) do dosfreaks' update step pacman -S --needed --noconfirm {libtool,pkg-config,automake-wrapper,autoconf,make,git,svn,mercurial,tar,gdb,patch,libiconv} okie-doke, done.
If you try to build dosbox here, autoconf now successfully runs, but configure will stop from missing the compiler, where mingw comes into play.
Do dosfreaks' mingw install step(takes awhile): pacman -S --needed --noconfirm {mingw-w64-i686-clang,mingw-w64-x86_64-clang}
finally finishes installing, try to rerun configure and.. crash. after repeatedly trying to force kill the locked up msys process(it refused to die) it finally does.
restart mys console, and try configuring again, compiler found, past that point, but configure doesn't complete, no sdl.
try installing with pacman, pacman -S --needed sdl, not found, pacman -S --needed SDL, not found
okay, lets build sdl, tar xvf SDL-1.2.15.tar.gz, autogen, configure, make install, no reported errors
try dosbox configure again, and.. completes.
make.. fingers crossed.. dosbox.exe
does it run? yes.
using x64 recompiler? hmm, how to tell, I don't know a simple check other than to add a log in one of the x64 recompiler functions, so.. LOG_MSG("x64 gen_call_function");
using x64 recompler? yes!
faster? yes! 6-15% going by various benchmarks.
Now a part of the dosbox x64 master race! kjliew and DosFreak thanked profusely at the acceptance speech, jmarsh too.

Reply 14 of 16, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I think you got most of the stuffs right. MSYS2 is very simple and straight forward and similar to typical Linux build tools and environment, especially if you are also a fan of ArchLinux/pacman.
1. You will need MSYS2 POSIX tools for running standard autogen.sh, configure scripts and GNU make.

$ pacman -Su --needed autoconf automake autogen awk bison flex make m4

2. You will need WIN64 native code compilers and binutils

$ pacman -Su --needed mingw-w64-x86_64-{gcc,binutils,libtool,pkg-config}

3. Finally, get the neccessary libraries for DOSBox

$ pacman -Su --needed mingw-w64-x86_64-{SDL,SDL_net,libpng}

Notice that you need to prefix "mingw-w64-x86_64" for the packages for native code. Some packages (such as gcc, binutils etc) are available in all 3 flavors. You *DO NOT need to build SDL from source. You should refrain from building from source if you can get same stuffs from pacman packaging ecosystem to prevent breakage from a nice and sane build environment. If you do not know what you are doing, then you could potentially have native codes tainted by POSIX libraries and this is a NO-NO.

Reply 15 of 16, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2020-08-18, 13:58:

You *DO NOT need to build SDL from source.

That might depend which version of SDL is provided? There was a bug that would cause an invalid memory access, and due to it happening inside a window procedure the "application compatibility wizard" or whatever it's called would pop up and say "This program's busted so I'm going to babysit it for you" and then it would just eat any future bad memory references. Undoing it required manually editing the registry to unflag DOSBox as a badly behaving app.

Reply 16 of 16, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox SVN only needs SDL1.2 and I think that has been stable for some time and no longer being actively developed. The version provided is the last stable version, I believe, and I never had any issue with that.