VOGONS

Common searches


DOSBox Compilation Guides

Topic actions

Reply 20 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Official DOSBox (0.74-2 and current SVN) supports 95 and NT4 with Active Desktop.
My builds support NT 3.50, NT 3.51, 95 and NT without Active Desktop. (Still haven't submitted patches yet)

Lowest SDL 1.2.13 supports is 95 (original) (unknown about betas) and NT 3.50 (Have to disable fullscreen support and use 3.51 joystick dll.). (SDL 1.2.14,1.2.15 and 1.2 branch work on 9x but DirectInput is bugged as of 1.2.14 so either have to use WINDIB, change a small bit of code or revert back to 1.2.13 mouse code)

For DOSBox to support Windows versions less than 95 or NT 3.50 SDL would have to support it which it does not and I definetly do not have the skills for that.
There would be no point in using older versions of DOSBox since they all rely on SDL.

You can run DOSBox using HX DOS extender which would be more preferable than running it under Windows 3.x. HX DOS Extender is still being updated too and there is an unofficial build of HXRT that supports modern sound cards. Check my compilation thread for the HX post otherwise you'll be wasting time. Currently I haven't made any HX specific changes, just use my 9x build which works well enough in HX (Or official DOSBox which should work) but DOSBox-X has made some specific changes for HX that I'd like to incorporate.

Instead of Windows 3.x I'd focus more on HX or coding DOSBox for DOS itself.

Modified HXRT with Intel-HDA, ICH/AC97, VIA82xx, ENS1371/1373, CMI 8338/8738:
http://www.bttr-software.de/forum/forum_entry.php?id=14645

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

Reply 21 of 48, by 95DosBox

User metadata
Rank Member
Rank
Member
DosFreak wrote:
Official DOSBox (0.74-2 and current SVN) supports 95 and NT4 with Active Desktop. My builds support NT 3.50, NT 3.51, 95 and NT […]
Show full quote

Official DOSBox (0.74-2 and current SVN) supports 95 and NT4 with Active Desktop.
My builds support NT 3.50, NT 3.51, 95 and NT without Active Desktop. (Still haven't submitted patches yet)

Lowest SDL 1.2.13 supports is 95a (unknown about betas) and NT 3.50 (Have to disable fullscreen support). (SDL 1.2.14+ works on 9x but DirectInput is bugged as of 1.2.14 so either have to use WINDIB, change a small bit of code or revert back to 1.2.13 mouse code)

To go any lower than the above SDL would have to support it which it does not and I definetly do not have the skills for that.
There would be no point in using older versions of DOSBox since they all rely on SDL.

You can run DOSBox using HX DOS extender which would be more preferable than running it under Windows 3.x. HX DOS Extender is still being updated too and there is an unofficial build of HXRT that supports modern sound cards. Check my compilation thread for the HX post otherwise you'll be wasting time. Currently I haven't made any HX specific changes, just use my 9x builds in HX which work well enough in HX but DOSBox-X has made some specific changes for HX that I'd like to incorporate.

Instead of Windows 3.x I'd focus more on HX or coding DOSBox for DOS itself.

I think the HX DOS Extender may have some compatibility issues on modern chipsets. DOS memory managers may not work properly on some Sandy Bridge chipsets and later. During SkyLake more DOS compatibility issues like Himem.sys no longer working properly began to occur. Have you tested on anything recent or from Sandy Bridge onwards?

Windows 3.1 can be made to support up to 512MB in standard mode and runs on modern Coffee Lake systems. 9x is a bit trickier to install than 3.1. However 95B with USB Support would be a good low end starting point OS due to its compact size and capable of supporting USB devices (limited) but no where near Windows 3.1's small footprint. But whether the Intel HD Graphics HDMI Audio out can be accessed under 9X for sound output is something that would allow the possibility of a USB portable DOSBOX running 9X on the go.

There's still the 9x display driver DOSBox requirement for 256 Colors that causes an issue unless DOSBOX can be made to do only the audio emulation and not do any video translation. Can you try to port DOSBOX to run on 95OEM and 95B with USB / 95C to avoid needing the 256 colors display driver requirement and keep the DOSBOX audio emulation separate and working or worst case running on the standard 16 color native OS display driver so any generic video card will work?

I'm not a coder so I'll have to start from the bottom with the less complex versions to analyze to catch up to where you are at. I still need to know if the original source codes to older Windows versions of DOSBOX can be downloaded.

If so are these available still can you provide the links to these?

Currently the oldest Windows executables I see is for v0.50 to 0.74 but no source code files are present with them.

Are there source codes to any older versions of Dosbox pre v0.50?

Reply 22 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

If there are issues with HX then contact the developer.
Since Himem.sys is no longer developed and if you have issues with it then should be using himemx or XMGR.

I haven't encountered any issues but I don't run DOS on anything that new except in VMs.

If you want to use DOSBox properly then you'll need at least 64mb of memory so 512mb isn't an issue.

I really don't know what your obession is with 256 colors. If your video card supports VESA and isn't buggy and if you don't have a video card driver then you should be able to use a generic vesa drive like VBEMP or similar instead of using standard vga....even DOS supports more than 256 colors so why would you limit the application for an artifical limitation?

It's possible Harekiet or Qbix have the source for those older versions, I believe they weren't using sourceforge before that. I doubt there would be anything to gain by going back that far as compatibility on both guest and host the latest ver of DOSBox is better.

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

Reply 23 of 48, by 95DosBox

User metadata
Rank Member
Rank
Member
DosFreak wrote:

It's possible Harekiet or Qbix have the source for those older versions, I believe they weren't using sourceforge before that. I doubt there would be anything to gain by going back that far as compatibility on both guest and host the latest ver of DOSBox is better.

I'm not a coder like yourself so to analyze simpler code makes it easier to digest what's going on in the newer later much improved versions.

I just modify drivers to work on older operating systems from XP to work in 2K. Or I compact it so it doesn't require a bunch of unnecessary drivers to run compared to the original. Sometimes you just don't need the extra fluff. Take your typical nvidia Driver it can be rather large some in hundred of megabytes. I was able to get the nvidia driver down to its bare minimum while still fully functional without the massive bloat.

DosFreak wrote:

If there are issues with HX then contact the developer.
Since Himem.sys is no longer developed and if you have issues with it then should be using himemx or XMGR.

Yes I already used those to get around some of the issues. But in general DOS compatibility is lost on the much later chipsets beginning with SkyLake.

DosFreak wrote:

I haven't encountered any issues but I don't run DOS on anything that new except in VMs.

If you want to use DOSBox properly then you'll need at least 64mb of memory so 512mb isn't an issue.

I really don't know what your obession is with 256 colors. If your video card supports VESA and isn't buggy and if you don't have a video card driver then you should be able to use a generic vesa drive like VBEMP or similar instead of using standard vga....even DOS supports more than 256 colors so why would you limit the application for an artifical limitation?

I only mentioned the 512MB because Windows 3.1 can handle it in Standard Mode. This extra memory could be allocated for a number of things like DOSBOX emulation or more sophisticated sound emulation. Running natively in DOS will pose conventional memory issues. Going to 9X and on another machine it may crash or not boot. Whereas booting in DOS or Windows 3.1 there's no need to configure anything on the OS if plugged into some random computer via USB.

The 256 colors issue is not an obsession but a way to make it possible to use DOSBOX with minimal requirements for the average user on any computer. I already tested VBEMP long ago on 9X and it's not compatible with the Intel HD Graphics and causes a corrupt garbage screen issue in DOSBOX in full screen. VBEMP will work with certain older generation graphics card in my tests but even with newer PCIe cards it will not be compatible for DOSBOX.

Navigating 9X with VBEMP in 2D doesn't pose any issues but running DOSBOX or any 9X 3D games will not work which is the point. If VBEMP worked properly I wouldn't be requesting this special DOSBOX 9X port. If DOSBOX sees a compliant card with proper 9X drivers then it should work as normal.

This is why I'm looking for a way to port DOSBOX to not check for this 256 colors requirement just to launch. I'm not limiting DOSBOX to run in less than 256 colors I just don't want to have any special 9X graphics driver installed for DOSBOX to function. If the user had a compliant working 256 color 9X driver then of course DOSBOX would then see it and use it so this wouldn't be an issue. But for generic systems with non compliant 9X drivers compatible for DOSBOX this is an issue.

If you don't believe me then try using DOSBOX on 9X with the Intel HD Graphics and you will see what I mean that DOSBOX will not run with VBEMP as you will get the corrupted graphics issue making it unusable.

Can you explain why DOSBOX even needs to have this 256 colors check compliance to work? What's wrong with running a 16 Color EGA game in DOSBOX while using the standard 16 Color Vga driver? Can't DOSBOX be separated to act in sound emulation mode only and let Windows itself run the DOS game in the Command Prompt window? I noticed DOS program will run fine in 256 colors mode using the Command Prompt in 9X. So why even enforce the 256 color graphics driver compliance for DOSBOX to even run?

DOS is the best method for running VGA 256 colors without any driver headaches but given the sound card restrictions on newer motherboards not having ISA slots this won't work for easy sound. Now if HX Extender can support USB Audio devices for sound output as if it were a genuine Sound Blaster card then that would solve that issue for native DOS sound compatibility. If it's gotten to that point then it could replace DOSBOX for OTG testing on any machine.

Reply 24 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

VS2003
DOSBox SVN Builds
https://virtuallyfun.com/wordpress/2018/12/13 … ositing-themes/

While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10. The first th […]
Show full quote

While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10. The first thing is that if I search through the source code base, the application locks up, hard. It turns out that this has been an ongoing issue with Windows 8 (maybe Vista/7?) with Aero rendering of all things. The fix is to disable Desktop Compositing & Desktop Themes, but the application comparability tab is hidden on many applications for Windows 10.

Broken Visual Studio
See how the application preview doesn’t render anything at all? This is the hint that it’s broken. I think it may be worth sharing this ‘fix’ as I’m sure that other applications that behave strangely have the same issue.

I found the solution to this over on stackoverflow in this discusstion:[https://stackoverflow.com/questions/2422581/v … hangs-on-search]. The fix is a registry entry in the “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” key.

The required settings to devenv.exe is:

“^ RUNASADMIN DISABLEDWM DISABLETHEMES”

Which, will run Visual Studio as Administrator allowing you to debug, and disable all the Aero assists for the application allowing things like resume to work again.

I had gone further and enabled the Windows XP SP3 compatibility settings, however on doing a clean build I was presented with this error:

[

]czo1MjpcImZhdGFsIGVycm9yIEMxMDMzOiBjYW5ub3Qgb3BlbiBwcm9ncmFtIGRhdGFiYXNlIFxcXCdcXFwnXCI7e1smKiZdfQ==[

]
Which I never could find any good source on what caused it, other than by guessing to remove the Windows XP flag, and now I’m able to build.

In order to do a full build of DOSBox I had to re-build SDL, SDL-net, zLib, libPNG, and set them to a common C runtime linker setting to get a build where the final link didn’t complain. However when it came to existing project files I did have to find some older Visual C++ 6.0 stuff for many of the components, but using those I was able to ‘upgrade’ them to the 2003 environment and produce a working set.

I’ve got to say, that the AVI capture in the newer branches (I’m using build r4177) is really great!

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

Reply 25 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

https://web.archive.org/web/20140908085148/ht … amer.net/truth/

Retest DOSBox w/ Mingw-W64 w/ GCC 8
See:
Re: ScummVM support for <=Windows 2000 dropped

Dominus OSX script
Build SVN in macOS - no keyboard input?

DOSBox mouse issue in a window with DPI scaling
Re: DOSBox SVN r4168 mouse cursor malfunction with Windows 10 display scaling

Key/Mouse problems while debugging dosbox-debug is active

https://nullprogram.com/blog/2018/04/13/

But when I brought the resulting binary into the virtual machine it crashed when ran it: illegal instruction. Turns out it conta […]
Show full quote

But when I brought the resulting binary into the virtual machine it crashed when ran it: illegal instruction. Turns out it contained a conditional move (cmov) which is an instruction not available until the Pentium Pro (686). The “pentium” emulation is just a 586.

I tried to disable cmov by picking the specific architecture:

$ i686-w64-mingw32-gcc -march=pentium -Os hello.c
This still didn’t work because the statically-linked part of the CRT contained the cmov. I’d have to recompile that as well.

I could have switched the QEmu options to “upgrade” to a Pentium Pro, but remember that my goal was really the 486. Fortunately this was easy to fix: compile my own Mingw-w64 cross-compiler. I’ve done this a number of times before, so I knew it wouldn’t be difficult.

I could go step by step, but it’s all fairly well documented in the Mingw-64 “howto-build” document. I used GCC 7.3 (the latest version), and for the target I picked “i486-w64-mingw32”. When it was done I could compile binaries on Linux to run in my Windows 98 virtual machine:

$ i486-w64-mingw32-gcc -Os hello.c
This should enable quite a bit of modern software to run inside my virtual machine if I so wanted. I didn’t actually try this (yet?), but, to take this concept all the way, I could use this cross-compiler to cross-compile Mingw-w64 itself to run inside the virtual machine, directly replacing Borland C++.

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

Reply 26 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Need to verify Windows XP (likely minimum SP3) and Visual Studio 2019
https://docs.microsoft.com/en-us/visualstudio … 9/compatibility

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

Reply 27 of 48, by junglemontana

User metadata
Rank Newbie
Rank
Newbie

MSYS2 is a surprisingly great tool. I managed to compile both 32 and 64-bit SVN versions of Dosbox on Windows. But I ran into problems when I tried to enable the debugger.

How I did it:

0) Installed MSYS2 from the official site https://www.msys2.org/

1) Start MSYS2, choose either 32-bit or 64-bit MinGW. Run pacman -Syyu twice to update the system.

2) Install the required utilities and dependencies using the pacman package manager. No need to install anything manually, except SDL_sound which is not available in the repository at the moment. But I guess it's not very important so I didn't install it.

3) Place Dosbox source code to the MSYS home folder.

4) Run ./autogen.sh and ./configure. I used --enable-core-inline LDFLAGS="-static-libgcc -static-libstdc++ -s" for configure, as suggested in Dosbox wiki.

5) Run make to compile Dosbox

6) Take dosbox.exe from the src folder. These were also needed: libwinpthread-1.dll, libpng16-16.dll, zlib1.dll, SDL.dll, SDL_net.dll and for some reason, libgcc_s_dw2-1,dll. I took these from the mingw/bin folder. For a 64-bit binary, the 64-bit DLLs must be used, but apparently not the libgcc DLL.

However, when I tried to enable the debugger, I got an error:
"configure: error: Can't find curses, which is required for debug mode"

I installed both ncurses-devel and pdcurses but it still complains about curses. Is there a solution for this?

edit: I forgot the output of configure:

checking curses.h usability... no
checking curses.h presence... no
checking for curses.h... no
checking for initscr in -lcurses... yes
checking for initscr in -lncurses... no
checking for initscr in -lpdcurses... yes
configure: error: Can't find curses, which is required for debug mode

So curses.h is not found... Maybe it's in a wrong directory, or configure doesn't search it from the correct directory?

edit2: So I copied curses.h from include/pdcurses to include/ and now compilation worked. But the resulting binaries don't work.

The 32-bit binary crashes and a pop-up appears: "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."

The 64-bit binary just closes immediately, and this appears in stdout.txt: "Exit to error: Setting up windows failed"

Reply 28 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I haven't added curses to my guide on Google Drive yet. I'm almost done upgrading my server so when that is done I can start work on the guides again.

I would recommend removing the ncurses and pdcurses packages and then reinstall pdcurses and follow the DOSBox wiki.

There is good reason for why it's recommended to download the source code and recompile for the libraries. Don't assume everything will work with the packages downloaded from the MSYS2 repo or elsewhere with DOSBox functionality or host compatibility.

Also this hasn't been needed for quite some time: "--enable-core-inline"

MSYS2 is usable in Windows but you're better off with a Linux VM or a Linux machine. MSYS and MSYS2 tools are usually ancient compared to repos. Also MSYS and MSYS2 environments are slow on Windows (but faster than WSL), Linux beats all of them.

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

Reply 29 of 48, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
junglemontana wrote:

ncurses-devel and pdcurses but it still complains about curses. Is there a solution for this?

You only need pdcurses for native code. The header is installed as pdcurses.h in top level include that simply serves as the proxy into include/pdcurses, which you can copy or rename as curses.h. The ncurses-devel is for building with POSIX emulation layer when you choose the MSYS2 environment. PDCurses and ncurses are not always making friends with each other. MSYS2/Mingw-w64 used to have ncurses for x86_64 and i686 native code libraries, but they are removed in recent updates. Typically, ncurses and readline are not easy to re-implement without POSIX emulation layer.

