VOGONS


First post, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

Finally getting around to working on some optimizations for DOSBox... and since I messed with it years ago I forgot how frustrating it can be to get it to build all the way.

1. Need SDL.. so I get SDL and then try to compile.
2. Then it wants SDL_net which is not on the main SDL page.. ok, do a search and get it.
3. Need libpng so I get that.
4. need zlib so I get that.
5. Now it wants pnglibconf.h.. which is generated when pnglib is built.
6. Try to compile pnglib and even though zlib has been added to the include directories, it can't find zlib.h.. grrrr.. now have to figure that out.

I see this with all kinds of open source packages... they required a ton more fiddling with and quite a few more libraries, etc. to even be able to do a successful build.

WHY, WHY, WHY, WHY, WHY????? 😠 😠 😠 😠

Any project I release includes EVERYTHING needed to just build without having to do a bunch of messing with to get to work.

And if you absolutely don't want to include the libraries, at least have some folders (using relative paths) to put the source,libs, etc. in for each additional package with a readme or something that details where to put stuff.

I don't get it. If you are releasing a project, why not just include everything that is required to build it?

It just makes things super frustrating to work on otherwise.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 1 of 17, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

DOSBox really isn't that hard to compile, check the mingw guides in the compilation thread in my sig.

If you just want to run regular DOSBox w/ dynamic libraries on a i686 machine then all you have to compile is SDL and DOSBox.

My guides are focused on compiling everything since I'm focused on compatibility and elimination of errors and oddities which is lost when you use someone else compiled builds.

If you use mingw....then don't. For DOSBox it's only need for supporting <i686.
If you use mingw-64 then everything is likely available using pacman so you don't have to compile anything except for SDL which requires a modification for DirectX.

Storing the libraries in a different location is user preference. Currently for my mingw guides I store them in the mingw default locations since I had issues storing the prefix outside the mingw folder. (Issue with the variable not parsing correctly). There isn't much of a point of going against the default unless you want to provide your own compiled libraries for easy compilation (devs of those libraries recommend you use their builds).

If you're asking why DOSBox uses those libraries well if you have the coding skills to create that functionality from scratch while supporting everything those libraries do across all supported operating systems then get to it.

P.S. You're better off not using mingw or mingw-w64 on Windows and just using Linux to cross compile w/mingw to Windows. It's much easier than dealing with MSYS oddities, no outdated MSYS packages and compiles faster. If you're too lazy to use VMs you can use WSL which mostly works but has it's own issues and you can't really test your compiled executables properly using it without jumping through hoops.

How To Ask Questions The Smart Way
Make your games work offline

Reply 2 of 17, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

I'm using Visual Studio 2017... the projects converted fine.

And it isn't that I even mind using libraries.. it's just that the default VS solution is made for a specific version of the zlib library sources.. 1.2.8 and the external dependencies are set for a specific folder, etc...

My complaint is more about the SDL, zlib, and libpng sources.... the VS solutions are just horrible... and SDL_net is not even available to download from the main page.

Mostly just a rant of having to figure out stuff that should have been well documented AND well laid out in the first place.

Also just saying that the projects I have done have everything included to build and have clear instructions on exactly what to do if you want to build the needed libraries instead of the ones I include in the project.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 3 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Well, you know, it's an open source project and if you think it needs better documentation... do something about it. Contribute!
The ReadMe clearly states that you should take a look at the "Install" file, btw. A file that you should always check in open source programs.

Btw, DOSBox compiles fine without most of these libs on the autotools target... 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 17, by root42

User metadata
Rank l33t
Rank
l33t

The main problem is the C/C++ world. With Java you would have a maven or gradle project and it would just pull all dependencies for you. With Linux you can at least quickly install all necessary dependencies via your package manager. However with Windows and C/C++ you must do it all manually.

There are C++ package managers, like conan.io for example, but the project would have to switch completely to using it.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 5 of 17, by runar.orested

User metadata
Rank Newbie
Rank
Newbie

I agree with you that it is hard to compile and the instructions are not easy. Also, it does not help that while the instructions of the compilation guide tell you to simply get the precompiled dlls, headers and libraries, those do not work, because the ones supplied are too old for the free available compilers (Visual Studio Community 2017~2018, current GNU compilers), or can't compile in 64 bit mode without aplying patches not oficially released.

DosBox-X is for me the best semi-official succesor, but it does add a lot of new things like new hardware and pc-98 emulation without fixing others that may be useful, even if not for games exclusively: like running Windows 3.1 correctly, full support of floppy disk images, network card support, not being able to change or mount floppies on the fly, or allow to export the sound card, joystick, serial and parallel ports output to/from the host correctly.

