ISSUESDOSBox 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 coreNeed 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 gccClang 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/32When compiling vorbis with clang march= causes failure to compile.Need to compile MacOS buildNeed to cross-compile from Linux for MacOSCompile mingw for linuxFinish WSL and linux guide and upload linux vm

Credits:gandhig (For reviewing the guide,providing corrections and testing)QbixNeozeed (Blog posts and tips via email)All the people that wrote the guides that I read to make this one.

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 wineOnce these tools are installed its possible to compile and test by executing the following commands, or something similar depending on your system:

MEMORYIf 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.

1. tar xzf gcc-4.6.4.tar.gz2. rename gcc-4.6.4 to gcc2b. Originally ran 3-step bootstrap process for native build, but instead save time and do 1-step for testing3. cd gcc4. 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-nls5. make6. 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=/mingw3. make; make install

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.

Removing the following from SDL_dx5events.c "fixes" the first issue but breaks the mouse when DOSBox is relativeThis 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) ||

#303 !(SDL_PublicSurface->flags & SDL_FULLSCREEN) ) {

#304 return;

#304 }

Remove Line 551 extra bracket:

#547 if ( xrel || yrel ) {

#548 post_mouse_motion(1, xrel, yrel);}

#549 }

#550#551 }

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:

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

DosFreak wrote: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,

a) 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'.

b) Under Win7, the ClipCursor function works properly inside the SDL window with each mouse movement.

c) 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):

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."

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.

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 modificationAsk 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.

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

Test only making some things dynamicIf need some things static and some things dynamic:-static-libstdc++ -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-BdynamicEverything after “-Wl,-Bstatic” will be linked statically, everything after “-Wl,-Bdynamic” will be linked dynamically

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/436 ... le_rich_qa

Get Python 2.7.9 from the http://www.linuxfromscratch.org/blfs/vi ... thon2.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

libpcapThis 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

libtbbThis 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/localCopy everything from /usr/local/lib/ia32/gcc4.4 to /usr/local/lib

Obtain the source and extract it to /dosbox. Change to the dosbox source directory.Do "./autogen.sh" or type the following:aclocalautoheaderautomake --include-deps --add-missing --copy autoconfexport CPPFLAGS="-I/opt/local/include"

Open Powershell as an AdministratorRun enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-LinuxGo 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

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 configNT 3.51 DIsable profile config, use WSOCKNT 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:

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:

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/bu ... pplication 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):

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'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=originalSwitching to fullscreen results in windows going to other screen when DOSBox is switched fullscreen but are moved back when DOSBox is minimizedDOSBox freezes for a couple of seconds when switching between fullscreen and windowed mode.

OPENGL with fullresolution=originalSwitching to fullscreen results in windows moving to other screen when DOSBox is switched to fullscreen and are not moved backDOSBox freezes for less that surface/overlay/ddraw

SURFACE with fullresolution=0x0Windows are not moved to other screensDOSBox still freezes for a couple of seconds when switching between fullscreen and windowed modeDosbox video is not scaled

OVERLAY with fullresolution=0x0Windows are not moved to other screensDOSBox still freezes for a couple of seconds when switching between fullscreen and windowed modeDosbox video is scaled and takes up the full screen

DDRAW with fullresolution=0x0Windows are not moved to other screensDOSBox still freezes for a couple of seconds when switching between fullscreen and windowed modeDosbox video is scaled and takes up the full screen

OPENGL with fullresolution=0x0Windows are not moved to other screensDOSBox freezes for less than surface/overlay/ddrawDosbox video is scaled and takes up the full screenOPENGL with fullresolution=0x0Switching to fullscreen results in windows moving to other screen when DOSBox is switched to fullscreen and are not moved backDOSBox freezes for less that surface/overlay/ddraw

Recommendation:fullresolution=0x0windowresolution=1280x800 (60% of steam users have a 1920x1080 display)aspect=truescaler=nonewindows use output=ddraw or openglnb (OpenGL ICD may not be present so SDL1=DDRAW (unless unofficial d3d) SDL2=D3D)

LCD = disregards fullresolution and aspect. Sets both to fullscreen=0x0 and aspect=true behind the scenesCRT = disregards fullresolution and aspect. Sets both to fullscreen=original and aspect=false behind the scenes