junglemontana wrote:

The 64-bit binary just closes immediately, and this appears in stdout.txt: "Exit to error: Setting up windows failed"

Applied the following patch.

--- dosbox-r4228/src/debug/debug_gui.cpp        2019-05-26 13:36:35.000000000 -0700
+++ devel/src/debug/debug_gui.cpp 2019-06-16 14:14:10.389844800 -0700
@@ -274,12 +276,12 @@
noecho(); /* don't echo input */
nodelay(dbg.win_main,true);
keypad(dbg.win_main,true);
- #ifndef WIN32
+// #ifndef WIN32
printf("\e[8;50;80t");
fflush(NULL);
- resizeterm(50,80);
+ resize_term(50,80);
touchwin(dbg.win_main);
- #endif
+// #endif
old_cursor_state = curs_set(0);
start_color();
cycle_count=0;

After this, running DOSBox will spawn 3 windows, one blank console, one debugger window and the DOS window. Not cool, on Linux with ncurses, it can reuse the terminal as debugger window.

Reply 30 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Doesn't really apply to DOSBox but can if someone wanted to use 32bit DOSBox on 19.10 for some reason:

https://discourse.ubuntu.com/t/i386-architect … /11263/2?u=d0od

So for every 32bit game they would all have to be either in one LXD or multiple? Would probably be better off using a VM but hardware acceleration in a VM is very spotty and passthru even more so. How portable is an LXD among different operating systems as compared to a VM I'm guessing not very? Likely would have to run a Linux VM in Windows, install LXD in that VM and import your container. bleh Are there snapshots? Does the OS in the LXD need to be updated? How prone is it to configuration issues, same as host OS?

Looks like a PITA:
https://blog.simos.info/running-steam-in-a-lx … stem-container/

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

Reply 31 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Virtualization must be enabled.