Some of those things would allow a lot of new features adding them externally. For example, full hardware support of the floppies would mean:

  • Disk images with copy protections, or non-standard disk formats could be used (the ones used in Windows 95, OS/2 and 2M).
  • You could create blank disk images and format them from inside the emulator, just add a folder with some dosbox tools.
  • Mode3 disk support for Pc-98.
  • Using an usb floppy disk files.

Other example is that fixing port communication with the hosts would allow to:

  • Use old, legacy hardware on joystick ports which are ignored in modern machines.
  • Offload things like MT-32 to MuNT running on the host, which would run on another core, and reduce the CPU speed required to emulate the game, or allow to chain several instances of it instead of only one (higher polyphony).
  • Allow to run or communicate several dosbox instances between themselves, or even with another machine inside an actual emulator (DoxBox, Bochs) using virtual null modems, with the actual host machine as a bridge.

My reason is that the compiled custom versions with even a few of said patches, 99% of the time break keyboard compatibility with non english languages. I'm spanish, I use a spanish keyboard, and I like to play old text adventure games and run old DOS drawing and printing software (Deluxe Paint, Banner, etc) and not have Dosbox hangs or close everytime I write "\" , "ñ" or "@" when I'm trying to write a command or save a game or picture I've been working for the last hour. Graaa! 😠 Sesh!

As things are, I do need to switch between at least 5 versions (vanilla 0.74, vanilla svn, dosbox-x, DosBox Daum, and YJWong) to use some of said features, and they work in an iffy way.

Myself, I'm trying to make a series of cmd scripts to automatize the download, expansion, source patching and compilation of Dosbox. In that way, I would run an emulated Windows 7 machine with an installation of a current Visual Studio and VS 2008, and make a buildbot that can potentially compile dosbox for all versions of Windows supported (from NT 3.5 to 10 in 32 bit, from XP to 10 in 64bit). Once I could do that, I could add a folder to add custom patches, and then everyone could make their own custom Dosbox.

If you are interested, I would love some help, because I'm a virgin using Microsoft compilers, and the trick here is to make it work from the command line as much as possible. I'm attaching a sample.

Help me, Obi Wan Kenobi! 😉

Attachments

  • Filename
    DosBox-Buildbot.zip
    File size
    1.55 KiB
    Downloads
    296 downloads
    File license
    Fair use/fair dealing exception

Reply 6 of 17, by bloodbat

User metadata
Rank Oldbie
Rank
Oldbie
cyclone3d wrote:

I'm using Visual Studio 2017... the projects converted fine.
My complaint is more about the SDL, zlib, and libpng sources.... the VS solutions are just horrible... and SDL_net is not even available to download from the main page.

Recent zlib and libpng use Cmake (it can be horrible in its own right, though).

Reply 7 of 17, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
cyclone3d wrote:

I'm using Visual Studio 2017...

I hate to say this, but I want to tell you that this is the cause of your problem.
If you switch to MSYS2/mingw-w64-i686, then building DOSBox is just a cup of tea. All the dependencies libraries can be obtained from the pacman packaging system.

Reply 9 of 17, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I put together a complete VS2015/2017 build environment here:

http://www.columbia.edu/~em36/wpdos/dosboxwpsourcecode.html

But I don't really recommend it, except as something to experiment with, because a few things seem not to work correctly in a VS2015/17 build that work correctly in VS2010 (parallel port, and I think one or two other things that I've forgotten). Someday, if anyone wants it, I'll try to put together an equivalent package for VS2010.

Reply 10 of 17, by collector

User metadata
Rank l33t
Rank
l33t
emendelson wrote:

Someday, if anyone wants it, I'll try to put together an equivalent package for VS2010.

Sure. I still have 2010 installed.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 12 of 17, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Actually, this was easier than I thought. This is probably really bloated because I didn't clear out the parts of the library folders that aren't needed, and remember that the source code is my own custom build. Presumably you could replace all of the src and include directories with the contents of current SVN - but do NOT overwrite the visual_c directory, because that contains the properties with all the correct paths. Also look at config.h to see the options that I turned off. If you use the net features, you'll need to add sdl_net.dll to the Binaries folder.

This is (or is supposed to be) a complete build-environment for DOSBox that runs in VS2010. All you need to do is run the cmd file in the top-level folder that launches the project in VS2010 (which needs to be installed, of course), then right-click on DOSBox in the project navigator and choose Build. When the build is done, a folder named Binaries will open with DOSBox.exe inside, ready to be launched. So, basically, you build DOSBox with four or five clicks. No muss, no fuss, no downloading of anything other than the 7z file linked below.

