tracking these upstream issues:

• mackron/dr_libs#75
• mackron/dr_libs#76
• mackron/dr_libs#77
• mackron/dr_libs#78
• mackron/dr_libs#79
• mackron/dr_libs#80
• mackron/dr_libs#81
• mackron/dr_libs#82
• mackron/dr_libs#83
• mackron/dr_libs#84
• mackron/dr_libs#85
• mackron/dr_libs#86
• mackron/dr_libs#87
• mackron/dr_libs#88
• mackron/dr_libs#89
• mackron/dr_libs#90
• mackron/dr_libs#91
• mackron/dr_libs#92

This list created with echo mackron/dr_libs\#{75..92} | xargs -n1 echo -

A script that builds DOSBox for Windows under Linux would be great. MSYS2 is rather slow.

mackron/dr_libs#112 (fixed)
mackron/dr_libs#110 (fixed)
mackron/dr_libs#109 (fixed)
mackron/dr_libs#107 (fixed)
mackron/dr_libs#103 (fixed)
mackron/dr_libs#101 (fixed)
mackron/dr_libs#98 (fixed)
mackron/dr_libs#96 (fixed)

Clang:

• nothings/stb#816 (already addressed in our version)
• nothings/stb#817 (already addressed in our version)

Coverty:

• nothings/stb#838 (closed)
• nothings/stb#839 (fixed in our #71)
• nothings/stb#840 (closed)
• nothings/stb#841 (closed)
• nothings/stb#842 (fixed in our #71)
• nothings/stb#843 (closed)
• nothings/stb#844 (closed)
• nothings/stb#845 (closed)
• nothings/stb#846 (closed)

List created with echo nothings/stb\#{838..846} | xargs -n1 echo -

In staging, there are some regressions: it can't mount .img files anymore (see topic on vogons). At least what i find from fast tests, maybe something else.

Originally posted by @kas1e in #144 (comment)

So basically extend both the cue format and imgmount to 'emulate' a cd from files in a dir for the binary track, like mount -t cdrom.

Why
It saves some space, because the iso fileformat mandates Error Correction Codes (ECC).

This would also allow the ability to mount multiple host filesystem dirs as cds and 'change' them with the CTRL+F4 mechanism, as well as use cd audio mechanism, that imgmount already has.

As for why this good, it's a very nice way to share files between dos games used in dosbox and engine recreations that need different names or organization for the files, like scummvm or openlara.

By having the files in the host filesystem, you can simply use hardlinks or symlinks to duplicate or rename them elsewhere, and if you have filesystem compression, like squash, they are already deduplicated; which is not the case if the files exist as a iso and a extracted directory; because compression is not that smart.

The alternative if you want to use the data for both cases is either to find or create a nocd for the particular game and use a directory mount (doesn't work if the game has cd audio), use mount -t cdrom (doesn't work if the game has cd audio or multiple cds) or just duplicate files, which can get problematic for large collections.

How
Use the code in mount -t cdrom that can mount the host dirs, to mount a path as a track in the imgmount code after the cue parser recognizes that path (probably with a extension of the format, for instance 'DIRECTORY' instead of 'BINARY' on the track affected).

mackron/dr_libs#65

At the moment, the DOSBox code is exclusively SDL1.2 compatible - this is a growing problem, as SDL1.2 is no longer being supported for ~7-8 years at this point - maintainers encourage everyone to move to SDL2, which is a substantial upgrade. Additionally, official releases of DOSBox on Windows use modified version od SDL1.2 library (see file: src/platform/sdl-win32.diff), which makes it harder to properly reproduce build on Windows.

A lot of users (and some DOSBox devs) don't consider this an issue, as there is 6-year old, so-called "SDL2 patch" (f1b82ef). However, this patch/thread is not named correctly - it's really a port of DOSBox to Android platform with SDL2 parts attached. This patch has some inherent problems, that (I believe) prevented it from being merged so far:

• +13k lines of code in a single commit
• incompatible with SDL_sound 1.2 (despite information in that thread), breaking the mounts of .cue files
• tries to be compatible with both SDL2 and SDL1.2 on compilation-level by introducing a whole lot of ifdefs in code, making it borderline unmaintainable. In result the code is ifdefed not only per-platform, but also per SDL < 1.2.13, SDL < 2 and SDL >=2, OpenGL and OpenGL ES.

These are not criticisms of author or his code - author had no other way of suggesting his patch for inclusion in SVN without having direct commit access.

Problems with SDL 1.2

• The library is not maintained any more
• Game-breaking input issues on Linux (it depends on the game)
• Problems with integration into modern Desktop Environments (e.g. broken Alt-tab)
• Requires dosbox-specific patch to SDL1.2 on Windows
• Non-support for setups using multiple displays (broken in several ways, fix requires specific values in dosbox configuration AND environment variables to trigger specific SDL 1.2 behaviour)
• Problems with support for modern gamepads/joysticks/other input methods
• Problems with input in specific environments filtering input or injecting overlays (e.g. Steam/SteamOS)
• No Vulkan support, no Metal support (which means: sooner or later, there will be no more hardware accelerated renderer on macOS)
• No Wayland support
• Breaking input issues in XWayland in Wayland in ALL games

