Google Drive
Contains all Mingw environments and all files required to compile DOSBox.
Now includes DOSBox binaries for NT 3.51, 95, 98+ and XP+ 64bit compiled with Mingw and Mingw-W64 w/ gcc 7.x.0 https://drive.google.com/open?id=1G13rkLjYDDv … VZfop3aMO8U9mvV
Everything is on Google Drive now except for the attached and the posts in this thread awaiting review.
Recommendations for compiling:
*CLANG not recommended due to issues with ogg and flac. If you don't need those then use it.
*Posix builds require XP+ (Possibly 2000 can work with unofficial updates)
Linux builds
i386
?
i686
1st Ubuntu VM w/ GCC
2nd Windows 10 WSL w/ Ubuntu w/ GCC
Windows builds
i386
1st MSYS w/ Mingw w/gcc 6.3 for NT3.50+
2nd Visual Studio 2005 or 2008 for NT3.50+
i686
1st Ubuntu VM w/mingw-w64 win32 GCC for 3.50+
2nd Windows 10 WSL w/Ubuntu w/mingw-w64 win32 GCC for 3.50+ or Visual Studio 2005,2008 or 2017 (XP+)
3rd MSYS2 w/ Mingw-w64 win32 GCC for NT3.50+ or posix for XP+
ISSUES
DOSBox in DOS requires SDL_Videodriver=Windib for functional mouse. (Removing 9x if statement in SDL would probably fix it but would there be any point?)
64bit DOSBox requires normal core
Need to recompile mingw-w64 to i386 to compile DOSBox for < i686 support. (Would potentially eliminate MSYS\mingw)
For Mingw and Mingw-64 can't use /c/ for prefix have to use /mingwxx. If so then need to seperate 32 and 64bit and clang vs gcc
Clang v5 doesn't support static for libstdc++ and having issues with -Bdynamic and -Bstatic switches. Clang instructions use shared for everything. https://github.com/tpoechtrager/wclang/issues/32
When compiling vorbis with clang march= causes failure to compile.
Need to compile MacOS build
Need to cross-compile from Linux for MacOS
Compile mingw for linux
Finish WSL and linux guide and upload linux vm
Credits:
gandhig (For reviewing the guide,providing corrections and testing)
Qbix
Neozeed (Blog posts and tips via email)
All the people that wrote the guides that I read to make this one.
To use:
-----------------------
add to dosbox.cpp
#define WINVER2 0x0400
#include "commonfix.h"
and add commonfix.h to the dosbox\src directory for now.
--------------------------------------------
VS2005 compiled DOSBox
*Windows 95 works with LegacyExtender. Fixes InterlockedCompareExchange
VS2010 compiled DOSBox
*Windows 95 will not work even with LegacyExtender. Missing "FindFirstFileExA"
*Need to check 98+ If 98 then try KernelEX
VS2012 compiled DOSBox
*Windows 95 will not work
*Need to check 98+ If 98 then try KernelEX
DOSBOX COMPILED WITH VS2008 (Runs on NT3.51)
Windows NT 3.50
DOSBox should work as long as correct msvcrt.dll is used and modifications to SDL to display fullscreen are made. Need to test.
Also copy winmm.dll from NT3.51
Windows NT 3.10:
DOSBox will not work. SDL 1.2.15 not supported on NT 3.10
It is also possible to cross compile from Linux to windows using the MinGW cross tools and even to run the test suite under Wine, the Linux/*nix windows emulator.
On Debian and Ubuntu systems, these cross compiler tools can be installed by doing:
sudo apt-get mingw32 mingw32-binutils mingw32-runtime wine
Once these tools are installed its possible to compile and test by executing the following commands, or something similar depending on your system:
./configure --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux
make
A multi-platform software synthesiser emulating (somewhat inaccurately) pre-GM MIDI devices such as the Roland MT-32, CM-32L, CM-64 and LAPC-I. In no way endorsed by or affiliated with Roland Corp.
Need to categorize third party patches:
What are the "necessary" third party patches?
cross-platform
Never will be crossplatform
Already in DOSBox
Never will be in DOSBox
etc
VISUAL STUDIO
Link-time Code Generation
Whole Program Optimization
COMPILERS
VISUAL STUDIO
OFFICIAL
Visual Studio 2003 95-98-NT4-2000
Visual Studio 2005 NT4-98-2000 (NT4 if /MT set)
Visual Studio 2008 NOSP 2000+
Visual Studio 2008 SP1 XP+ (Possibly Windows 2000 with KB816542 and PE header modified)
MEMORY
If you want to use Dynamic core or use higher than 16mb of memory in DOSBox then you'll need more than 64mb of memory on your host system.
If you have 64mb or less then only normal core and 16mb of memory can be used in DOSBox.
VIDEO
If you only get a black screen when loading DOSBox then verify that you have not exited Windows and then tried to start DOSBox. Boot straight to DOS instead.
INPUT
DOSBox with HXRT & HXGUI seems to have issues with the mouse in vmware.....so don't use vmware use pcem v14.
BENCHMARKS
DOSBox running quake on the host
210 320x200
70 800x600
QUAKE running in DOS under vmware
*fps numbers vary significantly
377 320x200
233 800x600
167 1024x768
DOSBox running quake under hxrt in DOS under vmware
180 320x200
60 800x600
40.7 1024x768
Between DOSBox in DOS (VMWARE) vs DOSBox on the host there isn't much of a difference in speed.
Between Quake in DOS (VMWARE) vs Quake in DOSBOX using HXRT in DOS (VMWARE) there is a big difference.
So did some testing with HXRT and DOSBox and found out that vmware was causing the issues with the mouse.
Using PCEM v14 (not 12!!), HXRT and DOSBox AND with SDL_Videodriver=windib then no mouse issues!
If recompile sdl 1.2.15 and allow new code to apply to all OS instead of just 9x then would probably work but there isn't much point.
If PCEM v12 set then DOSBox displays no video
If SDL_Videodriver not set then mouse issues.
Non-DOSBox. CMOV theory with Mingw 4.6+ versions and libraries. True or false? Is objdump accurate? Not relevant for DOSBox but possibly for other projects.
Consolidation of Ryzen posts
NOT RELEVANT TO COMPILING DOSBOX BUT USEFUL FOR CMOV RESEARCH
1. tar xzf gcc-4.6.4.tar.gz
2. rename gcc-4.6.4 to gcc
2b. Originally ran 3-step bootstrap process for native build, but instead save time and do 1-step for testing
3. cd gcc
4. This was the original configure line, but I don't know yet whether PPro instructions are emitted from this build. Best to specify architecture explicitly in this line and also verify in code that no CMOV code is enabled.
./configure --prefix=$HOME/gcc --enable-languages=c,c++ --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw --disable-libquadmath --disable-libgomp --disable-nls
5. make
6. make install
Built the above three libraries using mingw32/gcc462/binutils222.
1. configure shared libraries of gmp/mpc/mpfr for /mingw
./configure --enable-shared --disable-static --prefix=/mingw
3. make; make install
I recall that the earlier gcc versions have a ready-made configure system, but v493 doesn't. Here is a potential configure line for gcc v493 (--prefix= should be changed accordingly):
./configure --prefix=$HOME/gcc --enable-languages=c,c++ --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw --disable-libquadmath --disable-libgomp --disable-nls --disable-bootstrap --host=mingw32 --with-tune=i386 --with-arch=i386
make install
OLD
The bug report for gcc 4.7 branch shows at least some of the problem in i386.h:
X86_ARCH_CMOV
#define TARGET_CMOV
#define TARGET_CMOVE
This is one section of code which refers to activation of the PPro instruction set. I haven't searched for other examples nor in other branches yet. If the PPro issue is difficult to solve, then these targets may be defined away in the code for testing.
Edit: one possibility is that the GMP library is the cause along the gcc 4.6 branch. Found this in the configure log for it: march=pentium4. In the source code of gcc 4.6.4, couldn't find any examples of *CMOV*, but the GMP library had many references to it.
Perhaps defining "HAVE_HOST_CPU_pentium" in GMP configure.ac will at least fix the issue in GMP?
Edit 2: it is probably necessary to confirm that objdump is producing the correct output by trying another tool and compare the results.
For example, a Quake 2 binary from 1998 shows a single fcmovu instruction from the PPro set. It was presumably built by Visual C++ 5.0 which does have the capability to emit the PPro set.
Edit 3: verified that the gcc 464 custom build had PPro instructions in libgmp while the official gcc 46 version did not. However, the CMOV patch discussed in the previously posted gcc bug report was applied to gcc 464. Also, verified that i386.c/h are the main parts of gcc 464 which have references to the PPro instructions.
Edit 4: tried to verify the PPro instructions predicted by objdump against those generated by gcc itself (gcc -S option). The result was that PPro instructions were already in "libdxguid.a", a third-party available mingw32 library. That probably explains a previous finding of PPro instructions when building with the default gcc 4.6 of mingw32. Requires more testing.
Edit 5: the gcc 3.4 finding was probably a result of false detection of cmovs by a djgpp version of objdump. This version of objdump also detected cmovs in software compiled by gcc versions before the PPro was supported.
When DOSBox (or any program that uses SDL) is executed and NOT using WIBDIB on a 9x systems then when the mouse cursor is non-relative and inside the DOSBox window then the cursor will freeze or move erraticaly. When the cursor is in relative mode then the mouse works fine.
Also if the mouse is in relative mode and DOSBox is quit then the mouse cursor will be frozen until DOSBox is executed with the mouse NOT captured and then DOSBox is quit again to release it.
SDL 1.2.13 - works fine
SDL 1.2.14 - mouse issue
SDL 1.2.15 and current branch - mouse issue
BUT THESE ARE THE MAIN ONES:
SDL_dx5events.c
SDL_sysevents.c
FIXES:
Removing the following from SDL_dx5events.c "fixes" the first issue but breaks the mouse when DOSBox is relative
This was removed to allow directinput to work with OpenGL previously when opengl was used then windib was used:
Replace Lines #373-377 with the following from SDL 1.2.13:
#301 /* If we are in windowed mode, Windows is taking care of the mouse */
#302 if ( (SDL_PublicSurface->flags & SDL_OPENGL) ||
To fix the above then SDL_sysevents.c needs to be modified with the SDL 1.2.13 mouse code.
SDL_dx5events.c
This was removed to allow directinput to work with OpenGL previously when opengl was used then windib was used:
6.101 - /* If we are in windowed mode, Windows is taking care of the mouse */
6.102 - if ( (SDL_PublicSurface->flags & SDL_OPENGL) ||
6.103 - !(SDL_PublicSurface->flags & SDL_FULLSCREEN) ) {
6.104 - return;
6.105 - }
INFO
Look into trackmouse storing coordinates outside of dosbox window for 9x vs 0,1 for non-9x.
it's not recommended to use dinput for mouse and keyboard...
DirectInput is a set of API calls that abstracts input devices on the system. Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly. DirectInput is only useful for reading data from DirectInput joysticks; however, if you only need to support the Xbox 360 controller for Windows, use XInput instead. Overall, using DirectInput offers no advantages when reading data from mouse or keyboard devices, and the use of DirectInput in these scenarios is discouraged
hmmm so mabye it's not tracking the coordinates when using the DX driver on 9x when in non relative mode. I'm assuming relative is when the mouse is captured since it works fine inside dosbox. (Mouse cursor hidden and stuck in center of screen).
Yes, the non-relative mode seems so, but needs to be re-verified at my end('mouse_relative' variable). I'm assuming that you didn't refer to the 'relative' variable used inside the SDL_PrivateMouseMotion function.
That aside, observations(subject to edit, later) as per my current understanding are,
1a) In dosbox 'windowed' as well as 'fullscreen' mode (Win95), the mouse cursor movement inside the SDL Window(i.e. dosbox Z prompt) is taken care of by the SDL's post_mouse_motion function, which in turn utilizes Windows' ClipCursor function to supposedly move the Cursor to the calculated position inside the dosbox window, based on the inputs received from the actual hardware & reported through the Direct Input interface/mouse device object. But ClipCursor doesn't seem to be working. However the cursor position as per the actual movement is properly getting updated in the SDL mouse structure internally with the correct screen/client coordinates. The above is obviously with 'no grab'. 2 3b) Under Win7, the ClipCursor function works properly inside the SDL window with each mouse movement. 4 5c) Under Win7, the mouse motion events generated are also somewhat different compared to Win95. In case of Win7, 'handle_mouse' function is not called when the cursor movement is outside the window and the dosbox window isn't 'in focus' or 'active'. However under Win95, the function gets called even when the dosbox window is not active and the mouse is moved outside the window.
Edit(12.12.17):
If I just replace the ClipCursor(&trap) with SetCursorPos(cursor.x, cursor.y) in line 344 of SDL_dx5events.c, mouse does move inside the dosbox window and also doesn't get stuck on exit(not captured). However, as warned in the comments, the mouse movement sort of resembles a tug of war. I will try till this weekend and then throw the towel.
Ok, I give up.
Contrary to my earlier statement, the ClipCursor function does work as I'm getting proper return values when checked in gdb.
The return value of ClipCursor in Win7 is different w.r.t Win95 in that under Win7 it returns only '1' (EAX value) on success, whereas in Win95 the return value observed in EAX register is the X coordinate of mouse. If I manually change the 'trap' rectangle which is fed as the argument to the ClipCursor function, the cursor does get restricted to the changed rectangle. But it doesn't happen during the normal run of the SDL test program (threadwin.exe) with directx driver. My incomplete understanding leads to the following possibilities(not in any particular order) & observations:
a)_TrackMouseEvent points to SDL's WIN_TrackMouseEvent in Win95, but Win7 has its own TrackMouseEvent(takes care of mouse leaving the SDL window). Incompatibility with new mouse handling code in SDL-1.2.14/15??? Should not matter as it is responsible for only tracking as to when the mouse leaves the window???
b) Direct Input implementation in Win95??? As per the links you referred, the direct input's mouse and keyboard interfaces are wrappers around WM_MOUSEMOVE messages under later OS versions (since WinXP), so there is no issue there.
c) Too many WM_TIMER messages(due to TrackMouseEvent???) observed during the handling of Window messages at the start of DX5_CheckInput function under Win95 (timer resolution ???)
d) Under Win95, once the mouse enters the client area of the SDL window, say, from the top (i.e client coordinate SDL_MouseY=0, at_edge is true, cursor changes to black...), further mouse movement(left/right) in the X-axis is fine as the OS is taking care of the motion. Just moving the mouse one step down(i.e. client coordinate SDL_MouseY=1, at_edge is false..), something happens that makes the cursor get stuck, though this initial one step movement does happen(again courtesy of OS probably). After that, no movement. However if we keep on moving the mouse,say, towards the bottom, it does get released once enough movements in the Y-axis get accumulated such that the mouse cursor warps out of the bottom of the SDL window/DOSBox Z prompt window. Similarly if we make small upwards movement of the mouse(w.r.t SDL_MouseY=1) towards the top, it immediately gets released outside the SDL window, off the top.
Would it be better to leave a note in the guide with all the possible options and let the users decide as per their requirements? I'm not sure about the best option, that's why.
The closest I got to a workaround to the erratic mouse movement issue with 'directx' driver is by modding the code from line nos. 324 to 327 of SDL_dx5events.c(just expanding the 'trap' rectangle slightly):
1 Line No:324: trap.left = cursor.x - 1; 2 Line No:325: trap.top = cursor.y - 1; 3 Line No:326: trap.right = cursor.x + 2; 4 Line No:327: trap.bottom = cursor.y + 2;
'Mouse stuck on exit' issue resolved by adding 'ClipCursor(NULL)' in DX5_DestroyWindow function after line no. 990 of SDL_dx5events.c
1 Line No:990: DX5_DInputQuit(this); 2 Line No:991: ClipCursor(NULL); /* free the stuck cursor while exiting in Win9X(windowed & grab mode = off) */ 3 Line No:992: /* Destroy our window */
Not pretty, but this is the best I can do presently.
------------------------------
Need to see about getting the following added to upstream:
SDL
Soooo.....even though the SDL 1.2.13 mouse code works in SDL 1.2.15 (Actually current branch of SDL 1.2) I've been unsuccessful with adding the subsequent changes back to those files that don't have anything to do with the issue. Issue is adding that code back doesn't allow a proper patch to be created so I've scratched that project and modified ghandig's code to only apply for 9x. (Is that necessary? Probably not but it only affects 9x)
See attached for a replacement sdl-win32.diff
This means that DOSBox can now be used with SDL 1.2.15 and supports the same Windows operating systems that SDL 1.2.13 does. (95+) (SDL also works in NT 3.51 but DOSBox file cross.cpp needs a few changes..see below)
With this change it now means DirectInput can be used in a window and in OpenGL fullscreen whereas with SDL 1.2.13 WINDIB was used in a Window and OpenGL fullscreen.
This also means that high DPI mice are supported now in DOSBox in those configurations for those games that need it.
Getlocaladdresses breaks programs for NT3.51, 95 and NT4 that use SDL_NET 1.2.8+ if IPHLPAPI is missing.
*3.51 - IPHLPAPI not supported.
*95 - IE4 comes with the .dll
*NT4 - Possibly comes with IE4 or elsewhere
"If you don’t need to know your local IP address, just comment out the entire SDLNet_GetLocalAddresses function. This only reports the LAN address, which for most users is going to be behind a NAT and not actually be their public IP address."
Cannot create a diff since too many changes so here is the attached.
This does not break functionality in DOSBox since DOSBox does not use this function.
Alternative is to use SDL_NET 1.2.7 to support the above
or use SDL_net 1.2.8+ with IE4 on 95 and NT4.
*This fixes the issue with compiling SDL_NET 1.2.8+ with mingwrt 5.0.2
DOSBOX
NT 3.51 SUPPORT
*See if I can create a diff. Using full file for now.
SDL_NET introduces WS2_32 or WSOCK32 requirement but NT 3.51 (or 95 if you want to use WSOCK) doesn't support WS2_32. To support need to replace WS2_32 in configure with WSOCK32. Need to figure out how to offer both options or mabye just add a note to DOSBox INSTALL
DISABLING PROFILE
*See if I can create a diff. Using full file for now.
This enables a --disable-profile switch in configure which allows all supported operating systems to save the profile in the current directory.
Another benefit is that this disables the Active Desktop requirement for IE4 on 95 and NT4 and also allows DOSBox to run on NT 3.51.
OLD
SDL
SDL-1.2.13filesfor SDL-1.2.15 for mouse issue.zip
These are SDL 1.2.13 files modified with the minimum amount of changes to get them to compile on SDL 1.2.15. Keeping just in case. Use sdl-win32.diff instead which modifies SDL-1.2.15 to only apply what's needed to get the mouse to work on 9x.
OLDERSDL-1.2.15 9x-Minimal.zip
OLDERSDL-1.2.15 for 9x-toomanymods
These two were earlier attempts to fix the mouse issues.
Finally got DOSBox working in NT 3.50. Wasn't that difficult but did take all day since I don't know what I'm doing.
Windows NT 3.50 was released September 21, 1994 making this the oldest version of Windows that can run DOSBox.
Use the attached with the previously posted msvcrt.dll.
Also keyboard doesn't work for some reason. Likely due to the changes I had to make to DOSBox. Need to figure out how to disable the mapper or rather the joystick part of the mapper without butchering the code. Same behavior on Windows 10.
For DOSBox to work in NT 3.50 SDL has to be modified to remove changedisplaysettingsa which means that SDL can't use fullscreen in NT 3.50. Also joystick support has to be removed from SDL which also means it has to be disabled in DOSBox.
Next:
Simplify SDL modification
Ask about configure switch to disable mapper or disable joystick part of mapper or see if I can figure it out.
*Need to test with VS
NEED TO IDENTIFY WHY DISABLING THE JOYSTICK IN DOSBOX DISABLES KEYBOARD INPUT. NOT A SDL ISSUE
DOSBOX
*If joystick disabled in SDL then receive the below when compiling DOSBox.
mv -f .deps/dosbox.Tpo .deps/dosbox.Po
g++ -O3 -march=i386 -mtune=i386 -mno-ms-bitfields --static -s -o dosbox.exe dosbox.o winres.o cpu/libcpu.a debug/li
ebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a h
dware/mame/libmame.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -lSDL_sound -lsdl_net -lwsock32 -L/mingw/
b -lmingw32 -lSDLmain -lSDL -mwindows -liconv -lm -luser32 -lgdi32 -lwinmm -lpng -lz -lSDL_net -lwinmm -lwsock32
gui/libgui.a(sdlmain.o):sdlmain.cpp:(.text+0x35d5): undefined reference to `SDL_JoystickUpdate'
gui/libgui.a(sdlmain.o):sdlmain.cpp:(.text+0x4e55): undefined reference to `SDL_NumJoysticks'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x14d5): undefined reference to `SDL_JoystickEventState'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x1588): undefined reference to `SDL_JoystickEventState'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x40c9): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x460f): undefined reference to `SDL_NumJoysticks'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4648): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x465a): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4693): undefined reference to `SDL_JoystickEventState'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x48fd): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4910): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x491e): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x492c): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x498e): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4cbd): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4cd0): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4cde): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4cec): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x4d4e): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x50ad): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x50c0): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x50ce): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x50dc): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x513e): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5481): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5494): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x54a2): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x54b0): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5749): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x575c): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x576a): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5778): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x57da): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5a7d): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5a90): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5a9e): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5aac): undefined reference to `SDL_JoystickNumHats'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b01): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b46): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b58): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b6c): undefined reference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b78): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b8a): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5b99): undefined reference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5c7c): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5c86): undefined reference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5d14): undefined reference to `SDL_JoystickOpen'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5d26): undefined reference to `SDL_JoystickNumAxes'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5d35): undefined reference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5df2): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text+0x5e6a): undefined reference to `SDL_JoystickNumButtons'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroup9BindStartEv[__ZN15CStickBindGroup9BindStartEv]+0
1): undefined reference to `SDL_JoystickName'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroupD1Ev[__ZN15CStickBindGroupD1Ev]+0x16): undefined
ference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15C4AxisBindGroupD1Ev[__ZN15C4AxisBindGroupD1Ev]+0x16): undefined
ference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN13CFCSBindGroupD1Ev[__ZN13CFCSBindGroupD1Ev]+0x16): undefined refe
nce to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN12CCHBindGroupD1Ev[__ZN12CCHBindGroupD1Ev]+0x16): undefined refere
e to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroupD0Ev[__ZN15CStickBindGroupD0Ev]+0x16): undefined
ference to `SDL_JoystickClose'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN13CFCSBindGroupD0Ev[__ZN13CFCSBindGroupD0Ev]+0x16): more undefined
eferences to `SDL_JoystickClose' follow
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroup27ActivateJoystickBoundEventsEv[__ZN15CStickBindG
up27ActivateJoystickBoundEventsEv]+0x3b): undefined reference to `SDL_JoystickGetButton'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroup27ActivateJoystickBoundEventsEv[__ZN15CStickBindG
up27ActivateJoystickBoundEventsEv]+0x1e3): undefined reference to `SDL_JoystickGetAxis'
gui/libgui.a(sdl_mapper.o):sdl_mapper.cpp:(.text$_ZN15CStickBindGroup27ActivateJoystickBoundEventsEv[__ZN15CStickBindG
up27ActivateJoystickBoundEventsEv]+0x403): undefined reference to `SDL_JoystickGetHat'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [dosbox.exe] Error 1
make[2]: Leaving directory `/mingw/codeprojects/dosbox/32/vanilla/dosbox351/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/mingw/codeprojects/dosbox/32/vanilla/dosbox351/src'
make: *** [install-recursive] Error 1
Okay figured it out with a workaround until/if I can figure out how to disable the joystick in DOSBox:
Note that below joystick support has not been disabled in either SDL or DOSBox so the executable will error out on NT3.50 with joygetposex error in winmm.dll.
Simply copy winmm.dll from NT3.51 to the DOSBox directory on NT3.50 and execute
Also it turns out fullscreen does work in NT3.50 but it's a fullscreen window versus true fullscreen. The more things change the more they stay the same.....
Need to see if can turn into a configure switch for SDL
Also likely that joystick doesn't work, this just satisfied the dependency.
Getsystemtimeasfiletime not caused by MINGW but by msvcrt.dll
To bypass this error then need to use a msvcrt.dll that does not include getsystemtimeasfiletime.
See attached.
OLD
SDL
--disable-joystick
SDL_config.h
#define SDL_JOYSTICK_DISABLED 1
VS ONLY?
C:\MinGW\codeprojects\dosbox\32\vanilla\SDL-1.2.15351\include\SDL_config_win32.h
Add
#define NO_CHANGEDISPLAYSETTINGS 1
VISUAL STUDIO
Update Visual Studio Guide with MINGW guide changes
Add gulikoza d3d patch to unofficial build http://www.si-gamer.net/gulikoza/
Ask bearwindows about VS2010 and findfirstfileex (does not work in 9x but does for NT4+) (msfn)
See if it's worth doing PGO
Cleanup junk at the bottom of each guide http://bearwindows.zcm.com.au/msvc.htm#c9
MINGW
Setup Linux VM and create Linux guide
Add gulikoza d3d patch to unofficial build http://www.si-gamer.net/gulikoza/
Cleanup junk at the bottom of each guide
Test only making some things dynamic
If need some things static and some things dynamic:
-static-libstdc++ -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic
Everything after “-Wl,-Bstatic” will be linked statically, everything after “-Wl,-Bdynamic” will be linked dynamically
If recompile mingw-w64 for i386 then verify does not have same bug as old ver of mingwrt v5
Check *MINGWRT 5.0.1 with 2357 fix https://sourceforge.net/p/mingw/bugs/2357/ against mingw-w64. See if same issue
See if it's worth using PGO:
Need to try -fprofile-generate, then recompiling with -fprofile-use,
"If you have the patience, add -fprofile-generate to the switches, compile, run dosbox with a few different games, using different video modes, cpu instructions, scalers and sound cards. (I'd love to hear which ones you take. I tried Settlers for protected mode+svga+gus and MOM for hq2x+sblaster. Didn't have other ideas yet, no useful real mode program yet). After running the sample programs, reconfigure, replace -fprofile-generate with -fprofile-use, make clean, make" https://stackoverflow.com/questions/4365980/h … =google_rich_qa
Download the PDCurses source files from http://sourceforge.net/projects/pdcurses/file … rses-3.4.tar.gz
Copy the downloaded file to your MSYS home folder
Switch to the MSYS command prompt
Extract the file
tar xvf PDCurses-3.4.tar.gz
Compile the library
cd PDCurses-3.4/win32
make -f gccwin32.mak DLL=N
And now copy the files to your /mingw folders
cp pdcurses.a /mingw/lib/libpdcurses.a
cd ..
cp curses.h panel.h /mingw/include/
cd ..
Download the libtool from the http://www.gnu.org/software/libtool/ and extract it to /tmp
./configure --prefix=/usr/local && make && make install
Don't install the automake 1.14 or above that may interrupt the compilation of Glib and DOSBox.
Moe's OpenglHQ
Get Moe's OpenglHQ patch from the http://ykhwong.x-y.net and apply it to the SDL source.
This patch includes several fixes for DOSBox and also implements Moe's OpenglHQ output.
patch -up1 < openglhq-dosbox-for-sdl-202121117_msvc_gcc.patch
./autogen.sh && ./configure --enable-shared=no && make && make install
Change to the physfs directory and type:
cmake-gui .
Click configure -> unix makefiles -> use default native compilers.
Uncheck physfs_build_shared
Click configure again
Click generate and close the cmake window.
Type:
make && make install
******* glib (needed for Fluidsynth)
In order to install glib, libffi, expat and python are required.
Visit http://www.linuxfromscratch.org/blfs/view/7.5 … ral/libffi.html
Get libffi, extract it to /tmp and type:
./configure --prefix=/usr/local && make && make install
Get Python 2.7.9 from the http://www.linuxfromscratch.org/blfs/view/svn … al/python2.html
(don't install if the Python has already been installed)
Extract it to /tmp and type:
./configure --prefix=/usr/local --enable-shared=no --with-system-expat --with-system-ffi --enable-unicode=ucs4 && make && make install
******** Fluidsynth
This is used for loading soundfonts with MIDI synth.
git clone git://git.code.sf.net/p/fluidsynth/code-git fluidsynth-code-git
Change to the fluidsynth directory and type:
cmake-gui .
Click configure -> unix makefiles -> use default native compilers
Uncheck build_shared_libs, pulseaudio, enable-dbus, and enable-ipv6
Click configure again. Click generate, close cmake window, and type:
make
If pthread is missing, add "-lpthread" to src/CMakeFiles/fluidsynth.dir/link.txt
make install
SDL_sound
--enable-physfs=no
libfreetype
This is used for printing.
git version may not work. /*git clone git://git.sv.gnu.org/freetype/freetype2.git*/
Get freetype-2.5.5.tar.gz from the http://www.freetype.org/. extract it to /tmp and type:
./configure --enable-shared=no && make && make install
libpcap
This is used for computer networking / Internet.
Get libpcap-1.6.2.tar.gz from tcpdump.org. Extract it /tmp and type:
./configure --enable-shared=no && make && make install
libtbb
This library will be used by xbrz scaler. (Don't compile!)
Get the latest version of tbb from the official website http://threadingbuildingblocks.org/
Extract it to /tmp and move the bin, include, and lib directories to /usr/local
Copy everything from /usr/local/lib/ia32/gcc4.4 to /usr/local/lib
To add some missing libraries and the support for the C++11 to dosbox, type:
export LIBS='-ltbb -lglib-2.0 -lgthread-2.0 -lFLAC -ldl -lglib-2.0 -ldbus-1 -lasound -lpulse'
export CXX='/usr/bin/g++ -std=c++11'
export CFLAGS="-s -O2 -msse2"
export CXXFLAGS="-s -O2 -msse2"
export LDFLAGS="-static-libgcc -static-libstdc++"
DOSBox can be compiled with one of the following compilers: Clang or GCC.
1. Open App Store and download and install Xcode that contains the Clang first.
The MacPorts is already included as a bundle of the XCode.
However, the Macports can also be manually downloaded from the http://www.macports.org/
Usage of the MacPorts:
In order to install a package, type: sudo port install [package-name]
For more information about the [package-name], refer to the http://www.macports.org/ports.php
Example:
In order to install the FluidSynth, type: sudo port install fluidsynth +universal
Most of the remaining libraries required by DOSBox can be installed by this way.
For the GCC installation (optional):
In order to install the GCC version 4.8 type:
sudo port install gcc48 +universal
port select --set gcc mp-gcc48
Obtain the source and extract it to /dosbox. Change to the dosbox source directory.
Do "./autogen.sh" or type the following:
aclocal
autoheader
automake --include-deps --add-missing --copy
autoconf
export CPPFLAGS="-I/opt/local/include"
For the Clang:
export CC='gcc -arch i386'
export CXX='g++ -std=c++11 -arch i386'
export GCOV='gcov -arch i386'
For the GCC:
export CC='/opt/local/bin/gcc -arch i386 -static-libgcc -static-libstdc++'
export CXX='/opt/local/bin/g++ -std=c++11 -arch i386 -static-libgcc -static-libstdc++'
export GCOV='/opt/local/bin/gcov -arch i386'
For the libraries to be dynamically linked, type:
export LIBS='libtbb.dylib -framework CoreAudio -framework CoreMidi -framework AudioToolbox -framework AudioUnit'
For the libraries to be statically linked, set the following LIBS variable in src/Makefile:
LIBS=-framework IOKit -framework OpenGL -framework Carbon -framework ApplicationServices /opt/local/lib/libSDL_sound.a
-framework CoreAudio -framework CoreMidi -framework AudioToolbox -framework AudioUnit -L/opt/local/lib /opt/local/lib/libSDLmain.a
-Wl,-framework,AppKit /opt/local/lib/libSDL.a -Wl,-framework,Cocoa /opt/local/lib/libpng.a /opt/local/lib/libz.a -L/opt/local/lib
/opt/local/lib/libfreetype.a /opt/local/lib/libz.a /opt/local/lib/libbz2.a /opt/local/lib/libpng16.a /opt/local/lib/libpcap.a
/opt/local/lib/libSDL_net.a /opt/local/lib/libX11.a /opt/local/lib/libfluidsynth.a /opt/local/lib/libphysfs.a /opt/local/lib/libz.a
/opt/local/lib/libflac.a /opt/local/lib/libogg.a /opt/local/lib/libmodplug.a /opt/local/lib/libspeex.a /opt/local/lib/libvorbis.a
/opt/local/lib/libxcb.a /opt/local/lib/libvorbisfile.a /opt/local/lib/libvorbisenc.a /opt/local/lib/libportaudio.a /opt/local/lib/libdbus-1.a
/opt/local/lib/libgthread-2.0.a /opt/local/lib/libreadline.a /opt/local/lib/libsndfile.a /opt/local/lib/libjack.a /opt/local/lib/libXrandr.a
/opt/local/lib/libglib-2.0.a /opt/local/lib/libiconv.a /opt/local/lib/libintl.a /opt/local/lib/libtermcap.a /opt/local/lib/libXext.a
/opt/local/lib/libXrender.a /opt/local/lib/libXau.a /opt/local/lib/libXdmcp.a /opt/local/lib/libtbb.a
./configure --enable-core-inline --prefix=/opt/local --host=i386
make
Clang and mingw-w64
Try clang++ -Xclang -flto-visibility-public-std for static libstdc++
WSL Install Instructions
*Need to find appx download
Open Powershell as an Administrator
Run enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Go to Start->Run and type in "ms-windows-store://pdp/?productid=9N9TNGVNDL3Q&referrer=unistoreweb&scenario=click&webig=0c38a303-bb74-4377-af49-5aee43944125&muid=057088A8765F68B1287B835077A2697C" and install
SDL2 98SE - No emulator supports D3D9 in 98. Find software D3D9 wrapper or OpenGL Mesa3D that works with SDL2 on Windows 98 or dig out laptop from closet.
Latest DOSBox with Clang warnings
Ignore -switch and -Waddress-of-packed-member warnings
-Wl,-Bstatic -lc++ -Wl,-Bdynamic
1clang++ -m32 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/mingw32/include/libpng16 -I/mingw32/include/SDL -I/mingw32/include -I/mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main -O3 -march=i686 -m32 -mno-ms-bitfields -MT sdl_mapper.o -MD -MP -MF .deps/sdl_mapper.Tpo -c -o sdl_mapper.o sdl_mapper.cpp 2sdlmain.cpp:635:29: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] 3 if (!sdl.blit.surface || (!sdl.blit.surface->flags&SDL_HWSURFACE)) { 4 ^ ~ 5sdlmain.cpp:635:29: note: add parentheses after the '!' to evaluate the bitwise operator first 6 if (!sdl.blit.surface || (!sdl.blit.surface->flags&SDL_HWSURFACE)) { 7 ^ 8 ( ) 9sdlmain.cpp:635:29: note: add parentheses around left hand side expression to silence this warning 10 if (!sdl.blit.surface || (!sdl.blit.surface->flags&SDL_HWSURFACE)) { 11 ^ 12 ( ) 13mv -f .deps/sdl_mapper.Tpo .deps/sdl_mapper.Po 14clang++ -m32 -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/mingw32/include/libpng16 -I/mingw32/include/SDL -I/mingw32/include -I/mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main -O3 -march=i686 -m32 -mno-ms-bitfields -MT render.o -MD -MP -MF .deps/render.Tpo -c -o render.o render.cpp
make clean not working for libraries when switching between archs. Need to find out which ones and do rm for deps and libs. This will eliminate having to maintain multiple source files.
DOSBox may need --disable-shared and --disable-static switches:
When compiling DOSBox statically on win32 then have to change configure to use wsock32 instead of ws2_32 because test case adds ws2_32 lib or mabye just remove test case.
When compiling DOSBox statically on Linux then have to change configure to remove -x11 because SDL_net adds this library and they conflict or mabye just remove test case.
Possibly SDL and SDL_net add the libraries anyway so DOSBox adding the library may be redundant. Need to check.
Propose --enable-static which doesn't add the libs.
------------------
Official DOSBox supports Windows 95,NT4+ W/ Active Desktop since Mingw is used to build it although Mingw-w64 works as well (If using mingw-w64 then may need latests MSVCRT provided in KB for 2000).
if the Daum build does work on 9x it's likely because it uses SDL 1.2 and was built with an old ver of Visual Studio likely VS 2008 or below.
Unofficially that I haven't submitted patches for:
SDL - commit after SDL 1.2.13 was released broke DirectInput on 9x. Either rollback commit or add two changes that seems to fix the issue...or just use WINDIB with DOSBox.
95,NT4 without Active Desktop Disable profile config
NT 3.51 DIsable profile config, use WSOCK
NT 3.50 Disable profile config, Use WSOCK, and disable fullscreen support in SDL
Hi, thanks for all the work on the Visual Studio compilation guide! It got me most of the way to producing a working Dosbox exe from the SVN source. I have some updates where I deviated or made corrections. I used the multi text since I only have Visual Studio 2017 and it seemed to apply better. I'm pasting the diffs between the original and the new text:
I found and added libModPlug and libMikMod to the SDL_sound library:
Instead of installing the DirectX SDKs, I extracted them with 7-zip and copied the include and library folders, per your notes.
When opening some solutions and letting VS2017 upgrade them, it would sometimes prompt for the Windows SDK target. For this compilation, I always chose 8.1, over the Windows 10 SDK.
Some libraries provided "static" and "dynamic" projects. Since I went for a static build this time, I only updated and built the static project and ignored steps that prompted modifying the dynamic project. This was done for FLAC and SDL_sound.
When adding include or library folders, I used relative paths in all cases:
1@@ -448,10 +451,11 @@ 2 VISTA+ 3 b. Verify that "Platform Toolset" is set to "Visual Studio 2017 (v141)" 4 5-**If you want to keep SDL_net.DLL seperate from DOSBox.exe then set to "Dynamic Library (.dll)" 6+**If you want to keep libvorbis.DLL seperate from DOSBox.exe then set to "Dynamic Library (.dll)" 7 8 c. Select "VC++ directories" then "Include Directories" and add the following directory: 9- C:\Build\DOSBOX\multi\VSXXXX\XXXX\COMPILE\libogg\include\ogg 10+ 11+ ..\..\..\..\libogg\include\ogg 12 13 e. Click "Apply" and then "OK"
For SDL_sound, instead of removing blocks of code, I removed the definition instead from the project, to remove those dependencies. In this case, I turned off smpeg support:
1@@ -520,9 +524,15 @@ 2 3 c. Select "VC++ directories" then "Include Directories" and add the following directory: 4 C:\Build\DOSBOX\multi\XXXX\XXXX\COMPILE\SDL-1.2.15\include 5- C:\Build\DOSBOX\multi\XXXX\XXXX\COMPILE\flac-1.3.1\include 6- C:\Build\DOSBOX\multi\VS2017\XP\COMPILE\libvorbis-1.3.5\include 7+ ..\..\SDL-1.2.15\include 8+ ..\..\flac-1.3.1\include 9+ ..\..\libvorbis-1.3.5\include 10+ ..\..\libmikmod-3.3.11.1\include 11+ ..\..\libmodplug-0.8.9.0\src 12 13+ d. Select "C/C++" then "Preprocessor". Edit Preprocessor Definitions and remove: 14+ SOUND_SUPPORTS_SMPEG 15+ 16 e. Click "Apply" and then "OK" 17
The last thing I did was set some flags that didn't carry over during the VS upgrade. In the dosbox properties, C/C++ -> Optimization, changed "Whole Program Optimization" to Yes. Then in Command Line, I added /GA to "Additional Options", which should optimize dosbox for windows: https://docs.microsoft.com/en-us/cpp/build/re … ows-application I probably should go back and check the flags for the libraries too.
It seems like a couple more flags could be set, like under C/C++ -> General, "SDL Checks" and "Multi-processor Compilation", but I haven't done that research.
After building the static libraries and wiring everything up, dosbox-svn compiled in Visual Studio 2017 and ran in Windows 10! I've tested a couple games and they seem to work ok. Thanks again for all your work on creating new guides!
--------------------------
I've been playing around with getting munt to compile in Visual Studio and learned about vcpkg. With it and the cmake support in Visual Studio 2017, I was able to build munt/mt32emu (use "open folder" and select the munt folder). So, I went back to try using the vcpkg libraries on dosbox-svn. This seems to have worked (a working dosbox exe is built and runs games as expected). This method should also provide some options for x64 or universal windows builds, without much effort.
Install vcpkg following the easy instructions in the repo readme. It's recommended to clone to a short path like C:\src\vcpkg This will contain the headers and libraries.
Install the following libraries via powershell (these are the x86 static versions):
For x64 static libraries you would use x64-windows-static. These can be installed side-by-side with the x86 versions and we'll target a triplet later. Notes on using "triplets" found here: https://blogs.msdn.microsoft.com/vcblog/2016/ … -now-available/
SDL1 isn't available via vcpkg, so SDL, SDL_net and SDL_sound still need to be built using the manual method, but should be able to use the vcpkg libraries instead of pulling the source for the other libraries.
Open the dosbox solution with Visual Studio and let it upgrade the solution and the project as usual.
Following notes from the triplet blog above, I now opended the new project file (.vcxproj) in notepad++ and added these properties to the "Globals" property group:
I'm not sure if there's a direct way to get to the globals from the Visual Studio property editor.
Now VS will pull libraries and header files from vcpkg. All that's needed is to edit the project properties:
In Solution Explorer right-click dosbox and select properties.
Add the SDL directories to VC++ Directories -> Include Directories and Library Directories.
Also change Linker -> Input -> Additional Dependencies to (match the lib names in vcpkg, specifically FLAC++, ogg, vorbis, libpng16):
Click on C/C++ -> Optimization -> and set Whole Program Optimization to Yes (/GL).
Click on C/C++ -> Code Generation -> and set Runtime Library to Multi-threaded (/MT).
Click on C/C++ -> Command Line -> and type /GA in Additional Options.
Edit the config.h with #define C_CORE_INLINE 1
Compile!
I'd like to be able to specify the triplet globals via configuration manager so x64 and universal builds could be easily selected. I haven't tried building with the x64 libraries yet, so I have no idea if the x64 problems are still present.
SURFACE/OVERLAY/DDRAW with fullresolution=original
Switching to fullscreen results in windows going to other screen when DOSBox is switched fullscreen but are moved back when DOSBox is minimized
DOSBox freezes for a couple of seconds when switching between fullscreen and windowed mode.
OPENGL with fullresolution=original
Switching to fullscreen results in windows moving to other screen when DOSBox is switched to fullscreen and are not moved back
DOSBox freezes for less that surface/overlay/ddraw
SURFACE with fullresolution=0x0
Windows are not moved to other screens
DOSBox still freezes for a couple of seconds when switching between fullscreen and windowed mode
Dosbox video is not scaled
OVERLAY with fullresolution=0x0
Windows are not moved to other screens
DOSBox still freezes for a couple of seconds when switching between fullscreen and windowed mode
Dosbox video is scaled and takes up the full screen
DDRAW with fullresolution=0x0
Windows are not moved to other screens
DOSBox still freezes for a couple of seconds when switching between fullscreen and windowed mode
Dosbox video is scaled and takes up the full screen
OPENGL with fullresolution=0x0
Windows are not moved to other screens
DOSBox freezes for less than surface/overlay/ddraw
Dosbox video is scaled and takes up the full screen
OPENGL with fullresolution=0x0
Switching to fullscreen results in windows moving to other screen when DOSBox is switched to fullscreen and are not moved back
DOSBox freezes for less that surface/overlay/ddraw
Recommendation:
fullresolution=0x0
windowresolution=1280x800 (60% of steam users have a 1920x1080 display)
aspect=true
scaler=none
windows use output=ddraw or openglnb (OpenGL ICD may not be present so SDL1=DDRAW (unless unofficial d3d) SDL2=D3D)
Need to:
default DOSBox to fullresolution=desktop (0x0 may confuse people),scaler=none, aspect=true, vs 1600x1200 for full
Default windowresolution to 1280x960
Put info in dosbox.conf about checking video card scaler settings, most default to aspect. If DSR used then disable scaling in video card properties.
Priorities:
Linux guide uploaded
Thread cleanup and prioritize
See about converting guide to wiki with pics and see about updating DOSBox INSTALL as well as build script.
DosFreak wrote:COMPILING DOSBOX
Windows NT 3.50
DOSBox should work as long as correct msvcrt.dll is used and modifications to SDL to display fu […] Show full quote
COMPILING DOSBOX
Windows NT 3.50
DOSBox should work as long as correct msvcrt.dll is used and modifications to SDL to display fullscreen are made. Need to test.
Also copy winmm.dll from NT3.51
Windows NT 3.10:
DOSBox will not work. SDL 1.2.15 not supported on NT 3.10
MUNT Windows 98
This thread seems to be the most relevant to what I'm looking for.
DosFreak I appreciate the nod to my thread for Munt98. Although even it is not perfect and without hoops to jump through to work successfully.
I'm looking deeper to try and get Munt and DosBox to run under Windows 3.1 Standard to simplify the process.
Have you done any testing of compiling DOSBOX to work on Windows 3.1?
I also can't locate the source codes for older versions of DosBox v0.50 -> v0.72.
Is there a direct link to download the DOSBOX Source Codes for much older versions?
Or have these been removed/hidden as I can only see the standard compiled Windows executables and I need to get a hold of the source codes for the older versions to do some analysis and testing.
Although it seems you have more experience compiling DosBox from scratch you might be able to help make this happen sooner.
A preliminary Dosbox for Windows 3.1 might work with my P4 with a Sound Blaster ISA card since Windows 3.1 audio drivers seem to be more of an issue at the moment for only modern systems. Later it will involve porting the Audio to the Intel HD Graphics HDMI Audio port where the sound signal is purest running on Coffee Lake down to older Sandy Bridge systems where PCI and PCIe sound cards will later be adapted to work and eventually USB Audio devices.