https://communities.vmware.com/thread/488599?db=5
https://kb.vmware.com/s/article/1993
https://en.wikipedia.org/wiki/CPUID
http://www.michaelm.info/blog/?p=1393

SSE1 hidden <Pentium 3
Add this line to the .vmx file: cpuid.1.edx=----:--0-:----:----:----:----:----:----

SSE2 hidden <Pentium 4
Add this line to the .vmx file: cpuid.1.edx=----:-0--:----:----:----:----:----:----

SSE and SSE2 hidden <Pentium 3
Add this line to the .vmx file: cpuid.1.edx=----:-00-:----:----:----:----:----:----

MMX hidden <Pentium
Add this line to the .vmx file: cpuid.1.edx=----:----:0---:----:----:----:----:----

CMOV <Pentium Pro
Add this line to the .vmx file: cpuid.1.edx=----:----:----:---0:----:----:----:----

- = use default value
0 = Hide feature
1 - enable feature

This likely isn't foolproof but may work in some cases.

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

Reply 32 of 48, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
kjliew wrote:
You only need pdcurses for native code. The header is installed as pdcurses.h in top level include that simply serves as the pro […]
Show full quote
junglemontana wrote:

ncurses-devel and pdcurses but it still complains about curses. Is there a solution for this?

You only need pdcurses for native code. The header is installed as pdcurses.h in top level include that simply serves as the proxy into include/pdcurses, which you can copy or rename as curses.h. The ncurses-devel is for building with POSIX emulation layer when you choose the MSYS2 environment. PDCurses and ncurses are not always making friends with each other. MSYS2/Mingw-w64 used to have ncurses for x86_64 and i686 native code libraries, but they are removed in recent updates. Typically, ncurses and readline are not easy to re-implement without POSIX emulation layer.

junglemontana wrote:

The 64-bit binary just closes immediately, and this appears in stdout.txt: "Exit to error: Setting up windows failed"

Applied the following patch.

--- dosbox-r4228/src/debug/debug_gui.cpp        2019-05-26 13:36:35.000000000 -0700
+++ devel/src/debug/debug_gui.cpp 2019-06-16 14:14:10.389844800 -0700
@@ -274,12 +276,12 @@
noecho(); /* don't echo input */
nodelay(dbg.win_main,true);
keypad(dbg.win_main,true);
- #ifndef WIN32
+// #ifndef WIN32
printf("\e[8;50;80t");
fflush(NULL);
- resizeterm(50,80);
+ resize_term(50,80);
touchwin(dbg.win_main);
- #endif
+// #endif
old_cursor_state = curs_set(0);
start_color();
cycle_count=0;

After this, running DOSBox will spawn 3 windows, one blank console, one debugger window and the DOS window. Not cool, on Linux with ncurses, it can reuse the terminal as debugger window.

I removed ncurses-devel, and cloned pdcurses.h into curses.h but the problem still occurs.

Thanks for the patch, I might try it next.

Using a Linux VM may work well but I find it rather cumbersome, and not all distros are that good for Windows/32bit cross-compiling.

Reply 33 of 48, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
junglemontana wrote:

Using a Linux VM may work well but I find it rather cumbersome, and not all distros are that good for Windows/32bit cross-compiling.

The ncurses usually is meant for Linux native code and work very well there for any POSIX compliant OS. If you plan to use Linux VM to cross compile for Windows, then this is a different story and more complicated setup than using MSYS2/mingw-w64. I would avoid going that route.

Another option is to build DOSBox with debugger option as Linux native code in Linux VM and use it inside Linux VM.

Reply 34 of 48, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
kjliew wrote:
Applied the following patch. […]
Show full quote

Applied the following patch.

--- dosbox-r4228/src/debug/debug_gui.cpp        2019-05-26 13:36:35.000000000 -0700
+++ devel/src/debug/debug_gui.cpp 2019-06-16 14:14:10.389844800 -0700
@@ -274,12 +276,12 @@
noecho(); /* don't echo input */
nodelay(dbg.win_main,true);
keypad(dbg.win_main,true);
- #ifndef WIN32
+// #ifndef WIN32
printf("\e[8;50;80t");
fflush(NULL);
- resizeterm(50,80);
+ resize_term(50,80);
touchwin(dbg.win_main);
- #endif
+// #endif
old_cursor_state = curs_set(0);
start_color();
cycle_count=0;

After this, running DOSBox will spawn 3 windows, one blank console, one debugger window and the DOS window. Not cool, on Linux with ncurses, it can reuse the terminal as debugger window.

So I tried this patch, but now compiling failed. I also tried to compile without the patch, and it failed with the same error, so this patch was not to blame. Dosbox version is r4252. Perhaps something changed in a recent MSYS2 package update?

g++ -g -O2 -mno-ms-bitfields -static-libgcc -static-libstdc++ -s -o dosbox.exe dosbox.o winres.o cpu/libcpu.a debug/libdebug. […]
Show full quote

g++ -g -O2 -mno-ms-bitfields -static-libgcc -static-libstdc++ -s -o dosbox.exe dosbox.o winres.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/mame/libmame.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -L/mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows -lncurses -lpng -lz -lSDL_net -lopengl32 -lwinmm -lws2_32

debug/libdebug.a(debug.o): In function `Z15DEBUG_CheckKeysv':
D:\msys64\home\user\dosbox-patched\src\debug/debug.cpp:1605: undefined reference to `PDC_ungetch'
D:\msys64\home\user\dosbox-patched\src\debug/debug.cpp:1596: undefined reference to `PDC_ungetch'
D:\msys64\home\user\dosbox-patched\src\debug/debug.cpp:1608: undefined reference to `PDC_ungetch'
D:\msys64\home\user\dosbox-patched\src\debug/debug.cpp:1599: undefined reference to `PDC_ungetch'
D:\msys64\home\user\dosbox-patched\src\debug/debug.cpp:1602: undefined reference to `PDC_ungetch'
collect2.exe: error: ld returned 1 exit status
make[3]: *** [Makefile:407: dosbox.exe] Error 1
make[3]: Exiting directory ”/home/user/dosbox-patched/src”
make[2]: *** [Makefile:444: all-recursive] Error 1
make[2]: Exiting directory ”/home/user/dosbox-patched/src”
make[1]: *** [Makefile:376: all-recursive] Error 1
make[1]: Exiting directory ”/home/user/dosbox-patched”
make: *** [Makefile:317: all] Error 2

Reply 35 of 48, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
junglemontana wrote:

g++ -g -O2 -mno-ms-bitfields -static-libgcc -static-libstdc++ -s -o dosbox.exe dosbox.o winres.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/mame/libmame.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -L/mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows -lncurses -lpng -lz -lSDL_net -lopengl32 -lwinmm -lws2_32

I noticed that on 2019-06-30, ncurses is back for mingw-w64 native code, but it didn't remove PDCurses which was its replacement when it was gone. I did a manual removal of PDCurses to get back to ncurses. My earlier patch is no longer valid. You were actually linking with ncurses while the undefined references were for PDCurses.

You need to pay attention to how your source was configured and if it picked ncurses or PDCurses. Typical, I would prefer ncurses over PDCurses, but I haven't tried my build, since I don't usually need the debugger from DOSBox. I am at r4252, too.

Reply 36 of 48, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
kjliew wrote:
junglemontana wrote:

g++ -g -O2 -mno-ms-bitfields -static-libgcc -static-libstdc++ -s -o dosbox.exe dosbox.o winres.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/mame/libmame.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -L/mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows -lncurses -lpng -lz -lSDL_net -lopengl32 -lwinmm -lws2_32

I noticed that on 2019-06-30, ncurses is back for mingw-w64 native code, but it didn't remove PDCurses which was its replacement when it was gone. I did a manual removal of PDCurses to get back to ncurses. My earlier patch is no longer valid. You were actually linking with ncurses while the undefined references were for PDCurses.

You need to pay attention to how your source was configured and if it picked ncurses or PDCurses. Typical, I would prefer ncurses over PDCurses, but I haven't tried my build, since I don't usually need the debugger from DOSBox. I am at r4252, too.

Thanks. I found a solution:

I created a file curses.h in the main include directory of MSYS2/mingw with the following contents

#include "ncurses/curses.h"

and now compiling was successful. Both 32-bit and 64-bit version seem to work well and the debugger appears correctly.

edit: Found a problem! Using Alt+X in the debugger window to set data view to DS:DX doesn't work. It enters an "x" into the debugger command line instead.

Reply 37 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

VS2017 w/ 98, NT4 and 2000
https://stackoverflow.com/questions/19516796/ … 548116#53548116
https://tedwvc.wordpress.com/2010/11/07/how-t … n-windows-2000/

Investigate <XP on VS2017.
Investigate VS2019 with v141 toolset for XP. v142 Vista+

Possible SDL2 Backports

Although in both cases possibly using a maximized window would be the easiest "fix".

Dual-Monitor
Re: DOSBox in fullscreen disables second monitor

Dropped keys
Dosbox dropping pressed keys?

Compilation
Post 791252

VS2017 less than XP
https://stackoverflow.com/questions/19516796/ … s-2000/53548116

VS2003 Windows 7+
http://bytepointer.com/articles/vs7.1_2003_on … fficial_fix.htm

VS
mkdir c:\dosbox\vcpkg
cd c:\dosbox\vcpkg
git clone https://github.com/Microsoft/vcpkg
bootstrap-vcpkg
vcpkg integrate install
vcpkg install "library"