I've only tested the cmd file under 64-bit Windows, so I'm not sure about the line that branches to a different folder in 32-bit Windows. I've tried to write the cmd file so that it will only run VS2010 and not mess up the project by starting it in a later VS version that may be the default on your system. (I have VS2017 on my system and installed VS2010 Express Edition in order to try this out.)

Let me know what's wrong with this (and what's right if it works):

http://www.columbia.edu/~em36/wpdos/DOSBoxWPS … e2017-VS2010.7z

Again, it's probably easy to remove a lot of needless stuff, but I didn't get around to it.

If you can figure out how to get rid of the linker warnings at the end, I'll be grateful. Also if you can trim down the bloat.

P.S. For the original poster - my code includes a patch that should make the Spanish keyboard work correctly; I didn't write the patch, it was supplied privately by one of the DOSBox devs. EDIT - The code I posted when I first posted this message didn't have the Spanish-diacritic patch, but I've updated it and the patch is in the download now.

Reply 13 of 17, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I've now got rid of two-thirds of the bulk of the download in the previous post. Probably a lot more can disappear also, but this is at least manageable. Remember that this builds custom code, not standard SVN, but it should be easy to make it build SVN by replacing the include and src folders with the SVN versions. You may need to edit config.h to suit SVN.

Reply 15 of 17, by rainwarrior

User metadata
Rank Newbie
Rank
Newbie

I went through the process of figuring out how to build with VS 2017 today. Was eventually successful, but had a few hiccups. In hindsight, it probably would have been easier to install MinGW, but I didn't know until reading this thread that that was the more official way to go. If the VS version is not on equal footing, it might be worth putting a short recommendation of MinGW over VS on the wiki at BuildingDOSBox or the main page? At least, that Wiki was my point of entry for this.

Some notes, in case they're useful to anybody else:

Current libpng ( 1.6.34 ) comes with a VS solution that seems to conveniently also build zlib ( 1.2.8 ) if you have it in an adjacent directory... however this ended up being a big trap for me. That project defines Z_SOLO for zlib, which causes video generation to fail and crash. (Specifically in hardware.cpp: capture.video.codec->SetupCompress will fail to initialize the zlib deflate stream, and this error isn't handled properly, the video is in a "half open" state and will silently fail to write video leaving an empty file, and crash when you try to close it later.)

Less minor issues with libpng/zlib: code generation should be /MD to match the other stuff, and you may need to tweak the warning level because all warnings on VS 2017 produces some extra warnings about the Spectre thing that you probably don't care about and will "warnings as error" fail the build.

SDLmain has to be rebuilt with VS2017 to get rid of a strange error looking for __iob_func from the pre-built libraries from an older VS version. (I saw some tip to define it yourself elsewhere but that seems to cause a crash on exit. Better to just rebuild.) I also rebuilt SDL at the same time, not sure if that was a necessary part of this.

SDL_net seemed fine with existing available library binaries, though I'm not sure I know how to use its relevant features in DOSBox so I'm not 100% sure. (Could always rebuild it though.)

Didn't bother figuring out how to build curses.lib, as it sounds like it's just for using a DOS debugger? Also didn't bother with the compressed sound thing, but maybe I'd look at it whenever I actually want to run something that requires it. (Though really I'd probably just do MinGW if I was going to revisit this.)

Dominus wrote:

The ReadMe clearly states that you should take a look at the "Install" file, btw. A file that you should always check in open source programs.

Looking at INSTALL would have been a good tip. To be honest, I did open README, but it's 64k and almost entirely a users guide for the program, so though I did start reading it I assumed it wasn't going to help me build it. I see now that this tip about INSTALL is in there, at the very bottom. I guess I could have noticed "building" was in the table of contents, but I missed it too. I had looked at a bunch of other files as well, but there's so much stuff in there (plus a docs folder), and none of the random things I did open ended up helping, unfortunately. Mostly I tried to go by the Wiki, but it's guide is for a very old version of VS, and completely sidesteps zlib/libpng where I had most of my problems anyway (screenshots and video are important features to me).

Not the most difficult build experience I've had with an open source project, but that Z_SOLO problem really bit hard. Took a fair bit of time to debug that.

Reply 16 of 17, by rainwarrior

User metadata
Rank Newbie
Rank
Newbie

As a followup, I went through Building DOSBox with MinGW on the wiki, and managed to build DOSBox that way as well. There were several hiccups along the way, but I documented them on that wiki page.

After going through it, I'm not sure if the MinGW way is easier or harder than doing it with VS2017, but I think the documented process on the Wiki was at least closer to the current state of things. The main issue I had in VS was that Z_SOLO issue but it seems possible to alleviate that problem, so it might just disappear. I'll try to add an explanation of the __iob_func thing on the wiki though.

Reply 17 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks for taking the time to correct and to ad comments 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper