dosbox-x: init at v2023.10.06

[hughobrien]

Description of changes

Introduce dosbox-x, a fork of DosBox with a focus on emulating later stage systems such as Win98.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[OPNA2608]

Launches and can mount a PC-98 disk image. Keyboard input stops working every time I get to a game's title screen though - not sure if upstream bug, user/config error or smth else… 🙁

Trying to close it makes the window stop responding and prints a dialogue to the terminal, maybe this should have some dialogue program like gnome.zenity wrapped into its path for nicer behaviour?

[hughobrien]

maybe this should have some dialogue program like gnome.zenity wrapped into its path for nicer behaviour?

yad was supposed to handle that, let me try and replicate.

[OPNA2608]

Ah whoops, right. You'll need to use makeWrapper / wrapProgram then, i.e:

nativeBuildInputs = [
  makeWrapper
];

postInstall = ''
  wrapProgram $out/bin/dosbox-x \
    --prefix PATH : ${lib.makeBinPath [ yad ]}
'';

… or browse the source code, find the places where such binaries are listed and expand the relative, PATHed yad to an absolute, nix-expanded ${lib.getExe yad} to hardcode their locations.

[hughobrien]

You're right that worked wonderfully. Would you mind seeing if your input issue is present with DOOM?

$ cat doom.conf 
[dosbox]
title=Doom

[dos]
ver=7.1
hard drive data rate limit=0
floppy drive data rate limit=0

[autoexec]
mount a doom
a:
doom

$ dosbox-x -conf doom.conf

I used DOOM from here

[OPNA2608]

Builds on x86_64-linux, but I have some issues with the way this is written. Will also check how trivial adding Darwin support to this is.

[hughobrien]

Let me go through your points but would absolutely love some co-maintainership. Feel free to PR to the branch I have

[OPNA2608]

Disregard the input issue, SDL2 was just having a problem with my connected-but-not-paired controller. Input works fine on IBM & NEC systems.

[hughobrien]

With autoreconfHook I'm able to skip the patchShebangs and seemingly the in-tree SDL_NET.

Much cleaner build now. No need for file or which.

I also added ffmpeg for video capture as per the build instructions

[hughobrien]

video capture working: https://imgur.com/a/xF6jqtU

[hughobrien]

squashed

[OPNA2608]

I have a patch to fix building on Darwin: 0001-dosbox-x-Enable-on-Darwin.patch.txt

But I can't run the resulting binary on my 10.13 system:

dyld: Symbol not found: __objc_empty_cache
  Referenced from: /nix/store/09lrr2yf432m52ihv4m4gz4d27w2d4lw-dosbox-x-2023.09.01/bin/dosbox-x
  Expected in: /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
 in /nix/store/09lrr2yf432m52ihv4m4gz4d27w2d4lw-dosbox-x-2023.09.01/bin/dosbox-x

This might be because building this needs the 11.0 SDK for futimens, and newer versions of Carbon might pull in libobjc while my system-shipped one doesn't? I'm not sure.

I tried to change the #ifdef there so futimens isn't needed and the regular SDK can be used, but that gives a compile error that I don't understand:

clang++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I../../src/aviwriter "-DRESDIR=\"\"" -I../../src -I../../src/libs/mt32 -Wno-int-to-void-pointer-cast   -Wno-address-of-packed-member   -Wno-format-zero-length   -Wno-missing-field-initializers   -Wno-strict-aliasing   -Wno-implicit-fallthrough   -Wno-deprecated-declarations   -Wconversion-null   -Wsign-promo   -pedantic   -Wunused   -Wextra   -Wall   -I/usr/local/include -D_THREAD_SAFE -I/nix/store/4p0574y0y85qiw5m6pg826x3p5dr9ic6-SDL2-2.28.3-dev/include -I/nix/store/4p0574y0y85qiw5m6pg826x3p5dr9ic6-SDL2-2.28.3-dev/include/SDL2 -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source/vs/sdlnet/linux-host/include -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source/vs/sdlnet/linux-host/include/SDL -I/nix/store/q1x1h7n9d3yycf2j8z5q9aad96n2n5yg-freetype-2.13.1-dev/include/freetype2 -I/nix/store/s05ika6ljwa38c1r08l67dyk46sd24ih-glib-2.76.4-dev/include/glib-2.0 -I/nix/store/ag37hpnacgwm4ci76hdr38jkdl17yrdb-glib-2.76.4/lib/glib-2.0/include -I/nix/store/y28n2cs6v575ia8bn279pqzc8wqjmn9v-libslirp-4.7.0/include/slirp -I/nix/store/6np6h2dnkhjl08b61wybs1yn3m17kddz-ffmpeg-5.1.3-dev/include  -g -std=gnu++14  -O2 -msse  -Wall   -Wextra   -Wunused   -pedantic   -Wsign-promo   -Wconversion-null   -Wno-deprecated-declarations   -Wno-implicit-fallthrough   -Wno-strict-aliasing   -Wno-missing-field-initializers   -Wno-format-zero-length   -Wno-address-of-packed-member   -Wno-int-to-void-pointer-cast  -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source/vs/sdlnet/linux-host/include -I/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source/vs/sdlnet/linux-host/include/SDL  -c -o sdl_mapper.o sdl_mapper.cpp
sdl_mapper.cpp:5472:61: error: expected unqualified-id
    mainMenu.get_item("hostkey_mapper").check(hostkeyalt==0).set_text("Mapper-defined: "+mapper_keybind).refresh_item(mainMenu);
                                                            ^
1 error generated.
make[3]: *** [Makefile:442: sdl_mapper.o] Error 1
make[3]: Leaving directory '/private/tmp/nix-build-dosbox-x-2023.09.01.drv-0/source/src/gui'

---

Could you apply the patch file above + the following in a separate commit and let the OfBorg builder test if the produced binary works on Darwin? If the x86_64-darwin run manages to build dosbox-x but happens to have the same issue in dosbox-x.passthru.tests that I had, then just revert the commit & we'll consider Darwin support beyond our capabilities for now (unless someone with a newer Darwin box wants to figure this out).

  passthru.tests.version = testers.testVersion {
    package = finalAttrs.finalPackage;
    # Version output on stderr, program returns status code 1
    command = "${finalAttrs.meta.mainProgram} -version 2>&1 || true";
  }; 

[hughobrien]

Might be easier if I just add you as a collaborator on my fork from which this PR originates. Invite sent. Go nuts.

[OPNA2608]

building '/nix/store/h059zzii5si94nakmkfc026j247ps6k5-dosbox-x-2023.09.01-test-version.drv'...
DOSBox-X version 2023.09.01 SDL2, copyright 2011-2023 The DOSBox-X Team.
/nix/store/09lrr2yf432m52ihv4m4gz4d27w2d4lw-dosbox-x-2023.09.01
/nix/store/i5bcqyjax75zsp9zzvimdg9q0769dxpg-dosbox-x-2023.09.01-test-version

Darwin changes worked on OfBorg, I'lve squashed everything down.

[OPNA2608]

I've force-pushed some minor style changes, nothing functionality-related. I hope you don't mind.

Quite recently a new system for managing packages was introduced where stuff is supposed to be put under pkgs/by-name/<first-two-letters-of-package-name>/<package> instead (see explanation here). I've been too busy to really follow when it should be used and what its limitations are, but I think now that we're using pkgs.darwin.apple_sdk_11_0.callPackage for Darwin support instead of the regular pkgs.callPackage, we need to stick with the "old" pkgs/<categories>/<package> system? That's how I understand the limitations section of the readme? So AFAICT, this is done.

---

I can't run nixpkgs-review on the hardware I'm currently stuck on, but I've built it on aarch64-linux and tested it under Wayland. yad dialogue also works. LGTM, though I have no merge permissions & am now a co-committer.

[hughobrien]

I hadn't seen the new layout yet, thanks for sharing. Using nixpkgs SDL2 gives us wayland support IIRC, I think the vendored one didn't support it.

Were you able to test aarch64-darwin ?

I've force-pushed some minor style changes, nothing functionality-related. I hope you don't mind.

On the contrary, very glad of the help. Thanks again.

[OPNA2608]

(re-approving cus automation re-requested a review)

Were you able to test aarch64-darwin ?

I don't have apple silicon hardware so no. The version test passes on aarch64-darwin OfBorg though, so I assume it works.

[hughobrien]

bumped to latest release