MT-32
https://www.gog.com/forum/general/dosbo ... lain/post6

C++98 for GCC
C++03 for VS

C++11 would probably bump the minimum VS requirement from VS 2003 to VS2012 or VS2013 and mabye GCC 4.8.1.

No loss of Windows OS compatibility when compiled with mingw w/ GCC but VS would be XP minimum due to the CRT breaking compatibility. Although I'm looking into that viewtopic.php?f=31&t=55706&p=792269&hilit=compilation#p792237

C++ 11 DOSBOX
Post 804131

https://github.com/tpoechtrager/osxcross

-----------------------------------------------

Keyboard repeat
https://hg.libsdl.org/SDL/rev/b48d8a98e261

Clang
https://github.com/mstorsjo/llvm-mingw

DOSBOX Compilation

DOSBOX COMPILATION

MSYS2 variable mingw64 libpng

REPEATED KEY

https://hg.libsdl.org/SDL/rev/c244bc85fb84

305 /* Check to see if this is a repeated key.
306 (idea shamelessly lifted from GII -- thanks guys! 😀
307 */
308 static int X11_KeyRepeat(Display *display, XEvent *event)
309 {
310 XEvent peekevent;
311 int repeated;
312
313 repeated = 0;
314 if ( XPending(display) ) {
315 XPeekEvent(display, &peekevent);
316 if ( (peekevent.type == KeyPress) &&
317 (peekevent.xkey.keycode == event->xkey.keycode) &&
318 ((peekevent.xkey.time-event->xkey.time) < 2) ) {
319 repeated = 1;
320 XNextEvent(display, &peekevent);
321 }
322 }
323 return(repeated);
324 }

149 static Bool X11_KeyRepeatCheckIfEvent(Display *display, XEvent *chkev,
150 XPointer arg)
151 {
152 struct KeyRepeatCheckData *d = (struct KeyRepeatCheckData *) arg;
153 if (chkev->type == KeyPress &&
154 chkev->xkey.keycode == d->event->xkey.keycode &&
155 chkev->xkey.time - d->event->xkey.time < 2)
156 d->found = SDL_TRUE;
157 return False;
158 }

160 /* Check to see if this is a repeated key.
161 (idea shamelessly lifted from GII -- thanks guys! 😀
162 */
163 static SDL_bool X11_KeyRepeat(Display *display, XEvent *event)
164 {
165 XEvent dummyev;
166 struct KeyRepeatCheckData d;
167 d.event = event;
168 d.found = SDL_FALSE;
169 if (X11_XPending(display))
170 X11_XCheckIfEvent(display, &dummyev, X11_KeyRepeatCheckIfEvent,
171 (XPointer) &d);
172 return d.found;
173 }

SDL_x11events.c

149 static Bool X11_KeyRepeatCheckIfEvent(Display *display, XEvent *chkev,
150 XPointer arg)
151 {
152 struct KeyRepeatCheckData *d = (struct KeyRepeatCheckData *) arg;
153 if (chkev->type == KeyPress &&
154 chkev->xkey.keycode == d->event->xkey.keycode &&
155 chkev->xkey.time - d->event->xkey.time < 2)
156 d->found = SDL_TRUE;
157 return False;
158 }
159
160 /* Check to see if this is a repeated key.
161 (idea shamelessly lifted from GII -- thanks guys! 😀
162 */
163 static SDL_bool X11_KeyRepeat(Display *display, XEvent *event)
164 {
165 XEvent dummyev;
166 struct KeyRepeatCheckData d;
167 d.event = event;
168 d.found = SDL_FALSE;
169 if (X11_XPending(display))
170 X11_XCheckIfEvent(display, &dummyev, X11_KeyRepeatCheckIfEvent,
171 (XPointer) &d);
172 return d.found;
173 }

------------------------------------

mingw32 only available earlier than Ubuntu 15.04. Try Ubuntu 14.04

Available in universe

sudo apt-get install mingw32

sudo apt-cache search mingw32

mingw32 - Minimalist GNU win32 (cross) compiler
mingw32-binutils - Minimalist GNU win32 (cross) binutils
mingw32-runtime - Minimalist GNU win32 (cross) runtime

32bit
wget http://archive.ubuntu.com/ubuntu/pool/univers … buntu1_i386.deb
wget http://archive.ubuntu.com/ubuntu/pool/univers … buntu1_i386.deb
wget http://archive.ubuntu.com/ubuntu/pool/univers … ubuntu1_all.deb

64bit

wget http://archive.ubuntu.com/ubuntu/pool/univers … buntu1_i386.deb
wget http://archive.ubuntu.com/ubuntu/pool/univers … buntu1_i386.deb
wget http://archive.ubuntu.com/ubuntu/pool/univers … ubuntu1_all.deb