Costs/benefits of using SDL2

Costs:

• SDL2 dropped SDL_sound library (this issue will be addressed by #12)
• SDL2 dropped SDL_cdrom library (f1b82ef bundles this library, but don't want to include it in dosbox-staging master unless there will be a dedicated programmer, who will maintain it. Physical CD-ROMs are already quite rare in modern computers, and users clinging to their physical CDs should back them up as .iso files sooner rather than later)
• Dropped support for ddraw renderer (it is, theoretically, replaced by direct3d renderer, but the code was likely never tested)
• The "SDL2 patch" is likely incompatible with a number of other important patches posted on Vogons forum
• No support for OS/2

Benefits

• Testing indicates, that it solves ALL input issues
• Very likely will work fine without patching SDL library on Windows
• Solves most of Desktop Environment integration issues on Linux
• Enables an upgrade path towards implementing Vulkan and Metal renderers
• Enables an upgrade path towards Wayland support
• Dropping OS/2 is actually beneficial from POV of code maintenance
• Provides better scaling by default (I'm not sure if it is as good as scaling implemented by "Pixel Perfect" patch (openglpp renderer), but it's definitely better than current version of DOSBox.
• Removes a number of hacks implemented in DOSBox code for SDL1.2 support on Linux
• Provides additional features and support for modern platforms

Plan

This is my suggestion on steps required to resolve this issue, I am open to suggestions/alternative plans

edit: leaving original plan in here; revised plan and status update in comments below

1. Step by step, resolving #12
2. Replace dependencies on SDL_cdrom, that exist outside of CDROM-related code (included in #28)
3. Remove physical CD-ROM support to avoid SDL_cdrom dependency altogether
4. Remove OS/2 support from DOSBox code
5. Strip "SDL2 patch" out of Android-related and CD-ROM related parts
6. Provide detailed documentation/instructions on converting DOS games distributed on CD to .img files or, even better, .cue files with audio stored in .flac.

Test implementation of Step 5 can be found in 26027c9 - it changes initial +13k lines of code to +704,-966.

These are several inter-connected small bugs, that irritate me:

1. DOSBox accurately emulates "appending newline" after each interactive command. This is exactly how MS-DOS behaves and also cmd.exe (even on Windows 10) - so in this way, this behaviour is "correct". However, this is extremely annoying as it means losing >= 4% of terminal window just to show nothing.
2. Appending newline "breaks" CLS command, as it assures, that there's always a blank line on top, unlike unix clear. This is in line with MS-DOS and Windows cmd.exe, not in line with FreeDOS, PowerShell or bash.
3. Additionally, DIR command formats initial lines wrong (making them blend with actual file listing, unlike any real implementation of DIR) and other details wrong (e.g. "Bytes" instead of "bytes").
4. Command PAUSE appends newline before any key is pressed (unlike MS-DOS or cmd.exe)
5. Additionally, DIR /P pauses one line short and injects newline too fast, so the text "Press any key to continue." (should end with "..." btw) is shown twice on the screen, could've easily show 2 more files per screen.
6. FreeDOS and PowerShell fixed these issues and behave the same way as any sane UNIX terminal would do (no additional newlines are injected in interactive mode) - I like FreeDOS choice in this matter. Removing this newline would not affect .BAT scripts in dosbox (newline is appended only in interactive mode). Perhaps the removal of this newline should be a user option, but I don't feel it's necessary.

Packaging the latest builds from master will allow users to test and provide feedback regarding newly-integrated features. Feedback, both good and bad, is critical toward building confidence in the technical work, the people involved, and the process here regarding git and its workflow.

Import aspects:

• Obvious and easy versioning - a commit identifier should be readily available for feedback and issue reporting. It should be easier to find the version that it is to not find it; if that makes sense.
• low barrier of entry - beginners should be able to run the binary without requiring esoteric DLLs or installing some percent of the development tools. This "threshold" might be different based on the OS; for example, on Linux perhaps we can ask users to apt install -y sdl sdl_net opusfile, where as Windows and OS X users we can package those libraries inside the zip/dmg file.
• expiration - ideally only the current latest build should be available. Old packages should be removed once new ones are available. With limited man-power, this will keep the focus on the current state of master.

Currently, the documentation states that nuked provides the best accuracy while compat provides the best quality.

These adjectives need to be qualified and expanded upon with other traits, to help users.

Found today another bug in staging which didn't happen in the latest original DosBox.

Take as example ocp260pre6.zip filename. That what I have with staging:

http://kas1e.mikendezign.com/aos4/dosbox/longfilenames/dn_000.png

That what I have with the latest original DOSBox:

http://kas1e.mikendezign.com/aos4/dosbox/longfilenames/dn_001.png

See on the right panel, we have 2 files after the dirs. In original we have ocp260~.zip as expected, but in Staging, we have some cryptic numbers like ~7046798.zip.

But worth of check on other platforms IMHO as well.

An effort is underway to address this:

1. Replace the original WAV decoder that came with SDL_Sound 1.2 with dr_wav
2. Work with dr_wav upstream to address current big-endian issues, tracked here: mackron/dr_libs#66

Under windows, the build's return code isn't making it up to GitHub's CI run: level.

https://github.com/dreamer/dosbox-staging/runs/299604745#step:6:439

Vogons user citrixscu reported:

DOSBox content within the window disappears if output=texture[nb] and renderer=auto or metal. This is consistent with any SDL2 build I run on this machine, but I can't find much info on what's going on behind the scenes.

https://www.vogons.org/viewtopic.php?p=820547#p820547

The CDDA code currently handles "beyond-end-of-file" reads as invalid: it will play up-to the end of the track, and not beyond it. This behavior turns out to be incorrect, and the playback should carry into into the next track.

The GoG release of Betrayal at Krondor (which uses cue+oggs), either due to a CD mastering issues or a faulty rip, can sometimes request playback of a given track at the tail end of the prior track. For example: if it wants to play track 16 for 44 seconds, it requests to play track 15 at its 99% position (which is merely a blip of audio), and the game expects playback to carry on into track 16 for roughly 42 second (minus the blip in track 15).

The bin+cue version of the game is not affected by this. In testing hundreds of CD-DA games, this is the first game encountered that requests playing more audio frames than are present in the track being played.

Issue reported by Dagar and Pr3tty F1y, and confirmed as a bug by ripsaw8080. Thank you!

Tested with latest DosBox-Staging and with latest original DosBox repo: in all cases, recorded video have a distorted sound if you record anything which has sound/music.

GitHub currently requires a login account to download CI logs and artifacts.
It would be nice to offer at least the current latest-master CI results publicly and not require a GitHub login account to view them.

When implementing release builds I presumed libpng12 will be available everywhere while libpng16 might be missing… as it turns out, the opposite might be true.

It seems like libpng12 is available everywhere… except Ubuntu > 16.04… And some packages might bundle their own copies of libpng12 so that might result in the package working for some users and failing for others.

It seems like most distributions transitioned to libpng16 by default due to security issues.

I need to investigate what package is pulled by SDL or preinstalled by default on major distributions and adjust our scripts and instructions accordingly.

Recently I installed Windows 3.11 inside dosbox-staging for testing, and nothing kills enthusiasm for installing older software then the necessity to juggle multiple floppy images. Especially if installer sometimes asks user to put in floppy out of order ("please insert this disk 5 out of 10").

It is totally possible to mount them alrady with imgmount and change with Ctrl+F4, but it is annoying due to lack of feedback.

With SDL2 it should be possible to implement mounting via SDL_DropEvent, which should make it much easier to mount floppies selectively.

Additionally, we could leave some visual indication about mounted floppy by placing e.g. A:<label> in the title bar (and remove "frameskip" information to make room).

Description

Playing CDROM Audio in DOSBox results in the PCM audio samples being copied across three (or more) memory buffers before they're processed by SDL. During the last copy, each sample is individually copied in a tight for-loop that includes evaluation of several if/else branches.

This issue asks the question, "is it possible to eliminate one or more of these buffers?" This would reduce the number of unnecessary memory transactions from 529,200 bytes (or more) per second to something lower; the lower-bound being 176,400 bytes per second (CD audio is 2 channels, 44,100 samples per second per channel, at 16 bits per sample).

Buffer Locations

The three buffers mentioned above are nested as follows: Mixer's work buffer [ CDROM imagePlayer's buffer [ SDL SoundSample buffer ] ] ]

1. The Mixer's work buffer Bit32s work[MIXER_BUFSIZE][2] is defined in./hardware/mixer.cpp.
2. The CDROM imagePlayer's buffer buffer Bit8u buffer[AUDIO_DECODE_BUFFER_SIZE]; is defined in dos/cdrom.h.
3. The cdrom_image instantiates a Sound_Sample object, which defines its buffer in ./libs/decoders/SDL_sound.c.

Runtime Flow

1. The DOSBox's Mixer calculates how much of its "work" buffer needs to be filled, called len.
2. The Mixer asks the imagePlayer for len bytes.
3. The imagePlayer asks cdrom_image for len bytes.
4. The cdrom_image asks the Sound_Sample to decode len bytes.
5. The Sound_Sample calls the decoder (flac.c), which tells the codec (dr_flac.h) to fill the SampleBuffer with enough PCM frames to fill len bytes.
6. The cdrom_image memcopies the Sample's buffer into the imagePlayer's buffer
7. The Mixer copies the imagePlayer buffer into its work buffer (in a per-sample for loop)

Note that the Mixer compares the user's configured [Mixer] rate (in dosbox.conf) with the sample rate of the audio source, and if needed the mixer will interpolate (creating additional) samples to satisfy the output rate to the audio driver.

In the case where CD Audio creates a mixer, the original DOSBox code hardcodes the audio source rate to 44100 samples/s. In the case of this patch, we adjust the source rate on a per-track basis and get the sample rate from the compressed file, via the codec. So our rates might be 48Khz, 44.1kHz, 22.05kHz, and so on.. even 96kHz is valid.

Therefore, to avoid this interpolation and zero-copy direct into the SDL buffer, we would need to confirm that the user's [Mixer] rate matches the track's rate. If they don't match, then fall-back to the interpolating code.

Optimization / Simplification

Is it possible to eliminate one or more of these buffer-middle-men?

Ideally the mixer could pass-through its work buffer and desired len into the imagePlayer, which would pass them onto the cdrom_image's callback, which would pass them onto Sound_Sample's read() function, which would pass them onto the decoder, which would pass them to the codec to be written into.

Automated regression testing would let us make changes with the confidence that functionality and performance regressions are caught fast.

To avoid changing DOSBox's internal code (with whitebox tests), a blackbox approach would allow non-developers to contribute cases.

A test case would involve feeding DOSBox a custom dosbox.conf file (setting particular features), running a DOS program that generates some capturable result (then quits on its own when done), and finally comparing the captured result to a previously saved known-good result.

The test harness could also record metadata such as test runtime, memory usage, latency, etc - so performance and resource uses could at least be measured and more importantly trended or flagged. (although some tolerance would be included as we aren't guaranteed isolated and identical CI VM hardware).

Getting this off the ground would involve modifying DOSBox so it can run headless; currently it fails to even start if SDL can't latch onto an active display. We would need to find or write representative DOS programs that exercise some singular element of common game functionality: real mode, protected mode, EGA, VGA, SoundBlaster, GUS, and so on. For now, simply having DOSBox run "hello world" would let us get the framework in place.

Themes are:

• alignment issues in the x86 emulator: cache.h and mem.h
• direct and indirect leaks in gui/sdl_mapper.cpp
• indirect leaks in hardware/serialport/serialport.cpp

Updated runs attached.
clang-usan.log.gz
gcc-tsan.log.gz
gcc-uasan.log.gz
gcc-usan.log.gz
clang-msan.zst.txt

Note: Clang's 400KB MSAN report will expand to over 1GB 💣. Use zstdless --long=30 clang-msan.zst.txt to view it on the fly without touching your disk.

ATM, DOSBox appens version name to the configuration file, e.g. ~/.dosbox/dosbox-0.74.conf. This is not a common practice (configuration files are rarely versioned this way) and it's rather user-unfriendly, however hard to spot when running SVN version-less build for long time.

To mitigate this a little bit, dosbox-staging uses fixed configuration file (atm it's ~/.dosbox/dosbox-staging-git.conf - for debug and development releases - introduced in #72). This makes the default config more usable, but it triggers a different issue: now it will be practically impossible to upgrade users to changed default configuration.

There are several ways to approach this, the easiest solution would be to not dump whole default config in a new .conf file and let user decide what should go there. Perhaps also store defaults, with better documentation in the package or in /etc/.

The goal, per @dreamer 's description:

I suspect a file, which would look sort-of like this:

#!/bin/bash

case "$1" in
	macos)
		echo "coreutils autogen autoconf automake pkg-config libpng sdl sdl_net opusfile speexdsp" ;;
	ubuntu)
		echo "package1 package2 (...)" ;;
	ubuntu-32)
		echo "packageX packageY (...)" ;;
	fedora)
		echo "packageN packageM (...)" ;;
	msys2-64)
		echo "(...)" ;;
	msys2-32)
		echo "(...)" ;;
	vcpkg)
		echo "(...)" ;;
