DOSBox Compilation Guides

General information and assistance with DOSBox.

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 08:47

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 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.
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-11-02 @ 09:16

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 ... p?id=14645
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 10:37

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 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?
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-11-02 @ 11:06

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.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 13:03

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.
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-12-08 @ 09:58

12-8-2018

Verify compilation with builds on Google drive. Supposedly network support not working. Check log.

Check variables (Decide if should include variables automatically....probably not):

User stated this worked with SDL_net 1.2.8+:
"./configure --enable-core-inline LDiatic -s LIBS=-lsdl_net -lws2_32 -liphlpapi CXXFLAGS=-O3 -march=i386 -mtune=i386"

Possible I tested with modified sdl_net that removes iphlpapi (Dependency introduced in SDL_net 1.2.8 but not needed for DOSBox) Need to check Mingw on Google Drive and review guide.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-12-13 @ 01:45

VS2003
viewtopic.php?f=32&t=9306&start=280#p719513
https://virtuallyfun.com/wordpress/2018 ... ng-themes/

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/visual-studio-net-2003-on-windows-7-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:

[
Code: Select all
]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!
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-12-20 @ 17:03

https://web.archive.org/web/20140908085 ... net/truth/

Retest DOSBox w/ Mingw-W64 w/ GCC 8
See:
viewtopic.php?f=24&t=52187&p=721209&hilit=scummvm#p721209

Dominus OSX script
viewtopic.php?f=32&t=64254#p721984

DOSBox mouse issue in a window with DPI scaling
viewtopic.php?f=31&t=63606&p=728131#p728131

viewtopic.php?f=32&t=60667

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 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++.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head


Re: DOSBox Compilation Guides

Postby junglemontana » 2019-6-16 @ 17:13

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:

Code: Select all
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"
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Compilation Guides

Postby DosFreak » 2019-6-16 @ 18:52

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.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby kjliew » 2019-6-16 @ 20:31

DosFreak wrote:MSYS and MSYS2 tools are usually ancient compared to repos

I think you mixed up MSYS and MSYS2. MSYS is ancient, true, but MSYS2/Mingw-w64 toolchain is current. Its GNU GCC is more updated than Archlinux toolchain which is the most bleeding edge Linux distro.

The tools are slow, mostly due to POSIX emulation layer, but the produced native binaries are not. Linux VM and WSL do not produce native binaries, so they are not the same and do not belong in the same context of producing and running native binaries.

There will always be small hiccups when the projects do not actively support the build environment. MSYS2/Mingw-w64 is new, many open-sourced projects still rely on legacy MSYS/MinGW which does not have pkg-config to begin with, so the configure scripts and source files will have to make certain assumption when pkg-config is not available. Unlike MSYS/MinGW, MSYS2/Mingw-w64 does have working pkg-config, but because it is new, the configure scripts may just make the same assumption for MSYS2/Mingw-w64.

I certainly do hope MSYS2/Mingw-w64 get better traction in the open-source world for Windows. Though the team was accused of hijacking the original MSYS/MinGW efforts, the ecosystem that was created is much more usable than MSYS/MinGW and more Linux-like.
kjliew
Member
 
Posts: 478
Joined: 2004-1-08 @ 03:03

Re: DOSBox Compilation Guides

Postby kjliew » 2019-6-16 @ 21:46

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.
Code: Select all
--- 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.
kjliew
Member
 
Posts: 478
Joined: 2004-1-08 @ 03:03

Re: DOSBox Compilation Guides

Postby DosFreak » 2019-6-16 @ 22:02

No mixup the the programs on the repo that MSYS and MSYS2 use for the various tools (not GCC or Mingw-w64 itself) used to compile libraries and various other programs are outdated compared to Linux. I know because I went through each when writing the guides. MSYS2 is alot better than MSYS about that but still outdated compared to Linux. I noticed because I had a lot of compilation issues on MSYS that were caused by outdated programs. It makes sense that they would be afterthoughts compared to the Linux versions.

Not referring to compiled binaries but the compilation environment. You're better off with a Linux VM or WSL on Windows than using MSYS or MSYS2 in my experience but I'll still write guides for them all.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby DosFreak » 2019-6-18 @ 19:14

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-arc ... 3/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-i ... container/
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby DosFreak » 2019-7-01 @ 02:02

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.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby junglemontana » 2019-7-03 @ 19:36

kjliew wrote:
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.
Code: Select all
--- 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.
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Compilation Guides

Postby kjliew » 2019-7-03 @ 19:49

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.
kjliew
Member
 
Posts: 478
Joined: 2004-1-08 @ 03:03

Re: DOSBox Compilation Guides

Postby DosFreak » 2019-7-03 @ 23:46

The motherboard I received for my server was bad so waiting on that....

Once the server is good to go then going back through the guides from scratch:
MSYS/MSYS2 Mingw and mingw-w64
Linux and WSL and windows cross compilation
Visual Studio (I've focused on the paid version but I'll look into the free versions as well)

VMs will be uploaded for Linux and I'll base my Windows guides off the latest MS Windows 10 ISO that anyone can download and uploaded zipped copies of the MSYS folders like I already have done.

The above looks like alot of work but it's mostly already done. The next step after that will be automation and then work on a MacOS guide.

viewtopic.php?f=32&t=52414&p=751603&hilit=WSL#p751603

UPDATE
7-19-2019
Finally got the server upgraded today and FreeNAS reinstalled and the config uploaded.
Working on the VMs next. Definetly not a fan of this bhyve virtualization but I can work with it.
User avatar
DosFreak
l33t++
 
Posts: 10424
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby junglemontana » 2019-7-19 @ 14:49

kjliew wrote:Applied the following patch.
Code: Select all
--- 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.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

junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

PreviousNext

Return to DOSBox General

Who is online

Users browsing this forum: Stretch and 1 guest