Install packages
sudo dpkg -i *.deb

Install dependencies
sudo apt-get install -f

Install packages
sudo dpkg -i *.deb

compile my own Mingw-w64 cross-compiler for less than Pentium Pro
Mingw-64 “howto-build” document

http://webkit.sed.hu/blog/20100716/cross-comp … nux-using-mingw

https://www.reddit.com/r/gcc/comments/8dhpot/ … ngww64_creates/

hello.cpp
#include <iostream>

int main()
{
std::cout << "hello world" << std::endl;
}

$ i486-w64-mingw32-g++ hello.cpp

Installing cross compiler manually
Alternatively you can try building from sources e.g. you can try older MinGW or MXE. After you do so, you must make compiler "visible" in your system. Adjust the $PATH environment variable e.g. if the compiler is /usr/local/myrcrosscompiler/bin/myrcrosscompiler-gcc then add /usr/local/myrcrosscompiler/bin to your $PATH:

export PATH="/usr/local/myrcrosscompiler/bin:$PATH"
Notice that this will affect only your current shell. Add it to something like .bashrc if you wish to make it permanent.

If you decide to modify $PATH permanently (through something .bashrc -like), this should have effect when sudo'ing (just don't use -i option when running sudo). However, if you don't do this, be aware that $PATH will not be passed to sudo. You may need to pass it manually when invoking sudo e.g.

sudo PATH="/usr/local/myrcrosscompiler/bin:$PATH" make install
Testing cross compiler
If compiler is ready you should be able to obtain GCC version at command line:

i686-w64-mingw32-gcc -v # should print gcc version
i686-w64-mingw32-g++ -v # should print g++ version
If sudo'ing with permanent $PATH:

sudo i686-w64-mingw32-gcc -v # should print gcc version
If sudo'ing with manual $PATH (see #Installing cross compiler manually):

sudo PATH="/usr/local/mycrosscompiler/bin:$PATH" i686-w64-mingw32-gcc -v # should print gcc version

https://ubuntuforums.org/showthread.php?t=170 … 30#post10561430
https://www.libsdl.org/extras/win32/cross/

Attachments

  • Filename
    VS2017forlessthanxp.txt
    File size
    15.58 KiB
    Downloads
    33 downloads
    File license
    Fair use/fair dealing exception
Last edited by DosFreak on 2020-02-25, 02:29. Edited 4 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 38 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

So I'm spinning this back up again. This weekend I worked on the attached guide for compiling DOSBox with Mingw-w64 6.0.0-3 on Ubuntu 19.10 for compiling executables from NT3.50+, Linux, 32bit and 64bit.

Mingw-w64 still works for compiled executables for NT3.50+ but a commit added in Nov 2017 almost threw me for a loop until I tried some newer msvcrt.dlls. Once these are used then NT3.50+ still work, although officially Mingw-W64 only supports Windows XP+.

I've worked towards making the guide more script-like while also readable.

This current guide has only been tested with Ubuntu 19.10 on a physical machine, I'll need to re-test with WSL and add specific instructions.

Need to work on:
check with clang
Verify that clang mingw-w64 exes only work for Windows 7+. Supposedly less than support dropped a couple of years ago? I don't remember any issues when compiling with MSYS2\Mingw-w64 so likely BS.
Need to add in NT3.50 SDL changes, DOSBox removal of Active Desktop requirement, WSOCK. These were already done previously but haven't re-tested for this guide.
Add info from msys\mingw-w64 guide. Misc troubleshooting, Mingw-w64 builds only for Pentium Pro+. Anything less requires recompiling mingw-w64 (which I plan on working on).
Recompilg mingw-w64 for <Pentium Pro and/or test installing the original mingw. Less than Pentium Pro important for running fDOS games that run too fast and compatibility.

Last edited by DosFreak on 2020-01-31, 23:42. Edited 6 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 39 of 48, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Added MSYS2 to the guide.

Need to do:
Check SDL_Sound and SDL_NET
Add DOSBox .diff change for SDL so DOSBox while in a window using ddraw or surface gets updated otherwise in window mode the screen is frozen
Test Clang
Verify Clang is Windows XP minimum (2000 with BlackWingCat)
Test original mingw with MSYS2 otherwise need to jump through hoops to update tools in MSYS1 that cause issues when compiling
Original mingw needed for <Pentium Pro until/if I recompile Mingw-W64 to support less than. Also since mingw is readily available whereas a build of Mingw-w64 for <Pentium Pro is not so it's still useful. (Well for those that care about gaming on old computers anyway)

Last edited by DosFreak on 2020-01-25, 22:04. Edited 1 time in total.

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