esac

Instant-launch would take place when DOSBox is started with an executable (.bat, .com, or .exe) on its command-line. ie: dosbox rungame.bat

Instant-launch would:

• skip all DOSBox-specific visual output (logos / banners / other messages)
• set the video-mode to whatever the game has requested, straight-away, without any prior video modes being set

If no executable is provided, DOSBox would start in interactive-mode, per its existing behavior:

• display the logo
• display the help banner
• display any other DOSBox-specific content
• deposit the user at the DOS command prompt

Motivations for instant-launch are:

1. to fall in-line with all other high-quality emulators that simply "get out of the way and start your game", such as those supported on RetroPie.
2. to match the experience in real DOS. When your launch a game from the command prompt, Microsoft does not insert pre-popup fanfare before the game starts up.
3. to eliminate visual redundancy. If the user launches multiple games in short succession, these screens act as unavoidable redundancy to the user's experience.

Please vote with a 👍 or 👎
(nothing personal here: this is simply an idea that we can kill or run with!)

This is a nice to have for sometime after SDL 2 support is done. Pcem supports it, and I can say playing dos games with a nice CRT shader is a pretty sweet alternative for those of us who don't actually want to lug around the real thing. :)

Tracking upstream:
https://sourceforge.net/p/dosbox/bugs/476/

I suspect a ./configure.ac block that leverages pkg-config would address it:

PKG_CHECK_MODULES([NCURSES], [ncurses],
  [ LIBS="$LIBS ${NCURSES_LIBS}"
    CPPFLAGS="$CPPFLAGS ${NCURSES_CFLAGS}" ], [])

I was experimenting with fixing some code related to labelling floppy drives (because it does not work in DOSBox at all - seems like it got broken years ago), and noticed that dosbox-staging does not exit cleanly any more (I need to press ctrl-c to abort the process after exit).

Eventually, I pinpointed the smallest number of steps needed to trigger the regression:

./src/dosbox -c 'imgmount A ~/.dosbox/A/Disk01.img -t floppy' -c 'exit'

In my case, the image is the first floppy of Windows 3.11 installation disks, but presumably, it'll happen with other images as well.

git-bisect points to c9198b2 as a commit, that introduced the regression. I gave it a brief look (again, I reviewed this code in the past) and can't immediately spot the problem.

@krcroft Can you confirm this is actually an issue? Maybe it's something different related to my setup (or my floppy image).

The good thing about this bug: it forced me to use git bisect for the first time in a long time, and it gave me idea about how to do some preliminary regression setup.

I was testing some other feature and noticed that Warcraft 1 (GOG version) started crashing on exit for me. I did bisect and some preliminary investigation:

Crash was introduced in eaeb001 (somehow I missed it in review :( ).

Reproduction steps

GOG version of Warcraft 1 mounts CD image this way: imgmount D "../WAR1.CUE" -t iso; content of the .cue file:

FILE "WAR1.BIN" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PREGAP 00:02:00
    INDEX 01 29:39:25
  TRACK 03 AUDIO
    INDEX 01 30:26:69
  TRACK 04 AUDIO
    INDEX 01 34:38:54
  TRACK 05 AUDIO
    INDEX 01 38:25:46
  TRACK 06 AUDIO
    INDEX 01 42:07:59
  TRACK 07 AUDIO
    INDEX 01 45:57:10
  TRACK 08 AUDIO
    INDEX 01 49:35:12

With this setup, crash happens in CDROM_Interface_Image::ClearTracks():

void CDROM_Interface_Image::ClearTracks()
{
	for (auto &track : tracks) {
		if (track.file) {
			delete track.file;  // <- crash happens here
		}
	}
	tracks.clear();
}

Turns out in this case, multiple tracks point to the same TrackFile (track.file field) object (I'm not sure if this was intentional or not); all tracks try to destroy the same object on close.

@krcroft I think two scenarios in here might be happening, but I don't know the surrounding code well enough to decide:

• either TrackFile object is supposed to be shared between tracks (in such case shared_ptr might be a good solution here)
• or TrackFile is supposed to be owned by one specific object and Track objects should access file indirectly (so unique_ptr in owning object and mechanism to refer for indirect access).

What do you think?

i would slow down a little, all the changes are good and needed - but it seems that the svn adoption (patchset 3 and 4 waiting) is too slow to cope with your boths speeds - maybe have some sort of re-integration-phase like the linux-kernel-submit-windows - to keep svn/git as near as possible

what is the current svn stance on the big 3:

1. getting more C+11 into the code base: that will break SVN compatibility very fast and hard
2. remove of OS/2 code? is seems possible to use gcc4.9 and SDL2 (from main repo) according to "josch"
3. remove of win95/98 support (ScummVM still got it having both SDL1 and SDL2)

i think the fear of removing source is the biggest slowdown in patch acceptance - is there some sort of consence how to move forward

Vsync causes frame stuttering and audio-drop outs when backed by SDL2's hardware accelerated backends such as opengl and opengles2. This is true for:

• fullscreen and windowed modes
• resolutions ranging from original (postage-stamp) to hardware-scaled 1080p
• output modes texture(nb) and opengl(nb)
• aspect correction on or off
• scaler disabled or enabled (such as none, normal2x, or normal3x)

The only way vsync = true becomes useable is to avoid hardware acceleration such as using output = surface or renderer = software.

The following steps reproduce the issue on Linux x86-64, and include a pre-configured dosbox.conf.

Copy & paste:

cd /dev/shm
wget "https://github.com/dreamer/dosbox-staging/files/4000936/Jazz.Jackrabbit.Holiday.Hare.1995.zip" \
    -q -O - | busybox unzip -
cd "Jazz Jackrabbit Holiday Hare 1995"
wget "https://github.com/dreamer/dosbox-staging/suites/377829540/artifacts/876301" \
    -q -O tmp.zip \
    && unzip -p tmp.zip | xz -dc | tar -xv --strip 1 \
    && rm tmp.zip
./dosbox jazz.exe

Jazz Jackrabbit Holiday Hare 1995.zip

@dreamer , for the next revision to our workflow, you mentioned moving to --enable-debug.

Should we move to that across the board for all our CI jobs? I think we can, because the debug system rides on top of a fully-functioning DOSBox, so we're not giving up or excluding an "release" code-paths by enabling debug.

Also, I'm using these flags at home, which I find helpful: -Wall -Wextra -Wshadow -Wnon-virtual-dtor -pedantic; so we can considering adding them too.

We might also want to consider going even further to this recommended set:
https://github.com/lefticus/cppbestpractices/blob/master/02-Use_the_Tools_Available.md#gcc--clang

Some of them can be very helpful - however a handful only work with GCC 6 and greater. So perhaps for our usual CI builds we would differentiate flags based on GCC 5.x vs 6+.

Continuation of #31

We already have snapshots builds for Linux and Windows, macOS is the last remaining mainstream OS we want to add right now.

We need some macOS dev, who could implement packaging job in our CI and test if generated packages work correctly.

At Github there is a stand-alone version of MAME CHD for the formats v1-5
https://github.com/rtissera/libchdr

https://github.com/mamedev/mame/tree/master/src/lib/util (Look for CHD Files at top)
https://github.com/stenzek/duckstation/blob/master/src/common/cd_image_chd.cpp
https://github.com/hayate891/nulldcr/blob/master/plugins/ImgReader/chd.cpp
https://github.com/FCare/Kronos/tree/extui-align/yabause/src/libchdr

There are already a lot of emulators that read compressed CD-Roms (ISO, BIN, CUE with Audio) in CHD format Container and the use the standalone version.

I tried it myself but my skill in C ++ is not really good enough for that. I use and code only in MingW on Windows without Debug Features like Visual Studio. I begin in cdr_image.cpp for a LoadCHD and give up with Readsektor in Loadimage Routine (drive_iso.cpp) . :(

It would be great if Dosbox could use the compressed CHD format for CDRoms.
Overall, it would be an advantage since there is finally a standard for compressed CD-ROMs.

regards

Post-motem: for anyone reading this from the list of Closed issues, please skip to the bottom as the issue was caused by a copy-and-paste issue from Chromium.

Sorry @dreamer ; I looked at the CI results before the code and should have noticed that there should be more output.

From the output here - https://github.com/dreamer/dosbox-staging/commit/2bfae63f1f9e60854a1c0af005ed7378170f4a46/checks?check_suite_id=311563984

It looks like the two crawlers, git ls-files | xargs file, aren't getting off the ground, so we just get the version output from the two linters.

I pasted it into my local shell:

git ls-files| head -4
git: 'ls-files' is not a git command. See 'git --help'.

(git ls-files) | head -4
.github/workflows/analysis.yml
.github/workflows/linux.yml
.github/workflows/macos.yml
.github/workflows/windows.yml

I can't explain what's going on here just yet - is git detecting it's writing to a non-interactive stdout pipe, and disabling the command? Where as when I sub-shell it, I hide that fact from it and it happily runs?

(I'm only thinking this way because I've seen how tar will instantly return success if it detects output redirected to /dev/null tar -zxvf my.tar.gz > /dev/null; so to fool tar into actually doing the work you can pipe to cat and then redirect to /dev/null tar -zxvf my.tar.gz | cat > /dev/null)

LOG_MSG("MODEM: FIFO Overflow! (adds len %" PRIuPTR ")",_len);

GCC 32-bit: warning-free
GCC 64-bit: all of sudden doesn't know what it is, warning: unknown conversion type character 'l' in format

gcc -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast -fauto-profile=/Users/runner/runners/2.159.2/work/dosbox-staging/dosbox-staging/scripts/profile-data/gcc.profile -flto    -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast -fauto-profile=/Users/runner/runners/2.159.2/work/dosbox-staging/dosbox-staging/scripts/profile-data/gcc.profile -flto  conftest.c

error: /Users/runner/runners/2.159.2/work/dosbox-staging/dosbox-staging/scripts/profile-data/gcc.profile: Could not open profile: Unrecognized sample profile encoding format
1 error generated.

Performance data is captured from a Linux kernel and then converted to gcc coverage data, which should be portable to other instances of GCC. There seems to be a bug in this scenario, given GCC-8 and 9 under Windows correctly use the same gcc coverage file.

On the other hand, the FDO data (also from the Linux kernel) was read and used properly by Clang on macOS.

A couple approaches to address this:

1. flag this incompatible scenario (macos + gcc + fdo) asking users to not use FDO.
2. add a two-step build process on the Mac: --fprofile-gen followed by -fprofile-use. This will require someone willing to perform this process at least once on a Mac, and send us the coverage file. Then going forward, --fdo will use this file instead of the incompatible one I currently have.

Lately, I found an issue on my AmigaOS4 (PowerPC, BigEndian) build of DOSBox that game and apps which are used more than 256 colors fail with bad colors. The same issue happens on another PowerPC based OS: MoprhOS

Examples:
Hugi diskmag: http://kas1e.mikendezign.com/aos4/dosbox/dosbox_badcolors_hugi.jpg
The 11th Hour: http://kas1e.mikendezign.com/aos4/dosbox/dosbox_badcolors_11hour.jpg
TomRaider (only intro): http://kas1e.mikendezign.com/aos4/dosbox/dosbox_badcolors_tombraider.jpg
Screamer2: http://kas1e.mikendezign.com/aos4/dosbox/dosbox_badcolors_screamer2.jpg

With "screamer2" we have different exes: 2 which uses 256colros, and 2 which use 65k colors, so those which use 256 colors produce the correct result, and those which use 65k colors produce such a mess.

Now, I also create a thread on Vogon's there: https://www.vogons.org/viewtopic.php?f=32&t=71547

Where can be seen, that for example for MacOS PPC there are no such issues (that need to be rechecked, to be 100% sure. Also some LinuxPPC 32bit check wouldn't hurt as well).

MorphOS developer guessing that it can be an issue with 16 vs 32 modes because we use PC modes, so the grouping of bytes may be different. And he even a bit prove that theory (At least in half) by managing somehow to run test case (Hugi in our example, as it small, just 3mb, unpack & run)

• set desktop to 16bit (instead of 32 or 24)
• run DOSBox, run HUGI -> wrong colors
• alt+enter -> go to fullscreen -> wrong colors
• alt+enter -> go to window mode -> good colors 😀
• alt+enter -> go to fullscreen -> again wrong colors

So, something is broken somewhere, but we not sure where, and if our SDL port involved at all, or its DOSBox issues.

The auto-tools documentation regarding cleanup says the auto-generated make distclean target should remove files created during the ./configuration phase. Additionally, the document describes an auto-generated make maintainer-clean target, however this target does not exist in our case.

After ./autogen.sh && ./configure && make distclean, we see (using git ls-files -i -o --exclude-standard) that many extraneous files are not actually removed, contrary to the documentation:

• Makefile.in
• aclocal.m4
• autom4te.cache/output.0
• autom4te.cache/output.1
• autom4te.cache/requests
• autom4te.cache/traces.0
• autom4te.cache/traces.1
• compile
• config.guess
• config.h.in
• config.sub
• configure
• depcomp
• docs/Makefile.in
• include/Makefile.in
• install-sh
• missing
• src/Makefile.in
• src/cpu/Makefile.in
• src/cpu/core_dyn_x86/Makefile.in
• src/cpu/core_dynrec/Makefile.in
• src/cpu/core_full/Makefile.in
• src/cpu/core_normal/Makefile.in
• src/debug/Makefile.in
• src/dos/Makefile.in
• src/fpu/Makefile.in
• src/gui/Makefile.in
• src/hardware/Makefile.in
• src/hardware/mame/Makefile.in
• src/hardware/serialport/Makefile.in
• src/ints/Makefile.in
• src/libs/Makefile.in
• src/libs/gui_tk/Makefile.in
• src/libs/zmbv/Makefile.in
• src/misc/Makefile.in
• src/platform/Makefile.in
• src/platform/visualc/Makefile.in
• src/shell/Makefile.in
• visualc_net/Makefile.in

A fix for this issue with ensure the generated 'distclean' target removes those extraneous files and directories added by ./autogen.sh && ./configure

Continuation of discussion from: https://www.vogons.org/viewtopic.php?p=813297#p813297

Basically, dosbox-staging behaviour when losing focus is inconsistent and needs to be improved. In DOSBox 0.74-3 (and SVN) it was impossible to Alt-tab when in-game, so the problem was "hidden" this way (at the cost of usability).

The behaviour right now is different depending on OS, and inconsistent when losing focus, e.g.:

• on Windows 10 emulation is paused when the window loses focus
• on Linux it does not (when in windowed mode)
• on Linux video display is stopped, but emulation runs in the background (when alt-tabbing from fullscreen)

aaronp made a very good suggestion in Vogons thread:

You probably want this behavior to be configurable, because it depends on the game. I know I've seen this as an option in other emulators, so it's pretty standard. If you're playing an action game, you almost certainly want the emulation to pause. If you're playing a more slow-paced strategy or simulation game — SimCity for example — you may want the game to continue running in the background.

Also, you may need the emulator to continue running if you're playing some online game like Warcraft, though I've never experimented with that so I'm not sure.

I agree with this - but (at least according to documentation) there is already a pref for it:

[sdl]
priority = normal,pause

So, there are two actions for this issue:

1. Test if existing setting works the way it is supposed to in all situations.
2. Perhaps replace it with a different setting, which would be easier to discover, e.g.

[dosbox]
lost_focus_pause = never / always / fullscreen_only

?

The Steam Link is a streaming appliance running a custom embedded Linux by Valve. It has an ARMv7 processor and 512MB of RAM.

DOSBox could be compiled and packaged for this device which would allow games to be played directly on the hardware, rather than streamed.

See: https://www.exploitee.rs/index.php/Steam_Link

The Windows GCC-9.x build started failing (https://github.com/dreamer/dosbox-staging/runs/299604881) on commit: 4e65c8f.

This build turns on -std=c++11 despite this is commit not touching configure.ac or the Makefiles.

It's as if configure inspected the headers/used-features and decided to enable the -std=c++11 flag (not that this should cause any problems! It certainly is fine under the other environments).

Perhaps there's some broken code in the WIN32 path(s) that need some cleanup to make compatible with GCC C++11.

Making this issue, so I won't forget ;) Lack of this feature caused me a little bit of pain while testing #61 and this might prove very useful in the future.

DOSBox supports changing keyboard layout via .KL files https://www.dosbox.com/DOSBoxManual.html#KeyboardLayout which is a minor feature for game emulation, but it is important nonetheless. All fine and dandy, except nowadays it is basically impossible to find .KL files online. FreeDOS stopped shipping them, but keyboard layouts can still be downloaded as .KEY files: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/keyb_lay.html

KC.EXE is a program, that translates a .KEY file to a .KL file. It was/is shipped with FreeDOS, but it seems not to be part of base system any more (not sure). Can be downloaded e.g. from here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/2.0/

Fortunately, it can be just dropped inside DOSBox, used for creating a .KL file to be then loaded via built-in KEYB. It works.

It would be better if it worked out of the box somehow. FreeDOS includes GPL-compatible implementation of this program (and it's not complicated) - perhaps it should be included as a builtin in DOSBox? Or KEYB updated to work with .KEY files as well?

Windows-only paths used in .conf and .cue files are a major source of headaches for DOSBox users - it makes it impossible for .conf/.cue files written on Windows to be usable on other platforms (and also the other way around - it is possible to write .conf file usable on Linux, but unusable on Windows).

The solution to this is quite simple:

• convert Windows-paths to point to files on Linux filesystem; in general case it can't be done 100% reliably, but for DOS games (where original files are all case-insensitive already), it certainly can. Test implementation was already written for Boxtron in Python and can be found here: winpathlib.py
• for Linux->Windows - display warning/error whenever .conf file refers to path that is impossible on Windows (e.g. the paths including : character).
• use above-mentioned conversion in following features:
  • path to filesystem passed to MOUNT
  • path to file passed to IMGMOUNT
  • path to individual files in .cue file used for imgmounting

There is one prerequisite though: before implementing this, we need to have framework for unit testing, otherwise it will be hard to handle all corner cases without regressions.

First reported by in https://www.vogons.org/viewtopic.php?f=32&t=69497&sid=27cde34d8984ff40eb45bd942ad0114c&p=800263#p800263

User hail-to-the-ryzen said:

The CD-DA improvements allow for playback of CD audio in DOS, but the position on any audio track is not updated while playing. Tested with open cubic player that displays the track position and a cue/bin pair for the music.

I confirm this is an issue - tested with fe7600b, using Open Cubic Player (for DOS) with DOS/32A renamed to dos4gw.exe.

I tested Steam version of Worms (uses audio tracks in OGG/Vorbis):

$ ~/<path>/src/dosbox .
# in DOSBox prompt:

C:\>imgmount D "worms.cue" -t iso -fs iso
C:\>cd ocp
C:\>cp
(select D: and any track to start playing)

Track position is being updated in 0.74-3, so this is a regression.

This revealed a bug in the compiler:

configure:3587: checking whether the C compiler works
configure:3609: gcc -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast -fauto-profile=/home/runner/work/dosbox-staging/dosbox-staging/scripts/profile-data/gcc.profile -flto    -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast -fauto-profile=/home/runner/work/dosbox-staging/dosbox-staging/scripts/profile-data/gcc.profile -flto -flto=2  conftest.c   >&5
lto1: internal compiler error: in compute_working_sets, at gcov-io.c:1006

The build script should detect this faulty build type (gcc 5.4 + lto + fdo) and instruct the user to change one or more of those before proceeding.

https://www.vogons.org/viewtopic.php?f=41&t=43899
This patch is mandatory imo.

320x200 games x3 result in only 600 vertical resolution which is scaled to Desktop resolution and it is blurry.
I intentionally use the interpolated options like opengl with higher scaling factor to have properly interpolated image and maintain sharp pixels with correct aspect ratio,, this cannot be done with NB option which distorts the pixels.

Once we started counting compiler warnings in all the jobs and all compilers, we seem to be immediately hit by warnings numbers appearing inconsistent for some configurations.

At least one of causes behind this is: logs from several compilation jobs are being merged unreliably (not line-by-line), while count-warnings script depends on a warning being reported in a single line e.g.:

https://github.com/dreamer/dosbox-staging/runs/318215850#step:6:20 (227 warninigs)
https://github.com/dreamer/dosbox-staging/runs/318228442#step:6:20 (210 warnings)

The difference is in format (-9), deprecated-declarations (-7), and deprecated-register (-1). I started investigation with deprecated-register, and in the actual number of warnings is the same in both logs (9), but script does not count one occurence because of this:

https://github.com/dreamer/dosbox-staging/runs/318228442#step:5:786

It should look like this:

./render_templates_sai.h:188:4: warning: 'register' storage class specifier is deprecated and incompatible with C++17 [-Wdeprecated-register]
                        register int r = 0;
                        ^~~~~~~~~

but looks like this:

./render_templates_sai.h:188:4: warning: 1 warning generated.
'register' storage class specifier is deprecated and incompatible with C++17 [-Wdeprecated-register]
                        register int r = 0;
                        ^~~~~~~~~

(not sure why Clang decided to issue this warning for code compiled with C++11, but that's besides the point)

Text 1 warning generated/X warnings generated seems to be issued only on Clang.

What is the exact root cause? I'm not sure, candidates being:

• maybe we shouldn't merge stdout with stderr to compile build.log (but it seems to work ok for GCC)?
• maybe Clang some issues with buffering output? (I find it unlikely)
• maybe colorized output contributes to the problem (e.g. by triggering binary output in Clang or something)

Running compilation with -j1 is not acceptable in my opinion, and we avoided it so far only because top-warnings job happened to be GCC. The issue is not macOS specific, it happened to Clang on Linux as well.

@krcroft any ideas how to resolve this and keep th clang warnings count usable?